Re: Parallel processing for Theora?

Id Kong wrote:
> The problem with starting with a parallel decoder is that decoding is
> much easier.  Correct me if I'm wrong but decoding requires much less

That depends on resolution and bitrate, of course. 400 Mbps 2160p files
are quite difficult to decode in real time (with current hardware). But
the point was that a good bit of the work needed to make a parallel
decoder would also be required to make a parallel encoder anyway, so
it's a good first step. Especially as the code is much simpler.

> not an outrageous idea but I think it will be better to leave threading
> to the client and support parallelism through the API much like Vorbis.

This is non-trivial to export, and there is a cost to doing it that way.
There are too many complex data dependencies to make exporting
within-frame parallelism a good idea. However, once you go to
multi-frame parallelism, you have to start changing the way rate control
works (and worse, _exposing_ how rate control works to the client,
because you may now have to dump frames that are in the process of being
encoded and start over, e.g., when you decide to insert a keyframe).
This could maybe be done for unconstrained two-pass with reasonably
minimal pain, but as I've already said, that's not the interesting case.