View Full Version : (x264) Perhaps a ME range bug?
Farfie
27th September 2012, 00:36
Hello there! New around here; this is my first post.
I'm a hobbyist encoder, and I mostly do anime, but a decent amount of film too. Probably 70/30.
Anyway, let me get a bit detailed here. Upon seeing the new 'K' anime PV, and it having a large size for it's length (244MB for 2.5mins), I decided to encode it myself.
After fiddling with CRF and being surprised with how big x264 always ended up making the file, I said oh well, and I then decided to try out different ME ranges on the source since it was very actiony (plus I just love to test different values of things all the time :)), and I could get a feel for how much a higher ME range really helps.
Anyway, here's the weird thing I ran into:
http://puu.sh/18WQg
x axis is ME range, y axis is resulting file in bytes. As you can see, the 24 is even bigger than 16. I didn't see how that could be possible in any way, and at first I shrugged it off, but then I decided to post about it. Maybe to possibly find a bug, or learn something in the process :)
Encoder used is JEEB's 64bit 10bit output version r2216+698 b3c1019
I would try an encode with the one from x264.nl, but I believe I would have to use something other than AQ3, though that might not necessarily be a bad thing, since if the results came out "more correctly", perhaps it could be a bug with AQ3 instead. But first things first I suppose. And speaking of settings, if you would like to see settings used I can post that too of course.
Glad to be here! Long time lurker.
LoRd_MuldeR
27th September 2012, 00:42
Same mistake as always:
CRF mode does not give 100% identical quality for the same CRF value on different sources, it only gives approximately the same quality. And even that only as long as you don't change other influential settings!
As soon as you change other settings, you will have to re-adjust your CRF value ;)
In other words: You are most likely comparing files of different quality, because there is absolutely no guarantee that CRF value X still gives the same quality after messing the with ME Range option!
A better way to do the test would be to encode with different ME Range settings, but in 2-Pass mode and with the same target bitrate. Then you'd get files of identical (average) bitrate that you can compare visually.
But: Experience shows that increasing ME Range over the default doesn't give much of a noteworthy improvement. Even the "veryslow" and "placebo" presets of x264 use "only" 24, everything below sticks with 16.
(Keep in mind that ME Range does not limit the maximum length of a motion vector, it only limits the search range around the predicted motion vector)
mandarinka
27th September 2012, 00:54
However, merange only affects the motion search quality. It shouldn't influence stuff in the same way that bframes, aq, psyrdo and other options like that do. In other words, the difference is most likely really due to a better compression, I'd say.
So IMHO, the difference of about 20% (between 16 and 64) *is* surprising - assuming the encoding parameters were really constant except for merange.
Didée
27th September 2012, 02:14
@mandarinka
Check your calculator. The difference is not 20%. That would be a bit too much, really.
ME64/ME24 : (90'200'000)/(92'400'000) =~ 0.976, i.e. the diff is 2.4%.
ME32/ME24 : (91'500'000)/(92'400'000) =~ 0.9902, i.e. a diff of 1%.
mandarinka
27th September 2012, 03:09
Oh you are right, I made a little mistake when juggling with those zeros. Funny thing is that just this evening I was bitching at my little sister for not converting properly between units like centimeters, milimeters, meters etc :D
/Well, this wouldn't happen if O.P. didn't use a chart with non-zero base. Maybe he studied marketing./
Farfie
27th September 2012, 03:56
Well this is interesting, I didn't expect such replies and in such a matter of time.. but it seems like I wasn't clear enough. Either that or perhaps Muler is being overly helpful and I'm taking it as him not understanding fully. Let me try again, and I'm sorry if your answer ends up being the same, I guess I have some learning to do :o
Anyway, it's the same source file for all the encodes, exactly the same settings, same CRF etc., with the only change being the ME range. It was just a little test I was conducting since it seemed like a source that would make the differing ME ranges really stick out.
The only weird thing was that at 24, it somehow produced a file larger than ME range 16, when all other settings were exactly the same.
Now, I could just drop the whole thing, and say to myself there could be some complicated reason for why the file came out bigger.. perhaps it was finding more things to try to encode as a vector but not finding its paths as often, creating a larger file in the end. Or that could be a bunch of crap, because my only basis is logical thought rather than studying of the specifics of x264 :)
Other than that though it just seemed impossible. Still, I wanted to ask about it, since all the steps beyond 24 were exactly what I would expect. But for some reason 24 just... wasn't, heh (except also maybe 32 to 40 being not as much as you would expect, but of course there could be many reasons for that based on the source material.) Anyway 24 coming out a bit bigger was just weird when given precisely the same settings.
Either way I appreciate the input, this stuff interests me greatly.
Blue_MiSfit
27th September 2012, 07:21
Don't test this kind of thing with CRF. Use 1 or 2 pass VBR / CBR to test.
LoRd_MuldeR
27th September 2012, 11:13
Anyway, it's the same source file for all the encodes, exactly the same settings, same CRF etc., with the only change being the ME range. It was just a little test I was conducting since it seemed like a source that would make the differing ME ranges really stick out.
As explained before, the same CRF value X is not guaranteed to give the same quality after messing with other influential options, such as ME Range - not even for the very same source!
The only weird thing was that at 24, it somehow produced a file larger than ME range 16, when all other settings were exactly the same.
It's probably because you compare the size (i.e. average bitrate) of files which may very well have different quality. So you are comparing apples to bananas ;)
A "magic" objective metric that perfectly predicts the human perception doesn't exist. Even SSIM is too vague for this kind of test.
Instead, as Blue_MiSfit suggested, encode your files in 2-Pass mode with a fixed target bitrate and only change the ME Range value, so you get files of identical file size (average bitrate).
Those files can then be compared visually. Because all files got the same number of bits to "work" with, the comparison will be fair.
Now, I could just drop the whole thing, and say to myself there could be some complicated reason for why the file came out bigger.. perhaps it was finding more things to try to encode as a vector but not finding its paths as often, creating a larger file in the end. Or that could be a bunch of crap, because my only basis is logical thought rather than studying of the specifics of x264 :)
Actually, cranking up ME Range too much might lead to worse results, because it can increase the chance to find a "far off" motion vector just by chance, which doesn't capture the actual motion. While such vector may look the "best" for the current frame, it can worsen the prediction for future frames. After all, you should look at the x264 built-in Presets to get a feeling for "sane" configurations. As said before, no preset goes above 24 for ME Range.
Dark Shikari
27th September 2012, 13:40
Comparing PSNR between two encodes at --tune psnr at the same bitrate is perfectly fine for this kind of test. Attempting a visual comparison to measure such a miniscule difference is hopeless and unnecessary, since there's no reason --merange should have a disproportionate psychovisual impact.
Farfie
27th September 2012, 23:01
Actually, cranking up ME Range too much might lead to worse results, because it can increase the chance to find a "far off" motion vector just by chance, which doesn't capture the actual motion.
Ah okay, I think this cleared it up for me. I was just really buying into the idea that CRF would always produce the same quality, but the size of the file would decrease if I changed settings to be more efficient. That's pretty much what I was doing for the ME range test, as I wasn't comparing visual quality but just recording end file sizes to see the increase of compression efficiency every time I added more pixels to ME range.
@Dark Shikari
Yeah, I knew there'd be no way I'd see a difference between the two. I was just looking at end file size. At the very least, I always expected to see a smaller file size, which was the case in every step except from 16 to 24, where it was somehow bigger instead. Mulder has brought how this could happen to light though.
Bloax
28th September 2012, 18:31
Well obviously it depends on whether the source would benefit from a higher MErange, if it does, then the quality does seem better.
Though do note that I base this on a 800x600@500kbps test, which looked like butt nevertheless.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.