[FFmpeg-devel] Question about parallelizing h264 decoding

[Thorsten Jordan]

Michael Niedermayer schrieb:
> Hi
> 
> yes gops can be large (300 frames is common with mpeg4 in avi, i dunno about
> h.264 gop sizes)
well it is variable, but for our case we want to decode TV broadcasts,
that have one GOP per second at least...

> 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 ...
With row do you mean row of macroblocks?

About separating CABAC to other CPU: is the part of the h264 bitstream
that has cabac encoded data identifyable that easily, so it can be
pre-read? I mean could the decoder know that the next N bits are part of
cabac and could defer them? Or depends the range of cabac-related bits
in the encoded bit stream on some bits that have to be decoded before?

As Loren said, cabac can't be multithreaded well for small blocks or
single operations, but is it possible to parallelize larger blocks

sorry, i have only little knowledge about h264...

btw., i did some profiling runs with valgrind/callgrind on newer,
cpu-demanding h264 streams, if anyone is interested in data, mail me
(tjordan at macrosystem.de)

-- 
Regards, Thorsten