Which is the optimal motion search range in x264 and x265?

[Stears555]

Hello!

Which is the optimal motion search range in x264 and x265 for high quality encoding?

Thank you for your reply!

[poisondeathray]

There is no optimal. Depends on the content and situation. e.g high action content like sports, action movie may benefit more with a larger range than say a slow moving drama with little motion, static scenes. It's a tradeoff like most settings, and there are diminishing returns

[jagabo]

As big a number as you can stand. As poisondeathray pointed out, the bigger the value the longer it takes. And you get diminishing returns. The larger the frame the larger the range should be.

[Detmek]

For x264 default is 16, and also is maximum for --me dia and --me hex. If you want to use larger motion search range you need --me umh, at least. FullHD video might benefit from 24. Larger range than 24 will just slow down encoding without any real benefit. Or I didn't fing it on my test clips. But most of those are 720p.

Default for x265 is 57. I tried to reduce it to 24 and 16 using --me umh but I didn't gain much of compression speed. I didn't try larger values.

[jagabo]

In truth, x264 doesn't really pay much attention to --merange. Even if you set it to 4 it still uses much larger motion vectors. You can see this by using ffdshow to decode the video and enabling its Motion Vector Visualization option. And the difference in file size (crf encoding) between --merange=4 and --merange=64 (using umh) is typically less than 1 percent. And large values can have the reverse effect. So the setting isn't worth worrying about.

[Detmek]

--merange is not length of motion vectors. It is range for additional search for best motion vector. That is why you won't see much difference between 4, 16, 24 or larger values.

[jagabo]

--merange is not length of motion vectors. It is range for additional search for best motion vector.

In addition to what? Is there any control over the distance of the initial search?

[Detmek]

I am not an expert for x264 internals so I am not sure in which order options work but here some explanation on me and merange.

me

Set the full-pixel motion estimation method. There are five choices:

dia (diamond) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.

hex (hexagon) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than dia and hardly any slower, and therefore makes a good choice for general-use encoding.

umh (uneven multi-hex) is considerably slower than hex, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike hex and dia, the merange parameter directly controls umh's search radius, allowing one to increase or decrease the size of the wide search.

esa (exhaustive) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.

tesa (transformed exhaustive) is an algorithm which attempts to approximate the effect of running a Hadamard transform comparison at each motion vector; like exhaustive, but a little bit better and a little bit slower.
Useful link: http://forum.doom9.org/showthread.php?p=1544428#post1544428

merange

Default: 16

merange controls the max range of the motion search in pixels. For hex and dia, the range is clamped to 4-16, with a default of 16. For umh and esa, it can be increased beyond the default 16 to allow for a wider-range motion search, which is useful on HD footage and for high-motion footage. Note that for umh, esa, and tesa, increasing merange will significantly slow down encoding.

Extremely high merange (e.g. >64) is unlikely to find any new motion vectors that are useful, so it may very slightly decrease compression in some cases by picking motion vector deltas so large that they even worsen prediction of future motion vectors in the rare cases they're locally useful, making them worse than useless.

The effect is so small as to be near-negligible, though, and you shouldn't be using such insane settings.

There is also option mvrange:

Default: -1 (auto)

Set the maximum (vertical) range of any one motion vector in pixels. The default value is level-dependent.

For level 3.1+ it is 512 pixels. Blu-ray standard requires 511.75 if I remember correctly.

[Stears555]

I am not an expert for x264 internals so I am not sure in which order options work but here some explanation on me and merange.

me

Set the full-pixel motion estimation method. There are five choices:

dia (diamond) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.

hex (hexagon) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than dia and hardly any slower, and therefore makes a good choice for general-use encoding.

umh (uneven multi-hex) is considerably slower than hex, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike hex and dia, the merange parameter directly controls umh's search radius, allowing one to increase or decrease the size of the wide search.

esa (exhaustive) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.

tesa (transformed exhaustive) is an algorithm which attempts to approximate the effect of running a Hadamard transform comparison at each motion vector; like exhaustive, but a little bit better and a little bit slower.
Useful link: http://forum.doom9.org/showthread.php?p=1544428#post1544428

merange

Default: 16

merange controls the max range of the motion search in pixels. For hex and dia, the range is clamped to 4-16, with a default of 16. For umh and esa, it can be increased beyond the default 16 to allow for a wider-range motion search, which is useful on HD footage and for high-motion footage. Note that for umh, esa, and tesa, increasing merange will significantly slow down encoding.

Extremely high merange (e.g. >64) is unlikely to find any new motion vectors that are useful, so it may very slightly decrease compression in some cases by picking motion vector deltas so large that they even worsen prediction of future motion vectors in the rare cases they're locally useful, making them worse than useless.

The effect is so small as to be near-negligible, though, and you shouldn't be using such insane settings.

