[x264-devel] Re: Motion Estimation in X264

Loren Merritt lorenm at u.washington.edu
Tue Nov 14 00:00:07 CET 2006


On Mon, 13 Nov 2006, Måns Rullgård wrote:
> Mathieu Monnier <manao at melix.net> writes:
>
>>> 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.
>>
>> Indeed, but there's a difference between motion estimation, and actual
>> encoding. You can very well search the motion between two non-encoded
>> frames, then encode the frame with the found motion vectors and the
>> actual reconstructed references. It may even be worthwhile at low
>> bitrates when the frames get really distorted by the encoding
>> process. I'm especially thinking of the mpeg2/4 blocking at high
>> quantizer, which tends to bork motion estimation. AVC, in that
>> regards, suffer much less thanks to the inloop deblocking.
>
> Doing the motion search against the reconstructed picture should in
> most cases give a smaller residual, requiring fewer bits to encode.  A
> good match found against the original picture need not be even close
> to optimal with the reconstructed values.

As long as the mvs used in compression they match the mvs of the objects 
represented by the video, any artifacts in residual compression can be 
mistaken for actual texture. But if the compression mvs and the real mvs 
don't match, then the residual artifacts are much more blatant. So it may 
look better to use the real mvs even if the quality of each individual 
frame is reduced.
It looks very disconcerting to see the texture on an object wander around 
randomly while the object moves coherently.

--Loren Merritt


More information about the x264-devel mailing list