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.
(yay!)
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.
But first…
-Encodes fast
-High quality
-Smallest file size possiblePick 2.
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.
—
x264 Preset
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.
—
x264 Tune
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: https://www.youtube.com/watch?v=IDJH5p15tNU
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.
Can you explain one thing to me: Why is it that sometimes the encodes will go really fast but the next time they go really slow? I was ripping a cartoon DVD (using your settings) and one disc did roughly 1 minute per episode (5 minute episodes), but the next disc took roughly 10 minutes per episode. I don't get it.
- Similar content (same series, etc), at
- Identical durations, at
- Identical resolutions (in other words, one wasn't a DVD and the other a BluRay), at
- Identical Handbrake settings
Were you encoding directly from the DVD, or did you copy the DVD to the computer first (and encode from the ISO, MKV, etc)? If it was directly from the DVD, sometimes read issues or varied copy protection methods on certain discs can throw a wrench into things. A good practice is usually to rip the DVD to the computer first and encode it from there.Beyond that, if everything in the list above holds true, short of some other odd issue like a computer overheating and throttling, I'm not sure. Episodes with a lot of fairly static scenes tend to go quicker (you'll notice in movies that the end credits tend to encode rather quickly), but that wouldn't justify a 10x difference in overall encode time.
- "Similar content (same series, etc)" - Yes (for what its worth, Batfink cartoon DVD).
- "Identical durations" - Episodes are around 4:30.
- "Identical resolutions (in other words, one wasn’t a DVD and the other a BluRay)" - They are all DVDs.
- "Identical Handbrake settings" - Yes. Although, do the settings reset when you continue the encoding process the next time? Because I had the episodes in queue, and then resumed where I had left off.
I first made a copy of the discs to my HDD (DVDFab created VIDEO & AUDIO_TS folders). From there I selected the folder in Handbrake and encoded them episode per episode.
I hope this helps.
As for the settings, they do generally persist correctly when bulk-adding in the MacGUI at least (with the exceptions of "Audio" , "Subtitle", and items in "Picture Settings"). If you exit Handbrake, I believe the next time you open it, you have to re-enter your settings again though for any new items you add to the queue - old/existing ones in the queue should "remember" - usually saving your settings to a profile helps make things a little quicker the next time you use it.
You could try checking the log files to make sure the same x264 settings were applied. To do so, open up the "Activity Window" in Handbrake (from the menu bar), and right-click anywhere in that activity window and choose to open the "log file directory". You'll see all the logs show up - open up the ones for those 2 videos compare the section under "encoder: H.264 (x264)" (if you find the file hard to navigate, choose Edit/Find and type in H.264 to jump to the correct area). Alternately, since your stuff encoded pretty quickly, you could just try encoding those 2 again, but 1 at a time (verifying the settings for both) to see if there's any difference.
If those settings were indeed the same, I'm sure there's an explanation of some sort, but I'm out of ideas (sorry!).
As for the 2.5 hour encodes, assuming you're using the x264 presets, just try bumping the slider to a faster setting until you get a time frame you're comfortable with. Note that before going off and encoding hundreds of videos, it can help to do a few test encodes on the same episode, using different presets. Compare the file sizes afterwards (if using Constant Quality) and see if the time tradeoff is worth it to you. If using Average Bitrate instead of Constant Quality, compare the quality of the videos afterwards, and again, weigh it against the time it took.
Good luck.
A simplified version of why, even keeping all settings the same, the encode time vs a similar source cannot be predicted precisely.
Just my guess.
cheers
Frank
Thanks for the website
First of all I fully agree with the other comments - GREAT website; easy to understand and very helpful.
I'm using Handbrake only to be able to tranfer my many Dvd's to my newly bought Synology NAS. I'm a normal user og Dvd's enjoying films for what they are: entertainment. I not a DVD/film "geek" or "nerd" interested in the finer points and technical sides of transcoding a DVD.
Still I'm interested in the best possible quality and highest possible speed of trancoding. I understand thre's a trade off.
As far as I read your guide, I should be perfectly safe qualitywise using Handbrakes standard "H.264 (x264)" Video Codec, and should only use the settings under the "Advanced" menu if I for some reason should alter my status from an ordinary viewer of film to a "geeek"/"nerd" being very interested in the intricate and finer points of trancoding a DVD - or is this an overstatement?
One thing, though.
I'm slightly bewildered with regard to "x264 preset" under the "Video" menu.
You write that if one uses "Constant Quality", which I do, any setting under "x264 preset" won't make a bit of difference - qualitywise. Quality depends on the RF setting.
However, you then continue to elaborate on the differences between "ultra fast, medium and placebo" settings without having stated whether these diffences only apply to the "Avg. Bitrate" setting, to the "Constant Quality" setting or to both settings.
Likewise I not quiet sure whether your description of "Details" apply only to "Avg. Bitrate" setting, to the "Constant Quality" setting or to both settings.
If I choose "x264 Preset", which I do, why not use "Ultrafast" rather than f.ex. "Very Slow" and get the same output quality?
Slower "x264 preset" like "medium" gives me a larger output file than when I use "very fast"?
Why should I choose a transcoding that is slower and at the same time gives me a larger MP4 file?
....or am I completely missing your point?
Thanks in advance
Jan
As to the presets vs advanced settings panel, it's mainly a matter of the presets doing a great job of getting you the most bang-for-your-buck. The x264 devs put them together - they're quite good when it comes to bumping up the important stuff as the slider moves along. Being as easy as shifting a slider to swap between these settings is an added bonus. The way you stated it is fairly accurate too. There are a few situations where using the Advanced settings to fine tune something can make sense, but most of them are edge cases or used by people who are looking for something very specific.
On to the speed settings (ultrafast, medium, placebo, etc), they affect both avg bitrate (slower settings tend to increase quality) and CQ (slower settings tend to reduce file size).
As to the question of why you wouldn't use "ultrafast" instead of "very slow", if using CQ, the output quality would certainly be similar, but the file size using ultrafast would usually be a lot larger.
Hope some of that helps.
I'm not only transcoding my Dvd's to be able to play the films on my PC or iPad. I have also bought a Synology NAS server which through WLAN is linked to my state-of-the-art Loewe TV (a german brand which f.ex can play both the MP4 and MKV formats).
When trancoding my Dvd's I'm using the following Handbrake settings based on your excellent guide:
Format: MP4
Picture: Anamorrphic is set to Strict. Cropping is set to Automatic. Display size is by default: 1024 x 576. Rest is unaltered.
Filters: Default; Default; Off; Off and grayscale is also Off
Video: H.264 (x264) and not the advance menu - Variable Framerate - Constant Quality 19 - x264 preset at Medium - H.264 Profile: High - H.264 Level: 4.1
Subtitles: Burned In Danish subtitles
Chapters: I've checked the "create chapter markers" checkbox.
It seems to do the trick!
1) What are your audio settings?
2) What is your average encode time?
3) What is your CPU? (I7 2Ghz, 3.5Ghz, etc..)
4) What OS are you using handbrake on?
The reason I'm asking is that I can't find a single decent page comparing different CPU's/OS's using handbrake. I have access to Windows/Linux/OS X, but it would be nice to see if there are any major differences before I tear my storage drives out of server and put them in a different box just to encode. (Yeah my server is capable of dual booting, but I would rather not mess with that can of worms just to test an idea.)
2) This obviously varies drastically depending on the resolution, duration, preset used, and more. In a denoising comment, I'd mentioned that an episode of Alias took 1h12m (but only 48-52m with varied levels of denoising) done on the veryslow preset at RF18. I loosely budget around an hour or so of encode time for 1-hour episodes from DVD.
3) Sandy Bridge i5 (3.4Ghz).
4) MacOS X Mountain Lion.
I believe the Windows version now has some form of OpenCL acceleration (they'd been working on implementing it for a while anyway), so if you make use of it, it'll probably be faster. Otherwise, I'd be surprised if there were a substantial difference between Win/OSX/Linux - pretty sure the core is written in C, some of x264 is hand-tuned ASM, and the encoder is manually multi-threaded (so few if any benefits of GCD etc). Well-written encoders, compressors, renderers, etc are generally pretty equal when it comes to different OS's.
Before going through the hassle of swapping storage drives, I'd suggest you just do a quick test encode on each machine. Toss a video on a USB stick, copy it to each, open in HB, and let em race. Good luck!
First of all, thank you for supplying such a great in-depth look into Handbrake and explaining every point. Got me testing quite a bit!
I am wondering though, which settings would you chose for BluRay, since most of the time you talk about DVD which has a lower Source Quality already. I tried all the advanced setting from your 0.9.6 guide, which resulted in a very long encode time and smaller file size.
Turning up the Ref-Frames to 6 and Subpixel to 9 gave me an overall higher Bitrate for the File with a slightly larger File.
I figure, a higher Bitrate of the encoded File is better?
I am just now encoding the file again, this time with the new x264 settings , using Preset Medium, Film, High and L4.1, estimated encode time is around 4 hours, @ RF18 and Audio Pass-Through.
Could you recommend something just for BluRay? I want the Best Quality and do not care about File Size or Encoding Time (Although everything over 12 hours would be considered exsessive by me ;) )
After this encode I will try the x264 veryslov Preset, to compare the Bitrate of the file.
Maybe you have some tips for high quality sources or maybe this is already the "Best" to go with...
Regards, Wolf
If I can give just one tip, it would be: in the "Picture Settings" tab, make sure to check the "display preview" and then "Show Crop".
It's very useful to check that the automatic crop is not messing your movie. I just realized that Handbrake was going to cut 30 pixels of useful "image" on one side of my movie, I would have wasted hour of encoding otherwise.
I'm using Handbrake 0.9.9.5530 in Windows 7 to convert half-hour episodes of a TV show from a PAL DVD to MKV with Constant Quality set to 25.5. With x264 Preset at "Main" "Very Fast", I get a file of 151,900KB, and with "Main" "Medium" I get a 174,061KB file - keeping all other settings constant (I've done this twice to check). This is the *opposite* of your statement that "Going with slower settings (with Constant Quality) will find ways to fit that quality into a lower file size. Going with faster settings will result in a larger file size". Note that Jan reported the same thing about 2 months ago. "Slower 'x264 preset' like 'medium' gives me a larger output file than when I use 'very fast'."
Similarly, when I use "Very fast" but change the H.264 profile from "Main" to "High", I get a slightly larger file size of 153,103KB (instead of 151,900KB). All these are at constant Quality = 25.5.
Would you mind trying these experiments yourself with a DVD? That is, keep all settings constant, but vary the x264 Preset from "Very Fast" to "Medium" and compare the file sizes, and compare H.264 "Main" to "High" with all other settings constant. Do you have an explanation?
Just did a bit of testing with the presets on 3 small clips (different sources), and I'm showing similar results to you.
The "veryfast" preset is a massive outlier. Much smaller file size than expected on all 3 sources I tried.
This had me a bit perplexed, so I spent a while looking through all the encode settings stored in the outputted files to see what "veryfast" is doing differently, and the only thing that sticks out is that the veryfast preset is using lookahead_threads=2. None of the other presets do (they all used 1 which should be the default with the machine I'm using).
I'm not sure why veryfast seems to be forcing this to 2. And while I can't say for sure that it's the sole reason, unless I missed something else, all the other presets seem to build on the previous ones as expected (increasing reference frames, subme, trellis, adding weighted pframes, etc as you get to slower settings).
---
Now lookahead_threads is something I'd looked into previously, and based on the scattered conversations/debate I'd read, their reason-for-being goes something like this:
-address a bottleneck that happens on CPU's with a lot of cores/threads
-sizeable speed boost in that situation
-may decrease quality (no consensus as to whether you'd notice)
-by default are set to 1/6 of your "logical cores"
-thus, unless you have a hex-core with hyperthreading (2x6 logical cores) or a multicore machine, it should usually be 1.
Again, why it's being set to 2... I don't know.
---
So to take a stab at a guess, there might actually a quality loss due to lookahead_threads=2 happening at veryfast to get that size decrease. Again, from what I'd gathered there wasn't any consensus as to whether it would be noticeable or not, but personally I'd probably shy away from the veryfast preset.
In any case, I'd avoid using the veryfast preset. It's such a significant outlier that something else has to be going on under the hood, and I have no idea what that something else is.
The veryfast preset at, for example RF22, outputs at a lower bitrate and lower overall quality than the fast preset at RF22.
Anything from the FAST preset (and better ones) have ALL important quality-affecting features enabled, so I don't recommend anyone to EVER go faster than the FAST preset.
My recommendation, if time is tight but you still want lower filesizes, is to use the FAST preset and tweak the CRF until you get the desired filesize.
verb3k | Do different presets have an effect on quality when used with CRF?
@Dark_Shikari | verb3k: yes, but not too much.
@Dark_Shikari | a 0th-order approximation is that they have no effect.
@Dark_Shikari | The main reason there's a difference is because the preset affects how x264 itself measures quality
@Dark_Shikari | that is, it uses better, more accurate methods of measuring quality
@Dark_Shikari | obviously, this will affect the definition of what -crf does!
@Dark_Shikari | It's just not too much, so we can mostly ignore it.
@Dark_Shikari | specifically, there are three big things that can affect the definition of quality
@Dark_Shikari | 1) AQ being on/off
@Dark_Shikari | jump: ultrafast to superfast
@Dark_Shikari | 2) mbtree being on/off
@Dark_Shikari | jump: superfast to veryfast
@Dark_Shikari | 3) psy-rd being on/off
@Dark_Shikari | jump: faster to fast
@Dark_Shikari | above fast there are no more big jumps.
Basically, Average Bitrate only works PROPERLY in 2-pass mode. Exactly what it does is this:
Pass 1: Analyze every frame of the input video and write a file that describes how detailed each frame is.
Pass 2: Use that "how detailed is the video?" file to calculate a CRF value that will be able to compress all of those frames at an output size that gets you as close as possible to your desired filesize. For instance, it might pick CRF 21.4773 to fit a 700MB CD.
In other words: All encoding is done using the "rate factor". If you don't need to fit a specific filesize, then you should NEVER, EVER use multi-pass / average bitrate encoding. It's far, far, far superior to save yourself all of that analysis-time and just immediately input the rate factor you want.
For Blu-Rays, CRF 22 is usually good, and for DVDs you should try 20-21. These are just good starting points, but you're allowed to deviate from this based on the source material.
All x264 video encoding is variable-bitrate by definition. It only ever uses as many bits for each frame as that individual frame requires for storage.
The more advanced settings you enable, the more data it can compress into fewer bits, through using more advanced techniques. That is why I recommend never going lower than the FAST preset, so that you'll be sure to have all of the primary, advanced features enabled. Going any faster/more simplistic than that will mean getting less quality and larger filesizes.
What the Rate Factor does in the encoding equation, is that it affects the divisor for how much we are allowed to DEVIATE from the "perfect, losslessly encoded picture". Higher Rate Factors means that we allow more deviation, which in turn means that the algorithms are allowed to throw away more and more detail, which in turn means lower and lower filesizes (but also more and more blurry and visibly compressed videos).
However, x264 is an extremely advanced encoder and it will optimize the encoding so that it throws away imperceptible details first. The first things to go will be dark shadow details, noise, etc.
So pick a preset from one of: Fast, Medium, Slow, Slower, and VerySlow (the most advanced that we recommend using).
Then, pick a CRF that looks good to you and hit encode.
If you need to hit a specific filesize, then use the Average Bitrate mode instead. Just be sure that you really NEED to hit a specific size, otherwise you are just wasting your time by letting x264 pick a CRF that you could have set yourself.
To reply to the 2nd bit (thought I'd split these up, as they're a bit long...)
I wouldn't worry as much about the Main/High profile stuff being different sizes. It could be anything from a little extra overhead, to a very chunk of a scene that needed the extra bitrate that "High" allows over "Main" for any given level.
---
Just to clarify here too, small counter-intuitive variances in filesize based on the preset happens quite a bit. A common one is that placebo often ends up being very slightly larger than veryslow, despite the more reference frames available, and the more thorough motion estimation and mode decision in placebo.
And quite honestly, you could probably clump faster/fast/medium/slow/slower together in terms of their output size more often than not. Between those 5 in the 3 short tests I did, "slower" came out ahead 2/3 times, beaten by "slow" the other 1/3 times. "faster" and "medium" each had a run at 2nd place. If you look at the mess of encoded settings used, you'd expect a more consistent linear decrease in size as you get to settings-that-take-longer, but that certainly isn't always the case by any means.
I have a few questions regarding encoding gameplay videos that are already exported/rendered by Sony Vegas Pro in a nearly lossless format (using Lagarith/UtVideo codecs).
I rendered a Batman Arkham City video that is about 8.5 minutes @ 4K resolution (4096x2160) @ 30FPS. I know this is a monstrous resolution but that's what I need for our YouTube channel and so would appreciate help with this.
When I finished rendering the file, which took about 44 minutes in Sony Vegas Pro 12.0, it was 152GB! Then, I imported it into Handbrake and want to encode it into the H.264 format (MP4 container) so that it can be more manageable for YouTube.
I want to do this without losing visual fidelity/quality, if possible.
What are the "best" settings to go about doing this? I set the RF to 19 and x264 Preset to "Slow". The encoding took about an hour.
Can you recommend settings to optimize visual quality since I'm encoding 4K video and I want the absolute BEST quality?
My computer uses a hexacore "Extreme" i7 processor (3970X) and I have GTX-Titan SCs in my system. I also have an 8-SSD RAID-0 Array that can write at 2.7Gb/s and read at 3.0Gb/s. Storage is not a concern as I also have a NAS device with 15TB of storage.
I want to be able to get the best 4K video quality after exporting it from Vegas using Handbrake.
Any help/advice would be greatly appreciated.
Thanks in advance.
ThirtyIR
I'm looking for some help getting some settings good settings for re-encoding some F1 2013 gameplay into YouTube HD videos, basically a 23 minuite video currently is 83gb, I want to reduce this size so I can upload it to YouTube obviously I want to minimise the loss in quallity.
Any advice would be welcome.
- RyanD
I need to burn-in subtitles, because I need to play the file on my tv which has an USB entry but no subtitle menu.
The burn-in option however is grayed out when I select a subtitle file (*.srt)
The source structure is:
myvideos/videodir/*.mkv
myvideos/videodir/Seperate-Subtitles/*.srt
Many thanks.
Handbrake won't let you burn in an external subtitle track - only a track stored in the video. I don't know if this was a technical issue, a time issue, or an intentional decision.
In any case, you can add a subtitle track via MKVToolNix ( http://www.bunkus.org/videotools/mkvtoolnix/ ). It's available for Mac/Linux/Windows. Basically load your original file, load the subtitle track, and save it as a a new file.
The downside is that you'll have to do this for each and every video before you plop it through Handbrake. But Handbrake should see the subtitle track as being built-in and let you burn it in.
Thank you for a very well written guide, I googled this topic to death and this guide is by far the best one I have come across.
Have you come across this and any suggestions?
Thanks...Grant
If your files are hitting 4GB, you'll have to select that box for the videos to work. I haven't run into it myself, but my impression was that if you didn't select "Large File Size" when you hit the 4GB mark, you'd get a broken video (rather than nothing at all). Either way it's going to be required. As far as compatibility goes, it tends to be older devices that don't support it - there's no way around it except to get the file size down, or say... encode half the video as 1 file and the other half as another so that you don't have to select that box.
The other thing to watch for if you're getting into file sizes that large is that if you're saving to a drive formatted as FAT32, you'll have a 4GB limit anyway. There are a number of WinXP machines out there (not all) that are formatted as FAT32, which won't allow 4GB+ files to be saved to them *at all*. And external USB drives (whether flash memory or hard drives) are still frequently formatted as FAT32 too. So compatibility-wise, the potential headaches for 4GB+ files is going to extend beyond whether your video player can simply handle it or not. So be aware of that.
Short version: Select the box, make sure the hard drive you're saving it to isn't formatted as FAT32, and it should work. Then test it on your devices - if it doesn't work, you'll have to find ways to get below that 4GB barrier.
The default for handbrake is like 720 x 360 but in the first article it talks about true 1080p of 1920 x 1080, So when using Handbrake after ripping what should you set the size for?
You'll end up with different resolutions for a BluRay vs a DVD, but that's expected.
Your DVD's will tend to be output at resolutions near 720x480, 720x360, etc.
Your BluRays will tend to be output at resolutions near 1920x1080, 1440x1080, etc.
When it comes to the iPad 3, it'll play both of the above. Those high resolution BluRay encodes are going to take up a lot of disk space though. If you were encoding something *just* to watch on the iPad, you could potentially lower those values (use anamorphic loose for easy resizing) to give you a lower filesize - in that case it's common to lower it until it's ___x720 or ____x480.
Some time ago, I'd thrown together a video that deals with resizing, the picture settings, etc. You might find parts of it helpful. It can be found at http://youtu.be/IDJH5p15tNU if you're interested.
In the middle of something atm (sorry that the response will be short), but try adding the following line to the "additional options" window:
no-fast-pskip:no-dct-decimate
For the life of me, I don't remember which one of those deals with those blacks, but one of them will usually help clean things up. They will add time to the encode (one of them is already included in placebo if I remember right) and I think it'll bump up the filesize a little.
Try it on a small test sample first. If it works (or doesn't), please report back! Good luck!
First off, thank you for the help and the site!
I am sort of a newbie and I've been using MPEG4 encoding all along. I guess you telling saying better with H264?
I am going to make a few samples with the same movie/60 second clip on various combinations and will report back.
Can I ask a few questions in the mean time?
1. If I do use MPEG4 encoding and I don't care about file size, is RF1 the way to go?
2. Regarding the anamorphic, I thought if I went loose with mod 16 I could land up with a slightly bigger image that would minimize the black borders at top and bottom (for movies shot this way). That is to say, it still a long rectangle either way, it is just about maximizing the height of that rectangle to use the most part of my TV real estate screen when playing on a so called HD, 16:9 TV.
3. Assuming I am going X264 encoding, on the basis that 99% of my play back will be via VLC on a high powered Windows PC connected HDMI to a high end TV, what are your suggestions for the H264 profile and level values?
Thank you Matt!
Look forward to your replies.
Jeff.
1) I honestly haven't played with it enough to know (the few times I've had to use MPEG4 for an older video editing program, I fixed a bitrate instead of trying to guess where the RF would land me). Incidentally, RF1 *may* carry a risk you could run into - assuming for the moment that RF1 with MPEG4 might behave in a similar to the way that x264 does (virtually lossless though I'm not certain), the bitrate required will be incredibly high. And you might run into either players that won't accept it being that high, or you could run into issues where slower hard drives can't keep up - or at the very least take a long time to seek.
2) No, the anamorphic flag itself will foil your attempts here - you're going to get the original aspect ratio on playback, so whether you're using mod 2/4/8/16, you won't have any affect on black bars. The anamorphic flag makes sure it's displayed right. The risk you run into is that mod16 will sometimes resize the stored content slightly to fit the new dimensions, and then on playback it's being stretched back out anyway. It's probably not as big a deal as I've made it out to be mind you - most people are watching content that's been scaled to fit whatever-device-they-are-using-at-the-time anyway. I just don't like the notion of arbitrarily resizing the source when you don't have to and losing that bit of fidelity, as minor as it may be.
3) If you're only ever going to play on the PC, auto or high/5.x I suppose. VLC will play just about anything with enough CPU power. But keep in mind that even though *right now* you might think it's the only place you'll play the content, you might be kicking yourself later if someone tosses you a free smartphone/tablet for a trip and you find it won't play the dozens of videos you have encoded. I don't know if portable devices will *ever* see support for 5.0+ (they may just skip to "H265" or VP9. High/4.1 is probably a little safer. Personally I wouldn't consider 5.x unless I was moving beyond 1080p or needed to pack in an insane bitrate that just couldn't be handled otherwise. But you can try it if you don't foresee any short/long-term issues and if it works out great for you, then it does!
So here is where I landed. Using "Strict" as you suggested. Going with 264 with HIGH and 4.1. RF 20. Doing BLU RAY only. I didn't see any difference using that option you mentioned to handle the pixel in the black area. That said, once I went to 264 with HIGH and 4.1 and RF20 (with FILM) that concern has gone away. I am left with a VERY sharp image. Looks good. For a 2 hour and 24 minute movie from BLU RAY I am in the 8GB file size range. I am OK with that. The encode time is in the 5 to 6 hour window right now which is tolerable.
Thank you.
If you have any further suggestions or questions for me, let me know.
Jeff.
Specs: i7-4770k 3.5Ghz
32GB Ram DDR3 1866
So bascally, the CPU is the biggest determiner.
From what I recall, "default" uses a few filters that do a combination of blending and interpolation. Blending is essentially taking 2 "half frames" and merging them together with a little averaging. Interpolation on the other hand takes a half frame (say, a frame containing all the odd lines) and extrapolates the missing lines - usually with information from the previous/next half-frames (even lines) combined with some math and then drops those preceeding/next frames. So if the input was essentially 60i, you'd end up with something effectively at ~30p.
"Bob" on the other hand is what's known as a doubler. It takes a half frame (say, all the odd lines) and just doubles all the lines, then does the same for the next half-frame (say, all the even lines). Something that was essentially at 60i should result in a video effectively at ~60p.
Bob should have an advantage in high motion video that was actually shot/stored at 60i, like sports - you'd retain the 60 changes-in-positon-per-second of a player. You also technically retain all the detail since no fields were dropped. The downside is that each frame is essentially half the vertical resolution on playback, and if you look closely you might see some bobbing as there's a 1-pixel shift up and down between frames. Both of those disadvantages are heavily mitigated though since the frame rate is essentially doubled - you're not likely to notice it. While Bob spits out extra frames (up to twice as many), it usually doesn't result in a massive increase in filesize when using x264 (the increase is surprisingly minimal).
The "default" setting on the other hand *should* be advantageous in a source that wasn't interlaced to begin with (a movie shot at 24fps for example, and then interlaced/telecined for distribution) because even simple blending should perfectly (or almost perfectly) reconstruct a frame in many cases where they just split the fields.
Note that personal preferences vary. Your best bet is to try a source with both options, watch it up-close on a massive TV and see if you can tell any difference. Handbrake has some pretty complex custom settings if you want to delve in further. I've generally been content to just use the default setting but I'm also not the type of person to necessarily notice the differences visually during playback.
All that being said, I haven't looked too much into Handbrake's decomb/deinterlace, so their filters might do things a little differently than what I've alluded to. Even if that's the case, they should be based on the same principles for the most part though.
Someone can correct me if I've made an error above. If not, hope that helps!
One weird thing that happened was a green line at the right of screen. I was using automatic cropping and seems like it used 6 at left and 4 at right. I repeated entering 6 at right too and the green line was gone. I then used Manual Cropping and enter 0 an all options and there was no green line. It just happened if both detelecine and decomb are selected with automatic cropping and strict. Not happened with the same but loose anamorphic option. I really don't know what was happening and decided to do manual cropping with 0 all. (Variable Frame Rate always).
Thank you again!!
If cropping is set to automatic, it may just be cropping off black bars from the top and bottom. In the case you mentioned it might be chopping off 98 from the top and 98 from the bottom. That's usually the desired behaviour as long as Handbrake is getting it right, but generate a preview to verify (you can try one at auto cropping and another at manual cropping of 0, and compare). If you didn't have black bars in the source and Handbrake guessed wrong and did some unnecessary cropping, you'll probably have to manually set it to 0.
Otherwise, if you've selected one of the built-in presets, some of them implement restrictions on the resolution. Try setting "Anamorphic" to "Strict" and see if that un-does it. Alternately you could select "High Profile" as a preset, though it'll undo all the other options you've set, so you'll have to reimplement. Speaking of presets, if you've saved your own custom preset it's possible that you accidentally hard-coded a resolution there (usually if saving a custom preset, "source maximum" is what you want to use).
Technically, the H264 profile/level should probably implement restrictions if it's too low (it doesn't seem to in the interface but perhaps it actually does in the output file). It might be worth checking to make sure you don't have it set to something like Main/2.0.
That's all I can think of off the top of my head. Good luck!
Thanks for the super fast and detailed reply, it helped a lot. I didn't expect to get back from my lunch break and see a reply.
But anyways, I think you are right that its chopping off the sides. I actually made a mistake and said height instead of width..but I compared it, and saw no real apparent differences. Also, when I set Anamorphic to "strict," it actually locks both the height and the width, so there's really nothing I can do about it anyways. Everything seems fine though.
Thanks again for the help!
Thanks for this. Really explains a lot. I'm in the process of digitizing my home videos. Right now they're mpg's approx 3.5gb for about 2 hours. I was wondering what you would suggest a setting to be for encoding to MP4. They're obviously all SD & I'm running them thru Plex to my Roku. Thanks in advance.
Referring to one of the previous comments, I've also experienced output files disappearing because the size exceeded 4gb. I'm almost a novice when it comes to this, so I followed your guide above as closely as I could but I also checked the web optimized box in the hope that Handbrake would shrink files that are just over 4gb, to just under, while trying to maintain the highest possible quality for that intended output size. Sadly that was not the case, and after two attempts and almost three lost hours I'm left with nothing to show for it.
Put simply, I have to stick to the 4gb file limit regardless of how long in duration each individual video file I have is. Any advice you could offer on the best settings for a guaranteed 4gb and under file output, would be greatly appreciated.
Thank you.
If you absolutely need to guarantee that the file size never exceeds 4GB, you'll probably want to go with "average bitrate" instead of "constant quality" and use an online video bitrate calculator to determine what video bitrate to set to meet a specific filesize. So if you were aiming for a 3.5GB file (I'd avoid going right to 4GB because I don't know exactly where the limit sets in), you'd punch that in to the calculator, give it the video length in hours/minutes/seconds, and feed in whatever you've set for an audio bitrate so it can take that into account. You can, incidentally, calculate it manually but the online calculators save time here. When you've got it all set up, do a test encode at 1-pass "Ultrafast" to make sure you're ballparking the right filesize before you do the real encode at whatever-slower-setting-you-can-handle to get more quality packed in that bitrate/filesize.
The obvious downside to doing it this way is that you have to use the calculator for every video you do (since they'll have have different durations, and you might not want to give shorter videos as many GB of space).
Edit: example of a sample bitrate calculator would be this one (via a random google search): http://www.3ivx.com/support/calculator/
I encoded the same blu-ray tv show episide at 2 speeds that are next to each other on the Preset slider.
One file is slightly bigger than the other and using MediaInfo has a slightly higher *average* bitrate.
So I put both files on a thumb drive, plugged it into my blu-ray player, skipped down to a nice sunny scene, hit Info on the remote - and the file with the lower average bit show a real time playing bit rate 50% over again higher than the one with the higer average bitrate.
So should I go with the file with the higher average, or should I go with the one that seems to do better with bright/colorful scenes?
drc :)
...Preset speed.
Everything I read says the SLOWER it is the smaller the file and the BETTER the quality...
... this flies in the face of reason - if the file is smaller than there has to be LESS information in it so how can the video quality be BETTER?...
... ALSO I've processed the same blu-ray tv show episode at seveal speeds and the faster speed the larger the file which I'd expect BUT when I use MediaInfo or check the bitrate when the file is playing my blu-ray player it's HIGHER - isn't bitrate a measure of how much information is present per second so the higher values mean better video implying the faster speeds are yielding better quality?
drc :)
Slower doesn't always mean smaller size "and" better quality. It's closer to "or" most of the time. If you encode using average bitrate (which essentially fixes the filesize), slower settings eek out more quality in that same filesize. If you use "constant quality" (the RF values), slower settings tend to give smaller filesizes with similar quality - this isn't written-in-stone, and gets really messy...
Taking a gander through https://mattgadient.com/handbrake-rf-slower-speeds-craziness/ might help you see why I say it gets messy. It also shows a few size/quality results which might help you wrap your head around the effects a little.
Bitrate is certainly a measure of how much data there is per second. Higher values don't always mean better quality though, because it depends on the settings that were used for the particular video. A very easy way to see this in practice would be to encode 30 seconds of your BluRay video using the "Ultrafast" preset at 1000kbps (average bitrate, 2-pass). Then encode the same 30 seconds using "VerySlow" at something a little lower - say 900kbps (average bitrate, 2-pass). Watch them both (both should look ugly enough that which one is better should be obvious). The 2nd one has a smaller filesize and a lower bitrate (since we set those manually via the bitrate), so less data stored. However, because we've used a slower setting, the encoder was able to make better use of that limited amount of data and it should look better and less blocky. If you can't tell a difference, drop both bitrates by a couple hundred - most BluRay sources should start blocking by the 1000kbps mark, but every source is different.
As to the bitrate you're seeing during playback, note that Handbrake spits out a variable bitrate file that can fluctuate wildly (hence the average bitrate part), so never rely on what you see at a specific point. A black scene (fadeout) will often be very low. And a highly lit scene with a lot of detail will often be quite high. Even when comparing the same scene between sources: because slower settings in Handbrake can utilize better motion estimation, can add more reference/b-frames, etc, it's very hard to get a firm grasp as to how and why bitrates in a certain scene differ between encodes.
Anyway, hopefully some of that helps a bit. As to which file to go with, personally I'd go with the one done at the slower of the 2 settings to get the most bang-for-the-buck, but I tend to aim for RF values that give me the rough quality/filesize balance I'm looking for and then just go as slow as I can handle. It sounds like your approach/methodology might be a bit different, so go with whatever you feel is best based on what you're looking for with the information you have. Good luck!
With that said I'm having a hard time converting a regular tv show mkv file to mp4 without the file size increasing more than the original size.
File: 289.1mb
Settings:
RF: 23
Preset: Very Slow
Tune: Film
Profile: High
Level: 4.1
Output: 376mb
--I've also tried Tune at 'none' and the file is still big. Can you please help me out? Thank you very much
Trying to re-encode a video, particularly one that's already been encoded to a small size, can be a little perilous and you often start running into quality vs filesize issues very fast. The source being pretty small (and likely with a fair bit of lossy compression in there) to begin with is on top of the whole "making a photocopy of a photocopy of a photocopy...." issue.
If your source was already done in H264/x264, there's probably not a lot that you can do settings-wise. I haven't encoded anime myself, but you could give Tune:Animation a shot and see how it looks, though I doubt it'll knock the 100mb off that you need... you might be stuck increasing the RF value and perhaps dropping the audio bitrate a little if you really need the size to get close to what the source was. I suppose you might be able to get away with a little resizing too if all else fails and filesize is of the upmost importance.
Note: I've read that using the 10-bit variant of x264 is somewhat common in the anime community - if that's the case, you'll probably have to eat the extra filesize in Handbrake to avoid banding since it won't currently do 10-bit AFAIK (and since most devices don't support 10-bit, I wouldn't expect that to change anytime soon).
However, if you're really lucky and:
- The source is in H264/x264
- The source audio is MP3, AAC, or something else supported by the MP4 container.
- You're on a Mac
...you can download Subler, which will let you open the source MKV and re-save the video into an MP4 container. File size will be almost exactly the same, and it won't recode anything (so quality will be identical - it's literally just changing the container). I'm not sure if there are Windows/Linux variants/equivalents of Subler, but it could be worth a look for something else that'll also let you open an MKV container and save to an MP4 container.Of course, your best bet is to try and encode from the original source if at all possible. Good luck!
All of my settings are pretty much based on your guide item for item and I'm using the nightly build from just a couple nights ago.
I think I sorta see the more efficiency given more time give a better video stream but the smaller size at the same time just makes my head hurt - less physical bits should mean less information is being stored...
... in other words, I wished HB and it settings scaled quality and file size linearly in all cases so making a selection between params was a snap.
sigh...
drc :)
How important is the average bit rat as revealed by something like MediaInfo?
drc :)
It depends on the context. In the basic form: (average_video_bitrate + average_audio_bitrate) x video_duration_in_seconds ~= file_size. There's a little overhead as well for the container, metadata, etc., so the file size is generally slightly larger.
It can also hint at a possible level of visual quality, but you'd need to:
- know what encoder was used
- know what settings were used within that encoder (MediaInfo will spit out most of these for encodes done through Handbrake)
- have a notion as to what the source's resolution & complexity was
...to be in the right ballpark. 2 videos with the exact same bitrate can potentially vary heavily in visual quality based on a difference in even 1 of those 3.... I'm working with episodes 1 and 2 from the blu-ray of the Supernatural tv show season 1, disc 1...
... I'm using Handbrake, started with High profile and tweaked everything to match what's in your guide HOWEVER I'm doing pass through on the best audio track...
... here are the results from various preset speeds - time in minutes or hours.minutes, file size in gb, and average bitrate as revealed by MediaInfo:... so now with this info and these stats - do you think the average bitrate as revealed by MediaInfo is of any use as a measure of video quality?
drc :)
drc :)
Thehttps://mattgadient.com/handbrake-rf-slower-speeds-craziness/ post I'd mentioned earlier addresses what you're seeing. If you were to put your bitrate results in a bar chart, you'd see a resemblance to some of the images I have in that writeup (Test1-Test3). Short answer though is that the bitrates you're seeing when using different speed presets are not a reliable indicator of quality.
Topic: Old B&W Film (i.e. documentaries, etc.) I'm so glad I found your "community" -- thank you for taking the time to do this. I found one other decent "manual" which has been invaluable, except it didn't cover what I'm looking for now. I typically want good quality, good sound (if possible) and have the time to wait. . .why have a high-def TV and surround sound if you can't enjoy it? So, I really relate to your "Pick Two" example (for business we say, "Quality, Time, Money". Pick two). What I really need, and can't find, is how to set Handbrake for old B&W video . . . like from the 1950s. Many of these are documentaries . . . some are a compilation of still photos [read: slideshow] mixed with film (ok, that's somewhat redundant, but I think you know what I mean), and some are just old B&W movies. Naturally, they're quite grainy, which I expect. But "grainy" does not mean "pixelated" -- which is what I'm getting. I don't expect high-def from these types of film but I would like a good viewing experience. Just in case you wonder (and maybe to save time), I have a custom-built "rad" (not RAID) PC, relatively speaking to the typical PC set-up (ok, maybe the SUPER-gamers won't agree). So, I am wide-open to suggestions, although I picked "two" from your list: Quality (No. 1) and Size (No. 2 but Time could be No. 2). Can you please suggest some settings or variations I could try? I've tried a few, but to my great disappointment.
My sincerest appreciation,
txblush
In the "Filters" section of Handbrake (just a tab in Windows - if on the Mac, the Picture Settings button at the top and then Filters), there's a Greyscale option. Depending on your B&W source, it might have some unnecessary chroma (color) information in there that might be working against you to some extent. Try a quick test encode using Greyscale to see if it helps at all.
Beyond that, grainy video is always tough to deal with. 2 main routes that you might want to consider:
- Use a slightly better RF value (smaller number) than you've been using, and set the "Tune" to "Grain". This will usually help to retain the grain nicely (as in, not all pixelated), but unfortunately it will make the file size pretty large because grain is very expensive detail to keep. The more you slide the RF to the right, the better it'll do retaining the grain.
- Try to remove the grain via denoising. This will usually get the file size waaay down, but obviously it depends on whether you prefer grain, don't like grain, or don't care too much either way. This is also set in the "filters" section of Handbrake. You'll probably need to use custom values to attack it well - I have a denoising writeup that might help. You'd probably want to start with a few tests focusing on temporal denoising first, with some possible spacial to clean up anything left over, but it's hard to say without seeing your source.
#1 and #2 are an either/or thing. One tries to retain the grain, the other does the opposite, so I wouldn't be inclined to combine "Tune Grain" with Denoising. Try each individually with some test encodes if you're not sure.Note that if #1 results in things looking *worse*, it's very possible that the x264 Profile/Level aren't set correctly for whatever device you're using to play it back through your TV. If the level/profile are too low, it can restrict the bitrate which can cause blocking. If it's set too high for your device, you'll get pixellated macroblocks (a good software player like VLC will playback fine on the computer in that instance though, so play it back on a computer to rule out that possibility).
Good luck!
I'll check back in with the results, especially for anyone else who tries to do something similar.
Thank you!
Thanks for all your time.
drc :)
For example I did my first blu-ray movie at Medium and went from 19 gb to 6.x gb...
... some movies I've acquired already in .mkv format are upwards of 15 or 25 gb SO is there anyway if I can tell if they were transcoded at all AND what will happen to an .mvk that perhaps was done at SuperFast if I re-transcode it at Medium to save additional file space?
Finally - why is the Handbrake logo a pinapple and an umbrella drink? :D
drc :)
As to your question about re-transcoding a video, the important bit is that you're making a copy of a copy, which results in the same downsides you'd see in a photocopy of a photocopy. You can certainly recode at a slower setting and/or at a weaker RF value to save space, though encoding from the original source material is always best if you want to retain as much quality as possible.
I found another MediaInfo tip - check the video bitrate. While you're already pointed out it's not a true measure of quality in many/most cases, the tip said if it's in Mbps then it HASN'T been transcoded but if it's in Kbps then it HAS ben transcoded - would you agree?
And... why is the Handbrake logo a pinapple and umbrella drink?
drc :)
So I made my first DVD transcode, an old Dark Shadows disc - the entire 3.x hours - using the same settings I've been using for blu-rays except I changed the rf to 20 from 22...
... in general it looks good BUT here and there when someone moves, even something a simple and turning their head, there's a slight bit of stair step effect on the side of their face which isn't in the original disc video.
Any thoughts? Are there other options I should change the preset from Medium to something else? Change the rf again up or down? Or...???
drc :)
With the time set to that 60 second period, try with the same settings you used for the full encode first (just to make sure the result of the test encode is the same). Then try with the RF set to 10 (something a little more extreme like 10 will generally help rule out it being an issue with the RF value). Then turn back the RF value and instead try tweaking some of the other areas like H264 level/profile, Tune settings, and speed settings.
It might sound like a bit of a lengthy process, but after you've set up the first one and added it to the queue, all you have to do is change a setting, adjust the filename to be "testmovie-RF10.mp4", "testmovie-tune-film", "testmovie-slow-preset", etc., and keep adding to queue. 60-second DVD clips encode pretty darn fast, so you're usually only looking at a few minutes to create the test encodes and then a few minutes to watch through and see which setting was responsible for the issue. Good luck!
Might be because the video is so old (late 60's), or it's black and white, or some other factor - I'll be watching for artifacts and experimenting with settings as I rip newer tv shows and movies from DVD.
drc :)
When watching 4:3 videos from my DVD Player over plain video, my Mits tv has a "stretch" mode that makes the picture fill the screen but the people aren't extra tall or wide...
... Q: is there a picture setting in Handbrake that will take a 4:3 and format the resulting .mkv the same way so when I play it on my blu-ray player over hdmi instead of the square picture in the middle of the screen it will fill the screen *without* any stretching distortion issues?
drc :)
Problem is, you've lost some of the picture by doing so. Consider that movies have generally been filmed in widescreen. To make a fullscreen version for TV/DVD, they often did what's called "pan and scan", which is essentially taking a square-ish (4:3) box and floating it around within that widescreen frame to make sure the important detail was focused, panning to the left and right as needed. Note that another method was having indicators in the camera that showed both a widescreen box and centered fullscreen box, and when filming they'd simply try to make sure that the important part of the scene was within both.
Anyway, by cropping, you risk cutting off detail important to the scene. Couple examples to show you what I mean:
Example #1: in Armageddon, when Bruce Willis and the entire crew are walking/strutting towards the camera in a scene, the widescreen version of the DVD captures all of them. In the fullscreen version of the DVD, you only see Bruce and the person to the left and the right. It's a full-body shot, and if you then crop that fullscreen version to be widescreen, you usually end up cutting off part of their heads. Unless you *only* crop from the bottom, but while doing so makes that 1 scene look good, it causes problems in the others (if you were determined, you could pan-and-scan the entire movie in a video editor, mind you).
Example #2: in Star Trek TNG which was recorded specifically for 4:3, there are a number of full shots of the Enterprise bridge. Worf often just makes it in the top, and Data/Wesley just make it in the bottom. Any cropping starts chopping them off. I suspect it's one of the (many) reasons that the new BluRay editions that were released recently maintained the full-screen aspect ratio instead of being converted to widescreen.
...so all that to say, you could crop in Handbrake to reproduce the effect of your TV. Or if you were trying to strike a balance between cropping and very slight stretching, you could combine cropping with a custom aspect ratio. But beyond the visual issues, you've now got a widescreen video, and there's no "going back" to the original look so-to-speak, unless of course you re-encode from the source. I personally recommend against it, but everyone has their own preferences here, and if being widescreen is a pro that outweighs the cons for you, by all means, give it a try and see if you prefer it.
""Stretch" mode is the best bet -- it mathematically makes the center of the screen as close to 4:3 as it can, while it lets the outside stretch and distort more"
... that's the effect I'm after - no zooming, no cropping, no bars top bottom or sides - a stretch sorta like pulling a piece of taffy where the center remains untouched and the edges where it's being pulled show the stretching.
For most 4:3 images it's a true winner - in all my years of watching Mits tvs I've never noticed anything odd looking even at the far edges of the picture in this mode.
Thoughts?
drc :)
Thanks for the guide, I am using Handbrake 0.9.9.5530 and I need to create 3 versions of the same video for network connections that are fast, medium and slow (slow being 256kbps).
Can you give me a quick tip on how to go about doing this please? My original video is an mp4 video, the bit rate is 1389296, frame width is 1024 and frame height is 576.
Thank you.
Yoshi
Thanks again.
Yoshi
I'd begin with the audio bitrate in the Audio section - try a Mono mixdown at as low a bitrate as you can handle.
In the video section, use Average Bitrate - not Constant Quality. Start with a setting of (256 - audio_bitrate). 2-pass encoding (turbo first pass is generally fine though non-turbo will be a little more accurate at hitting the target bitrate). Check the "Web Optimized" box. I'd go with veryslow for the speed - possibly placebo if you have the time to eek out every last bit.
Encode a test video and see how it looks. If visually it's very poor, you'll have to either reduce the video resolution and/or steal a little more bitrate from the audio. You may want to do some denoising from within Picture Settings - picture will get softer but overall quality will likely improve. It's very likely that you'll have to reduce the video resolution regardless.
...Assuming you end up with something watchable, simulate some 256kbps streaming. You should be able to find network utilities that'll let you clamp your speed. Keep in mind that the video will probably end up being a little over 256kbps due to the overhead of the container, so depending on how strict that 256kbps limit is, you might have to undershoot your bitrate a little. The bitrate itself will also fluctuate throughout the video - this probably won't be much of an issue if whatever you're streaming with/to allows pre-buffering because it'll grab more when the bitrate dips and take from the buffer in the heavier parts and it should average out to 256-ish in the end anyway. That said, if you're in a situation where the client won't be able to buffer, you'll want to look into clamping the peak bitrate via custom options - I don't remember them off the top of my head, but they should be listed in the x264 docs.
...
Once the slow version is done and working, the others will seem much easier. You can essentially up the average bitrate, increase the audio bitrate, restore some video resolution, reduce denoising, etc to hit each mark. By that point, I suspect you'll have a good idea as to what you want to "turn back up".
There may be other things I've missed, but that's what I'd start with, anyway.
Good luck!
I'm using a HB nightly build from a couple weeks ago and still workin on my Dark Shadows collection.
Each DS disc is 10 episodes in a single 3.4x long title with chapter breaks only at the episode breaks.
I began to notice as I worked through a disc that when the credits rolled and I hit next chapter it started jumping into the next ep instead of right at the beginning sometimes off by upwards of 2 minutes.
Here's what I discovered this morning - for example chapter 2 HB says the chapter length is 20.xx in length but when I play that chapter and get info from my Oppo blu-ray player it says the chapter length is 22.xx - off by 2 minutes.
All the episodes are in the correct order and all the opening/ending credits are correct it's just that one or more chapter lengths are wrong thereby throwing off where the stops should be.
Ever come across anything like this?
drc :)
I have a fairly puzzling situation that I was hoping you might be able to help me with.
I'm fully aware that Handbrake cannot 'burn in' .srt files to a video file, for hardsubs, so I've followed advice from numerous forums on how to convert .srt to .ass/ssa (Using Aegisub).
I then put the new .ass/ssa file back into my .mkv file (Using Mkvtoolnix) and then run the .mkv file through Handbrake.
I'm assuming I do this in just the same way that Anime fansubbers do, however in an attempt to avoid compatibility issues I haven't used any fancy fonts in my .ass/ssa file, just standard Arial.
I've followed your guide (You helped me out before and I really appreciate it) and then checked the boxes 'Forced Only' and 'Burned In', and.... nothing!?
I've tried different video files, I've tried checking just 'Forced Only' or just 'Burned In' or neither (I've read that occasionally Handbrake has issues with box checking), I've tried reinstalling Handbrake, I've tried single pass and two pass.... and now I've run out of ideas.
I'm 99.9% sure I'm doing everything correctly, technically it should work but it just doesn't. The .ass/ssa file works fine when it is in the 'soft' format, but when I try to hardcode it the subs just disappear.
My Macbook Pro is a few years old, but currently up-to-date and definitely capable of completing this task, and I'm at a total loss to know why it will not.
Like most people, I need hardsubs for tablet and USB enabled Blu-ray player playback.
It would be great if you could help, but if not I guess I'll have to humbly ask around on some of the Anime forums.
Thanks,
Thomas
For some reason, I thought that the .srt limitation was an oddball situation that only applied when using the "Add External SRT" button. Instead of converting to .ass/ssa, try putting the .srt into the MKV and see if it'll let you burn it in. I could be wrong, but it's worth a shot.
Beyond that, assuming the added subtitle track shows up in a video player like VLC (and in Handbrake's subtitle list), I'm not sure what might be causing the issue. Let me know how it goes.
My issue is that most of the time Handbrake puts the TS folder files into one MP4 file, but on some movies it will only allow me to re-code one vob file at a time. All settings are left at default and the only change is the movie itself. Any input on how to get around this?
Thanks
Anyone that can help, thanks!
If it's simply a long period of time before the video starts playing (but once started it plays fine), try selecting the "Web optimized" checkbox.
On the other hand, if it's constantly pausing to buffer, it could be that the network can't keep up. The peak theoretical bandwidth of wireless N works out to roughly ~75 megabytes per second, but distance, noise, other devices saturating the connection, and a number of other issues can cause that to plummet quickly. Doing a test encode at a much lower bitrate (or higher RF value) could help rule this out.
The other possibility is that the encode is too complex for one of the devices to decode in realtime. To attempt to rule this out, try a test encode at H.264 Main Profile, H.264 Level 3.0.
Note that depending on the settings you've been using, lowering the bitrate can also reduce the complexity (and choosing a lower profile/level can lower the bitrate), so if it's either a bandwidth issue or a complexity issue, it might be difficult to determine which one. Ideally, plugging into a wired connection is the route to go to rule out a bandwidth issue, but obviously that would only work if both your devices & your router have a wired ethernet port.
Good luck!
It is possible to achieve CBR audio using AAC (faac) codec?
If so, how? Thus far have only gotten VBR results. TIA.
My question relates to picture settings.
I am transcoding for an android tablet with a resolution of 1024x600
If the source format is larger than this, are there any benefits to reducing the resolution to match the target device? (I'd want to maintain the aspect ratio, I don't want to stretch or squish anything).
Also, do you have any recommendation on settings that will reduce cpu/gpu usage on target device to optimise battery life? e.g. reducing framerate from 30/60 down to 24fps
The main benefit to reducing the resolution would be a lower filesize (or you can bump up the quality and maintain the same filesize if you prefer) and it's a pretty sensible thing to do if you only intend to play the video on that tablet (and/or smaller devices). Anamorphic Loose in the Picture Settings would be the easiest way to go about doing this while maintaining the aspect ratio. Of course, a lower resolution might not look so great if you play back that file on a 1080p TV, computer, or any other larger device down the road so keep that in mind.
Most newer devices decode H264/x264 in hardware - if your tablet does (and the player you use supports sending it through hardware to decode), tweaking settings probably won't do much for you in terms of battery life. On the other hand, if your device is decoding through software, some tweaks might help. Checking the "fast decode" box, and using a lower H.264 Profile/Level (Main/3.0 instead of say... High/4.1 as an example) will often use tamer settings. File size will be larger, but it shouldn't take as much power to decode. Dropping the frame rate as you suggested should help too, but I personally tend to avoid changing the frame rate unless absolutely necessary, as it's possible to introduce stuttering/choppiness.
Your guide (including the comments section) has become my go to resource. Can you comment on on 3 areas.
1. I use media info/media tab to "look over" my files and have noticed that it displays frame rate (avg?), max frame rate, and min frame rate. My mp4s files are never 24/25/30 (or their more precise representations), and usually have min frame rates in the teens- what does this mean (especially concerned about the min rates)? Is this a transcoding horsepower issue (laptop i5 @ 1.7GHz/win7/8Gb RAM/Vidcoder 1.4.25.0.)?
2. The HB wiki ( https://forum.handbrake.fr/viewtopic.php?f=6&t=19426 ) indicates that the h264 tune option for "film" uses deblocking of -1,-1, "grain" uses -3,-3 and "animation" 1,1. HB and Vidcoder only have +5 increment slide bar options (which you comment on negatively). I assume that deblocking off=0=no deblocking processsing. What is happening at negative settings and how does that relates to picture quality?
3. Some of my B&W TV series have what I consider unnecessary levels of grain. I'm just trying to take the edge off the grain and want to maintain good sharpness (file size rediuction is not my motivation- but I'll take it). You commment that at denoise 2-3;10 softness and motion smear become problems- are these settings linear or more like the video quality rate factor? I am trying custom denoise of (1;1;7;7)- any thoughts?
Thanks
1) Nothing to do with the power of the machine (even if it were a slow machine, it wouldn't start dropping frames because of it - it would just take longer). It's likely that somewhere along the encoding process (whether on your end or in the source you used), duplicate frames were detected so instead of saving all the duplicates, it saved 1 and adjusted the instantaneous frame rate so that it displays that frame for the proper duration. Nothing to worry about unless something went wrong during that process (which would usually show up as severe stutter/choppiness if so).
2) There are 2 different types of deblocking in HB. The one you refer to with the "tune" options (-1,-1 etc) is a flag that tells the decoder how much to deblock upon playback. There is nothing inherently negative about that one unless pushed to extreme values. The easiest way to think about it (not correct, but easy) is to pretend it's like the "sharpness" control on older TV's, with something like (-6,-6) being sharpness turned up all the way (which in this case might expose blocks), and something like (+6,+6) being like the sharpness control turned all the way down (with the image starting to look soft/blurry).
The deblocking that I referred to with a negative connotation is the one in the "Picture Settings". Despite sharing the same name with the other "deblocking", it's a completely different setting and is a filter that's run against the source video before the transcoding takes place. Note that while *I* dislike it, it's worth nothing that it's just my preference/opinion. Others have found it works very well for them, so feel free to give it a try if you think you have a video it might help.
3) 1:1:7:7 is a good starting point (run a test encode of a 30-second section to see the results). Being a B/W show which is presumably older and not terribly crisp to begin with, you can probably get away with pushing up the spacial setting a bit (3:3:7:7 or even 4:4:7:7 if you're working from a 480p+ source). You could try pushing the temporal to 10 as well, but watch for signs of ghosting. This is one of those areas where you pretty much have to trial-and-error it out because different sources require different settings, and your own personal preference is going to be the driving factor. Lots of small test encodes as you tweak settings is the way to go. As to whether the settings are linear or not, I'm not 100% positive but I *believe* they are (or are close enough, up to the point that side-effects become unbearable, beyond which I haven't really tested).
Good luck!
cheers
Love the website...has been so helpful thank you. A question for you...been using DVDfab for a while to make Bluray discs (25GB) from whatever size the real BD is. Sometimes no compression is needed so obviously no issue there. However, when there is compression, I have no idea what their settings are...but does it really matter? Another way of asking this question is there a bitrate (average - file size determined to 23.307MB) where the x264 preset encoding speed doesn't really matter...ie: anything over 15000kb is gonna be so good you won't notice the difference?
I noticed handbrake only has mp4 and mkv file output...which is fine if I just want files...but if making BDMV folders for BD-R discs wondering if you think the stock DVDfab settings will really make a difference and/or should I create a mkv with handbrake to make a 23.307MB file and tsmuxer into a bluray folder.
Can handbrake output to a m2ts file or BDMV folder?
Thanks so much
Ben
- Make sure you're using x264 and didn't accidentally choose MPEG2/4.
- If using average bitrate, lower the bitrate.
- If using constant quality (RF), lower the slider (increase the value).
- It also wouldn't hurt to check the audio settings to make sure nothing wacky is going on there.
Note that if your source was already encoded and you're re-encoding it with the intention being that the output file is the same size or lower:- If the input file used average bitrate, you can't exceed whatever was used. For example if it used 1000kbps and you used 2500kbps, your output would be ~2.5x the size. You'd need to use < 1000kbps in that case to obtain an improvement in file size, in that particular example.
- If the input file used constant quality, the rules/math aren't as hard-and-fast here, but generally speaking if the source was done at say... RF24, the only way you're likely to see an improvement is if you use the same value or larger value (RF24, 25, 26, 27... etc). Using a smaller value like RF18 would generally result in a much larger file-size. I say generally because there are a ton of other factors that come into play when it comes to using RF value and the output filesize, so keep that in mind! You may have to do a couple test encodes at different settings to get a feel for how that particular source will behave at different RF values.
- If the encode settings the input file used were already pushed to the brink (the absolute lowest bitrate or highest RF value possible before severe visual degradation would start taking place), you're almost certainly going to notice visual quality loss even by exactly matching, or sometimes even approaching the settings that the source used. x264 is a lossy form of compression, after all.
Hopefully something in there helps. Good luck!Thanks for all of your tips and info.
Mainly I use handbrake to convert my dvd/bluray collection into digital for my NAS. I was doing a full copy but files are awful big and 12TB is not a lot of room for over 800 sets (counting things like MASH: Martinis and Medicine as 1). I was really hoping the 265 codec would improve quality and decrease file size (which is exactly what it should do) but in my testing i have not found this, at least in Handbrake. I usually end up with similar file sizes as 264 or not very noticeable differences in quality.
Ramble ramble ramble lol ok, well hopefully you will post a 265 guide in the near future ;)
As to the difference you're seeing (or not seeing), keep in mind that x264 is very mature. A lot of brilliant people have spent a lot of time working to make it the amazing encoder that it is. H265/HEVC/x265 on the other hand is in it's relative infancy - a "fair" comparison would be against an early H264 encoder (and I'm sure HEVC would easily win there). I suspect it may take awhile before it handily beats out the current x264 implementation.
I'm wondering if one of these methods would encode a "better" quality or if in theory they should be the same.
Encoding the same source (40.00GB) with exactly the same settings and using veryslow except that for file #1, use a fixed file size (average bitrate) say for example 20.00 GB, and for #2 using trial and error finding the Constant Quality setting that yields a file of the same size.
My thinking is they should be the same quality. Or will constant quality always yield better quality as it will emphasize a more stringent bitrate on areas that both need and don't need it?
Thanks so much
love your guides!!
Ben
Could someone please post their settings as a commandline parameter?
Best Regards,
Morten Kristensen
Like everyone else, I just want to leave a note of thanks for explaining the settings on Handbrake.
Too bad handbrake quality isn't very good when re-encoding some files to MP4 (720 x nnn) to be played on a DVD player that can only support DivX.
Thanks for your page again.
I have noted on many guides, including this one, that the recommended RF setting (at least as a starting point) is 20 or 22. Isn't the default 14? Anyway, the point has always been made that this setting should be determined based on two factors: namely the size of the file and the quality of the picture. While that is true, I think it is also important to consider the resolution of the video. As the resolution decreases (and the file size falls), the quality has to be increased to make up for the lower resolution.
A practical example is when encoding a file to be used for playback on a TV via USB. The standard requirement for TVs that play DivX is that the video resolution must not exceed 720x576. (A 1080p or a 4K TV can DISPLAY very high resolution from digital TV, DVD or BR discs, but it cannot PROCESS compressed video files that have resolutions higher than 720x576.) So one must encode at this low resolution. 720 is the maximum width, and the height depends on the aspect ratio of the video, with 576 as the maximum.
At that resolution, the quality is horrible when played on a 1080p widescreen, which scales the picture back up to 1080p. To compensate, the quality must be increased by lowering the RF setting. I found a value of 5-10 is preferred. I usually use 7, where a 2 hour movie will result in a 1GB video file. This will give you something that is not too much below 720p quality, despite scaling up the video from a far lower resolution.
In conclusion: When encoding for USB delivery of video content to a 1080p TV, using DivX standards (MP4 format, MPEG-4 video codec, MP3 audio codec) and set the video resolution at no more than 720x576. This means the TV will scale up the low resolution back to 1080p and the quality is horrible. So increase the quality by decreasing the compression, and lower the RF to 10 (for a small file) or 5 (for a larger file). 7 is probably best for most cases (2hr video is 1GB).
Hope my subjective experience helps others, and any feedback or correction to any errors I might have made above would be welcome (though I don't check this site for replies).
I'm very happy with the quality EXCEPT color banding, usually in the background on darker scenes. If I play the bluray in my bluray player, I don't see the banding, so I'm quite sure it's related to handbrake.
Is this a case where I should play with denoising? Or do you have any other advice?
Denoising won't help with color banding (it'll likely make the banding worse). Examine the source closely (pause a scene that showed heavy banding after encoding). Does the source have a nice gradient, or does it actually have banding that's simply covered up by noise?
If it's the latter, you can try the "grain" setting - should retain the grain that's covering up the banding.
If it's a gradient that's just not being retained, the following can help reduce blotchiness in dark areas:
no-fast-pskip:no-dct-decimate(plunk that into the "custtom settings" box).
If neither of those work, sometimes the only thing (aside from trying ridiculous RF values) that retains a nice gradient is using a 10-bit version of x264, or possibly a look into x265. 10-bit encodes are a whole other topic - a quick Google/Bing search will probably bring you to some Anime forums (where 10-bit encodes are popular) where you can find some more information. Note that 10-bit x264 encodes aren't supported on most devices.
Good luck!
However, there's one thing that I have noticed, when trying to convert music videos from various sources. I noticed that I get choppy video playback when there's horizontal movement (and sometimes on vertical camera movement as well) when using your suggested Filter settings (Detelecine: Default, Decomb: Default). So I tried to test with different options there, and now I have found settings that has been working every time if I find that those default settings are producing choppy playback:
Detelecine: Off
Decomb: Bob
With those settings I am getting smooth video playback. If I look closely, the picture smooths a bit during rapid camera movement, but that is hard to notice, and I value smooth video playback every time over choppy video playback with always-sharp picture.
I am not sure why Handbrake's Default filter settings doesn't seem to work well with music videos (I don't seem to have this problem with movies ripped from DVD!), because choppy video playback results sometimes even when the source is not interlaced.
I notice that "faac AAC" is no longer an option, at least for Windows users.
Which do you recommend: "AAC (avcodec)" or "AAC (FDK)"?
I'm still running through a bunch of tests in 0.10, but for the most part the items mentioned here still appear to hold true. A few notable exceptions:
- If denoising, the format for HQDN3D custom settings has changed and an additional preset has been added. A new NLMeans denoiser is also available (which is great), but custom settings for NLMeans are much more complicated (more settings, specific ranges for certain settings, and less of a clear separation between spacial/temporal than with HQDN3D), so I'm still working through a pile of test encodes with it.
- H265/x265 is now an available option. Test encodes here are taking a long time (partly because the encodes I've been doing on a 1-hour episode from BluRay have been taking 24-36 hours at the settings I've gone through so far). It uses an RF system that from what I gather has been largely ported from x264's RF system, but the end quality at a given RF level is different between x264/x265, so you can't really just carry forward whatever RF values you've been using. x265 is still relatively young, but is improving at a quick pace so any new write-up I do here would be fairly general to make sure the write-up has a shelf life of more than a few months.
- Advanced settings is disabled by default (in the OS X version anyway, I haven't looked at the Windows/Linux versions yet to see if this was a platform-specific UI change). Can be re-enabled in the preferences.
As to the AAC codec, I've been encoding on OS X so far (haven't popped into Windows yet). I did a bit of looking into both avcodec and FDK, and FDK seems to be considered the higher quality one more often than not, as it is supposed to retain some lower frequency data a little better and has apparently been considered an alternative (successor?) to Nero's AAC encoder. But honestly, opinions/preferences when it comes to audio encoders tend to vary quite a bit, and it's been a long while since I've looked deeply into audio encoder comparisons so it might be worth doing a couple tests or check out a couple audio forums to see if there's a solid consensus somewhere. Keep in mind that the AAC standard is so incredibly mature now that I suspect very few people would be able to tell the difference between any 2 modern encoders at standard bitrates - so it's probably hard to go wrong here.Keep up the great work!
_Use_the FDK_AAC_encoder_on_Windows_.
The FDK encoder is superior, and the inclusion of it in Handbrake is in my view the biggest improvement in Handbrake for many years. Well, that the inbuilt x264 presets are available is up there as well, but it was possible to manually configure the video settings to something good before that, while it was completely impossible to get descent audio without using ridiculously high bitrates.
Here's a listening test from Feb 2014, and as far as I know there have been no big improvements in avcodec/ffmpeg aac encoding since then (I could be wrong, please inform me if so): http://www.hydrogenaud.io/forums/index.php?showtopic=104471&view=findpost&p=857012
I might as well ask while I'm here.
I want to resize something with non-standard dimensions of 1814x1028 to 1271x720 in x264 but it never works. I wanted to ask how Handbrake makes it work (even if it changes 1271 to 1272 for some reason), which is why I was asking where to see the codes it uses while encoding.
Unlike some other x264 front-ends/wrappers/etc, Handbrake doesn't directly call an x264 executable. Instead, it's got it's own integrated implementation of the x264 library. So you don't really see a list of command-line arguments because things are implemented a little differently.
You can get a notion of the x264 settings it uses by looking through the encode logs though, and translate to x264.exe command line options from there. Look for lines in HB's encode log that begin with "encx264". Here's an example from a random log I just pulled up:
...you'll see the format (even of the unparsed options) is a bit different, but can probably translate fairly easily.
As for the resizing bit, I'm not 100% positive on this (someone can correct me if I'm wrong) but I believe Handbrake uses a separate resizing filter that takes place before the frame hits the encoder rather than making use of x264's resizing option. If that is indeed the case, the way to mimic it would be to resize the video via another program in your toolchain before the video hits x264.exe.
Anyway, if I can't get x264 to use those dimensions, I might as well ask about this green vertical line on the right side of my encoded videos. If I recall, I ran into a similar problem with something of unusual dimensions before. Would you know why it happens? I tried the EVR thing on MPC-HC and I tried using VLC. It still appeared, as if it was PART of the video.
Thanks for the quick feedback!
In rare cases, a modulus other than 16 can cause edge issues such as the green line (in Handbrake via anamorphic strict or anamorphic loose with a modulus of 2 for example). I don't know what the true trigger is or why it happens in some videos (and not others), but it's the first place I'd look. If you're using x264.exe instead of encoding via Handbrake, I'm not sure if there's an explicit modulus flag... if not, simply making the dimensions both divisible by 16 might be enough to do it (1280x720 or 1264x720 which should be needed anyway at mod16).
May be worth trying on a small sample of the video first to see whether or not it works. If it doesn't and you're still at a loss, the doom9 forums (if using x264.exe) are probably the best place to ask since there are a number of people there who know all the ins-and-outs of x264 and have a much deeper understanding of all the inner workings than I do. If the issue's in Handbrake, the Handbrake forums are worth a try - some of the devs were fairly active there last I checked and the community looked pretty friendly.
Good luck!
(edit: Note that if divisible-by-16 dimensions solves the green line but you absolutely need the 1272x720 display, you might be able to math out a custom anamorphic setting to squish/stretch the 8 pixels-worth upon playback)
It didn't support it last I'd checked, though I peaked through the forums just now to see if anything's changed. As far as I can tell, nobody's added it, but if someone wants to offer up a patch, it doesn't look like they'd be against it: https://forum.handbrake.fr/viewtopic.php?f=26&t=30717#p142860
To echo all the other comments here, thank you so much for this very helpful tutorial.
I am not nearly as experienced or knowledgable as everyone else here, so apologies if my question has already been answered/is very simple.
I need to convert a VOB file to something I can edit in Final Cut Pro X, but it is very important I don't lose *any* quality in the process, as it is for a video portfolio. I don't care about file size right now, as long as I can edit it. I will eventually upload the edited video to vimeo. Are the settings described above the best for achieving this? Should I even be using Handbrake for a totally lossless conversion (is that even possible)?
As to whether Handbrake's the right tool for the job... I'm sure there are other tools out there that might be a little more sensible for the conversion (perhaps something that would keep the original stream intact and just stick it in an FCPX-friendly container), but if you're just working with 1 video, Handbrake should do just fine.
cabac=1 / ref=8 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Please help. Thanks in advance and sorry for my bad English.
This guide is very interesting, but i have again some doubt (sorry for my english, i am italian)
I want to convert all my collection of bluray into .mkv h264 in FULL HD 1080p 24hz... Same as the source, but more compressed obviously...
I am using the HIGH PROFILE preset, and i change the RF from 18 to 15 and the encode to SLOW (i am courious to try also SLOWER or VERY SLOW)
I set also SAME AS SOURCE... But the doubt are for the VARIABLE FRAME RATE or COSTANT FRAME RATE... What i have to use for the Blu-Ray???
I see many, many many encode of bluray, and all are with COSTANT FRAME RATE... I am not sure to understand the difference for these two setting...
In the official forum (and you) the suggestion is for VARIABLE for default preset... But also with the full hd bluray?
Can you help me to understand well the difference?
I want to use these .mkv full hd with my iMac 27" (i5 2011) or with my Mac Mini (2.66 core 2 duo 2010) to my plasma tv and AV Receiver by Harman Kardon...
For the audio, i only use DOLBY-DTS/HD LOSSLESS pure (passthrought)
Best regard
Andrea
Variable is almost always recommended because it'll handle sources whether they are variable/constant, and will behave intelligently if you have a situation where detelecining/etc results in a modified frame rate. There's no real down-side to using variable, even if you know with 100% certainty that your source is constant.
There are cases where constant makes sense: if your encoder chain includes tools/formats that struggle to keep audio/video in sync on a variable source, if planning to toss the output into a video editing program that doesn't support variable rates, or if trying to work around some other technical restriction where you absolutely need a fixed or specific frame rate for whatever reason.
But most of the time, variable is a nice "set-and-forget" setting that automatically deals with virtually any source appropriately.
However, the conversion from a source MKV or MP4 file that had CFR that is now VFR after conversion has me worried which raises the question:
Should I have selected Same As Source with CFR?
In a case like yours there's probably no real downside to forcing CFR if you want, but I doubt you'd see any real upside either. One possible advantage to sticking with VFR though is it's within the realm of possibility that an encoder (present or future) may be able to identify scenes where you've got 2 seconds of static footage (an obvious example being some static CGI with no motion and/or intro logos where you could very well have a portion of video with 60 consecutive frames that are all identical) and may find it most efficient to simply encode 1-2 frames and temporarily drop the fps to 0.5 for that portion instead of doing encode-level stuff which may or may not be as efficient and could have profile limits imposed (B-frames etc).
I guess for me it really boils down to a mix of keeping things set-and-forget as much as possible, and trying to untie HandBrake's hands as much as possible so that it can always make whatever it thinks is the best decision. I see VFR as fitting both of those better than CFR.
That's just me though. And someone else might be able to come up with a really good argument for gravitating towards CFR wherever possible. And like I say, there's probably no real harm in using CFR for that video - if that's the route you'd prefer to go, by all means feel free to do so!
Thanks again and thanks for putting up such a wicked guide for Handbrake!
A quick question here I just noticed. It thought when using the same CQ# for example I used CQ16 for my tests, regardless of the speed the quality should be the same. The speed settings essentially just make the file smaller (slower speed) with the same quality.
However I first noticed it on 5 different titles, then to verify picked a few chapters on different sources for a good sample size. VeryFast is always the smallest file size, even when compared to Veryslow.
The first test was on 5 different full length movie titles on VeryFast and VerySlow. The VeryFast was smaller. Then I picked the various chapters and ran VeryFast, Faster, Fast, Medium, Slow and VerySlow and the other behaved like I thought they should but VeryFast was always the smallest.
???????????????
Should I assume then that VeryFast is actually not at the same quality (CQ16) like the others? Or do you think the VeryFast is at CQ16 and the others are just bloated or actually at a better Quality level? The VeryFast settings not only are always the smallest file size but by far take the least amount of time to finish?
Any thoughts?
Thanks
But my take home from the reading is: DON'T USE VeryFast unless you literally are leaving for a road trip in 42 minutes and want that movie ripped ASAP!!! And Use a CQ setting a little better (lower) than what you would normally use under medium or slow settings to get the same CQ.
Otherwise, if you have the time, use Slow or VerySlow...will give the best quality for a specific CQ#.
*(Editorial) On a side note, why have a setting called "constant" quality if it turns out it's not actually CONSTANT. A CQ20 on Veryslow is actually more like CQ22 on VeryFast??? That's not constant!!!
It's not truly perfectly constant because... well, it can't really be constant. The different speed settings enable/disable various features, adjust the number of b-frames, adjust the motion estimation method, etc. Each of those items throws a wrench into things. Actually, the only way I can think of to implement a setting that truly kept the output quality "constant" would be to pretty much have the encoder make multiple trial-and-error attempts (with the settings inflicted on the encoder by the speed preset) at different quantizer values until it hit a certain targetted PSNR or some other arbitrary quality standard. But that would add massive overhead (time) to the encodes to the point where there would be little sense in even having quicker speed options to begin with. And since the encoder uses a number of tricks to improve *perceived* quality, it would really be hard to have a consistent system even at that.
That said, the "constant quality" term really is close enough most of the time for the majority of uses. CQ20 vs CQ22 may be a measurable difference, and even enough for some people to visually notice, but we're also looking at one of the "worst case" comparisons there that you're only going to come across naturally if you're using different speed settings for each and every encode. Even at that, you're still at least in the same ballpark though: it would be a very different situation if one speed setting at RF20 was the equivalent to another at RF28.
Anyway, my recommendation in the end is generally to pick the slowest setting you can handle (to get the most "bang for your buck" when it comes to file size), and stick with it. Sources certainly aren't consistent, but by being as consistent as possible with settings on your end, you'll limit the wrenches-thrown-into-things when it comes to your output (as much as humanly possible anyway) and have a pretty solid idea as to what X source will look like at the RF value you've chosen.
Both get the same aspect ratio the end of ~2.32:1 (Star Wars was originally filmed at 2.35:1), but you lose 56 lines of vertical detail if you use anamorphic none - a 15% loss. Not the "vaporized" type of loss, but the "resized" loss. Once the black bars are removed you end up with 716x308 if using anamorphic none, vs 716x364 (scaled to 848x364 via anamorphic) if using anamorphic loose/strict. The latter is the "correct" value (no resizing), as the source had 480 lines to begin with, and 116 were cropped. (480-116=364).
Just about every video player handles the anamorphic flag, so that's usually the way to go because you retain all the detail possible (no unnecessary downsizing). However, there are some players out there (usually older ones) that don't handle it and will try to stretch the image, which will get you a wonky looking display. It sounds like that may be what you're coming across. Video editors can be picky too. In those cases, you might be stuck using anamorphic none. But those cases are generally few and far between.
As to the source (TV vs film) it really shouldn't matter as long as the video player adheres to the anamorphic setting.
You mention that "A frustrating number of TV shows that are shot in widescreen are, for some reason, squished into a fullscreen format on DVD". The reason for this is that the DVD spec limits the resolution to a max of 720x480 (for NTSC anyway: PAL is a bit different), and whether it's a TV show or a film, that's the most space that can be used. Thus it's common for a TV show (or movie) to make use of all the pixels they can (which results in a 3:2 aspect ratio at 720x480) and either letterbox the content, or pass an anamorphic flag to the DVD player. The latter is more common these days, because letterboxing wastes lines on black bars that could have instead stored detail and simply been resized anamorphically.
Anyway, hope that clears stuff up a bit!
after some rips of my bluray i am back here...
at the moment i rips the bluray with the personal modified HIGH PROFILE. i have current set the RF to 17 for all BR, but in some case i need to reduce or increase the value...
for example the bluray of PREDATORS (2010), i have used RF 18 and encoder speed to SLOW, and the result of TOTAL BITRATE is 19,2 Mbps and the size of mkv is 15,77 GB... THE AVENGERS same setting, but RF 17 and the bitrate is 17,5 Mbps and size of MKV is 18,71 GB...
i don't understand why some BR ripping with the same RF factor are big/small respect another different BR...
about the rip, in the ENCODER OPTIONS i see TUNE setting... i leave always to NONE... but it's a good choice? there are many option (FILM, ANIMATION and other)... i have better result with the FILM setting?
when i play on my iMac 27" at full screen (2560x1440) it's really difficult to see the difference to the original BLURAY...
i have try also to my PLASMA SAMSUNG HD READY (yes, hd ready... but it work very good) and the 1080p rip look very good...
about the audio, i leave all in PASSTHRU... but... the only problem is the DOLBY TRUE HD audio track... there is NOT passthru for this audio track... how i can extract and use these audio format on the ripped bluray?
best regard.
Andrea
Different sources at the same RF value will often result in fairly different output bitrates (it's normal). Sources that have more noise, detail, or a lot of stuff going on tend to result in higher bitrates. The PREDATORS video you encoded likely just falls into that category: it simply needs a higher bitrate to retain the detail that the encoder wants at the RF value selected.
As for the audio, it's been awhile since I dabbled in passthrough options. However, everything doesn't always "line up" the way you'd expect (Handbrake might just say "DTS" instead of "DTS MA" in your example). You may just have to make some best-guess choices. If there's something it absolutely won't let you pass-through, you may have to downmix to something else. Trying to pull the audio separately with another program and re-merge it is often a pain (higher chance of running into sync issues too), so if you're intent on getting something that HB absolutely won't let you pass through, you may want to look into some other encoding programs.
about the audio passthru... i see another strange detail...
in the AUDIO tab (where to select the audio to encode or to leave passthru) in some bluray HANDBRAKE show me double audio track...
example: ELYSIUM have DTS HD MA for English and Italian, but into handbrake (tab "audio") i see DTS HD MA and also DTS for both language...
and again, THE LAST STAND... bluray have only DTS HD MA, but handbrake show me also DTS standard track...
also DJANGO UNCHAINED... same situation, only DTS HD MA, but in the encoder i see also DTS...
why???
best regard.
Andrea
Thanks again for your time...
About the TUNE option... You have some suggestion? I leave it with NONE or i can use FILM? It increase the encode time? I can see some improved image result?
Have a nice day, bye
Andrea
This really depends on the content and your audience. If you're doing tutorials/interviews/etc, you can usually get away with lower bitrates, lower resolutions, and more liberal use of denoising to curb bitrate requirements than if you're doing, say... films.
Regardless, you'll probably want to do a little trial-and-error to get the result you want within your filesize (bandwidth) restrictions. Generally if you get to the point where a 1080 version needs to be smaller in file size but is starting to degrade, you're better off swapping to 720 and bumping up the quality.
Personally, I'd be inclined to do a 1080, 720, and 480 encode each at RF18, 20, 22, 24, 26. Use veryslow settings for each. Watch them all, and start making decisions from there.
For the profile, if people are likely to be watching these on phones/tablets to any extent, you'll probably want to limit yourself to Level 3.1 or 4.0. One possibility if you're willing to offer up all 3 options (1080/720/480) and let the buyer grab whichever they want is to use something like Level 3.0 for the 480 version and use 4.1 for the 1080/720 versions just to make sure there's a "fallback" solution there.
One of the other advantages to offering up all 3 would be that people with slow connections or limited data will probably gravitate towards the 480 version anyway so you'll save a little bandwidth there. And someone who's purchase might be influenced by whether 1080p is available keeps that option.
That said, depending on the specifics of what you're doing, any of the above might not really apply or be terribly important. Hopefully something in there helps though.
some guys rip TV show videos at a resolution of 1280x720 at a size 300 or 380 MB but, I tried a lot to do the same but nothing seems to be working. I'm kinda of losing the video quality and noise is increasing with the same settings they used (with the settings I used they achieved better quality videos). Can you guide me out of this problem. My hdd space is at low and I really want to compress the TV shows I have.... I used vidcoder and handbrake but, didn't get any good results...
Some slight denoising is a common method of getting bitrates (and file sizes) down. Aside from that, avoid the "film" preset, as it'll be inclined to retain a little more noise which is bitrate-expensive.
The only other thing I can think of is to double-check the audio settings and make sure you're not storing an extra uncompressed track or anything.
Those are the only simple things I can think of. If you're really running into a brick wall, try an encode at a fairly high RF (28-ish) and one at a really low RF (15-ish), and make sure the low-RF version looks good and the other looks poor. If you have a situation where you aren't getting the expected result, you'll know that your problem isn't with the RF value and that you have to look elsewhere.
Almost Human Ltd. Uses VP8 for .IVF videos in their 'Legend of Grimrock 2' dungeoncrawler. It's the oly supported video format for the game; so any imported video in user mods/maps, is VP8 encoded.
How do i encode multiple source files into one mp4/mkv target file? I don't see how to do this?
thanks
- Get your 2 Blu-ray discs into MKV format on the hard drive (MakeMKV/etc).
- Use MKVToolNix to merge them into 1 MKV file.
- Watch the new MKV to make sure there aren't sync issues where the 2 files were joined (make sure it's seamless). You may have to do some tweaking if there are any issues.
- Encode in Handbrake!
I'm sure there are other programs/processes/methods too, and hopefully someone will share if there's something they've used that works really well for them.Good luck!
First I want to thank you very much for this very well thought out and explained article. I have been searching for weeks for something like this online. A friend and I have both started a project to rip all our DVDs and Blu Rays for streaming in our home/devices via PLEX. We had ripped quit a few DVDs and Blue Rays with MakeMKV, but hadn't worked through on how to encode the video file with something better like h264. This article makes this dead simple.
I loved the straight forward and well explained points ... and the side articles which drove the points home.
However, I am still confused on the audio portion. I did read your info in the old guide. But, unfortunately I am still confused.
With DVDs I basically just want to make it so I have a surround sound track to play and it will drop down properly to stereo if not playing on a surround sound system.
With Blu Rays I it's a bit more confusing. I would like to to make it so that if there is a DTS HD or Dolby True HD audio track on the disc that it would pass that if applicable. But, I would also like it to have standard 5.1 that would still properly pass down stereo if needed.
I hope my explanation makes sense. If you could make suggestions for both DVD and Blu Ray based on what I explained I would be forever grateful.
Once again thank you so much for taking your time to put this article together. I will be sending this along to my friends that are looking to do this.
Ryan
As I can see, the ratio of my videos are well modified as I wish, the video quality is good enough at 1.500 kbps and the size is reasonable. only the encoding time is enormous, even longer than the duration of the movie, despite the fact that I have a quite fast PC.
many thanks in advance!
The biggest downside to using "none" for aspect ratio manipulation is that you'll lose some resolution/detail due to resizing. "Anamorphic Custom" is preferred because you can retain the full resolution/detail originally stored and just stretch/squish the image into the desired AR on playback.
Of course, whether that difference will even matter or not depends entirely on your use case, source, what you're trying to achieve, etc. The difference could be noticeable, but could just as easily be completely indiscernible. It tends to matter less when viewing the output video on smaller screens/devices, and more when viewing back on larger higher-resolution screens.
All that said, since "custom" can be buggy (particularly on Windows, which you're seeing first-hand), using "none" might be your only choice. It could be perfectly fine too: encode a few 30-second test clips - if you're happy with the result, I'd be inclined to just go with it.
first of all, thanks for this awesome guide, it helped me a lot get most of the settings right!
I have only one concern left: I was encoding a Blu-ray as an MKV with the standard audio setting of converting the source DTS audio to 160 kbps AAC. When I watched the movie, I noticed two quieter scenes sounding somehow "noisy", as if I had used a much lower bitrate.
I then encoded only one of those scenes individually with the same settings as before and it sounds totally fine. Is it possible that, when encoding a large file, the audio quality gets worse?
I would be very happy if you could help me!
Jonas
For dealing with black bars, try cropping at automatic. It looks like JW was shot at a 2.00:1 aspect ratio - I don't know if that's what made it onto the BluRay, but if so, they would have added some black bars on the top/bottom since BluRays use 1.78:1.
While automatic cropping will probably take care of those black bars without issue, keep in mind your TV will usually "regenerate" them during playback to maintain the proper aspect ratio (most consumer TV's tend to be sized for 16:9). So it'll probably end up looking the same anyway. It's still a good idea to crop though, because if you watch the movie on another device, cropping will keep it from being "postage stamped" at horizontal orientations, and reduce any additional letterboxing in vertical orientations. On your computer in a video player in windowed-mode, it'll save you from having wasteful black bars there.
As for the large size you're getting, assuming for the moment that nothing is set wonky, it's possible that the movie just has a lot of noise/grain/detail, and HB is really striving to retain all of it at RF 16 + Film. If there's a lot of non-stop motion and frequent scene cuts, that'll help balloon things too. I'd be inclined to try a test encode (2 min clip) at RF 18 and see how it looks. While you can usually settle on an RF (or a small RF range) that you're happy with for most videos, some sources will require a little tweak in the RF settings to maintain the quality/size ratio you're looking for. If for some reason *nothing* brings the file size down, re-encode a video you've done before to make sure it's not a stray video (or audio) setting that you've inadvertently set that's causing the size to balloon.
Anyway, that's where I'd start. Hope that helps.
I am a big fan of Handbrake.
But this morning I am having a little problem just after I have updated it to the latest Handbrake 0.10.
I have a short 4 mins mov movie (2.85GB, Prores 422) try to convert it to mp4 using Handbrake.
After several attempts with slightly different setting it partially hangs (It means "stop /freeze" in the middle of the movie.)
I have played these same movies in Realplayer, VLC, QT, but all hangs at the same spot in between the still photo and the movie. QT played through though but it stuck there for a sec or 2.
Now, the original mov movie (source) will play smoothly in Real player and QT. It has no problem with hanging at all.
Would you be able to guess why this might be happening?
We would greatly appreciate it if you kindly give us a little advice on how to fix this problem.
(Our first priority is that to make a best quality movie)
Thanks again in advance.
--------------------------------------------------------------------------------------------
====Our System======
Older Mac 2010 / Snow leopard 3.06GHz Intel Core 2 duo. (8GB mem, 1067MHz DDR3)
Old Mac but it has no problem running Adobe CS5 master suits + + some third party software
===== Our current Handbrake setting - 0.10.3 ======
Video setting
H.264: Same as source: Variable Frame rate: Constant Quality 18, (tried 20, 19)
Encoder options
Slower (and tried slowest) preset: film: high: 4.1
1920 x 1080 to 1920 x 1080
Anamorphic Strict: Crop Auto 0/0/0/0
Filter: Detelecine, Decomb both Default
Web optimized ticked
----------------------------------------------------------------------------------------------
Just a quick update. I have tried with
... film,... high ... and level 3 setting (because we have an older Mac 2010) with a "very slow" preset + RF 19
Still no luck.
By the way if I find the solution I will get back to you. I have a deadline. Wish me luck.
- Try on another machine to eliminate any chance of it being a hardware issue (usually RAM with a bit that flips).
- Encode with completely different settings to see if there's a setting that can be narrowed down as a culrpit. Start with a 480x270 encode at default picture settings, fast settings, a profile on the lower end (3.0 or less), MKV instead of MP4 (or vice-versa) etc.
If it works at different settings, start implementing your desired settings 1-by-1 until you find the culprit.If it *doesn't* work even if every single setting is set differently, then you may have run into a bug with Handbrake or x264. Chances are they'd need a copy of your source to reproduce/fix it on their end. Unfortunately, waiting for a bug fix might pose an issue in regards to your deadline, so in that case, you might have to use an alternative encoder in the meantime (Apple's H264 encoder via Quicktime/iMovie/FCPX/etc).
Seeing it's 2016 I figure I'll ask. Any update about x265, have you played with a bit recently? Wondering if it's time to switch yet or whether you still think x264 is the way to go. I've been told WDTV (which I have) will play x265 but if there really isn't any advantage yet, then what's the point. Thanks
At low bitrates, x265 is extremely impressive and blows x264 out of the water. To see a night-and-day example of this, grab a 1080p BluRay and do a 2-pass constant bitrate encode at 200 kbps (yes, we're severely bitrate-starving for this example because it shows so well). To keep things reasonable time-wise, just encode 10 seconds of the video (10s somewhere in the middle). Do an encode with x264 and one with x265. You'll immediately see the difference.
When you get to higher bitrates/quality levels, things aren't so cut-and-dry. x264 is great at retaining high-level fine detail. x265 is often considered to be worse (currently) in that area.
I guess I'd summarize it as follows: If you're one of those who are constantly chasing low file sizes (likely using RF values in the 20-25+ region currently), x265 is probably worth transitioning towards. On the other hand, if you're one of those who agonize over quality (particularly fine detail and likely using RF values in the 14-20 region currently), you may want to wait awhile yet or at the very least do a number of test encodes to see whether you're happy with the results or not before you start to move over.
All that said, x265 continues to improve so even if you decide to go with x265 for new encodes, I don't think it's necessarily worth going back to your original sources and re-encoding everything in x265 just yet. There's also the matter of device support when it comes to hardware decode - a lot of recent hardware has basic support for HEVC (x265), but stuttering and other issues aren't uncommon. The newest stuff (anything that claims to support 10bit HEVC) tends to do well with standard HEVC, but YMMV. If you're just encoding to watch on your own PC and are fine with software decode, I suppose none of that really applies. But if you've got phones/tablets/media_players/etc, it's something to keep in mind.
I really appreciate your write-up. Like many other people stated, it's the most detailed one I've encountered. I had tried messing with Handbrake in the past, but just ended up frustrated and confused, haha. I'm pretty new to the whole decoding and compression business. But I read through both your 0.9.6 & 0.9.9/0.10 articles and set most of my settings to your recommendations. I currently have version 0.10.3.
I had a quick question on the "profile/level" setting. You mentioned in your article that the basic standard nowadays is "High Profile/4.1" Does this setting affect quality at all, or is it just for compatibility's sake on newer devices? Also, does the high setting make the encode take longer? What's the best setting if I'm just encoding mostly DVDs? I noticed on your first screenshot in the 0.10 article, you had it set at "Main/3.1" and you were burning a copy of "Get Smart." Is this a better option for DVDs? Also, is there any noticeable difference when you vary the CB rating between 18-20, or is it better to just keep it at 20?
I've been using MakeMKV and then Handbrake in conjuction. I only just started with my first DVD and did a few different passes at different speeds. When I started at "slow," the estimated encode finish was over 2 hrs. I did one at "fast" and it took an hour and a half, with final size of 1.42GB. Then I tried "very fast," even though you recommend against it, and got a file size of 1.11GB (quality wasn't any noticeably different at all, at least for me). What is the real reason not to use "very fast?" Any updates on this conundrum? I read the exchange between you, Jan, and Frank. Again, I'm new to all of this. I just want to minimize my encode time, while still maintaining relatively "decent" quality. File size isn't as much of an issue. Thank you in advance!
The level/profile basically places a ceiling (cap) on some settings for compatibility reasons. I won't go into the technical details, but they can be found in the H264 entry on Wikipedia ( https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles ) if you're interested.
As far as quality goes, things get complicated quickly and there are a number of factors that come into play. If you're using the really fast settings, depending on the resolution you might hit some of the bitrate caps if the level is too low, which could cause a reduction in quality. On the other hand, if you're using the really slow settings, you're more likely to hit some of the reference frame caps which won't cause a quality reduction but might result in the file being a bit larger than it would have otherwise been.
To try to boil things down to a more simple "rule of thumb", for a typical DVD encode you'll probably do fine under 3.x most of the time, but 4.x is ideal (enough headroom that it's very hard to hit the cap). For a typical 1080p BluRay, bump those numbers up to 4.x and 5.x (keeping in mind that 4.1 is a realistic max for playback on a number of devices).
--
To the 18-20 bit (I'm assuming you meant RF instead of CB), an RF of 20 is "good" enough that I can't easily distinguish values below that except in a side-by-side comparison. But that's just me - there are people out there that can easily pick out the difference in encodes done at RF settings right down to the mid-teens. I just don't happen to be one of them. It's something where you're best to do a few test encodes and see what you personally are happy with. Whether you're watching on a small screen or a massive TV will obviously come into play.
--
As to "very fast", there aren't really any updates. The reason I don't use it is that it's a massive outlier: the settings it claims to use should put it right between super/faster in terms of output, but somehow the file size ends up coming out way smaller than every other setting. I suspect that there's a quality hit attached (either via a bug or an edge-case behavior of the settings used - I can't think of any other explanation that makes sense).
Thanks for your response, it helped clarify things a bit more. What about using just the "auto" setting for both profile/level? On Handbrakes x264VideoSettings page, they recommend just setting it at "auto," and it will adjust based on the options you've selected. They also mentioned that the "high" setting will suck CPU power, resulting in much longer encode times.
The "auto" settings won't limit the profile/level. So you might end up with something that's main/3.0, or high/4.1 anyway (or any other combination). Of course, if you used a really high bit-rate (or very low RF value) on a BluRay encode and set the speed to "placebo", you'd probably end up with something in the neighbourhood of high/5.2. While that will usually play fine in a typical software player on your computer, you'll have a bit of trouble finding a phone/tablet/etc that can actually play it back via it's built-in hardware decoder. A 4K encode at those settings would be off the chart as far as level/profile goes, and I doubt you'd find any phone/tablet/etc that could play it back via hardware. The few that would manage to play it back via software decode would have to decode on their CPU (instead of the dedicated hardware chip), and would thus tend to burn through their battery extraordinarily fast.
Personally, I'll use "auto" when I'm encoding something that won't ever be directly played back on a standalone device. The most common cases here are when I'm archiving a source (like original un-edited video camera clips), transcoding something from a format that my video editor doesn't support to H264, or running certain tests where I can't have that extra variable affecting the results. In those cases, I'm deliberately using specific bitrates, reference frames, etc, and I don't want the encoder restricting the profile or level and foiling my attempts.
When it comes to standard encodes I intend to actually watch (TV/Movies/etc), if I were only ever playing back on quick desktop computers, I'd probably use "auto" simply because a fast computer can software decode just about anything. Since playback on fast-desktop-PC-only is less-and-less the case these days though, I'll almost always set a profile/level.
---
As to the CPU power bit, "High" does allow the encoder to use certain features that require more CPU power. Most of these (like CABAC which the "baseline" profile doesn't support) give you really good bang-for-your-buck though. That said, it's not something I'd worry about these days... we've got the speed presets now, and they do a good job of restricting/limiting stuff that has a lower bang-for-your-buck ratio and retaining the features and settings that have the greatest impact.
When it comes to playback, portable & media devices decode via a dedicated hardware circuit (and even computer CPU's have dedicated decode now), so if your device supports high/4.1, there shouldn't be much (if any) CPU benefit to using something lower. That's something that mattered a lot more a number of years back when H264 hardware decode didn't exist.
The first thing I usually do in multi-device systems is figure out which device is the "lowest common denominator". It's probably going to be one of the Smart TV's in your case. The typical steps I take here:
- Hook everything up to the wired network to keep wifi issues from affecting results.
- Encode a BluRay (1080p) source at multiple levels: the 3.x and 4.x variants (up to 4.1). Use a low RF value (higher quality) and use one of the quicker speed presets to balloon the bitrate: the bitrate will essentially be clamped by the level.
- Try the encodes on all the devices. Start with the 4.1 encode, then try the 4.0, etc. Any device that played back a high level generally won't have to be re-tested at a lower one.
Hopefully, that'll narrow down the weakest device. And hopefully that device at least handled 3.0.If it didn't handle *any* of the encodes, you might have to repeat the test using "main" instead of "high" and consider resizing in the picture settings to reduce the resolution to 720p (resize a 1920x1080 video to 1280x720).
Assuming you found the "weak link" (and what the "weak link" will handle), go ahead and recode that same source at a really slow quality setting. Use the profile/level and resolution that just worked (ie main/3.1/720p), but try to use veryslow or something really close to it as the speed preset. The intention here is to balloon other settings (like reference frames) to the point where it's clamped by the profile/level.
Check that new encode on all the devices. If the "weak link" struggles with it, you can try reducing the profile/level again. If you've already hit the bottom here though (main/3.0), you're probably in a situation where you'll want to just do separate encodes.
Assuming it *did* work, as long as you adhere to that profile/level for your future encodes, it should work on all your current devices. You can tweak away at the speed, RF values (or bitrate if you're aiming for specific sizes on the tablets), etc, and everything should work as long as you adhere to that profile/level.
-----------------------------------------
---- The possibly-easier alternative ----
-----------------------------------------
It's been awhile since I've used Plex, but it should be able to transcode on-the-fly to your devices. So you could feasibly use whatever you have been already (high/4.1/1080p for example) and switch some settings in either Plex Media Server or the Plex Client itself to tell Plex to just transcode the darn thing to something that will work. As long as Plex Media Server is on a machine/device with a CPU powerful enough to transcode, that might be the most simple avenue to take.
Anyway, hopefully something there helps! Good luck!
Thanks for the advice, your approach all makes sense and I'm a little annoyed I didn't come to the same conclusions myself!
Looking at the manual for the smart TV, it suggests it can handle a profile of 4.1 but, clearly it can't. The server (i7\16GB) is plenty powerful enough for transcoding but, I suspect Plex is basing its decisions on a combination of parameters like the TV's claimed abilities and\or perhaps it’s a little more generic based on the (Samsung) TV’s OS, who knows! Ideally, I want to encode files that don't need transcoding and if the TV's are simply too weak or unreliable, rather than encode multiple files ,I'll simple plug some Roku's in. They're not as wife friendly as there will be two remotes in the equation :-) But, at least they only have the max bit rate limitation and if I understand correctly 20mbps is within the 4.1 preset, if not, I’ll simply drop the resolution, the kids won’t care.
I'll give this a try over the next few days if the kids allow me too...
Out of curiosity, what client\server software do you use if at all to view your movies around the house? As I suspect most people like me are trying to solve this same issue and encoding is just one element. In an ideal world, I want to pop a new bluray into my machine and hit the rip button and stuff just works!
Issues like that aren't always fun to track down, but a few possibilities off the top of my head:
- If it's on a certain device - Try playing the video on your computer through a software player (VLC, Windows Media Player, Quicktime, etc). See if the artifacts exist there too. If they're there too, you can usually rule out a device as being the issue. On the other hand, if computer playback is fine, you might have to look at toning down some settings in case the device just can't handle the settings thrown at it - on the plus side, faster settings tend to be a little more toned down so if this is the case, at least you'll have quicker encodes.
- Possible hardware issue - Failing RAM can cause odd issues. Often it just results in crashes, but if the encoder is putting together the video in what happens to be a bad part of RAM (where bits are flipping), it's very possible that bits of the video are getting corrupted. Running Memtest86 can help rule that out. If overclocking, similar symptoms can occur as well. Probably the easiest thing to do though to rule out your machine as being the issue is to simply try encoding the same source with your same settings on another machine.
- Encoder or Handbrake bugs - These are a fair bit more rare these days in x264, but anything's possible. If there is a bug, it's probably triggered by specific settings or certain options. The easiest way to pinpoint the issue is to do a bunch of test encodes (same source) at different settings. If you're using anything in "Picture Settings", try turning everything off and recode with the settings you've used. Same thing if burning in subtitles. That'll eliminate most of HandBrake's pre-processing possibilities. Next, try encoding at a really high RF and again at a really low RF (say... RF28, then RF14). If bitrate's playing a factor, hopefully one of those shows it and one doesn't. Finally, I'd try an encode at "superfast" and other at "veryslow" - a lot of x264 options change between those settings. If you're still not narrowing down anything at that point, I believe the Windows version might have OpenCL and QuickSync options depending on your hardware (check in the preferences/settings) - if they can be toggled, it could be worth trying them on or off.
Maybe someone will chime in with another suggestion, but in the meantime, those are the places I'd start anyway. Good luck!I appreciate your very thorough answers! I ended up just staying with "high, 4.1" as a general rule, just to be safe. I ran into another small conundrum while encoding the film, "Unbreakable." It's shot at a 2.35:1 aspect ratio, and I did two encodes, 1 at "medium," and 1 at "slow." And both times, the encoder blew up the ratio from the original, causing noticeable pixelation. So I'm guessing that this is a special case where I will need to resize the encode, using something like "anamorphic, loose"? What values would I set it at to accomplish this, in order to "mirror" the original film?
Also, another thing I've run into lately are a few "multi-angle" films. Is it ok to just encode one angle of these films? I know it really depends on what the feature is actually used for in the movie, but I just encoded one of 2 angles for "Armageddon," and the movie turned out fine. I didn't notice anything lacking, so just curious if that matters. "Unbreakable" also has 3 different angles, all the same size, on the main feature disc.
Great article, extremely useful but I have a question regarding the output of one of my projects.
I have put a looping background video together in After Effects, exporting using Apple Pro Res 4444 codec from AE with no issues, the video looks great. The video itself is a solid colour which blends across a colour spectrum, overlayed over 'flow' footage.
The result is a video which has gradient areas but no extreme shifts in colour and as I said the master export is perfect but at a hefty 1.6GB for a 90 second video.
The problem comes when I use handbrake to compress the video. I have used this article to try and work out the issue but to no avail.
Here are my settings; MP4, H.264(x264), framerate same as source, constant quality RF 20, encode 'slower', tune 'film', profile 'high', level 4.1.
The resulting video is 6mb which is perfect but there is very noticeable banding in some areas. Is there a way to fine tune these out whilst maintaining a low file size? I have read and read around about gradient issues which are unfortunately unavoidable but this seems like a problem to me that shouldn't be happening. I have played around with Handbrake's settings and lowered the RF to something like 12 which is better quality but the banding still exists.
Here's a frame;
https://drive.google.com/file/d/0Byd_BTJlTQEqWkEybWJRXzRvdms/view
Thanks again! Hope you can help
The frame you linked to isn't public, but I'd be surprised if it wasn't the same gradient/banding issues you mentioned you've read about.
A couple of the issues that tend to be bigger causes of it:
- x264 under typical settings has a tendency to simplify flat areas where it can (throwing bits in important detailed areas at the expense of flatter areas). This can definitely result in banding, especially in situations where grain, noise, or dithering took place, especially at lower bitrates.
- Using ProRes 4444, you're in a situation where you've quite possibly got a 12-bit 4:4:4 video source. The HandBrake/x264 toolchain is basically toning that down to 8-bit 4:2:0. You're losing some precision and some color information. Areas with gradients might become banded regions, and that's something really hard to work around.
To check for the 1st one, try a quick encode at RF:0 to see if this is indeed playing a role - if the banding goes away at RF0 (or under other odd situation like PSNR/SSIM tune settings), you've hit the cause, and you're probably going to have to look into some custom settings to try and retain detail in flatter areas. File sizes will end up being larger, but there's not a whole lot that can be done about that - retaining the type of detail that either covers up or avoids banding is expensive.The 2nd one is a bit harder to check for and address. You can try experimenting with a 10-bit x264 encode (to get a 10-bit encode going I've got some details here: https://mattgadient.com/how-to-10-bit-x264-and-10-12-bit-x265-encodes-with-handbrake-mac-os-x-linux-windows/ ). If things are notably improved by moving from 8 to 10-bit, it's a good indication that the 2nd issue is indeed the one you're hitting. Unfortunately, there aren't a lot of great ways to actually deal with it, assuming you actually need the output to be an H264 video playable by most stuff out there (10-bit H264 playback support isn't common on the consumer end). One of the nicer looking methods that you can look into is using dithering during pre-processing (before it meets HandBrake). Then you feed the video enough bitrate to keep the dithering intact. The other common method is adding some noise/grain to cover up the banding, and feed enough bitrate to keep it (and/or tune grain). That's often somewhat easier to do during pre-processing or editing, but obviously changes the overall "look and feel" of the video.
Anyway, I know it's not a great situation with some fairly sucky solutions, but those are the places I'd look at and consider to start with. Maybe someone who reads this and has actually had great luck dealing with it will chime in with something quite a bit better that worked great for them. In the meantime, good luck!
Nowhere on the Internet I a better explanation on Handrbake settings than yours. Thank you for it!
I am trying to 'losslessly' covert a .wmv video to .mp4. Every time I up having an image quality that leaves much to be desired. For example, here are two screenshots and a video comparison table: https://imgur.com/a/bMTk2 The original file has a size of almost 3 GB, the converted one in this example - 1.5 GB. I don't mind having the converted video to be 3 GB as well, but there doesn't seem to be drastic improvement if the size increases in result of using, e.g., RF lower than 16.
What settings would you suggest to use to have as less loss as possible?
Cheers.
Maybe someone's got an idea at a glance (I don't). I usually trial-and-error this stuff. I'd do a 10 second encode of that clip at RF:0. If the blocky/blotchy bit goes away in that test bit, generally you either need to push the RF value or start delving into some custom settings to try to get some more bits put in that blotchy section. If it doesn't go away at RF:0, then at least you know the RF value is irrelevant: at that point you can try auto for the level (to unclamp the bitrate), try a different tune setting (try each of film/none/psnr to see if the results start leading you in a direction), turn off any preprocessing in case something there is glitchy (picture settings) etc. If all those fail, you'll probably have to start messing with custom settings anyway.
I know that's probably not quite the answer you're looking for - maybe someone else will take a look, identify the issue right away as one they're familiar with, and chime in with a quick fix. Until then, that's the process I'd go through. Good luck!
What s the best preset for ipad mini 4 retina ?
thnks
Now, that latest Captain America clip at 1280 wide is 31MB in size after it's downloaded, I figure if I could duplicate their encoding settings but at 960 pixels wide I'd end up with a file under 20MB in size hopefully. The problem for me is that no matter how many times I give it a go using HandBrake (latest) on OSX (10.11.4) I cannot get my own encodes - even at 960 pixels wide - anywhere near that file size and I'm using HE-AAC audio at 80 Kbps which should help with the final encode bytesize. I'm stuck and I wonder if anyone might be able to help me figure out how to duplicate what YouTube is doing with their encoding process that results in such good/great visual quality (at least to me and my half-century old eyes, aka "it looks good enough for me") and such small sizes.
tl;dr I want to duplicate a YouTube 720p video clip but at 540p resolution (the audio thing will take care of itself). I don't want to just create 540p encodes, I want to create 540p encodes that would be exactly what YouTube would end up with if they adjusted their output resolution to 960 pixels wide, basically. Whenever I do an encode I end up with a file that's almost twice as large in terms of bytes and I can't get it crunched down like they do.
HELP!!! :D
Any assistance or info is greatly appreciate, and thanks for the very detailed article, Matt, outstanding work.
I customized the 16 chapter headings of a DVD video (changing "chapter 1" to "1 abc", etc.) in Vidcoder. These show without a problem (the newly created mp4 file is loaded as a movie) in itunes on my pc. So everything works fine to that point, including the custom chapter headings, in itunes on my pc.
But, after using itunes to I load the same new mp4 file on my ipad 3 (ios 5.1), the chapter headings in my ipad revert to chapter 1, chapter 2, etc.
Can you tell me how to get my custom chapter headings (instead of chapter 1, chapter 2, etc.) to appear on my ipad? Thanks.
If that doesn't work, I suppose it could be an iOS version specific issue or some other bug down the chain somewhere. Perhaps someone else will chime in if they've got another idea though. Good luck!
Thanks. But, my video in itunes is set to movies. And, I am transfering the movie from itunes on my pc to movies on my ipad. Perhaps ios 5 is the problem. I plan to update to ios 9, but I know this sometimes slows the ipad 3. I wondered whether there is some setting in Vidcoder/Handbrake that is causing this, but since the custom chapters work fine in itunes on my pc, I suspect the problem is ios 5 related.
Tom
Codec | Encoder preset | Time (mn) | filesize (MB)
Intel Quicksync | Fast | 8 | 604
Intel Quicksync | Balanced | 8 | 605
x264 | Ultra fast | 9 | 959
x264 | Medium | 22 | 467
x264 | Slower | 60 | 445
x264 | Very slow | 92 | 409
I did not try the placebo encoding preset: I thought that it was stepping into counterproductive territory (too much time consuming).
The same file size and encoding time for two different encoder presets for the Intel Quicksync is fishy but I did the test a second time and the outcome was the same.
OS: Windows 10.
Handbrake Version: nightly 20160518xxxxxx 64-bit
I am converting .mov files to mp4 using RF quality at 30.
These are only intended as viewing copies but are quite adequate for the purpose.
The size of the MP4 file is 70 - 100 times smaller than the .mov file.
The reason I am using this amount of reduction is to put multiple film clips on to a DVD data file or a flashdrive.
The problem I have is when I try doing batch conversion.
If I leave the default setting at 20 everything works perfectly but the files are only reduced slightly in size.
If I set to RF 30, even although it shows as RF 30 throughout the conversion, it reverts to 20.
I have looked at the device settings but haven't found any way to set RF 30 as a settable value when needed.
Maybe I am trying the impossible, but perhaps with your expertise, you may have a solution.
Incidentally, this operation is part of a voluntary project digitising and creating data for old historical cine films.
Many thanks for any advice you can give.
Maurice (long since retired ! ), Dunedin, New Zealand.
main Handbrake window it was very easy. I was also trying to change the settings in CDI (silly me ! ) Cheers - a great site you are providing .
I'm processing sme 4:3 480i tv show eps and I noticed some video stutter in *some* scenes when the camera pans.
I found I get HB set to cbr so I re-did one in vbr and compared then and the vbr is better but I still see it slightly.
I've processed many 480i and 480p tv eps and movies over the years and have never seen this, any general off the top of your head thoughts on what I can check?
Thanks in advance, email direct if you want...
drc :)
That's just the avenue I'd chase first - could be something else, but telecining judder is notorious for showing up during slow pans (on NTSC videos anyway).
I believe I always have framerate to same as source, but I will re-cook the original file again with the telecine as you suggest and see what happens.
So what kinds of things need this option? Is it just tv shows as I've done movies and concert/video collections from DVD and don't recall seeing this issue?
Speaking of tv shows, I also did all 5 years of the original Dark Shadows and never had a single instance of the stutter I've been seeing recently - is it only newer shows from year 19xx that I have to be careful of and if so about that year did it start?
Is there any way to tell from the .mkv file if it's telecined?
Anyway, back in the day, anything shot in 24fps that had to be brought up to 60Hz for terrestrial broadcast got telecined (to 30fps) and then interlaced (to 60fps) at some point in it's life. Since in the late 90's most of us were still using our big clunky CRT TV's, a lot of "hard" telecining that took place made it's way onto the DVD's. So stuff from this era had a high chance of coming to DVD in it's fully telecined format.
A number of years later it became increasingly common to "soft" telecine (don't actually telecine the content - put the 24fps video on the DVD and just tell the DVD player to telecine on playback). So telecining on the source before it hit the DVD started to be come less common.
Picking stuff down to specific dates is fairly tough because shifting to soft-telecining was a gradual change. Also, when companies started to go back and re-release old stuff on DVD, your chances of hitting telecined content started going all over the map. Nowadays, they won't go to the extra work of telecining it. But if the only (or most accessible) source of some video from 1950 is telecined because the original was lost in some flood, all bets are off.
As for detecting it, see if MediaInfo mentions it (I'd try it here, but my media server is currently unavailable).
The safe way to go though is to just keep Detelecine at 'default' most of the time. It looks for telecined content and detelecines automatically when needed, so leaving it at default can save a lot of headaches. I believe it might even spit how out many frames it detelecined in the encode log - I know it used to for deinterlacing but don't remember for sure whether it listed detelecining or not.
I'll have to spot check some of Dr. Who, but yes after some reading on my on just leaving it on Default seems to be the way to go.
Thanks for your time and input.
I used to use Quicktime 10.3 to export the MOV file to iTunes, but since I upgraded to Mavericks 10.9.5,
Quicktime no longer exports my Chapter Markers.
Handbrake does export the chapter markers, makes a slightly smaller size file (563MB vrs 744MB with Quicktime), but I can notice the lesser quality in my final video when compared to Quicktime, specially on photos with movement in the final edited video.
I use the AppleTV2 settings on Handbrake, but was wondering if there is a superior adjustment I can do to these settings to produce a better quality video? Thanks.
Below I included a screenshot of the difference in quality, you can really notice this on the text, the quicktime has a lot more sharpness than the Handbrake. I guess I will try and experiment with this clip to see what settings improve this.
It almost looks as though there's a white text-shadow present in the HandBrake version - when I zoomed in, it looks like a shadow going down-right, and there's a consistent white effect above each of the B's. Not sure if that's *supposed* to be there and QT is dropping that detail, or if it's *not* supposed to be there and the HB version is artifacting.
In any case, if you're starting with the base AppleTV 2 settings and are looking to get a little more sharpness/detail in some areas, the first place I'd tend to start tweaking would be trying Film or Grain under the Encoder Tune settings. If the video consists of a sequence of images (not actual motion video, and very little animated motion), you could also consider the "still picture" preset - definitely would only try that route though if most of the video has static images.
Beyond that, make sure you're not doing any denoising in the picture settings (spacial denoising will soften up text in an obvious way), and try to avoid resizing dimension-wise (make sure source resolution matches destination since you've got an edited video you don't necessarily need changed and probably don't have anything anamorphic to worry about). If you're really fighting with the handbrake presets (particularly with Encoder Tune options), you could look into using the Advanced tab (negative deblocking values and play with AQ + RD + Psy Trellis in particular), but that can get a bit on the messier side so I'd tend to try tweaking some of the built-in settings first.
Somebody else might be able to chime in with something a little more concrete, but hope something in there helps. Good luck!
I am sending a snapshot of the Picture Settings to see if anything there can be improved.
https://uploads.disquscdn.com/images/654315772bff67a811dba80d5aa87483d091f7824744f41e86e1f6ae3eaa2b4d.jpg
I have contacted many app developers of video converter available on the app store, and surprisingly none of them export chapter markers! The only one that gave me the same quality as quicktime was Brorsoft Video Converter, but no chapter markers export!
I got a hold of an older mac with Mac OSX 10.8.5 and Quicktime 10.2 and only this version exports the chapter markers and superior quality. Looks like Apple really messed up their quicktime app with 10.3 in Mavericks 10.9.5.
https://dl.dropboxusercontent.com/u/86716148/Videos/VideowithBlackText.mov
That said, I noticed your picture settings show a 1440x1080 source resolution, cropped and resized down a bit. The clip you uploaded on the other hand is coming up here as 1280x720 source resolution and doesn't seem to need cropping. It could be worth doing a quick test encode on your end at Anamorphic Strict (which will probhibit resizing), and manually set the cropping values to 0. See if the text looks fine. If it does, then it might be that something wonky is going on during the resizing (but at least you'll know where to start looking).
One other avenue that might be worth exploring: I'm using an older nightly version of HandBrake - not sure what you're using but just in case you're hitting an oddball bug it might be worth trying the current nightly (or current release version if you're on nightly - just something different).
Beyond that I'm unfortunately starting to take a few shots in the dark here. It's one of those situations where things seem to be working fine on my end but obviously you're seeing very different results and nothing really stands out to me as being a really obvious reason (hopefully if somebody else sees an obvious reason they'll chime in though before I start leading you down too many rabbit holes).
Saving as a preset is usually what I end up doing (and then select the preset each time).
On OSX (macOS) if you save it as a preset, I seem to recall there being checkbox when creating the preset that enables saving the picture settings you've chosen.
I'm on Windows at the moment (an old nightly), and just saving as a preset seems to work fine as long as the "Save Picture Size" drop-down in the preset pop-up is set to automatic when using anamorphic strict. Worth noting that in Windows under the main Presets drop-down dialog from the menu bar there is a "Set Current As Default" option which could be worth trying too (hopefully it'll persist when Handbrake restarts each time then too!).
Not positive on Linux - my Ubuntu laptop's not here and I've got my VM's on another machine. It's probably similar to one of the above methods though.
As a note, this tends to work well with Anamorphic Strict (which you're using!). However, if using Anamorphic Loose for a preset at some point be *very* careful to observe what happens to the resolution when you start swapping between BR and DVD sources - I don't know if Loose saved to a preset does the max (rounded to 2/4/8/16 depending on modulus), or if it instead saves the exact dimensions - both behaviors would be perfectly reasonable (the latter possibly a little more sensible for specific use cases) and I don't know what route the HB devs went here.
My vidcoder program (what I use for handbrake on Windows) just updated to version 2.44 and the video filters section changed a bit and I want to make sure I'm keeping the settings the same as I was using before which are the same as you have listed above: Detelecine: Default, Decomb: Default, Denoise: Off, Deblock: Off.
Only now there is no "Decomb" button but a "Deinterlace" button with the options Off, Decomb and Yadif.
Under the "Decomb" setting two new options pop up: Preset and Interlace Detection.
For Preset there is: Custom, Default, Bob, EEDI2 & EEDI2 Bob.
For Interlace Detection there is: Off, Custom, Default, Less Sensitive & Fast.
My guess is the settings to match above would be Decomb, default, default but is this wrong?
Should it be decomb, default, (interlace detection) off?
or should I just leave then entire thing at off to begin with?
Thank so much for your wonderful page...it really is quite helpful and amazing...and appreciated!!
Happy New Year!
As to just turning it all off, I'm usually hesitant because I have a bad habit of forgetting to turn stuff back on when I run into interlacing/etc (I'm biased towards "set and forget"), but if you're pretty sure your source isn't interlaced and aren't as forgetful as I am, then by all means give it a disable!
I mostly am just backing up my collection, rather making server friendly versions of commercial Blurays and occasionally some DVDs if they are the only source available. Would those never be interlaced, always be interlaced or dependent the content? For example a movie (film) versus a season of TV like Sherlock or Amazon's The Grand Tour (when it comes out)...or all they all mostly filmed, edited, mixed and released the same way these days?
I am usually very conscious of what I'm inputting and modify appropriately but definitely like the "set and forget" idea. I'm trying to brainstorm the downsides...what would be worse, not decombing/deinterlacing interlaced content or decombing/deinterlacing NON-interlaced content?
If you do any TV recording via antenna, broadcast TV (digital over the air) is generally either 1080i (interlaced) or 720p (progressive).
You can usually count on screen recordings being non-interlaced simply because there's generally no value in interlacing that stuff.
Recordings from a video camera are all over the place, so you can't count on it being interlaced or progressive.
So yeah... kinda a big mess. THIS IS ALL FOR NORTH AMERICA by the way... I really haven't looked too heavily into Europe/PAL so I'm not sure where there's overlap and where there isn't.
As for downsides of leaving it on when not needed, decomb/defaults are supposed to look for interlacing and only deinterlace if it finds evidence of it, so there shouldn't be any negative side effects usually. However, a few years back when I was doing some testing I found that decomb would turn on the deinterlacer on telecined content if detelecine was disabled. Don't know if that still holds true in the current version of handbrake, but in any case, if using decomb (or deinterlace), I'd strongly suggest keeping detelecine enabled/default as well. Either have both on (default) or both off basically.
Downsides to having it off... generally a bit higher filesize, and visually the comb effect when there's motion on a typical display with a fast refresh time (basically anything non-CRT these days). That said, TV's and media players should be smart enough to deinterlace before it hits the screen most of the time, so you might be spared the visual artifacts making that part a non-issue. Software players usually have the ability to deinterlace on the fly too, but whether that's defaulted to on/off and how it's triggered is something that'll depend on the player.
However, the conversion from a source MKV or MP4 file that had CFR that is now VFR after conversion has me worried which raises the question:
Should I have selected Same As Source with CFR?
I just upgraded HB to 1.0.2 and am sort of blown away by all the new presets. My only purpose (I assume like many others) is to compress my library of DVDs and Blu rays. I'm therefore amazed that it has to be so complicated. That simple act alone is very time consuming so I have just wanted to use one preset that is the best for those and leave it at that. I don't have the time to test and retest every movie to tweak the settings. Getting the absolutely smallest file possible isn't that important to me - maintaining a generally unnoticeable level of quality loss is, so therefore I have been using the 'High Profile' preset for everything and that has worked fine as far as I can tell. With all the new presets and the addition of H.265 I am wondering if I need to consider changing gears and start using something else, however the differences in the presets concern me, Here's the main differences I'd be interested in hearing your opinion on:
Picture/Anamorphic: Auto is now recommended, but Loose is the default for High Profile, so that is what I've been using. You mention using strict above but that's no longer an option. Regardless, I haven't noticed any issues using Loose - what would I look for to notice where that setting had an adverse effect?
Video/Framerate: "High Profile" defaults to "Same as Source/Variable". All the new presets default to something like "30/Peak Framerate" for example. Any opinion as to what is the best way to go there? Or does it even matter? I would think anyone ripping a movie would want the framerate to simply stay exactly as it was on the source, so I'm surprised that NONE of the new presets default it to 'same as source', yet the fact that they don't make me think I'm missing something and choosing that maybe isn't the best option.
Video/Encoder Tune: All the presets set this to 'None', yet you seem to recommend using Film. What would one notice or look for when comparing two files between the None and Film settings?
Thanks for this post - I have referred back to your page every so often over the past couple years as others sometimes as me about handbrake as well.
Picture/Anamorphic: As far as "auto" and "loose" go, if the profile you selected doesn't need to reduce the resolution, they're effectively the same. Where they differ is when the profile needs to reduce the resolution - "auto" will pack as many pixels (both wide and high) as it can while fitting within the preset constraints and will modify the anamorphic flag to stretch/squish things into the proper aspect ratio on playback. This is kinda how DVD's often worked. "Loose" on the other hand will basically reduce the width and height stored in the video file in-sync with each other so that the stored aspect ratio remains unchanged. Both will generally look fine and for typical use cases you probably won't notice a big difference.
As an example, let's pretend we made a video out of a massive horizontal website banner, with an original resolution of 1440x240. We want to make the new video fit within one of the "480p" presets (which effectively restrict video to 720x480).
If we used anamorphic "auto" in this example, the actual data stored in our new file would be 720x240. The height (240) ended up being unchanged because it fit within the 480p restriction, but the width went down from 1440 to 720 (to fit within 720x480). Handbrake will create an anamorphic flag to basically stretch the width back out on playback.
If we used anamorphic "loose" on the other hand, Handbrake would scale down both the width and the height in-sync until it fits. So our 1440x240 video becomes 720x120. You'll notice that's less than the 720x240 we got with "auto". Since Handbrake had to move down the width, it also moved down the height. However, Handbrake doesn't have to do any stretching/squishing via the anamorphic flag (it retains our original 1:1 in this case).
So via "auto" we got 720x240 and via "loose" we got 720x120.
That's a fairly extreme example, but the first one I could think of that was easy to visualize. You asked about noticing adverse effects: in our (extreme) example we might notice that the "auto" version looks a lot better vertically when played back on a massive display (because it didn't have to resize the vertical). However, horizontally they look the same. The "loose" version has half the pixels though, which results in a smaller file (roughly half).
Since real videos tend to have less extreme resizing needs than my made up example, whether you use "auto" or "loose" probably won't be visually obvious. And I can't really say that there's much of a right or wrong here. If you're not choosing presets that need to resize, it really shouldn't matter one way or the other.
Wow, that came out longer than I'd planned... I'll try to keep the next ones shorter.
--
Video/Framerate: "Peak Framerate" should just set a cap. In other words if your original video is 24fps but you select Peak Framerate (30), your output video should stay at 24fps which is effectively the same output you'd get as if you'd used "same as source". I suspect it was added to presets with a default of 30 because there are a number of devices and some online video services that have framerate restrictions (and 30 is the lowest common denominator here).
--
Video/Encoder Tune: I suspect the presets all go with "none" because it's a good middle-road setting that does okay for film, animation, etc. For what you'd notice, if you encode a typical film and look at the videos side-by-side you'll generally notice the one with the "tune film" setting being slightly sharper and keeping some extra fine detail in the environment. It's more obvious if you use a grainy film as your source (it'll keep more of the grain, though not as much as "tune grain" will).
I do use "tune none" quite a bit too since it doesn't push the bitrate as high.
--
Alright, time for a coffee. I know that was a bit long, but hopefully something in there helps!
Having used 1.0 for a while now I haven't specifically noticed any quality improvements or issues, but what I have noticed is that my encodes are now taking almost twice as long using what I believe to the be same settings. WIth version .9, using the 'high profile' legacy preset I was able to encode HD movies in about 2.5 hours (with my old i7 875k cpu). Now since upgrading, encodes are taking about 4.5 hours and I can't figure out why. The high profile preset used the 'encoder preset' value of Medium and 'quality' level of 20 and those are still the same. I even tried bumping that up to Fast and it didn't help much. It is also still maxxing out all 8 'cores' when it runs as it did before. Just wondering if you or maybe anyone else reading this has noticed any performance changes after having upgraded.
I see the old versions are still available for download so I may have to try downgrading to see if the encode times go back down to what they were before.
Encoder Preset: fast/medium/slow
Encoder Tune: None/Film
Encoder Profile: High/Baseline
Encoder Level: 4.0/4.1
The Movies were Highlander (grainy film source), Cloverfield (videotape style/look), The Nut Job (digital animation). Beyond those video types there was no other reason for choosing those other than they were next in my stack of discs to rip and compress.
To preface this I'll note that for all of these tests I left the Quality setting at 20, which is the default used for the High Profile preset. 20 is recommended for DVD and 22 for blu-ray, but as disc space isn't that precious to me I've always used 20 for everything. All comparisons were simply using my eyes on my 25" HD monitor, pausing playback at the exact same frame from two versions of the encode in two VLC windows, and then quickly toggling between them.
- Encoder Preset - again, everything else being equal there were no visual differences I could detect between the Fast/Medium/Slow versions of files. The only thing that changed were the files sizes and encode times. Fast was usually the largest and added 5-10% in size. It also was not consistently faster than medium by much, certainly not by enough to make it worthwhile to use. Slow was slower than Medium by around 20% but that's a loose estimate (I haven't gone back and compared the run times of every test). For example, slow vs. medium for the animated movie was 2:30 vs. 2:00 hrs and 4.30 vs. 3:45 for Highlander. Also one would assume the slow setting would produce consistently smaller files, however for the animated Nut Job it was actually larger than the Medium setting by 1%. Medium is generally the best option here.
- Encoder Tune - Again, as the presets generally use 'None' I was curious if 'Film' would improve the detail at all. It did not. In general I couldn't tell any difference, and at most a couple of the frames may have looked ever so slightly softer. The kicker though is that the 'Film' files were 3-5% larger, so with no discernible visual difference I see no reason to use Film over None.
- Encoder Profile - again no visual difference, Baseline files were slightly larger so High is again the choice.
- Encoder Level - The new presets in the latest 1.0.x release of HB all use encoder level 4.0. The legacy 'High Profile' preset I had been using prior uses 4.1, so I was curious to know if there was any difference, and there is - the 4.1 encodes were consistently about 3% bigger, and that's it. Everything else being equal, there were no visual differences I could see between files. Therefore I see no reason to use 4.1, as I had been.
Bottom line, after this I can say that when encoding blu-rays at a quality of 20, none of those other settings really do anything to improve or degrade the picture, all they do is affect file size, and you get the smallest files using either Med or Slow with None/High/4.0 for the other three. Someone might be able to blow up a screen shot to show an example of where they do have an effect, but I'm not too worried about one-off examples of blown up images that you wouldn't be able to notice while actually watching the movie.
The next question would be to run all of the same tests again at a quality of 22, or even higher. As you increase the Quality number (i.e. decrease the output quality), does toggling any of those settings result in a smaller file that is still indistinguishable from one encoded at 20? For me, at this point I'm not sure I care. I just want a visually indistinguishable picture at an easier to manage file size than the full mkv rip, and to be able to use one HB preset that I know is going to give me worry-free consistent results, and I think I have found that.
I'm using HB nightly 20161018162315-19b0ddf-master (2016101901) 64-bit version.
Taking all the basic video defaults has always worked fine, but I cooked Kubo and the Two Strings and it ended up being stretched vertically i.e. everything was very skinny.
I used MediaInfo on the original rip and it says 1920x108 but the final version says 1918x804.
When I open it in HN with Anamorphic set to Strict that's what the output resolution says so I changed it to None and set the width and height to the same as the original at 1920x1080 and cooked it again.
This time the resulting file says via MediaInfo 1920x1080 like the original, BUT everything is still skinny when I play the video.
Curiously enough I checked several other flicks I've watched recently at in all cases the height when down from 1080 to around 800 BUT *none* of them had any issues with being stretched too tall.
What the frak?
Your thoughts good sir?
drc :)
As far as the issue with the original video - if it wasn't a typo and the resolution of your original file actually *was* 1920x108 (not 1080), that's likely the culprit.
If it was a typo (and 1920x1080 is the original), I'd suspect something else goofy with the source file. If you want to fix it you can try using Anamorphic Custom - don't touch any other resolution values (leave at default), but modify the PAR Width up or down various amounts and do some previews or short test encodes to see the result. Note that I don't know whether they fixed the Anamorphic Custom bugs for Windows by the time they hit that build, so this may or may not work on Windows. Mac OS should work though. Not sure about on Linux.
When I select Anamorphic - Custom the PAR width and height spinners are disabled, the only one enabled is Display Width - leave the top settings the same and set that spinner to 1080?
drc :)
All that said, it's a bit odd for a clean MakeMKV rip to behave oddly as far as aspect ratios go - usually aspect ratios only get garbled when they've been through an encoder at goofy setttings. It might be worth grabbing a newer version of MakeMKV (if you're not on the latest), and simply try re-ripping from the source. Of course, if the original MKV plays back fine in various media players (VLC etc), that would tend to point towards the issue being in HB itself (though MakeMKV could have injected a wrong flag somewhere I suppose...). It could be worth jumping to the latest version of HandBrake in case there was a bug in that particular nightly version.
drc :)
At this point you're probably better off trying to chase down newer MakeMKV and Handbrake versions to see if a typical Anamorphic Strict will just handle everything and avoid whatever glitch/bug you may have originally hit. I say that because chasing down a way to get Anamorphic Custom working is likely to be more painful.
Note that in newer versions of HandBrake there's no more Anamorphic Strict so you'll likely either use the new "Auto" setting or use "Loose" - both should behave the same if you're keeping the max resolution (original minus cropping). They differ a bit in behavior when you start resizing downward (Auto allows storage width/height to be adjusted independently whereas Loose maintains the storage ratio), but that shouldn't have any real bearing in your case. If neither work, you could see if the Custom setting in the new version behaves and do the manual un-squishing of the image. However on un-resized sources there's a good chance the default for your source might be 1:1 for PAR and it doesn't allow decimal values so you'll likely have to change it to 100:100 and then start moving up the width (ie try 120:100 to stretch width out by 20% and play from there).
As for Kubo, I'll just snag a copy from online somewhere for my collection.
Thanks for your time and info.
drc :)
As long as the rest of my flicks seem to be fine I'll roll along with the current copy of HB until more videos go wonky.
As for Kubo, I'll just download a copy for my collection.
Thanks for your time and advice.
drc :)
Been thinking a lot lately about switching my encodes to HEVC versus AVC and wondering if you had played around with this much yet? I've been reading in some forums that at high bitrates, AVC is still the way to go but most of these posts are are form early 2016.
It seems pretty clear that at low bitrates HEVC is the way to go much like AAC is better than mp3 but when the bitrate goes up the difference lessens.
Mostly encoding 1080p blurays that I've bought to add to my server library and encode AVC at Veryslow, high4.1, film, at RFs around 18-20. I'm assuming that is considered fairly high bitrate so am wondering if it makes any sense to encode in HEVC. I've done a little testing and it appears the file sizes are definitely smaller.
Is it even remotely safe to say that an RF of 20 in AVC is similar to an RF of 20 in HEVC...or is it really apples and oranges as the encoders are totally different and RFs are a relative scale...meaning 20 is better than 22 when using the same encoder?
So in regards to the last bit, AVC/x264 @RF20 isn't quite equal to HEVC/x265 @ RF20. IIRC the x265 devs made some tweaks last year to try and get things close, but realistically the best anyone can hope for is "in the same ballpark".
As for high bitrates, yeah, you aren't going to see large differences between encoders once you start getting to really high bitrates, because really fine detail is still expensive for any encoder to keep. I don't think I'd try to attach that to a specific RF value though because bitrates can really vary between 2 sources at the same RF.
Getting to (hopefully) answer what I think you're getting at, it might be worth checking the Encoder Comparison page I put up last year. You can compare x264 and x265 around the RF20 range there if you'd like, though figuring out what bitrates your own encodes have been hitting and choosing the closest bitrate setting on that page might be a little wiser (since x265 outputs at different RF's may have changed since I put that up due to new versions).
That page was really put up to try and help answer those sorts of questions - essentially anything along the lines of "what difference will I see in x265 vs x264", and other bits like "what's the potential file size difference and speed cost of x265 vs x264". Not that it's going to be perfectly applicable to other sources and newer encoder versions, but it should at least give a rough starting point to go from before you run your own test encodes and make your own determinations.
I am having one problem
Recording in FilmicPro to Mov, then converting in HB (using most of these settings) to mp4, drop into Premiere.
When I drop it to the timeline / sequence, the video length is like 1s (for a 10min vid) and won't render/play. It seems to be something with the framerate or container?
I tried interpreting the video using the vid's frame rate, to no avail. If I use 1fps I get a video with loads of artefacts.
Double-check the mp4 in a video player (Windows Media Player, Quicktime, VLC, etc) to make sure the encode itself wasn't completely borked.
Assuming the mp4 itself is fine, my best guess would be a compatibility issue with Premiere. Try a few quick tests with a fixed and possibly lower profile (try 4.1 High, then try 3.0 Main). Just use quicker encode speeds and a low RF value (or high bitrate) - you probably don't need the slowest speeds since the purpose seems to be as part of a toolchain to Premiere so as long as you can handle a large file it's usually easier just to use quick speeds and just deal with the fat bitrates.
Another option would be to just see if Premiere can read the .mov directly, via a plugin or something if it doesn't have native support. If not, depending on the stream's encoding you might be able to find a tool that'll just convert the .mov to another Premiere-friendly container without the need for transcoding. This would actually be my first choice to avoid the intermediate transcoding by Handbrake (as a general rule try to transcode as little as possible until the final step of your toolchain unless you're doing lossless transcodes).
As for the deblocking in "Advanced Settings", it's very different. It's essentially a flag dumped into the video which tells the player how much to deblock on playback (and this deblocking is quite different from the filters deblock). If you've used the old CRT TV's in ages past, the way *I* think about this one is that it's like the "sharpness" setting those old TV's used to have.... positive values are more blurry, and negative values are more sharp (to the point where you'll see more artifacts if it's too far in the negative direction). The Film/Grain/None/Animation/etc presets all set these to specific values that are commonly used for those source types.
If that's not an option (or if other platforms don't allow below 5)...
-----
CLI stands for "Command Line Interface" and it's a different version of HandBrake (available in their downloads section currently at https://handbrake.fr/downloads2.php ) that runs from Command Prompt (Windows) or Terminal (Mac/Linux).
It's a little more advanced, in part because it's text only. To encode a video as H264, MP4, High Profile 4.1, Tune Film, Slow, 1000kbps, you might type something like:...if this looks like a route you're willing to pursue, you may want to have a glance at https://handbrake.fr/docs/en/latest/cli/cli-guide.html . The part pertaining to deblock is --deblock, and it looks like in a basic from it may be something like --deblock=qp=5 (possibly --deblock="qp=5" if it requires strings to be quoted).
Alright, hopefully something in there helps. Good luck!
keyint=600 / keyint_min=60
I tried an encode by adding the line keyint=120 in the options strings under the advanced tab (vidcocer) where I also add the code nr=200 for noise reduction however it didn't do anything...the outputted video was still keyint=600.
Do you know how to do this and is it possible easily?
thanks
Ben
Unless you have some guidance or helpful insight about using keyframes, please go ahead and delete my question.
Thanks
Ben
The only thing I'd add regarding keyframes is to be aware that reducing the "keyint" interval will generally increase the size of the encode. Those keyframes are basically I-frames which are not unlike a full jpg taken in that point in the video. This is as opposed to P and B-frames which will store changes - when you manually seek in some videos and see garbled output for the first few seconds after a seek, you're often seeing a mix of P/B-frames (and the output eventually clears up when the video hits the next I-frame).
So while reducing the keyframe interval can make seeking a little cleaner, the tradeoff is that it comes at an increased overall file size.
One other option you *could* look into if you haven't already and are still testing would be tweaking the "scenecut" value. Scenecut tries to detect when the image has drastically changed (common when Cameras A/B switch between Person A/B during a conversation) - if it detects a large enough change, it'll throw the keyframe there. This is a sensible behaviour because P/B frames fall a little flat when there's a significant change (like swapping to another camera), so an I-frame (keyframe) there gives the following P/B frames a better reference. Increasing the scenecut value will make the encoder a little more aggressive when deciding whether or not to place a keyframe when the screen changes. All that said, tweaking "scenecut" is one of those things that may or may not help a pile, and how much it helps depends on the source and how frequently/drastically the scenes change. If you're looking for consistant seek times in MPC (always < 5s for example) then it might not help a ton and "keyint" is certainly a better avenue to pursue. But if you're looking for seek times that are a bit lower in general, it might be worth looking into pushing up "scenecut" a little and see if that helps.
ASIDE: I learned all this through much trial and error, using USB 2.0 and 3.0 flash drives on multiple Samsung LCD and LED TVs. I have no idea if this so-called bug is present in other TV brands or occurs in the newer Samsung UHD TVs, as I have made Samsung aware of the bug through correspondence, but I will leave that up to the far more qualified readers of this website to determine.
Thank you.
Thanks
(From the perspective of a humble software engineer.)
I know some parameter name and value which show in mediainfo must adjusted, such as:
deblock=1:1:2 in mediainfo become deblock=1,1|2 in handbrake,
keyint_min=30 in mediainfo become min-keyint=30 in handbrake,
psy_rd=1.00:0.00 in mediainfo become psy-rd=1.0|0.0 in handbrake
Thank you
- chroma-qp-offset=0
- cplxblur=20
- qblur=0.5
Example in HB adv panel:chroma-qp-offset=0:cplxblur=20:qblur=0.5
You might start by doing a "dummy" encode (that you will cancel) at different speed presets - take a look at the estimated time after a few minutes go by, cancel, try another speed, etc. Do this until you've determined a speed setting you're comfortable with time-wise.
Next, using that speed setting, do a 5-minute encode of the movie at various RF values. Check the results of these encodes to see where you're happy visually. You may want to do some math to guess how large the movie will be when fully encoded (ie expanding your 5 minute clip out to a 120 minute movie is likely to be roughly 24x the file size of your 5 min clip).
Finally, do a full encode at your chosen speed setting and RF value. If the end result is within your file size budget, then great! If not, you may have to do some further tweaking.
There are other ways to approach this, and you'll undoubtedly learn and adjust over time, but the above is certainly a possibility to get you started. I do have a few other write-ups in the encoding section of the site here that might help give you a sense of where you might want to start RF-wise. Good luck!
I've got a few questions and hope that you can give me answers:
1. What would you personally prefer in 2020: x264 or x265?
2. What crf brings it nearly or close to Bluray quality @1080p source bluray? Can you tell the sweetspot for archive quality?
3. On x264 you go with the "slowest" preset to get the best picture quality and lowest filesize. On x265 my experiences are totally weird. Sometimes the filesize goes up, sometimes down. Is there a sweetspot to reach bluray 1080p quality or should I change crf instead?
Thx! Keep up the good work!
1) At this point in time I'd probably trend towards x265. iPhone7/AppleTV4/iOS11-era stuff has HEVC/x265 support, nVidia's had it in products since 2015, Intel since Skylake (8-bit) and KabyLake (10-bit)... unless you're sitting on older hardware you've probably got some pretty efficient video decode capabilities available. The x265 encoder has been around for a good long while now too.
2) This is completely subjective as person A and person B may both find the encode to be "identical" at different bitrates. If microwaving the disk afterwards and storage space was no issue, RF0 (though just archiving the source would probably take less hard drive space: I haven't checked to see how well 7zip or xz will do with a large window mind you if this is truly being archived). If microwaving the disk after and disk space does matter, I suppose I'd hit around RF10 for x264 since I doubt you'd find (m)any people who could tell the difference between the original and the encoded version playing back side-by-side. Obviously check the encode before microwaving any disks, as glitches do sometimes present.
3) This is fairly common. I went over a number of aspects in https://mattgadient.com/handbrake-rf-slower-speeds-craziness/ . Short version is that the slower speeds should get you a better quality-per-MB ratio, but the total output size might differ since speed settings tweak a bunch of other settings that all have an impact. Find a speed setting you're comfortable with, stick with it, and focus on tweaking the RF value to adjust quality. Don't go the other way (choosing RF and then trying to tune based on speed - it won't work as you might expect/intend).
Best settings for Mini DV captured mpg file encoding to H.264 or 265.
I have played some dozen free video converters until I found Handbrake and your brilliant descriptions. I have a really oldschool theme, but frenkly speaking there is no good advice on the net concerning DV captured MPG file conversion to H.264. The main problem with the most of encoders that don't have deinterlaced feature. I have played with filters with HB, but the result is still not so smooth as the original mpg. Would you be so kind to advise Best settings for MPG encoding. The DV capture was made by Power Director 8, later releases even the mpg files is useless as in build encoding and encode it with HB 1.2.0 with following filter setting: Interface detection>Custom-Custom=slower, Deinterlace:yadif. I'm not sure that this syntax of custom field correct, but seems working.Without using this filter settings the output file is almost useless. How could it be set better.
Thanks for your advise in advance.
If you still have the original in PowerDirector it could also be worth checking to see if it will allow you to export the video as a progressive video.
Best setting for MPEG-2 encoding to H.264/5
Thanks for your replay. I did some dozen of test of course with 1 min trials as you suggested with totally different settings and now I really disappointed, because ONLY MPEG-2 is seamless. Especially when camera is moving the encoded video is always disturbing for eyes. I also not sure that it might comes from interlaced issue. I use different size setting, fix and variable framerates interlaced detections and settings even off but the result is the same. The only useful version is the original. I even try to encode with Powerdirector, but the the result is the same. If I convert to mp4 or m2s (the old version use this for h.264) is not so seamless. I have tried with other encoding software HD Factory, VideoPad Editor with no useful result. At the moment I have not found any software which could reduce the size of MPEG-2 file with useful result. So I would ask you more general : what is the best setting for MPEG-2 encoding to H.264/5 format in general. Please note that reasonable capturing result comes with MPEG-2 format so this is very general for saving old stuff but encoding and reduce the size of captured file is not solved at the moment...
Best regards,
Gyuri
A best setting "in general" for MPEG-2 to H264/H265 would be very subjective. Keep in mind that DVDs use MPEG-2 - there's nothing particularly special about the MPEG-2 format aside from being a lot more simplistic (and bandwidth intensive) than newer encoders. As far as Handbrake is concerned, behind the scenes an MPEG-2 should be decoded (into something of a "raw" stream) and then that stream should be encoded to the new container.
The fact that you're hitting issues with this particular source leads me to believe there might be something very unique or non-standard about this source: something that is tripping up encoders.
It may simply require a lot of trial and error to try to resolve the issues with this source. A few additional things you could try:
- Do a test encode at RF:0 (make sure you have lots of hard drive space as this will be a huge file). See if the issue still exists - if it does, you may be able to find the threshold RF value where it still looks okay but with a smaller file size.
- In a separate test encode with a reasonable RF value, use a MEDIUM encode speed. For the Profile, manually choose MAIN profile and level 3.0 if your source resolution is 480p or less, level 3.1 if your source is 720p or less, and level 4.0 if your source is 1080p or less. The intention here is to restrict a lot of the x264 settings that might trip up older decoders. If the end result looks good, you can start raising some of these values until you hit the threshold where problems begin.
- In a separate test, try encoding your MPEG2 as something even more basic or closer to "raw" (MPEG1 for example with a massive bitrate). If it looks good, try encoding *that* video to x264/x265. If it works well, then there's a good chance something in the structure of your original MPEG2 is non-standard or incorrect.
If absolutely nothing works, then it may be a situation where you might have to consider simply keeping the original MPEG-2 around, and treat it in a similar way to sources that are so marginal that any recode would have a notable negative impact.Thanks for your clever answer. Looking at the origin file I can't see any special (yuv420) but I agree that probably the codec was used in PowerDirector make something special. I have tried all suggested idea RF0 is the same, no matter level of encoder and so one, Maybe I need to start to accept using MPEG-2 but 1 hour is almost 4G..
Finally for me Framerate (FPS) meaning not so clear in HB or theoretically at all.. Here if I choose Fast 1080p30 it will be set Peak framerate to 30 max. In my case (PAL 25Hz) it should be 25 constant but nothing visible happened if I change this values. What value do you recommend in this case or can you give a short explanation about this rule.
Best regards,
Gyuri
For framerate, you should almost always use "Auto". This especially goes if the source used a variable frame rate, or when deinterlacing/detelecining. Otherwise Handbrake may either have to duplicate or drop frames to hit the target which can cause stutter.
A few exceptions when you'd want to manually set the frame rate:
- Extremely high source frame rates that have to be brought down for various reasons (video sharing site frame rate limits, etc)
- When a very specific frame rate is required (creating DVD-Video, etc)
- When using very very old devices or software that do not support a variable frame rate. Should be exceedingly rare.
- When targetting for a specific device that does not support high framerates (though usually you'd just cap the framerate via the profile/level supported by the device).
I'd avoid attempts to force NTSC/PAL whenever possible, as you'll immediately run into all the headaches and potential glitches caused by those conversions. It's usually better to leave any necessary conversion to the playback device/software. An exception there would be if you had a film you were distributing on disk to different regions but even then there are specific (separate) methods used for say... 24fps to 30fps and 24fps to 25fps.Seems I'm getting closer. Anyway what is the setting in Handbrake for Yadif double TFF. In that case should I use fix frame rate 50 for PAL signal? I have tried yadif filter with double frame top first with Virtual Dub and seems to be OK, but in Handbrake the filter part is a little bit confusing. If I choose Deinterlace > Yadif Preset >Custom Custom :mode how can I choose yadif, double-TFF mode? Here the syntax is mode:=,parity=p? but no glue which mode should I choose and what is parity?
Thanks in advance,
Best regards,
Gyuri
So by poking into more detailed stuff, you're venturing beyond what I've done anything with.
Since your source has obviously been a challenging one, I'm going to guess that your best bet is to find one of the worst scenes, get the time index, and queue a whole bunch of 10-30 second encodes of that scene with every possible setting deinterlace/decomb combination you can find. To do this, I usually select the time period and then:
- Add to queue
- Change setting
- Change file name to reflect the new setting (ie video-deinterlace-bob-auto_fps.mp4)
- Add to queue
- Repeat
...once all are added to queue, I just run the queue, come back later, and look for differences in all the outputs. As to setting the frame rate to a fixed value, again I really try to rely on Auto (it should automatically end up at 50fps anyway if using a line doubler and not decombing if source was 25fps) but you may as well queue up both fixed and auto framerates for each test sample you're going to queue up just to see if there's a difference.Thanks for your great help, here comes one setting which works fine. The motion as good as the input compressed (e.g. MPEG-2) or raw files.
Best setting for DV or SVHS/Composit captured file in Handbrake: Filter > Deinterlace :Yadif > Preset: Bob + Fix Frame rate double (PAL 50, NTSC 59,94)
Interesting issue is that if I choose higher profile, eg. MKV2160p the file size will be smaller compared to 720p.(H264) Output display size leave it default and the size result is the same in both case. I used default settings not touched RF and there is no visible difference but file size different around 40%.
Notwithstanding I will try what you recommend and let frame rate auto (30) and come back to you with the result. What is your recommendation for HDMI USB capture stick, because there are plenty of good encoder software but good capture one not really.
Best regards,
Gyuri
I'm an older guy (71) trying to figure out what I'm doing wrong with Handbrake version 1.1.2.
I have a .mov file from iMovie 11 that has both widescreen and SD material in it. (Output from iMovie is widescreen 16:9 dimensions 1920x1080)
In my iMovie 11 project, the SD footage had the blacks bars on either side (which is what I want.)
When I put the QT .mov file output into VLC it plays fine both WS &SD....but when I get the Handbrake output it automatically cuts off the sides of the widescreen material and the SD shots have no black bars on the side.....AND the aspect ratio is almost SD.... Not sure what I'm doing wrong.
Do you have any ideas.....I appreciate any help as I'm trying to put a reduced file on a USB for someone. Thanks
By default, Handbrake auto-crops black bars (which is what people usually want). However, to do this it only samples 10 frames of the video when the video is first loaded. When you have mixed content (as in your situation) this sometimes poses a problem. There's a good chance that all of Handbrakes samples were of the SD portion, which means it likely assumed those black bars were present throughout the entire video and should be removed.
The first option if you don't need anything cropped is to disable Automatic Cropping (in Video/Filters if I remember right), and if it auto-filled numbers for top/bottom/left/right set those all to 0. Handbrake won't try to crop anything then so it should look like the original.
The second option is to go into the Handbrake preferences, and increase the preview samples from 10 to something much higher (and hope one of the samples hits a widescreen portion).
I suspect the 1st option will be more suitable. If you go with the second option do a short 1 minute encode of the clip to ensure things look right before you do the entire thing. Actually, since you had an aspect ratio side-effect it might be worth doing a 1 minute encode anyway just to make sure you aren't hitting another issue.
Now my widescreen is perfect and the SD material has the black bars on the sides the way I wanted it.
Many thanks to you.
We need an updated version of this guide please!