There is also option mvrange:

Default: -1 (auto)

Set the maximum (vertical) range of any one motion vector in pixels. The default value is level-dependent.

For level 3.1+ it is 512 pixels. Blu-ray standard requires 511.75 if I remember correctly.

Interestingly, the x265 codec use 60 ME.range as default setting

[somespirit]

lol vector of search no such thing in h.264

in Motion Estimation we just compare one frame with the next frame (or other) for differences, it is done by pixel to pixel compare from both frames, so we dont have any vectors of search .........

optimal variant is this:

Motion Estimation:
M.E. Range:8
M.E.algorithm: Diamond
Subpixel Refinement: this option is pointless better developers of x264 just to disabled it, so we can go with - 01 QPEL SAD

just understand, we have frames, frames consist of pixels not from subpixels, so for what is this Subpixel shit.........

[leghorn]

@somespirit:

Please spare us your repeated ranting at the (non-)existance of subpixel refinement in h264. AFAIC, and possibly others too, that option is there for some reason. And before going on with clamoring about h264 and those who have opinions different from yours, go to VideoLAN or komisar and check out the source code on that subject and see what it does.

[somespirit]

the reason that option Subpixel Refinement to be there is all you encoders to do pointless calculations with your CPUs, you can verify my words by using my settings for Motion Estimation and do encode with PSNR (or SSIM) calculation, then do the same encode with yours settings for ME, there will be no differences in PSNR results in both cases so ..........if you use my settings you will get very fast encoding speed but who care you have plenty time to make useless calculation with Subpixel Refinement

[Selur]

you can verify my words by using my settings for Motion Estimation and do encode with PSNR (or SSIM) calculate

With normal motion estimation settings:

1st pass:

"G:\Hybrid\x264.exe" --pass 1 --bitrate 500 --profile high --level 4.1 --direct auto --sync-lookahead 15 --qcomp 0.5 --no-mbtree --weightp 1 --aq-mode 0 --psnr --ssim --non-deterministic --stats "H:\Temp\test_21_17_51_1010_01.stats" --input-csp i420 --fps 25000/1000 --input-res 640x352 --output NUL -
raw [info]: 640x352p 0:0 @ 25/1 fps (cfr)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:3 Avg QP:24.00 size: 7641 PSNR Mean Y:44.49 U:51.51 V:52.98 Avg:45.90 Global:44.52
x264 [info]: frame P:168 Avg QP:20.22 size: 4241 PSNR Mean Y:46.94 U:52.03 V:53.17 Avg:48.13 Global:47.61
x264 [info]: frame B:258 Avg QP:22.29 size: 1157 PSNR Mean Y:46.71 U:52.02 V:53.07 Avg:47.92 Global:47.39
x264 [info]: consecutive B-frames: 6.3% 31.2% 28.0% 34.5%
x264 [info]: mb I I16..4: 69.2% 0.0% 30.8%
x264 [info]: mb P I16..4: 21.7% 0.0% 0.0% P16..4: 46.5% 0.0% 0.0% 0.0% 0.0% skip:31.8%
x264 [info]: mb B I16..4: 1.1% 0.0% 0.0% B16..8: 19.7% 0.0% 0.0% direct: 6.7% skip:72.6% L0:26.3% L1:41.0% BI:32.6%
x264 [info]: final ratefactor: 20.23
x264 [info]: direct mvs spatial:89.9% temporal:10.1%
x264 [info]: coded y,uvDC,uvAC intra: 18.7% 35.8% 2.4% inter: 11.9% 10.2% 0.1%
x264 [info]: i16 v,h,dc,p: 46% 22% 25% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 21% 18% 6% 6% 6% 6% 5% 6%
x264 [info]: i8c dc,h,v,p: 58% 16% 24% 2%
x264 [info]: Weighted P-Frames: Y:0.6% UV:0.0%
x264 [info]: SSIM Mean Y:0.9875346 (19.043db)
x264 [info]: PSNR Mean Y:46.784 U:52.018 V:53.112 Avg:47.989 Global:47.449 kb/s:481.93
encoded 429 frames, 663.06 fps, 481.93 kb/s
finished after 00:00:00.748

2nd pass:

