[x264-devel] out-of-range motion vectors

Loren Merritt lorenm at u.washington.edu
Wed Aug 1 18:25:01 CEST 2007


On Wed, 1 Aug 2007, CAdevel wrote:

> By the way, I checked the standard on the limits on the motion vectors and I
> found that the horizontal motion vector range is limited to [-2048,2047,75]
> luma samples. However the vertical motion vector limit depends on the level
> (Table A.1 of the standard) and can be 64, 128, 256, or 512. I assume x264
> obeys these limits?

No. The default mvrange ("auto") does vary according to level, but as I 
said it's not enforced, only suggested.
Levels are purely informative anyway. I tend to ignore them except for the 
few most important limitations (resolution and bitrate).

> The remarks of Peter makes sense to me. When analyzing movies and finding
> these large motion vectors, I did not see any 'pictural' reason for these
> large vectors. It would be worthwhile investigating the idea of Peter of
> preventing drifting. However, this is where it stops for me. I am desinging
> multimedia processors and I found out that I have to count on large motion
> vectors any time.

In any block where there is no corresponding object in the previous frame, 
the output of motion estimation will be essentially random. Most of the 
time such blocks will be intra coded, but occasionally they find some 
feature of the previous frame thats worth something as a prediction.
Or maybe a macroblock is partitioned, and one partition is nicely inter 
predicted while another partition should be intra, but h264 only allows 
whole macroblocks to be intra or not, so the encoder has to pick some 
mv. Or intra might be prevented for other reasons: some CQMs screw with 
mode decision.

--Loren Merritt
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel


More information about the x264-devel mailing list