[FFmpeg-devel] Question about parallelizing h264 decoding

[Guillaume POIRIER]

Hi,

On 5/14/07, Thorsten Jordan <tjordan at macrosystem.de> wrote:
> 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?

AFAIK, yes.


> 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.

Indeed.

Guillaume

-- 
Rich, you're forgetting one thing here: *everybody* except you is
stupid.
    M?ns Rullg?rd