"G:\Hybrid\x264.exe" --pass 2 --bitrate 500 --profile high --level 4.1 --direct auto --sync-lookahead 15 --qcomp 0.5 --no-mbtree --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 62500 --vbv-bufsize 78125 --psnr --ssim --non-deterministic --colormatrix bt470bg --stats "H:\Temp\test_21_17_51_1010_01.stats" --input-csp i420 --fps 25000/1000 --input-res 640x352 --output "H:\Temp\test_21_17_51_1010_02.264" -
raw [info]: 640x352p 0:0 @ 25/1 fps (cfr)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:3 Avg QP:17.67 size: 16360 PSNR Mean Y:49.37 U:54.21 V:56.02 Avg:50.56 Global:50.14
x264 [info]: frame P:168 Avg QP:20.07 size: 4058 PSNR Mean Y:47.52 U:52.69 V:53.92 Avg:48.73 Global:48.52
x264 [info]: frame B:258 Avg QP:21.73 size: 1299 PSNR Mean Y:47.68 U:52.74 V:53.87 Avg:48.87 Global:48.66
x264 [info]: consecutive B-frames: 6.3% 31.2% 28.0% 34.5%
x264 [info]: mb I I16..4: 2.0% 78.4% 19.7%
x264 [info]: mb P I16..4: 24.2% 0.0% 2.9% P16..4: 37.8% 13.4% 6.2% 0.0% 0.0% skip:15.5%
x264 [info]: mb B I16..4: 1.4% 0.0% 0.1% B16..8: 28.9% 5.9% 0.5% direct: 4.8% skip:58.5% L0:33.7% L1:48.1% BI:18.2%
x264 [info]: 8x8 transform intra:4.5% inter:47.2%
x264 [info]: direct mvs spatial:77.5% temporal:22.5%
x264 [info]: coded y,uvDC,uvAC intra: 19.3% 27.0% 3.2% inter: 9.9% 8.8% 0.0%
x264 [info]: i16 v,h,dc,p: 48% 21% 21% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 21% 47% 1% 1% 2% 1% 2% 2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 14% 19% 5% 8% 9% 7% 7% 5%
x264 [info]: i8c dc,h,v,p: 60% 16% 22% 2%
x264 [info]: Weighted P-Frames: Y:0.6% UV:0.0%
x264 [info]: ref P L0: 73.5% 18.0% 8.4%
x264 [info]: ref B L0: 86.5% 12.2% 1.3%
x264 [info]: ref B L1: 94.8% 5.2%
x264 [info]: SSIM Mean Y:0.9896333 (19.844db)
x264 [info]: PSNR Mean Y:47.627 U:52.728 V:53.902 Avg:48.827 Global:48.615 kb/s:496.86
encoded 429 frames, 518.12 fps, 496.86 kb/s
finished after 00:00:00.868
Created H:\Temp\test_21_17_51_1010_02.264 (1.0164 MB)

with subme 0:

"G:\Hybrid\x264.exe" --pass 1 --bitrate 500 --profile high --level 4.1 --direct auto --sync-lookahead 15 --qcomp 0.5 --no-mbtree --subme 0 --weightp 1 --aq-mode 0 --psnr --ssim --non-deterministic --stats "H:\Temp\test_21_17_58_3310_01.stats" --input-csp i420 --fps 25000/1000 --input-res 640x352 --output NUL -
raw [info]: 640x352p 0:0 @ 25/1 fps (cfr)
x264 [warning]: subme=0 + direct=temporal is not supported
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:3 Avg QP:24.33 size: 7173 PSNR Mean Y:44.26 U:51.07 V:52.55 Avg:45.65 Global:44.63
x264 [info]: frame P:153 Avg QP:20.64 size: 4436 PSNR Mean Y:46.28 U:51.74 V:52.80 Avg:47.51 Global:47.04
x264 [info]: frame B:273 Avg QP:22.88 size: 1242 PSNR Mean Y:45.95 U:51.50 V:52.48 Avg:47.19 Global:46.65
x264 [info]: consecutive B-frames: 3.0% 28.9% 22.4% 45.7%
x264 [info]: mb I I16..4: 68.3% 0.0% 31.7%
x264 [info]: mb P I16..4: 17.4% 0.0% 0.0% P16..4: 45.8% 0.0% 0.0% 0.0% 0.0% skip:36.8%
x264 [info]: mb B I16..4: 1.0% 0.0% 0.0% B16..8: 18.2% 0.0% 0.0% direct: 7.5% skip:73.3% L0:28.5% L1:42.8% BI:28.7%
x264 [info]: final ratefactor: 22.63
x264 [info]: coded y,uvDC,uvAC intra: 20.1% 31.8% 2.8% inter: 11.8% 10.2% 0.1%
x264 [info]: i16 v,h,dc,p: 48% 22% 21% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 21% 18% 8% 5% 6% 6% 5% 6%
x264 [info]: i8c dc,h,v,p: 45% 20% 29% 6%
x264 [info]: Weighted P-Frames: Y:2.0% UV:0.0%
x264 [info]: SSIM Mean Y:0.9860063 (18.541db)
x264 [info]: PSNR Mean Y:46.058 U:51.584 V:52.595 Avg:47.292 Global:46.770 kb/s:484.52
encoded 429 frames, 1873.36 fps, 484.52 kb/s
finished after 00:00:00.257

