[x264-devel] Re: Motion Estimation in X264

[Måns Rullgård]

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.

>> 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.
>
> I hope nobody is that desperate for speed. If so, then let him use
> ASP, instead of crippling a codec :)

I was merely suggesting a situation where there could be some
advantage in using the original picture for reference.  I didn't
recommend that anyone actually do this.

FWIW, I know people who are desperate enough for speed that they
disable the loop filter when decoding H.264.  Apparently the result is
still watchable to these people.

-- 
Måns Rullgård
mru at inprovide.com

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html