[x264-devel] motion vectors and threads

Loren Merritt lorenm at u.washington.edu
Fri Jan 18 21:54:36 CET 2008


On Fri, 18 Jan 2008, Christian Bienia wrote:

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

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

--Loren Merritt



More information about the x264-devel mailing list