[FFmpeg-devel] Question about parallelizing h264 decoding
Thu May 10 17:35:15 CEST 2007
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
> 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.
> 2) decode frames or even GOPs in parallel - this one i want to discuss a
> bit further.
> The I-frames of h264 are still independent of each other, and the
> P-frames only reference previous I- or P-frames, right?
> Could one then decode frames in parallel, if core #1 decodes I-frame of
> Gop #1, and core #2 decodes I-frame of Gop #2. After that core #2 could
> decode the first P-frame of Gop #2 (hence the B-frames of Gop #2 need
> pictures from Gop #1), while core #1 continues on Gop #1, and so on.
> My question is, could this work in theory or i am missing something? If
> it would work, do you see special problems here?
yes gops can be large (300 frames is common with mpeg4 in avi, i dunno about
h.264 gop sizes)
what i think is better is frame level parallelism
so that thread 1 decode frame 1 and updates a last_decoded_row variable
and thread 2 decodes frames 2 and checks if the needed reference is available
or if last_decoded_row is still too small in the later case the thread waits
a third thread could now work on frame 3 and so on ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel