So Handbrake 0.10 has been out for a while now (and 0.9.9 for even longer), and if you’ve looked through my previous multi-page guide that explained all the advanced settings in 0.9.6, I’ve got some good news:
Getting something that amounts to the “best settings” is a whole lot easier in v0.9.9 and v0.10.
The “x264 presets” are now in Handbrake, and 99% of the time, that should mean that you don’t have to dabble in the “x264 Advanced Options Panel”. Though if you want/need to for whatever reason, the old rundown of Handbrake settings (0.9.6) guide should help explain all those options for you in great detail (note that in v0.10 you may need to enable the x264 advanced options panel in the Handbrake settings/preferences located in the drop-down menu).
Note that since v0.10 is very similar to v0.9.9, I’ve simply updated this guide with v0.10-specific additions in orange (like this!).
I’ll use some images this time around to help make things quick & easy. We’ll start at the more complicated part, and work backwards.
-Smallest file size possible
The decisions you make during these sections will largely depend on which 2 you choose.
Anyway, let’s start at the highlighted area below.
Constant Quality (RF) vs Average Bitrate (kbps)
- These have the largest impact on quality & file size. Move the Constant Quality RF slider far enough to the right (or use a high enough Average Bitrate) and the video will be large, and look indistinguishable from your source. Moving the slider to the extreme left (or using a low enough Average Bitrate), and you can get really small file sizes, but something looking pretty ugly. Most people aim for something in between.
- Generally speaking, one isn’t going to get you a “nicer” video than the other.
- I’m really going to be simplifying the rest below (it won’t be 100% technically accurate, but accurate enough to give you an understanding).
First, a quick image to give you an idea as to what Constant Quality entails…. (click for a larger image)
Constant Quality – Usually this is the preferred method. This targets a certain level of quality throughout your video(s). The advantage to Constant Quality is that your videos all tend to look consistent. The downside is that you don’t know how large each video will be until the end.
RF – Sliding to the right (lower numbers) lead to better quality. Sliding to the left (higher numbers) result in lower quality, but lower filesizes too. If you’ve never used Constant Quality before, normally RF:20 is considered as a starting point for DVD encodes (and RF:22 for BluRay). Most people experiment to find an RF value that looks good enough to them at a file size they can handle, and use that RF value most of the time, deviating slightly when need be.
RF examples – Here are a couple screenshots taken at different RF settings (one at 20, and one at 30) to give you a very rough starting point (click for a larger view):
For a more in-depth look at RF values, check out Comparing x264 “RF” settings in Handbrake (examples) for the full write-up.
And an image to give you an idea as to what Average Bitrate entails… (click for a larger image)
Average Bitrate – Using this and a calculator, you can aim for a specific file size given a certain video length. Helpful if you wanted each of your movies to be exactly 700MB for example. Advantage to Average Bitrate is that you can effectively pre-determine your file size. The downside is that after you finish encoding, you might find out that the filesize you chose wasn’t high enough, and your video looks like junk. Or maybe the file size was higher than it needed to be. 2 pass encoding when using this option used to be strongly recommended, but it’s generally not thought to be as important anymore unless you need a precise file size (“turbo” first pass is okay if you don’t mind losing a little precision in size).
kbps – The higher this is, the larger the file will be (and thus, the higher the quality). Online bitrate calculators are the easiest way to do this.
Looking at Constant Quality vs Average Bitrate from another perspective…:
Let’s pretend we’re encoding a 1 hour TV series from DVD with constant quality and have determined that RF:22 looks just-good-enough to us. Here’s how it might turn out:
- Episode 1: RF22 – 278MB (avg video bitrate of 686kbps)
- Episode 2: RF22 – 349MB (avg video bitrate of 915kbps)
- Episode 3: RF22 – 363MB (avg video bitrate of 948kbps)
- Episode 4: RF22 – 304MB (avg video bitrate of 792kbps)
- TOTAL SIZE: 1294MB
All episodes should look consistent. Clearly, Episodes 1 & 4 didn’t need as much bitrate as the others, so they ended up being smaller.
Now what if we’d tried using an “average bitrate” instead, targeting exactly 323.5MB per episode?
- Episode 1: 798kbps (avg video bitrate) – 323.5MB
- Episode 2: 798kbps (avg video bitrate) – 323.5MB
- Episode 3: 798kbps (avg video bitrate) – 323.5MB
- Episode 4: 798kbps (avg video bitrate) – 323.5MB
- TOTAL SIZE: 1294MB
The TOTAL SIZE is the same. The problem is that this time, Episode 1 got more bitrate than it needed. Episodes 2 & 3 probably didn’t get enough. Episode 4 got close to the ideal amount for our “RF:22 looked good to us” standards and probably looks identical to the RF:22 version from before. Either way, we’re now in a situation where Episode 1 looks stellar, but in Episodes 2 & 3, things are below our standards, looking notably worse.
That doesn’t mean that average bitrate is *bad*. It’s just not consistent when it comes to visual quality – it’s only consistent when it comes to file size. So if you use average bitrate, you may have to “pad” your numbers a bit just in case some of your videos need the extra bitrate to look okay. If I were encoding the rest of the season via “average bitrate”, I’d probably be encoding everything at 1000kbps to be on the safe side. Unfortunately, that means my total filesize for 4 more episodes similar to the above would now be 1622MB instead of just 1294MB. And at that point, I’d have been better off using Constant Quality with a better RF value.
Short version: Unless you desperately need your file to come out at an exact size, use Constant Quality. Play with RF values until you find values where the video looks good enough to you on the devices you play back from, at file sizes you find acceptable.
As mentioned above, this has a different effect depending on whether you went with Constant Quality, or Average Bitrate.
If you went with Constant Quality, your quality has already been “decided”. Changing this won’t substantially affect the quality any further (if you wanted higher quality, move the RF slider more to the right). Using the 7 slowest settings will find ways to fit that quality into a lower file size. Using the 2 fastest settings will result in a larger file size. Either way, it should look about the same. Note that the 3rd setting (very fast) behaves very oddly with Constant Quality and I suggest you avoid using it. If you want more detail about the RF value and CQ, I’ve got a separate writeup to help clarify all of that (with charts) at Handbrake RF + slower speeds = craziness.
If you went with Average Bitrate, your file size has already been “decided”. Changing this won’t affect the file size any further. Going with slower settings here will try to pack more quality into that file size you’ve chosen. Going with faster settings here will result in less quality.
Details: This is where the time tradeoff comes into play. The veryslow preset is about the most hard-core anyone should typically get, and it can take a long time even on a quick machine. This is one of those areas where you’ll have to experiment on your machine and find something reasonable.
Keep in mind that there are diminishing returns as you get slower. Compared to “veryslow”, the “placebo” setting takes forever and a day. At the very least, it’ll usually add a few hours, if not days, depending on your source and computer. Even worse, you might not even notice the visual difference (it’s called “placebo” for a reason). On the other hand, the difference between “ultrafast” and “medium” (skipping superfast, veryfast, faster, and fast) might only be a few minutes and will often give a quite noticeable difference.
Finally, when on the quest for quality, keep in mind that days of encode time is no substitute for simply choosing a better Constant Quality or higher Average Bitrate. Slow settings will let you get more bang-for-your-buck, but it’s not going to work miracles. Sure, a 350MB TV show encoded at really slow settings will look better than the same 350MB TV show encoded at fast settings. But a 600MB encode of the same TV show will trounce both of them even if it was done at really fast settings.
In general, these focus on shifting “bits” between detailed & flat areas, depending on the setting. To be honest, you don’t have to really understand what they do – other people have done the grunt work figuring them out, so they’re whittled down to pretty simple “one size fits all” settings.
None – This is like the “old” Handbrake presets. Nothing inherently wrong with it. It’s something of a middle-road setting.
Film – For TV/Movies/Film and 3D animation (Pixar movies for example)
Animation – For 2D animation (Mikey Mouse, Simpsons, etc)
Grain – For very grainy movies/shows. For example, movies like 300 or Saving Private Ryan (the beach scene). Note that this tries to KEEP the grain, which uses a boatload of bitrate, and tends to result in higher file sizes when using Constant Quality (if you’re using Avg Bitrate, make sure you’re using a high bitrate, or overall quality will suffer.).
Stillimage – For still images (slideshow/pictures).
PSNR/SSIM – Generally for testing/comparative purposes. These stand for “peak signal to noise ratio” and “structural similarity”. x264 has some enhancements that improve the image as you would see it (robbing “detail” from places you wouldn’t notice it anyway, and putting that detail where you would notice it). These settings disable those, so that the image is more “technically” correct so that a computer can compare the video with the source to see how accurate/identical it is.
Zerolatency – Meant for fast encoding with quick streaming.
Short version: Film, Animation, and Grain are what you probably want to use most of the time (perhaps “None” as well). The others are for pretty edge cases that most people don’t have to worry about.
Fast Decode (checkbox)
Usually you do *not* want this checked. A few exceptions:
- Check it if you’re trying to play your videos on an older computer that struggles to decode H264.
- Check it if playing videos on an older device that struggles to decode H264.
- You could optionally check it if uploading to YouTube or other video-sharing sites. It may make it quicker for the site to decode it and put your video up. It’s usually not necessary.
It disables a few H264/x264 optimizations, making it easier to play but at the expense of a larger file (or lower quality if using an average bitrate). Since most recent computers/devices have built-in hardware support for these optimizations, you usually don’t need to bother with it. If you find that playback on your favorite device is choppy, try checking this though.
H.264 Profile & H.264 Level
This is where things can get a little tricky. Higher profiles & levels tend to get you better compression (so better quality in a given filesize). However, you’re going to be limited by the profile support of the hardware devices you’re planning to play your videos on. Here’s the order of things:
Baseline -> Main -> High
1.0 -> 1b -> 1.1 -> 1.2 -> ……. -> 5.1 -> 5.2 (this one’s easy enough to figure out)
Currently, High Profile, Level 4.1 is the most popular profile on recent / cutting edge devices. Such a device will also play Baseline/Main, and any level between 1.0-4.0. The industry’s stagnated at Level 4.1 for a couple years, probably because it’s at the point where it’s “good enough” until H265 starts taking over.
Here are a few examples of profile support for popular devices:
iPhone 3, iPhone 3GS: Baseline Profile, Level 3.0
iPhone 4, iPad 1, AppleTV 2: Main Profile, Level 3.1
AppleTV 3: High Profile, Level 4.0 (may actually support 4.1)
iPhone 4S, iPhone 5, iPad 2, iPad 3, iPad Mini: High Profile, Level 4.1
Blackberry 7 & 7.1 devices: High Profile, Level 3.1 (they recommend using Baseline Profile though)
Blackberry 10, Blackberry Playbook: High Profile, Level 4.2
WD TV Play & TV Live: High Profile, Level 4.1
BluRay devices (those which will read from a USB hard drive for example) should normally support High/Level 4.1, but are often somewhat picky and have a tendency to complain about being “too complex”. I haven’t actually bothered to try determining the exact cause, but if you run into this issue, you can try entering bluray-compat=1 in the “Additional Options” window (note that your file size may increase somewhat). If that doesn’t work, try Main profile or a lower level.
Samsung & Nokia don’t list profiles on their spec sheets for phones/tablets. Probably safe to assume at least Level 4.0 on their devices that record in 1080p.
Roku, Boxee Box, Netgear NeoTV don’t list profiles on their spec sheets for media streamers. Probably safe to assume at least Level 3.1 for 720p devices and Level 4.1 for 1080p.
…you’ll have to do your own digging for devices from other manufacturers.
Short version here is that for devices which are a couple generations old, Main Profile, Level 3.0 is usually supported.
Almost every current-generation device supports High Profile, Level 4.1.
Thus, you probably don’t want to exceed Level 4.1. If you go any higher, your video probably won’t play, or will play-with-glitches on any current smartphones, tablets, etc. Note that some slower computers which lack hardware playback support may also struggle to smoothly play back videos encoded at very high levels.
Enough with the complicated/hard stuff. Now the easier bits.
Format – MP4 file vs MKV file
This is known as a “container”. Doesn’t affect the quality, so don’t stress too much over this one.
MP4 file – This is what you usually want to use. It has the highest player & device compatibility. Windows Media Player won’t play MKV by default. Quicktime, iPhones/iPads/AppleTV/etc don’t play MKV files either. MP4 is the safe bet and works perfectly fine.
MKV file – This is a more flexible, but less supported container. Technically, you can jam multiple video streams in it, add DVD menus, use a wider variety of codecs, and a whole whack of other things (none of that through Handbrake, mind you). The 2 notable exceptions when it comes to Handbrake are that it will allow you to use the Theora (VP3) video codec, and FLAC or Vorbis audio codecs. In v0.10 it will also allow you to use Googles VP8 codec.
Short version: Unless you have a specific reason to use MKV, use MP4. Note that “Canadian Man” left a comment indicating that some Samsung TVs have audio sync issues when playing MP4 files over USB – if you run into similar issues you may want to encode using the MKV container instead.
Video Codec – H.264 (x264) vs MPEG-4 vs MPEG-2 (vs H.265/x265/HEVC vs VP8 in v0.10)
H.264 – This is probably the *reason* you’re using Handbrake to begin with. It’s the newest codec offered, results in high quality at low file sizes, and is supported by virtually every recent device out there.
MPEG-4 – An older codec, and very few reasons to use it. To give you an idea, old devices/players that won’t play anything newer than DivX will usually do well with MPEG-4. If you have a really old (or really cheap) phone that has very basic video playback capability, it might work on those too. And if you’re hoping to edit your video later in a 5-year old editing program that lacks H264 support, this gives you an option to do so.
MPEG-2 – Unless you have a specific reason for using this (beyond time travel to the late 90’s), don’t.
Theora – Only available when using the MKV container, it’s positioned somewhere between MPEG-4 and H.264 in terms of specifications. Not very popular in the mainstream – Linux users and the open source community in general tend to be most familiar with it. Those who use it usually have specific reasons for doing so – if you’ve never heard of it, it’s probably not what you’re looking for.
H.265 – New for Handbrake v0.10, this allows you to encode your video using the new H.265/x265 encoder. As you might guess, H.265 (also known as HEVC) is the successor to H.264. Don’t go encoding all your videos in x265 just yet though! Here are a few reasons why you might want to wait a while before making the switch from x264 to x265
(as of early-mid 2015):
- x265 encodes take a very long time. I did a number of tests with a 46 minute TV show from BluRay (1440×1080) with the veryslow preset. Using x264, the times were each around 2 hours (+/- 30 mins). Encoding the same episode using x265, times ranged from 21-34 hours.
x264 is very mature with many years of development behind it. x265 on the other hand is very young and still has a lot of room for improvement. Depending on what you encode, an x264 encode could very well come out looking better (and being smaller in file size) than an x265 encode. Eventually, x265 should blow away any x264 encode, but we’re not quite there yet… these things take time. Almost no device support yet. VLC v2.2+ is about the only mainstream player so far on desktop/mobile. Nothing built-in yet from iDevices (technically FaceTime can use H.265 on the iPhone 6, but no playback support yet). Android just added API support in “Lollipop”, but I haven’t come across devices with hardware support. 4K BluRay players aren’t expected until the end of 2015. Intel/nVidia just started adding hardware decode support to recent devices near the end of 2014 and early 2015. Basically, things are pretty early in terms of support.
Update: As of Jan 2018, x265 is considerably more mature. The latest version of iOS (11) and macOS (High Sierra) support HEVC. The latest version of Windows 10 supports hardware decode of HEVC on supported hardware. For those using software players, all the common open source players (VLC, MPC, etc) have had really solid support for a good long while now.
The biggest downsides currently are as follows:
- Encode time. x265 still takes significantly longer than x264.
- Playback on devices without hardware decode. Decoding in software uses a good bit of CPU power and sucks down battery life much faster.
…while you can make a good case for using x265/HEVC nowadays, before you go encoding your entire collection, I strongly suggest doing a few tests first to ensure you don’t run into issues playing back the video on your devices.
VP8 – New for Handbrake v0.10, this won’t show up unless you select the MKV container. If you’ve never heard of it, I tend to think of VP8 as “Google’s version of H.264”. It tends to be inferior to x264, except in perhaps a few very specific circumstances. It’s intended to be patent-free (and hopes were once that it would become part of a standard for web video), though there’s a huge mess surrounding all of that which you can search around for and read up on if you’re interested (both the patent side and the web browser side). As for encode time: a video that took 2.5 hours for me to encode in x264 took a little over 6 hours using VP8. If anyone actually uses VP8 on a regular basis, I’d be very interested in hearing about what you use it for and why in the comments.
VP9 – The successor to VP8. It does have hardware decode on Intel and AMD’s latest chips as of 2018 (Skylake+ and Raven Ridge), is the preferred codec for Google Chrome and Mozilla Firefox, and is predominantly used by YouTube. Netflix uses it on supported devices (many Android phones). It’s successor will be AV1 which is currently in development.
Short version: x264 for broadest compatibility and encode speed reasons. x265 if pushing for smallest possible file sizes and time/compatibility aren’t issues for you. VP9 if interacting with a lot of open source stuff or trying to avoid H264 and HEVC license fees.
Framerate (FPS), and Variable vs Constant framerate
Same as source – You almost always want to use this instead of manually picking a frame rate. Handbrake is smart and will virtually always get this right. If you detelecine or deinterlace, it will also do the smart thing here too and change the frame rate to be accurate. Manually setting the frame rate to something incorrect will often result in the video looking choppy/stuttery. Manually reducing the frame rate generally won’t reduce the file size by as much as you’d expect either. There are very few edge cases where manually setting it makes sense – usually it doesn’t.
Variable Framerate – Ideal most of the time (especially if de-telecining). If the “true” frame rate bounces around (or does after de-telecining), this will keep things looking as good & stutter-free as the original (and perhaps keep from encoding extra wasted frames). And if the “true” frame rate doesn’t bounce around, you’ll end up with a constant frame rate anyway.
Constant Framerate – I’d only go with this if I needed a specific frame rate & had manually set it.
Short version: “Same as Source” and “Variable” unless you have a solid reason for forcing something else.
On to the “Picture Settings” window.
(accessed via a button towards the upper right)
SIZE – Anamorphic – Unless you’re doing some manual resizing, you’re usually best to use “Strict”. I can’t think of a lot of reasons to use “Loose” unless you’re resizing the video resolution (loose makes it fairly easy). “Custom” is beyond the scope of this write-up, but allows you to do a bit of manipulation, including changing the aspect ratio if you have a desire to smush/stretch things. Don’t use “None” unless you know what you’re doing.
SIZE – Cropping – Use Automatic. That way, it won’t waste space trying to save any black bars (your device will add black bars if necessary). On the other hand, if you want black bars manually saved as part of the video stream, feel free to set it to “none” and change the values to all 0’s.
Hitting the “Preview” button is usually a good idea if you’re trying to tweak here.
If you want more detail on the anamorphic and cropping settings, I put together a video that thoroughly goes over each of the options. It’s long, but there’s a “table of contents” on the right side so feel free to skip around to the part(s) you’re interested in:
Next, if you click the “Filters” button…
FILTERS – Detelecine – Setting to “Default” is a good idea. If your source is telecined, it’ll detelecine automatically. If it’s not, it won’t. Set-and-forget.
FILTERS – Decomb – Setting to “Default” is a good idea here too. If your source is interlaced, it’ll automatically deinterlace it. If not, it won’t. Just like the above. Set-and-forget.
You normally don’t want to use “Deinterlace” unless decomb is giving you problems or you have one of those oddball situations where you want to manually set it for some other reason.
FILTERS – Denoise – Usually, keep this off. A couple exceptions:
- Turn it on if you have noise/grain in your source you want to get rid of.
- Turn it on if you want to reduce your filesize slightly (or improve overall quality) at the expense of softening your image some.
- Turn it on and use a CUSTOM value if you’re trying to get rid of “dancing dots”.
UPDATE: I put together a new denoise write-up with video and images if you’re interested in de-noise settings.
FILTERS – Deblock – Off. It’s supposed to get rid of blockiness but in my experience it ends up blurring everything a crazy amount that makes the video hard to watch. On the plus side, it pretty much destroys noise/grain in the process.
For Audio Settings, Subtitles, and Advanced Settings, nothing’s really changed so rather than re-write it all, I suggest reading the old writeup for version 0.9.6 if you need further details on those options.
That about sums it up. As a quick note, I’ve really generalized a fair bit – especially when it comes to the Constant Quality vs Average Bitrate part. But hopefully this has given you enough of an understanding that you’re comfortable using the new system.