[x264-devel] motion vectors and threads

[Christian Bienia]

Loren,

Thank you very much for your response. I have two follow-up questions.

> > I'm trying to understand the data dependency between threads a little
> > better. It seems x264_fdec_filter_row produces the shared data, and the
> > motion block computation consumes it. What data exactly is exchanged
> > between threads?
> >
> > The point is that motion compensation needs the image data of the
> > reference frame. This, however, is an input which is available at
> > program start. Why the need to wait for the encoding output of the
> > reference frame?
>
> The encoder's motion compensation needs the same data that the decoder
> will see. That means the decoded frames, not the input frames. Otherwise,
> quantization error would accumulate without bound and turn the image into
> garbage after just a few frames.
> Motion _estimation_ could use the input frames, at some loss in precision
> bcause it's not working from the same data that will be used for motion
> compensation. But you'd still have to wait for the reference before
> finally encoding the macroblock.

I see, that makes sense. I also found the following explanation in file 
threads.txt:

"To allow encoding of multiple frames in parallel, we have to ensure that any 
given macroblock uses motion vectors only from pieces of the refer
ence frames that have been encoded already. This is usually not noticeable, 
but can matter for very fast upward motion."

How come that the motion vectors of the reference frame are also required? Is 
this an optimization due to correlation of motion vectors, or is it a 
fundamental requirement?


> > Furthermore, B-Frames have two reference frames. Shouldn't the encoder
> > hence check the encoding progress of two frames? It seems only one frame
> > is checked.
>
> It checks the progress of all of the reference frames. See the
> x264_frame_cond_wait loop in analyse.c. Checking multiple refs is usually
> redundant, because each of the refs depends on the previous, but there are
> some sequences of frame types that might violate that, so checking all is
> easiest.

I found it, thanks for the pointer. AFAIK B-Frames are sandwiched between 
their reference frames, so there must be some sort of scheduler which makes 
sure that frames which will be used as reference frames are encoded before 
any frames inbetween which will refer to them. Where is that implemented?

Thanks again for your help.

- Chris