"G:\Hybrid\x264.exe" --pass 2 --bitrate 500 --profile high --level 4.1 --direct auto --sync-lookahead 15 --qcomp 0.5 --no-mbtree --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 0 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 62500 --vbv-bufsize 78125 --psnr --ssim --non-deterministic --colormatrix bt470bg --stats "H:\Temp\test_21_17_58_3310_01.stats" --input-csp i420 --fps 25000/1000 --input-res 640x352 --output "H:\Temp\test_21_17_58_3310_02.264" -
raw [info]: 640x352p 0:0 @ 25/1 fps (cfr)
x264 [warning]: subme=0 + direct=temporal is not supported
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:3 Avg QP:18.67 size: 15253 PSNR Mean Y:48.11 U:54.15 V:55.90 Avg:49.43 Global:49.07
x264 [info]: frame P:153 Avg QP:20.47 size: 4360 PSNR Mean Y:46.72 U:51.92 V:53.05 Avg:47.93 Global:47.65
x264 [info]: frame B:273 Avg QP:22.24 size: 1275 PSNR Mean Y:46.56 U:51.80 V:52.87 Avg:47.77 Global:47.46
x264 [info]: consecutive B-frames: 3.0% 28.9% 22.4% 45.7%
x264 [info]: mb I I16..4: 21.9% 51.3% 26.8%
x264 [info]: mb P I16..4: 23.8% 0.0% 0.7% P16..4: 38.7% 12.3% 6.4% 0.0% 0.0% skip:18.1%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 15.3% 3.8% 0.5% direct: 7.3% skip:72.5% L0:31.0% L1:43.5% BI:25.4%
x264 [info]: 8x8 transform intra:3.7% inter:44.4%
x264 [info]: coded y,uvDC,uvAC intra: 12.9% 24.7% 1.6% inter: 11.6% 11.6% 0.1%
x264 [info]: i16 v,h,dc,p: 56% 20% 17% 7%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 16% 32% 8% 5% 5% 5% 5% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 17% 20% 6% 4% 5% 5% 5% 5%
x264 [info]: i8c dc,h,v,p: 50% 19% 26% 5%
x264 [info]: Weighted P-Frames: Y:3.9% UV:0.0%
x264 [info]: ref P L0: 69.3% 21.0% 9.7%
x264 [info]: ref B L0: 87.9% 10.7% 1.4%
x264 [info]: ref B L1: 94.7% 5.3%
x264 [info]: SSIM Mean Y:0.9876592 (19.087db)
x264 [info]: PSNR Mean Y:46.632 U:51.859 V:52.959 Avg:47.840 Global:47.538 kb/s:494.60
encoded 429 frames, 1292.17 fps, 494.60 kb/s
finished after 00:00:00.370
Created H:\Temp\test_21_17_58_3310_02.264 (1.01176 MB)

-> I tried to verify your statement and from the looks of it your statement is simply wrong.

[ndjamena]

Subpixel Refinement: this option is pointless better developers of x264 just to disabled it, so we can go with - 01 QPEL SAD

subme
0. fullpel only
1. QPel SAD 1 iteration

with subme 0:

Actually, if SubMe is what I think it is, using it on videos that have been through a sharpening filter would most likely be a complete waste of time. Animation for instance. I guess, as always, it depends on the source and what's been done to it.

[Selur]

Here you go with subme 1:

1st pass:

"G:\Hybrid\x264.exe" --pass 1 --bitrate 500 --profile high --level 4.1 --direct auto --sync-lookahead 15 --qcomp 0.5 --no-mbtree --subme 1 --weightp 1 --aq-mode 0 --psnr --ssim --non-deterministic --stats "H:\Temp\test_new_23_45_17_7310_01.stats" --input-csp i420 --fps 25000/1000 --input-res 640x352 --output NUL -
raw [info]: 640x352p 0:0 @ 25/1 fps (cfr)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:3 Avg QP:23.67 size: 7989 PSNR Mean Y:44.61 U:51.49 V:53.10 Avg:46.00 Global:44.80
x264 [info]: frame P:153 Avg QP:20.01 size: 4346 PSNR Mean Y:46.93 U:51.88 V:53.00 Avg:48.10 Global:47.65
x264 [info]: frame B:273 Avg QP:22.26 size: 1281 PSNR Mean Y:46.48 U:51.78 V:52.82 Avg:47.69 Global:47.16
x264 [info]: consecutive B-frames: 3.0% 28.9% 22.4% 45.7%
x264 [info]: mb I I16..4: 64.9% 0.0% 35.1%
x264 [info]: mb P I16..4: 17.1% 0.0% 0.0% P16..4: 50.9% 0.0% 0.0% 0.0% 0.0% skip:32.0%
x264 [info]: mb B I16..4: 1.0% 0.0% 0.0% B16..8: 20.0% 0.0% 0.0% direct: 8.7% skip:70.3% L0:30.4% L1:44.9% BI:24.7%
x264 [info]: final ratefactor: 21.96
x264 [info]: direct mvs spatial:91.2% temporal:8.8%
x264 [info]: coded y,uvDC,uvAC intra: 19.7% 32.3% 2.7% inter: 12.0% 11.2% 0.1%
x264 [info]: i16 v,h,dc,p: 45% 22% 23% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 21% 17% 7% 5% 5% 6% 4% 6%
x264 [info]: i8c dc,h,v,p: 46% 20% 28% 6%
x264 [info]: Weighted P-Frames: Y:2.0% UV:0.0%
x264 [info]: SSIM Mean Y:0.9870862 (18.889db)
x264 [info]: PSNR Mean Y:46.626 U:51.816 V:52.887 Avg:47.824 Global:47.308 kb/s:484.29
encoded 429 frames, 1537.63 fps, 484.29 kb/s
finished after 00:00:00.310

