[FFmpeg-devel] Question about parallelizing h264 decoding

[Thorsten Jordan]

Loren Merritt schrieb:
> On Fri, 11 May 2007, Thorsten Jordan wrote:
>> Michael Niedermayer schrieb:
>>
>> With row do you mean row of macroblocks?
> What matters from the perspective of the thread doing motion compensation 
> is which rows of pixels have been decoded. But yes, the variable would be 
> updated only when a row of macroblocks finishes.
ok, that makes the idea more clear, thanks.

>> 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?
> 
> The entire bitstream is CABAC (except for headers, which take negligible 
> time).
Well, is it then true, that we can decode CABAC of the next block in
advance and parallel? If we could identify the CABAC coded blocks with
exact length we could defer decoding to a second thread, which would
give the decoded stream as array of bytes. The disadvantage would be
that parallelism is limited to 2 cores, but on the other hand, for HDTV
h264 decoding (which is the most demanding task at the moment) 2 cores
of current CPUs would be enough.
A further advantage would be that the changes to h264 decoder code would
be rather small.

-- 
Best regards, Thorsten