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.
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 neighboring 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)….
The chart is 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).
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.
Compared to MEDIUM, using PLACEBO gave a 13% drop in filesize.
——
And again…
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 behavior.
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 the sake of curiosity, 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:
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 neighbors).
——
So what can we take from all this? Do we have anything concrete?
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.
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
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).
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 s.th. 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?
- Try no-dct-decimate:no-fast-pskip in the advanced settings box. One of those sometimes has an impact (I don't remember which).
- 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.
- 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.
- 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.
- 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.
- 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!
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.
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.
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?
thanks
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.
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.
Cheers
Ben
Thanks
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!
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".
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.
http://pastebin.com/9Z1AfT2s
If you've got other things you'd like me to try, I'm up for that.
Of course, it's no substitute for testing with your own encodes (which it sounds like you're doing!), but can be helpful if you want some rough at-a-glance information.
ALso what is he best option for quality and filesize?
Thank you!!
Beyond that, to up the quality you either lower the RF value (if using Constant Quality) or increase the bitrate (if using Average Bitrate) though these will come with corresponding increases in file size. Really, when it comes to maintaining quality there's no substitute for throwing piles of bitrate at an encode - it'll result in a larger file but it's one of the simpler tradeoffs to make.
Other bits like pushing the profile/level as high as your devices will support, looking into possible denoising, etc are mentioned on the linked page above and in others in the encoding section here: https://mattgadient.com/category/encoding/ .
I have been testing quite a bit myself and x264 CRF16 has been my "golden standard" for some time now.
Since I recently bought a new CPU I am looking into the speed presets again and this helps a lot.
There is however one question that your text raises for me.
In the part where you look into the best quality out of the 7 slowest presets, you say this:
"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)."
What do you mean by "what the logs told me"?
How do you determine the quality without SSIM, PSNR etc.?
Is that your subjective evaluation?
Or is it bitrate or some other indicator?
Please help me out here. :)
I created five sample files for myself to get an average encoding speed to bitrate / qaulity ratio.
Subjective evaluation however is not very realiable, so I welcome any metric. :)
Thank you!
With normal encodes (non-SSIM and non-PSNR) the encoder makes use of "tricks" to improve perceived quality at the expense of what I'll call "measurable" or "quantifiable" quality. Basically shifting bits around to areas it thinks you'll notice (and robbing from areas where you won't notice). For example it might take a lot of bits from a background area (where you probably won't notice as much) to improve something like a face (where you'll almost certainly notice). As another example that can work a bit differently, it might drop some noise to improve overall picture or decide to average colors in a block and maintain the result into successive frames until the average deviates a certain amount.
While this makes things look better for the viewer and allows for better efficiency, this has the side effect of tanking SSIM and PSNR results because the encoder's no longer treating every pixel as equally important - it's instead prioritizing certain aspects/areas and allowing itself some leeway when it comes to certain areas being perfectly-accurate vs close-enough.
What all this means is that x264 encodes really have to be compared subjectively (using them eyes) unless using the SSIM/PSNR presets which really prevent x264 from flexing all it's muscles. I've tried to get away with using the SSIM/PSNR values above because I've got a situation where I'm using the same encoder (x264) on the exact same source at (mostly) the same settings. And we're looking at many visual results too close to really differentiate by eye. There *is* the caveat that some of those settings may allow/cause x264 to engage in more/less trickery, so using SSIM/PSNR for those results can't be relied on 100%, hence the disclaimer mentioned.
Hope that clears things up a bit!
I was very surprised to see that "Very Slow" was almost always a smaller filesize than "Placebo" quality (albeit by a minuscule amount), seeing as though - in my own brief tests - Handbrake estimates that it would take at least double (and sometimes triple) the time to encode at "Placebo" in comparison to "Very Slow".
Perhaps the visual quality of the video is more comparable, but I haven't the time to check sadly. At high enough resolutions I doubt it would be very noticeable anyway.
That said, if you use it and are happy with the results, by all means keep doing so (particularly if you disagree with my rationale for avoiding it)!