[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