2nd pass:

"G:\Hybrid\x264.exe" --pass 2 --bitrate 500 --profile high --level 4.1 --direct auto --sync-lookahead 15 --qcomp 0.5 --no-mbtree --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 1 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 62500 --vbv-bufsize 78125 --psnr --ssim --non-deterministic --colormatrix bt470bg --stats "H:\Temp\test_new_23_45_17_7310_01.stats" --input-csp i420 --fps 25000/1000 --input-res 640x352 --output "H:\Temp\test_new_23_45_17_7310_02.264" -
raw [info]: 640x352p 0:0 @ 25/1 fps (cfr)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:3 Avg QP:18.00 size: 16049 PSNR Mean Y:48.42 U:54.26 V:56.00 Avg:49.73 Global:49.42
x264 [info]: frame P:153 Avg QP:20.08 size: 4291 PSNR Mean Y:47.17 U:51.95 V:53.08 Avg:48.32 Global:48.12
x264 [info]: frame B:273 Avg QP:21.88 size: 1325 PSNR Mean Y:46.93 U:51.95 V:53.04 Avg:48.11 Global:47.87
x264 [info]: consecutive B-frames: 3.0% 28.9% 22.4% 45.7%
x264 [info]: mb I I16..4: 21.3% 51.4% 27.3%
x264 [info]: mb P I16..4: 20.0% 0.0% 0.6% P16..4: 45.9% 11.8% 6.3% 0.0% 0.0% skip:15.5%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 17.6% 3.3% 0.5% direct: 7.9% skip:70.0% L0:31.7% L1:45.4% BI:22.9%
x264 [info]: 8x8 transform intra:4.3% inter:49.3%
x264 [info]: direct mvs spatial:74.4% temporal:25.6%
x264 [info]: coded y,uvDC,uvAC intra: 14.3% 26.0% 1.9% inter: 11.3% 11.5% 0.1%
x264 [info]: i16 v,h,dc,p: 56% 19% 18% 7%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 16% 31% 8% 5% 5% 5% 5% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 32% 18% 19% 6% 5% 6% 5% 5% 5%
x264 [info]: i8c dc,h,v,p: 49% 20% 26% 5%
x264 [info]: Weighted P-Frames: Y:3.9% UV:0.0%
x264 [info]: ref P L0: 67.9% 21.1% 10.9%
x264 [info]: ref B L0: 86.4% 12.0% 1.6%
x264 [info]: ref B L1: 94.0% 6.0%
x264 [info]: SSIM Mean Y:0.9883245 (19.327db)
x264 [info]: PSNR Mean Y:47.022 U:51.966 V:53.077 Avg:48.197 Global:47.966 kb/s:497.19
encoded 429 frames, 1185.08 fps, 497.19 kb/s
finished after 00:00:00.408
Created H:\Temp\test_new_23_45_17_7310_02.264 (1.01706 MB)

-> can't reproduce your finding.

Actually, if SubMe is what I think it is, ...

I don't think it is.

using it on videos that have been through a sharpening filter would most likely be a complete waste of time.

unless you produce lots of artifacts through the sharpening: No.

I guess, as always, it depends on the source and what's been done to it.

