[x264-devel] Re: Motion Estimation in X264

Loren Merritt lorenm at u.washington.edu
Mon Nov 13 22:08:26 CET 2006


On Mon, 13 Nov 2006, Måns Rullgård wrote:
> Panagiotis Issaris <takis.issaris at uhasselt.be> writes:
>>
>> On Mon, Nov 13, 2006 at 10:04:02AM -0500, Guy Bonneau wrote:
>>> I was wondering about the reference buffers used in the motion
>>> estimation algorithm for the Test Model of h264 as well as
>>> X264. Does X264 and the Test Model JM10.1 used the reconstructed
>>> reference Y buffer or the original reference Y buffer to search for
>>> Motion Estimation. I know H263 uses the reconstructed reference Y
>>> buffer but I think Mpeg2 used the original reference Y buffer. I
>>> know all specifications don't provide guidelines regarding this
>>> matter. So I was wondering what was decided when implementing the
>>> JM10.1 and X264.

The original question is sane, for reasons explained by Mathieu.
x264 and JM use the reconstructed reference frame for motion estimation.
Except that x264's 1pass ratecontrol methods first run some fast motion 
estimation on the unencoded frames to estimate complexity, but those are 
not the mvs eventually used for compression.

>> Weird, I thought you'd always need to use the reconstructed frame,
>> as that's what the decoder will base it's prediction on. I thought
>> errors would accumulate otherwise.
>
> If you are encoding with high quality and frequent I-frames, I guess
> you could get away with using the original picture for reference.  It
> would save a few cycles in the encoder avoiding the reconstruction
> step.

Even with short gops + B-frames, it's not viable.
At high qp (>= 10), you get lots of blocking as the encoder desyncs the 
low frequencies. At low qp (<= 20) you get lots of flickering as the 
encoder desyncs the details. Since those ranges overlap, no quality-level 
other than lossless is safe.
Note: in the limit of all I-frames, the reconstruction doesn't matter... 
but that's ugly anyway. It takes significantly lower qp to achieve 
transparency in an intra-only encode than with inter-frames.

--Loren Merritt
-------------- next part --------------
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(revision 600)
+++ encoder/encoder.c	(working copy)
@@ -924,7 +924,12 @@
 {
     int i;
 
-    x264_fdec_deblock( h );
+    for( i=0; i<3; i++ )
+    {
+        h->mc.plane_copy( h->fdec->plane[i], h->fdec->i_stride[i],
+                          h->fenc->plane[i], h->fenc->i_stride[i],
+                          h->sps->i_mb_width*16>>!!i, h->sps->i_mb_height*16>>!!i );
+    }
 
     /* expand border */
     x264_frame_expand_border( h, h->fdec );


More information about the x264-devel mailing list