x264 Maximum motion vector search range

[Sirber]

What is it's minimum and maximum?

[Manao]

Sensible values ? No check is done in x264 itself, but some arrays' sizes depend on this value. In 'esa' me mode, a too high value will make the encoding too slow to be useful.

Looking at the code, if it's strictly under 16, it will b0rk ( the encoding process will occur, but don't expect anything good nor sensible from the result )

So, all in one, i'd say 16 - 64 are fairly sensible values.

[celtic_druid]

mencoder I think from memory allows 4->64.

[Sirber]

Ok. I will force between 16 and 64.

Would 64 be a good default in umh mode?

[Sharktooth]

16 is enaugh 99.9% of the times.

[Sirber]

I tested 32 and 64. They aren't slower. I'm defaulting to 64.

[Sharktooth]

are you sure?!?

[Sirber]

on my 500 frame test, using 16, 32 and 64 took the same 4 minutes.

[allclone]

I just started messing with the motion vector too, and have tryed 32/64 with umh on a couple of videos and im getting about the same fps for encoding as I would with the default 16, if I understand what everyone is talking about.

[Manao]

Sirber : try with --me esa, you'll see the difference

[Sirber]

using --me umh. I know esa bring everything speed down :p

@allclone

Exactly what we are talking about :)

[Manao]

Sirber : i meant that merange effect can be easily noticed with esa, whereas with umh & dia, it can't ( because in these case it's the max number of iterations, and the average number of iteration must be around 5 or 6 ). You would notice it if you set it to 4 or 5.

[Sirber]

ok. But, not noticing it in dia and umh is great isn't it? Means we can use it!!! :D

[berrinam]

ok. But, not noticing it in dia and umh is great isn't it? Means we can use it!!! :D
It also means it won't have much effect on the quality.

[akupenguin]

x264 foo_640x368.yuv -r 3 -b 3 --me hex --merange 16
x264 [info]: PSNR Mean Y:42.25 U:46.88 V:47.53 Avg:43.35 Global:42.99 kb/s:805.9
encoded 1000 frames, 13.28 fps, 806.13 kb/s

x264 foo_640x368.yuv -r 3 -b 3 --me umh --merange 16
x264 [info]: PSNR Mean Y:42.24 U:46.86 V:47.51 Avg:43.34 Global:42.98 kb/s:797.4
encoded 1000 frames, 9.37 fps, 797.59 kb/s

x264 foo_640x368.yuv -r 3 -b 3 --me umh --merange 32
x264 [info]: PSNR Mean Y:42.24 U:46.85 V:47.50 Avg:43.33 Global:42.98 kb/s:795.9
encoded 1000 frames, 8.00 fps, 796.12 kb/s

x264 foo_640x368.yuv -r 3 -b 3 --me umh --merange 64
x264 [info]: PSNR Mean Y:42.23 U:46.84 V:47.48 Avg:43.32 Global:42.97 kb/s:796.3
encoded 1000 frames, 5.75 fps, 796.46 kb/s
You don't notice this?

... And dia and hex cap merange at 16. It slightly reduces code complexity, and if the real mv is more than 16 pixels from the prediction, they won't find it anyway.

[Sirber]

hum... odd... I'll retest.

[Doom9]

so going above 32 only yields lower speed, lower psnr and higher bitrate.. not a pleasant thing.

I have one thing on the stats: line 2 out of 3 shows a different bitrate than line 3 out of 3.. why that difference?

[akupenguin]

The upper line is only video slices.
The lower line includes pps/sps and muxing overhead.

[DeathTheSheep]

so going above 32 [ME range with UMH estimation] only yields lower speed, lower psnr and higher bitrate..

So it would seem from this test, but this is not an entirely accurate assumption. A single test does not prove anything. In fact, I have found much evidence on the contrary; it all depends on the source material. A ME range of 64 is slightly beneficial (quality-wise) on low framerate, erratic-motion, anime content.
Because I am certain of my convictions, I picked an entirely random animation sample on my computer to test. It consists of 3306 frames of anime at about 12fps. I encoded at quant=36. I will host the result files shortly.

My results (range 64 vs. range 32):
1. Filesize was smaller (1,231,862 vs 1,234,412)
2. PSNR was very slightly higher (31.24 vs 31.23)
3. Encoding time was a bit longer (6:21 vs 5:10).

Output files will be here when available:
http://farmz.net/xsquared/ME32.avi
http://farmz.net/xsquared/ME64.avi

Cleary, this was not a sample indicative of the true potential of UMH_ME64, but it was a random sample designed all the same to show that different content (and different tests :)) can yield different results.

Likewise, encoding speed varies based on the complexity of the source material. Still scenes go equally fast, but the more complex and erratic the motion becomes, the more the higher ranges show slowdown.

Additionally, UMH in and of itself isn't the best way to test ME range efficiency. The only certain way is an exhaustive search, which I am currently in the process of performing on the same clip for comparison purposes.

DTS

[redfordxx]

I have one question concerning ME impact on Bframes:

I have seen examples and recommendations to make 1st pass with lower quallity ME to save the time. Please tell me what if some of following is incorrect.
1. Base of B-frames is good references to the other frames. If there is not possible good reference, encoder decides not to make Bframe and writes this decission to statsfile
2. In second pass it is not possible to change this "decission"
Conclusion: Reducing ME in 1st pass decreases the quality of the second pass which can't be fully recovered even with ESA. Just to understand how x264 works.