[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