Handbrake RF + slower speeds = craziness

If you’ve read the “best handbrake settings” guide for 0.9.9, there’s one area that I really simplified, in an effort to keep things a little less overwhelming for the average person. I basically indicated that:

When using constant quality (RF):
-RF value chooses your quality
-slider trades encode time for a smaller filesize

I mentioned at the end of the writeup that I’d generalized a fair bit when it came to the RF and Average Bitrate parts, but there are enough comments revolving around this area that it’s worth elaborating on.

So here we go. Incidentally, these slides were from a video I was starting to put together a few months back (and ran out of time for), but hopefully this helps if you’re trying to understand some of the craziness.

Results from an SSIM RF encode at various speed settings.

 

Above, I’ve run a video through Handbrake at an RF value using the same settings each time except for the speed. Note that I used “SSIM” settings. It’s really important to note that you would never use SSIM for your “real” encodes – it’s only for testing purposes, and generally only used when you need to make reliable quality comparisons (quality as a computer would see it, not as *you* would see it).

You’ll notice that the “slower-settings-gives-smaller-files” notion seems to hold true here for the most part, with a couple outliers. VERYFAST is always an outlier, and I recommend avoiding it since it falls so wildly out of any expectations (something very different appears to happen under-the-hood, as based on the settings it claims to use on output, it looks like it should fall between it’s neighbouring speeds, but it’s always way out of the ballpark instead).

One thing that ISN’T shown in the above image is that there were also quality drops as we got to lower file sizes – so while a slower speed helped reduce the filesize, some of that reduction was due to a loss in quality too – but more on that later.

Let’s look at “real” encodes now (not that SSIM stuff)….

Results from "real" (non-SSIM) encodes using an RF value at various speed presets.

 

The chart’s intentionally laid out differently so that you don’t get it mixed up with the other test.

I encoded 3 different videos, multiple times each.

Here if you look closely (click for a larger image), you’ll notice that we DON’T have the same reduction in file size as we get to slower settings. Everything from PLACEBO to VERYFAST is in the same ballpark, but none of them is always-the-largest and none of them is always-the-smallest.

So you might be wondering… “what the heck?” And the truth of the matter is that when you’re doing “real” encodes, that whole notion of slower-speeds-gets-lower-filesizes doesn’t hold true. A more accurate statement might be that:

When it comes to file size, UltraFast > SuperFast > EverythingElse. Usually.

 

The problem is determining what you actually got by using a slower preset if your filesize didn’t get smaller.

Basically, what sort of advantage are we getting in our real encodes by using something like placebo?

For that answer, we have to turn back to the SSIM encode (since it’s the only one that lets us compare quality).

At a given quality, the MB advantage of placebo.

 

Recall that I mentioned there was a loss of quality in the SSIM encodes as we moved to smaller presets in this SSIM encode. That probably makes a little sense to you just looking at the image – we had some pretty significant drops in filesize here.

To mitigate that quality loss, I had to bump up the RF value of placebo to compensate. This was just a trial-and-error thing until I got the same quality level reported in the logs. Then we see how many MB we actually saved by using the placebo preset.

Turns out that once we match the quality (as close as we can, anyway), by going from SLOWER to PLACEBO in this encode we see roughly a 4.1% drop in filesize.

So when using PLACEBO, we got 4.1% more bang-for-our-buck in an RF encode compared to using SLOWER (for this source).

 

 

——

 

Next, we bump up the quality of placebo a little more.

At a given quality, the MB advantage of placebo #2.

 

Compared to MEDIUM, using PLACEBO gave a 13% drop in filesize.

 

——

And again…

At a given quality, the MB advantage of placebo #3.

 

Here about a 12.8% drop in filesize for PLACEBO compared to FAST.

…wait… didn’t we just have a 13% drop in filesize earlier?

Now you might be starting to see why it’s nearly impossible to boil things down to a “system”. Even using these SSIM encodes (which look clean/predictable at first glance), we don’t get perfectly clear behaviour.

That said, bumping up the placebo RF value in 0.25 increments didn’t get me *exactly* to the quality levels (just extremely close in these 3 cases), so it’s possible that if I’d been able to fine-tune a little better and use a value like 0.21 maybe I’d end up at exactly the same quality and with a 13-17% drop (random numbers pulled out of the air). On the other hand, this could just as easily be an indicator that tiny changes in RF values can vary the % gained by moving to a slower preset.

Either way, using placebo as a basis, slower settings do give you more <something>. It’s just that with RF values, you don’t know whether that something will be a lower filesize, or a little more quality.

——

Note that I don’t have further comparisons – those were the only 3 cases where 0.25 increments in RF for PLACEBO had a very very close match to another preset for this source.

Just for curiousity’s sake, you might wonder with the “real” (not SSiM) encodes, if we only look at the 7 slowest settings, which gave the best quality? Here’s what we ended up with:

In "real" (non-SSIM) encodes, which technically had the highest quality?

 

Keep in mind that because these 3 tests aren’t SSIM (or PSNR-tuned) encodes, the “best quality” arrows could be totally wrong. You’re not actually allowed to use the quality results from normal encodes for comparisons, but I was curious and this is what the logs told me, and they seem somewhat reasonable given that in each case there was a little file-size bump attached to the item that claimed the highest quality (file-size bump compared to it’s immediate neighbours).

——

So what can we take from all this? Do we have anything concrete?

Looking for trends to come to a conclusion...

 

This probably wasn’t the best chart to use since the 7 slowest settings did vary quite a bit in filesize for this SSIM encode, but those generalizations in green tend to hold true.

 

So what do slower settings when using an RF value actually give you?

Usually, more bang for your buck. How much bang for your buck is probably going to depend on your source, which means you won’t know unless you’re willing to encode it at every single preset just to find out. And what form that bang for your buck takes isn’t going to be predictable. Assuming you’re trying to decide between FASTER, FAST, MEDIUM, SLOW, SLOWER, VERYSLOW, and PLACEBO, maybe you’ll get a little less filesize, or maybe you’ll get a little more quality. As we’ve seen above, it’s impossible to predict.

——

Conclusion

Hopefully the above helps you wrap your head around some of the results some of you are seeing when trying different speed presets (on the other hand, it’s perfectly understandable if it’s left you more confused than ever).

For anyone who is lost, the way I tend to think about it is that going with as-slow-a-setting-as-I-can-handle aids me in getting me the most quality in the smallest filesize possible. If you’re looking for a “system”, a fairly safe way to go about doing your encodes is to FIRST find a speed setting you can handle, and THEN tweak your RF value until you find something you’re happy with (in terms of the quality/filesize balance) for most of your encodes.