-> please post a source (which isn't a bunch of single colored images) where, that allows others to "do encode with PSNR (or SSIM) calculation, then do the same encode with yours settings for ME, there will be no differences in PSNR results in both cases", because I tested with normal movie and cartoon content and I never got the same PSNR&SSIM values, when I change the subme setting.

Sorry, for being persistent, but if the statement you have given would be correct, that would be a bug in x264 or any other encoder which uses subpixel motion refinement. And yes, the subpixel motion refinement shouldn't yield much effect, but that's kind of to expect from a refinement step.

Cu Selur

Ps.: Also sub-pixel motion refinement/search only makes limited sense on super-resolution content (content which was upscaled and then sharpened, so if you use SD content, resize it to HD content, it's to be expected that sub-pixel search does not help much, but it still should at least a bit)

[ndjamena]

I haven't read up on it, and have no idea what I'm talking about but it sounds like it detects movement of less than one pixel. Animation is mostly solid colour to solid colour, movement of less than one pixel would equal blurring, which sharpening should remove. I don't know, if that's not what it is then that's just another thing I got wrong. Anyway, I never use SubMe of less than 9 and see no reason why I would do otherwise, even on sharpened animation.

It is possible to shift a block by a non-integer number of pixels, which is called sub-pixel precision. The in-between pixels are generated by interpolating neighboring pixels. Commonly, half-pixel or quarter pixel precision (Qpel, used by H.264 and MPEG-4/ASP) is used. The computational expense of sub-pixel precision is much higher due to the extra processing required for interpolation and on the encoder side, a much greater number of potential source blocks to be evaluated.

[jagabo]

The higher --me and --subme settings do deliver smoother edges on moving objects and more accurate small details. With most video the visible difference is pretty small. Whether it's worth the extra processing time is a matter of personal taste. I use --me=umh and --subme=8 (slow preset) for DVD sources since small defects will be more visible when upscaled to full screen -- and encoding time isn't very long anyway. With HD material I might use lower settings to speed things up.

[somespirit]

here are my test encodings (2 pass, logs are from second pass):

subme:1 Diamond ME Range=8

[Warning] [9/27/2014 10:16] Standard error stream
-[Information] [9/27/2014 10:16] raw [info]: 712x480p 6:5 @ 24000/1001 fps (cfr)
-[Warning] [9/27/2014 10:16] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[Warning] [9/27/2014 10:16] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[Information] [9/27/2014 10:16] x264 [info]: using SAR=6/5
-[Information] [9/27/2014 10:16] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
-[Information] [9/27/2014 10:16] x264 [info]: profile High, level 4.1
-[Information] [9/27/2014 10:17] x264 [info]: frame I:99 Avg QP:18.87 size: 21861 PSNR Mean Y:45.84 U:50.40 V:50.70 Avg:46.82
Global:46.18
-[Information] [9/27/2014 10:17] x264 [info]: frame P:1892 Avg QP:20.91 size: 11147 PSNR Mean Y:43.45 U:47.79 V:48.03 Avg:44.35
Global:43.63
-[Information] [9/27/2014 10:17] x264 [info]: frame B:6111 Avg QP:22.42 size: 5743 PSNR Mean Y:42.88 U:47.82 V:48.12 Avg:43.87
Global:42.95
-[Information] [9/27/2014 10:17] x264 [info]: consecutive B-frames: 2.9% 3.5% 9.1% 30.9% 24.1% 16.4% 5.0% 4.4% 2.1% 1.4% 0.3%
-[Information] [9/27/2014 10:17] x264 [info]: mb I I16..4: 17.1% 42.2% 40.7%
-[Information] [9/27/2014 10:17] x264 [info]: mb P I16..4: 12.9% 15.7% 0.0% P16..4: 26.3% 20.2% 12.7% 0.0% 0.0% skip:12.2%
-[Information] [9/27/2014 10:17] x264 [info]: mb B I16..4: 1.9% 4.0% 0.0% B16..8: 20.9% 14.5% 3.4% direct:12.9% skip:42.3% L0:46.8%
L1:43.6% BI: 9.6%
-[Information] [9/27/2014 10:17] x264 [info]: 8x8 transform intra:58.2% inter:39.1%
-[Information] [9/27/2014 10:17] x264 [info]: direct mvs spatial:97.8% temporal:2.2%
-[Information] [9/27/2014 10:17] x264 [info]: coded y,uvDC,uvAC intra: 40.0% 49.4% 12.8% inter: 18.3% 29.5% 1.4%
-[Information] [9/27/2014 10:17] x264 [info]: i16 v,h,dc,p: 71% 12% 7% 10%
-[Information] [9/27/2014 10:17] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 16% 14% 4% 5% 7% 5% 7% 6%
-[Information] [9/27/2014 10:17] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 21% 9% 8% 6% 7% 6% 7% 7%
-[Information] [9/27/2014 10:17] x264 [info]: i8c dc,h,v,p: 40% 20% 28% 13%
-[Information] [9/27/2014 10:17] x264 [info]: Weighted P-Frames: Y:13.1% UV:9.2%
-[Information] [9/27/2014 10:17] x264 [info]: ref P L0: 47.7% 13.2% 18.1% 9.6% 8.8% 2.3% 0.3%
-[Information] [9/27/2014 10:17] x264 [info]: ref B L0: 75.5% 15.7% 6.3% 2.4%
-[Information] [9/27/2014 10:17] x264 [info]: ref B L1: 92.5% 7.5%
-[Information] [9/27/2014 10:17] x264 [info]: SSIM Mean Y:0.9843560 (18.057db)
-[Information] [9/27/2014 10:17] x264 [info]: PSNR Mean Y:43.050 U:47.845 V:48.133 Avg:44.018 Global:43.125 kb/s:1381.40
-[Information] [9/27/2014 10:17] encoded 8102 frames, 165.12 fps, 1381.42 kb/s

subme:9 MultiHex ME Range=16

[Warning] [9/27/2014 10:21] Standard error stream
-[Information] [9/27/2014 10:21] raw [info]: 712x480p 6:5 @ 24000/1001 fps (cfr)
-[Warning] [9/27/2014 10:21] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[Warning] [9/27/2014 10:21] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[Information] [9/27/2014 10:21] x264 [info]: using SAR=6/5
-[Information] [9/27/2014 10:21] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
-[Information] [9/27/2014 10:21] x264 [info]: profile High, level 4.1
-[Information] [9/27/2014 10:23] x264 [info]: frame I:85 Avg QP:17.69 size: 24561 PSNR Mean Y:46.98 U:51.01 V:51.32 Avg:47.87
Global:47.37
-[Information] [9/27/2014 10:23] x264 [info]: frame P:1924 Avg QP:19.59 size: 10404 PSNR Mean Y:45.99 U:50.04 V:50.28 Avg:46.87
Global:46.10
-[Information] [9/27/2014 10:23] x264 [info]: frame B:6093 Avg QP:21.30 size: 5964 PSNR Mean Y:45.08 U:49.93 V:50.22 Avg:46.06 Global:45.08
-[Information] [9/27/2014 10:23] x264 [info]: consecutive B-frames: 2.5% 3.4% 9.3% 35.0% 24.7% 16.4% 3.9% 2.4% 0.8% 1.0% 0.7%
-[Information] [9/27/2014 10:23] x264 [info]: mb I I16..4: 18.4% 52.1% 29.4%
-[Information] [9/27/2014 10:23] x264 [info]: mb P I16..4: 18.0% 42.4% 0.0% P16..4: 16.4% 7.8% 2.7% 0.0% 0.0% skip:12.7%
-[Information] [9/27/2014 10:23] x264 [info]: mb B I16..4: 5.6% 12.0% 0.0% B16..8: 23.6% 11.4% 2.7% direct: 6.2% skip:38.5% L0:43.6%
L1:45.9% BI:10.5%
-[Information] [9/27/2014 10:23] x264 [info]: 8x8 transform intra:68.5% inter:67.2%
-[Information] [9/27/2014 10:23] x264 [info]: direct mvs spatial:97.7% temporal:2.3%
-[Information] [9/27/2014 10:23] x264 [info]: coded y,uvDC,uvAC intra: 51.3% 55.5% 14.5% inter: 15.8% 14.7% 0.5%
-[Information] [9/27/2014 10:23] x264 [info]: i16 v,h,dc,p: 38% 16% 9% 37%
-[Information] [9/27/2014 10:23] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 16% 15% 4% 6% 8% 5% 6% 5%
-[Information] [9/27/2014 10:23] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 36% 21% 8% 5% 6% 6% 6% 6% 6%
-[Information] [9/27/2014 10:23] x264 [info]: i8c dc,h,v,p: 30% 25% 25% 20%
-[Information] [9/27/2014 10:23] x264 [info]: Weighted P-Frames: Y:10.6% UV:7.7%
-[Information] [9/27/2014 10:23] x264 [info]: ref P L0: 61.6% 8.9% 17.1% 6.8% 5.0% 0.7% 0.0%
-[Information] [9/27/2014 10:23] x264 [info]: ref B L0: 83.9% 11.4% 3.5% 1.2%
-[Information] [9/27/2014 10:23] x264 [info]: ref B L1: 94.0% 6.0%
-[Information] [9/27/2014 10:23] x264 [info]: SSIM Mean Y:0.9899700 (19.987db)
-[Information] [9/27/2014 10:23] x264 [info]: PSNR Mean Y:45.314 U:49.966 V:50.245 Avg:46.267 Global:45.320 kb/s:1383.68
-[Information] [9/27/2014 10:23] encoded 8102 frames, 58.25 fps, 1383.70 kb/s

x264logs says that

-[Warning] [9/27/2014 10:21] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[Warning] [9/27/2014 10:21] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!

so PSNR is not valid metod for measure (when i try to use --tune psnr no calculation at all)

take a look at SSIM then (bigger value is better quality)

subme=1 SSIM Mean Y:0.9843560 (18.057db)
subme=9 SSIM Mean Y:0.9899700 (19.987db)

i can live with this little difference and i will have fast speed when do encoding

one more thing, here is some reading about x264 - http://veetle.com/index.php/article/view/x264

they say:

The most important settings

subme

Subme stands for sub-pixel motion estimation. When P and B frames describe changes from a previous frame, they can say something like "the actor moved his hand 10 pixels up". They can get even more precise by saying "the actor moved his hand 10.4 pixels up". Subme deals with these fractional changes in movement. Higher numbers increase edge crispness.

again i will tell we have frames with pixels (not with subpixels), how they calculate movement of 10.4 pixels, it is very wrong statement, actor hand is represented in frame by whole pixels and on all frames where we have that hand is the same only whole pixels

[Selur]

i can live with this little difference and i will have fast speed when do encoding

which is a totally other story then the claim that subme didn't do nothing.
Just wondering, how much of a difference does changing just the subme setting for you?

so PSNR is not valid metod for measure

Not totally correct, but probably not worth discussing.

[jagabo]

Just wondering, how much of a difference does changing just the subme setting for you?

adding --me=dia and --subme=1 to the slow preset will get you about 3x the encoding speed (if if there are no other bottlenecks) with CRF encoding. The bitrate will increase by ~10 percent too.

[Selur]

@jagabo: sorry, but
a. your settings are not the settings somespirit uses
b. don't really care about your speed

[jagabo]

@jagabo: sorry, but
a. your settings are not the settings somespirit uses

How do you know that?

[Selur]

educated guess + b. still stands

[Detmek]

take a look at SSIM then (bigger value is better quality)

subme=1 SSIM Mean Y:0.9843560 (18.057db)
subme=9 SSIM Mean Y:0.9899700 (19.987db)

i can live with this little difference and i will have fast speed when do encoding

Just to clarify, that "little" difference in SSIM values is 55,97%.

[Selur]

@detmek: most people will not follow you on this

for a bit more of clarification:
ssim: ((1-oldssim)/(1-newssim) - 1)*100 = % improvement
psnr: (newPSNR - oldPSNR) / 0.05 = % improvement

Cu selur

[Detmek]

Right, sorry. I was writing that post from my phone so I skipped formula. Hard to type.

[jagabo]

And it's a ridiculous statistical manipulation to exaggerate a near-invisible difference.

[Mephesto]

So merange and subme options are a conspiracy to make your CPU work hard uselessly. Brilliant. The developers of the best H264 implementation in existence know ****-all about their own product that they included it for precisely no reason but to make your computer generate bitcoins for them.

Reality check morons: it does effect quality. merange higher than 16 is for the most part useless for anything lower than 720p and a waste of time for anything higher than 720p. But there are certain kinds of popular videos that enjoy mass audiences that benefit greatly from higher merange and we're talking a resolution of only... 256x224. 8 and 16-bit graphics love the longer motion vectors. I crank it all the way up to 64 sometimes.

subme=1 SSIM Mean Y:0.9843560 (18.057db)
subme=9 SSIM Mean Y:0.9899700 (19.987db)

i can live with this little difference and i will have fast speed when do encoding

A 0.984 vs 0.990 SSIM is about a difference of almost 60%. If you look at 'em side by side I can guarantee your encode that got the quick failing grade looks like smeared garbage if you bothered to even look at it.

Newbs these days.

[somespirit]

@detmek: most people will not follow you on this

for a bit more of clarification:
ssim: ((1-oldssim)/(1-newssim) - 1)*100 = % improvement
psnr: (newPSNR - oldPSNR) / 0.05 = % improvement

Cu selur

i think something is wrong with these formulas because we can have psnr=20 and psnr=50 so 1 psnr difference gives 20% improvment, so 50-20=30 and it is 30x20%=600% improvements ha ha it is impossible, improvement have to be between 0 and 100%, 0% means 2 frames a totally diffrent and 100% they are identically

later i will look for ssim ......

and according formula for ssim it gives 55.97 improvement but let see what x264 logs say about QP of frames:

subme:1
frame I:99 Avg QP:18.87
frame B:6111 Avg QP:22.42

subme:9
frame I:85 Avg QP:17.69
frame B:6093 Avg QP:21.30

so where do you see 55.97% better video quality........
---------------------------------------------------------------------------------------------------------
let crarify what is video quality improvement, original video have 100% quality,

1-first encoding have 60% quality
2-second encoding have 70% quality

so 2-nd video have 10% improvement in video quality compared to 1-st encoding

[jagabo]

Of course it's back assward. Consider a video that gets 0.999995 and another video that gets 0.999999. By their calculations:

((1-0.999995)/(1-0.999999) - 1)*100 
((0.000005/0.000001)-1)*100
(5-1)*100
4*100
400

The bad video is 400 percent worse than the good one! It must look like total crap, huh? No, they're both nearly perfect.

If your boss told you he was giving you a 400 percent pay raise would you expect the calculation to be made like this?