regarding subme 0 with x264 ;)

[Selur]

x264 doesn't even expose subme 0 as a choosable option!
source: http://forum.doom9.org/showthread.php?p=1155664#post1155664

Since I thought subme 0 was disabled since "the huge bitrate penalty wasn't worth the speed" (see changelog r86), I always assumed this ment subme 0 was removed, but reading the statement form DDark Shikari it sounded like it was just hidden.

Curious about the speed and bitrate penalty I just tested subme 0 vs. subme 1 and subme 1 even was faster,...
sing the following x264 call: (just changed subme to 1 for the subme 1 tests)
x264 --qp 18 --level 3 --ref 1 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 1 --qpmax 51 --qpstep 16 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --direct-8x8 -1 --partitions none --me dia --subme 0 --no-chroma-me --no-dct-decimate --deadzone-inter 11 --deadzone-intra 11 --threads auto --thread-input --no-cabac --no-deblock --no-psnr --no-ssim --progress --fps 29.97 --output "test.mp4" - 720x480
subme 0 gave an average of 266.8 fps (did six runs)
and
subme 1 gave an average of 268.2 fps (did six runs)
using a Q9450 on standard 2.67Ghz and always (for subme 0 and 1) produced the same bitrate.

So is this normal? :)

Cu Selur

[Dark Shikari]

As I said, it isn't exposed to the user--that is, the encoder.c parameter validation code will clip subme to between 1 and 7. If this code is removed, subme 0 will work because there is a "subme 0" setting still in existence in the me.c qpel/hpel array.

Subme 0 would disable the qpel motion search completely (not even a single iteration). This would save about ~750 clocks per macroblock (rough estimate) versus subme 1, but will likely be offset a good bit by the speed cost of writing the larger number of residual bits to the bitstream.

[Selur]

Ah, okay. Thanks for the explanation.

Cu Selur

[Sharktooth]

uhm... it could be good for a fast lossless preset though...
why not exposing it?

[Dark Shikari]

uhm... it could be good for a fast lossless preset though...
why not exposing it?It would probably slow down lossless because the increased bitrate requirement matters so much more speed-wise in such a case.

[Sharktooth]

even using CAVLC instead of CABAC?

[Dark Shikari]

even using CAVLC instead of CABAC?Not sure, probably not in that case. It'd have to be tested and could be source-dependent.