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.

  • Djfe

    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

    • I haven’t tried it, but that would make for a really interesting test. I’m a bit busy with other things at the moment, but if someone wants to give it a try on some test encodes (try a small clip at RF0 at various speed settings), I’d be interested in hearing the results. If no-one bites, I might give it a shot when I get some more time to play again.

  • JaSy

    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…

    • Hey JaSy,

      The quality is spit out in the Handbrake encode logs (I was using the SSIM data). It’s more-or-less a rating of how similar the end encode is to the original source.

      You can find the SSIM value for your own encodes by sifting through your handbrake logs. It won’t be an accurate indicator unless you’ve set the tune setting to SSIM though. And I suppose one could make the argument that since x264 uses a bunch of psychovisual enhancements for real encodes, SSIM isn’t the greatest way to judge quality to begin with (though it should give an indicator as to how efficient various settings are in comparison tests with the same source).

  • Bernd


    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 crop those Black bars from a BluRay?

    • Bernd: Glad you enjoyed the video! As for the banding, a few possible things you can try:

      1. Try no-dct-decimate:no-fast-pskip in the advanced settings box. One of those sometimes has an impact (I don’t remember which).
      2. Denoising can cause banding (or remove noise that was covering banding in the source). If you’re denoising, try lowering the settings you’re using.
      3. Use a higher bitrate (smaller RF value). Basically, the encoder tends to pull bits from flat areas where it thinks you won’t notice as much, although sometimes this results in noticable banding. Feed it enough bitrate and it generally won’t.
      4. Make sure you haven’t inadvertantly limited the bitrate via the profile/level settings. Just about everything supports “High” profile. If you’re using a lower level (say… 3.0), you can try bumping it up to 4.0 or 4.1 although check to make sure it’ll still play on your devices.
      5. You can try using the “film” tune setting, or if that improves it but not-enough, try the “grain” setting. The latter will usually increasae the needed bitrate substantially. Both tend to do a better job of retaining the noise that covers banding when compared to the normal tune setting.
      6. If you don’t have luck with any of the above, you may have to delve into the Advanced Options panel, and play with the AQ and psy sliders. It’s been a long time since I’ve had to play in there, and hopefully you don’t have to go that route, but feel free to ask if you do and need some help.

      In any case, maybe some others will have a little advice here too. Various things can trigger banding so unless you’ve got a gut feeling or can make some educated guesses based on your settings, it’s usually a matter of trial-and-error until you find something that works.

      Good luck!

    • Bernd: As to the cropping question, I haven’t made time comparisons. I’d expect a small time savings, but whether enough to be noticable or not I don’t know.

      As for the size, you generally won’t notice much of a direct difference (those black bars compress incredibly well and don’t change or contain any motion). However, because the output resolution is lowered, the encoder might be able to use additional reference frames which could very well reduce the file size a measurable amount. Whether that applies will depend on a variety of things including the H264 level you’re using, preset you’re using, source material, etc.

      Honestly though, the biggest benefit to cropping off those black bars is visual – you reduce the chance of letterboxing, pillarboxing, postage stamping, etc on different displays. And it’s always nice to be able to watch movies on a computer in a window without the extra black bars too.

  • robnitro

    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.

  • 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?



    • Ben,

      The former (quality won’t be exactly the same between speeds at a given RF). You’ll get roughly the same quality at a given RF when using different speeds, but not exactly the same. If you look at the 6th chart, you’ll see that there’s no consistancy as to which speed will push out the slightly-higher-quality file.

      Keep in mind that these are very slight differences (I’d be shocked if anything but a computer could spot them), and with more data-points I suspect you’d find that they probably correspond to slight increases in file size to match – so it’s not free quality because a certain speed was used. Rather, the file size randomly became a bit larger than you might expect, so you simply get the slight extra quality you’d expect by having a slightly larger filesize.

  • 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

    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.


  • Dave

    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.

    • Dave: The presets all (generally) primarily differ in that they increase reference frames, subme, trellis, add weighted pframes, etc as you get to slower settings. Each of those things take extra time, but reduce the filesize/increase quality. “Very Fast” isn’t out of the ordinary there – it sits somewhat nicely between the settings before/after it. The only thing it reports to do differently is use lookahead_threads=2 by default (and I’ve tested forcing lookahead_threads=1 to rule that out as a cause).

      It *should* sit between the preset before/after it based on the x264 settings it claims to use. But it never does and is always an outlier. So something different is going on under the hood. Because I have no idea what it’s actually doing, I tend to avoid it because I highly suspect that the quick speed + shockingly low filesize didn’t come free, and quality is probably a good bit lower than what any other setting puts out. I could be wrong, mind you.

      You mentioned that you’d done some quality tests – have you tried a few SSIM/PSNR tests against the settings before/after it to compare? The logs I had when putting together this write-up are long gone, and I’m a bit curious again, so I’d be very interested to see your results if you have!

      • Adriano

        The secret of veryfast is the “trellis” option: it increases quality but also increases the file size.

        trellis=0 : ultrafast, superfast, veryfast
        trellis=1 : faster, fast, medium, slow
        trellis=2 : slower, veryslow, placebo

        The best option for speep+filesize is “veryfast”.
        The best option for speep+filesize+quality is “faster”.

  • 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 like me to try, I’m up for that.

  • Anonymous

    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!!