[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