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.



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.

Leave a Reply

17 Comments on "Handbrake RF + slower speeds = craziness"

Sort by:   newest | oldest | most voted

I see so many posts on different sites regarding how slow Handbrake is and I agree. I did find a solution that cut my conversion time greatly. I’m using an old mac and rather than source my DVDs to Handbrake from the disc, I insert the DVD and once I close the player, I open computer in finder and choose the disc, then copy and paste it onto the desktop. Once that is complete, I eject the disc and then choose the source from the desktop. Even with the extra steps, this has cut my total conversion time in half on average. Still takes a while, but what a difference!!

I’ve been running some size vs quality test runs. I determined that music videos make for very good test material since they’re generally very busy, but also the short length makes running batches of them with lots of variations aren’t nearly as time-consuming as movies or TV episodes. I have some logs from some test runs I’ve done, and I’d be interested in sharing them with you since I’m not quite sure how to parse them. One interesting thing of note, while running tests with different speed profiles I’ve been watching my processor usage, I think that veryfast may be able to do the quality (reduced size) while being as fast as it is because it appears to spend more time in-kernel. What it’s doing in-kernel instead of in user-space, I don’t know. And this is just anecdotal, so I could be mistaken. If you’ve got other things you’d… Read more »

Please clarify why you ignored Very Fast other than it’s out of the norm. Your initial chart would seem to indicate that this would be the best selection for speed/filesize. And my tests have shown quality almost indistinguishable from the original.

Ben M

One last question…does anyone know? If using MP4 does the “web optimized” option make any change to the quality…or is it strictly a matter of where the file holds certain information…doesn’t change the information just where it holds.


Ben M

Thanks for the info…that got rid of my concern…if only a computer could spot the difference, then in reality there really isn’t a difference to me.

Is there an RF that roughly corresponds to what most commercial Blurays are encoded at? Or are they usually encoded with an average bitrate as size (usually) isn’t a limitation. I’ve noticed that commercial movies fluctuate widely in their video size (of roughly the same running time) and thought that might be because of using an RF versus an ABR.

Thanks again for responding.



Ben M

Slightly confused here: “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.”

I’m about the quality…that is my primary focus always…a little more time or a slightly larger file is okay with me. So with that said, if you use the same RF factor you’re saying the quality actually won’t be the same between super slow and say medium? Or will the the same RF always be the same quality?




Forgot to mention, that link ( )
shows how the SSIM is really not a real measurement, the SSIM can be improved with blurring, the average is still better at the same bitrate.
So pretty much SSIM is garbage without also considering blocking and blurring.
Seems like in his case, slow and slower do the best. I prefer slow myself.

Hey, i just watched your video on utube about anamorphic. You did an awesome job explaining this! Thx. I recently did tests about handbrake presets, too. In the most recent version slow, fast, and ultrafast doesn’t make a difference visually. Sometimes it makes in filesize, but not all the time. However in an older Version of Handbrake this had a dramatic effect on the image quality. There the old standard for the “normal” preset was set to slow or even slower. Guess they changed here. I notices some ugly color banding on some of my encodings. For example in “Green Lantern” when in the end of the movie he flies in space you can see huge banding. I tried from placebo to Ultrafast – it has no impact on the banding. Any ideas how to solve that? One more question to anamorphic: Do u actually save time/filesize when you… Read more »

thanks for sharing the results of your different tests on handbrake. Im still trying to find best settings to encode HD movies. Knowing that very fast shouldn’t been used is a great help by bringing down the number of different alternatives. However, you compared (besides size) quality as well. How did you assess the different quality levels? I don’t think you trusted just the visual perception…


What happens to SSIM and non-SSIM if you encode lossless (RF 0)?
Is it stable then? -> placebo for the smallest file size with 100% quality?
or is it still inconsistent? -> for example slower encodes better in one case or something like that