[FFmpeg-devel] Question about parallelizing h264 decoding

Loren Merritt lorenm
Thu May 10 18:13:37 CEST 2007


Frame level parallelism is best.

On Thu, 10 May 2007, Reimar D?ffinger wrote:
> On Thu, May 10, 2007 at 05:01:00PM +0200, Thorsten Jordan wrote:
>
>> since it seems that the performance of a single core is not enough for
>> full HDTV decoding, one obvious alternative is multithreading on SMP
>> systems.
>> I know that the current h264 decoder can't decode multithreaded, but i
>> want to discuss some ideas how this could be done.
>>
>> Two choices come to my mind:
>>
>> 1) decode slices in parallel - problematic, because intra-frame
>> references and many data dependencies, also because of difficult
>> parallelization of cabac decoding etc.

This is the easiest method. There are no data dependencies, and you just 
run several independ cabac decoders. But it can only work if the stream 
was encoded with slices, so if you don't control the encoder settings it 
will fail often.

> Hmm. It might be an obviously bad idea for those who actually have
> experience, but how about an idct (or other dsputil stuff) implementation
> that just submits the task to different threads + a barrier operation
> that waits for the all the threads to complete at the end?
> Of course it is not optimal (lots of overhead and probably bad cache
> use) but it doesn't sound quite as invasive and easy to extend to e.g.
> Cell...

Can't extend past 2 threads, since as much as 50% of the cpu time is spent 
in non-dsp stuff. Of course, if you can find a way to reduce those 
computations that's even better than threading them, but I'm not too 
optimistic.

--Loren Merritt



More information about the ffmpeg-devel mailing list