Re: Parallel processing for Theora?

Hi Id,
do you have a real email address I can contact you on ? If you don't
mind, I would like to ask you some questions about multithreading
support in general.

Thanks,
Salsaman.


http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman




On Sun, Mar 21, 2010 at 7:21 PM, Timothy B. Terriberry
<[email protected]> wrote:
> 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.
> _______________________________________________
> theora-dev mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/theora-dev
>