Update: If you’re using Handbrake 0.9.9 and would rather use the new “x264 Presets”, I have an updated guide for Handbrake 0.9.9 which focuses on that. However, if you’re sticking with the “Advanced Settings” or want more in-depth information on the Audio Settings, Picture Settings, etc (which I did not repeat in the new guide), keep reading….
The old best H.264 / x264 settings for Handbrake wasn’t very complete, and became outdated. Here I’ll try to take a more thorough peak at settings here to help you get the best x264 / Handbrake settings possible for your encode. Warning: the previous write-up was short. This one is insanely long and detailed. If you find yourself overwhelmed (don’t feel bad, there’s a lot to take in), muddle through in Handbrake the best you can and just use this as a reference when you get to an option you’re unsure about.
The focus here is on getting the best quality using x264 through Handbrake, even if it takes a long time to encode (within reason on a modern processor anyway).
Heaven help you if you’re using an old Athlon…
I’ll start with the advanced settings and work backwards.
Advanced Settings
Reference Frames: max possible
This goes up to 16. Unfortunately, 16 will break playback on a lot of hardware devices (and possibly some software players). So if you’re using say… an iPad3, WDTV, Roku, AppleTV3, etc, you’re going to have to find the max for that player. The easiest way is to see what “Profile” your device supports.
I’ll use an example. The iPad3. The specs page lists “Profile level 4.1” under the “TV and Video” section (right now anyway – that page might change whenever the iPad4 comes out). So we don’t want to go higher than what “Level 4.1” supports if we want the video to play back on the iPad3.
Next we take that “Level 4.1” to the MPEG4 page on Wikipedia where we’ll see a bunch of cryptic stuff under the “Level 4.1” part. When it comes to Reference Frames, we need to look at the following in the last column:
1280×720@68.3 (9)
1920×1080@30.1 (4)
2048×1024@30.0 (4)
The stuff in brackets (max stored frames) means Reference Frames.
A typical DVD will fit within the 1280×720 confines and can use up to 9 reference frames*.
For a 1080p BluRay, up to 4 reference frames.
If we go above this, the iPad 3 (using Level 4.1) might choke when trying to play it back.
*For the sake of simplicity, I’m being conservative here mentioning 9 ref frames for a DVD. If you look at a lower level such as Level 3.1 you’ll notice that it actually lists a DVD’s resolution of 720×480, and will handle 13 reference frames. So you might be able to push 13 reference frames (or more) at Level 4.1 on a DVD. Suffice it to say, finding the true max ref frames at your particular resolution and framerate can get very tricky – the wikipedia page just lists a few examples for each Level. If you’re very hard-core about finding the true max ref frames for your source, you can try to math-it-out or simply do some trial-and-error.
So look at your device’s specs to find the “Profile Level” and then match it up with the Wikipedia link above to find out the max reference frames you can use. Remember, this depends on the resolution and as we saw in the above example, a DVD can get away with 9 reference frames on the iPad 3, while a BluRay can only get away with 4 ref frames.
If you’re just playing your content on a decent computer (through VLC for example), feel free to crank it all the way up to 16. Just remember that it probably won’t play on many (if any) current hardware devices. And a really slow HTPC might even choke.
Note that high values will take noticeably longer to encode, even on a fast machine. If 16 makes your encode take way too long, feel free to bump down to something like 8 (the default for the “slower” preset in x264).
Maximum B-Frames: 16
16 is considered a “placebo” setting in x264. That said, it doesn’t add a ridiculous amount of time to the encode.
This just tells the encoder how many consecutive bframes it can use. Chances are that the encoder isn’t going to find a situation where it makes sense to actually *use* 16 consecutive bframes. If your encode times are are really hurting, 8 might be more reasonable.
CABAC Entropy Encoding, 8×8 Transform, Weighted P-Frames: yes (checked)
They’re all different, but just about everything relatively-recent supports these. If you’re trying to play the video on a really old or really weak device (where many of the other settings I’m listing will probably be problematic too), you might have to turn them off.
CABAC simply uses better compression for certain data in the encode.
8×8 Tranform lets the encoder do another nifty technical thing with i-frames.
Weighted P-frames tends to improve compression when fades take place.
Pyramidal B-Frames: Default (Normal)
If you’re creating an actual BluRay disc from your encode, use “Strict”. Otherwise, most recent devices support it (if you’re using something old/weak, you may need to turn it off).
B-Frames are great. This makes them even better. This allows B-Frames to be used as references for other frames (like other B-Frames!).
Adaptive B-Frames: Optimal
We’re aiming to pump as much quality into a filesize, so set this to Optimal.
From what I gather, if you set this to “none”, B-Frames would be put into a simplistic “cookie cutter” order, which isn’t likely to be ideal. Both “fast” and “optimal” allow the encoder to use them effectively/efficiently, with optimal doing a better job.
Adaptive Direct Mode: Auto
This has to do with “motion vector prediction”. I assume that spacial looks at individual frames whereas temporal looks across multiple frames. Spacial is supposed to be the most useful, but because that isn’t *always* the case, using Auto is the best way to go so that the encoder can use whatever is most useful.
Motion Estimation Method: Uneven Multi-Hexagon (umh)
UMH is about the highest you can go without running into insane encode times.
The encoder uses certain motion estimation patterns (do some googling if you want to know what each looks like). If you go beyond this to exhaustive (or transformed exhaustive – considered the “placebo” setting), it becomes something of a dumb brute force search.
If you’re intent on going with Exhaustive or Transformed Exhaustive, your encode even on a fast machine might take days, so consider if it’s really worth it for the “placebo” effect.
Subpixel ME & Mode Decision: 10 QPRD in all frames
Suffice it to say, higher is better, but 11 would take a good bit longer and is considered a “placebo” setting.
Motion Estimation Range: 24-64
Despite 64 being considered far beyond even the “placebo” setting, my DVD encodes have had pretty reasonable encode times (under an hour for a 44-min episode), which is the only reason I’ve allowed it to stay so high. BluRay encodes on the other hand…. those approach the better part of a day at a setting of 64.
Something in the range of 16-24 is probably more sensible.
This is the maximum range in pixels that the encoder will search for motion. Higher settings should be more valuable at higher resolutions (since a hand moving on a BluRay travels more pixels than a hand moving on DVD, despite travelling the same distance on your screen). Obviously, a high-motion video will tend to be more sensitive to this setting than a low-motion video.
Partition Type: All
As I understand it, the “most” (default) setting enables 4 primary partition types, and “all” enables a 5th, which is supposed to have negligible usefulness and slows down the encode. The “some” setting only enables the 2 most critical/beneficial ones.
If you’re using a modern 2011/2012 processor, I’d be inclined to set it to “all”. I myself haven’t noticed adverse effects on encode times (and I used “all” 3 years ago on older systems too), so if it might help sometimes, may as well keep it.
Trellis: Always
It’s required by the Subpixel ME & Mode Decision setting of 10 that was used earlier. If you’re doing 2-pass encodes and are finding the first to be painfully slow, you could consider setting it to “Encode Only”
Deblocking:
-1, -1 for film (tv/movies) and 3d animation (Pixar stuff)
1, 1 for animation (Bambi, etc)
-2, -2 for high levels of film grain
Note that if you’re trying to tune to retain film/grain, you should read over additional manual settings at http://forum.handbrake.fr/viewtopic.php?f=6&t=19426
The above are typical guidelines from x264’s “tune” settings. Unsurprisingly, this is designed to reduce “blocking” in your final video. It comes at the expense of “smoothing” the overall image though.
Generally, go with the above suggestions. If you’re seeing “blocking” in your video that didn’t exist in the source, you’re better off either increasing the RF setting (or average bitrate) first and/or playing with the AQ/Trellis settings I mention next.
Adaptive Quantization Strength: (slider)
1.0 (Default) for tv/film and 3d animation (Pixar stuff)
0.6 for animation (Mikey Mouse, Bambi, etc)
0.5 for high levels of film grain (you’ll need a high bitrate or quality setting)
These are x264 “tune” defaults and are good guidelines. The easiest way to explain this is that higher values tend to take some bits away from highly-detailed areas and put them in lower-detailed (flatter) areas. I’ve seen it explained as ringing (high AQ strength) vs banding (low AQ strength), though even that depends on the source.
From what I’ve tested, it doesn’t seem to have much visual impact for low-bitrate film encodes although it can affect the file size. Unless you’re willing to do your own testing/research, I’d recommend you use the recommended settings for a “one size fits all”.
Psychovisual Rate Distortion: (slider)
1.0 (Default) for tv/film and 3d animation (Pixar Stuff)
0.4 for animation (Mikey Mouse, Bambi, etc)
Again, x264 “tune” defaults, and good guidelines. This bears similarities to the above “AQ” setting in that it moves around bits. Higher values try to maintain “detail” the way you’d see it across the scene, at the expense of overall quality.
Psychovisual Trellis: (slider)
0.15 for tv/film and 3d animation (Pixar Stuff)
0 (default) for animation (Mikey Mouse, Bambi, etc)
0.25 for high levels of film grain
Tied into the Trellis setting above. The defaults are good guidelines.
Other goodies:
There’s a slew of custom settings you can add in the text box but you may have to search a bit.
You may have to modify some of them slightly to suit Handbrake. Settings in the text-box tend to be in the format settinga=1:settingb=5:settingc=32:etc with a colon (:) separating settings. By glancing at the text box in handbrake, you can probably figure out the format.
rc-lookahead – If you click the “High Profile” preset in Handbrake, you’ll see this pop up in the text box (there’s no option box or slider). There are a couple systems in the encoder that make use of this, and higher is generally better (max is 250). That said, rc-lookahead=60 is about the max recommended (even the “placebo” setting doesn’t go higher).
A couple reasons for this… First, it gobbles up RAM. If you’ve got 8GB+ of RAM and find yourself wishing that Handbrake would utilize more, this will do it. By the same token, if you’re on a 32-bit system or are on 2GB or 4GB of RAM, I’d imagine increasing this too much will probably crash the encoder.
The next reason is that huge values don’t really have much benefit – large values take quite a bit longer for the encode, and file size / quality don’t seem to change. I tend to set it to around 120, but I can’t say I’ve noticed any benefit.
nr – this isn’t touched/referenced by handbrake, but you can use it by manually adding nr=100 to the text box. It’s a denoiser built into x264. The good news is that it’s built in, motion-compensated, is minimal in the way of negative side-effects, will reduce your filesize slightly, and it’s fast. The bad news is that it’s not terribly good (the x264 devs are open about this) – from what I gather they only added it because they already had motion-compensated data in the encoder so it was easy to implement.
I used nr=100 and values up to nr=1000 in an encode with a very noisy/grainy source. There wasn’t a massive difference between 100 and 1000 (though quality didn’t really suffer either, and filesize went down).
Surprisingly, it’s alright at the 1 thing the denoiser in Handbrake is bad at – noise in the source during motion. See, the denoiser included with handbrake (hqdn3d) is good at temporal denoising during static scenes, but rather poor at addressing noise during motion – normally you end up having to bump up the spacial denoiser to clean that up, but at huge expense to your image.
However, the x264 denoiser does alright when catching noise during motion, which complements the hqdn3d denoiser in Handbrake quite well. I’d imagine it still pales in comparison to other motion-compensated denoisers, but it’s better than nothing, and as I said, doesn’t seem to hurt the rest of the image much (if it does at all… I really couldn’t tell – I’d have to try it on a clean source to see if I notice anything).
There are a number of other x264 settings you can manually plug into Handbrake too, but the 2 above are the only I’ve played with.
Chapters:
By default, if you load a source that includes chapters, they’ll be included here, often named Chapter 1, Chapter 2, etc. Not very descriptive.
Here, you can edit the chapter names.
In DVD/BluRay TV shows and movies, some have a “select scene” feature in the menu that lists all the scene names and lets you jump to a scene (which is actually jumping to a chapter). If you’d like, you can manually enter these chapter names in Handbrake. It’s also possible to import a CSV with Chapter names if you happen to obtain one.
Handbrake does NOT support editing anything other than the names though. So if your video has no chapters (or you want to add/remove some), you have to use a different program to do this.
That said, in the upper-section of Handbrake, you can choose which Chapters to encode. Sometimes a DVD/BluRay will have the last chapter be where the credits start. If you don’t want to encode the credits, check the DVD/BluRay in a video player (jump to the last chapter), and if it’s all credits, feel free to leave them out of your encode.
Note that credits don’t take a *lot* of bitrate, but in the case of something like a “Lord of the Rings” encode, they do take a long time (and cutting them out can save a good bit of filesize). In other cases, cutting them is just convenient – I’m not a fan of seeing constant credits when I watch 2-3 episodes of a show back-to-back.
Subtitles:
If Handbrake found subtitle tracks in your source, you can add them here (as many as you want). The “default” selection will make it the default track that plays when the video does (if there’s no default, none will play automatically unless you turn them on).
However, not all devices will play subtitle tracks. This can be particularly frustrating when you have “foreign audio” or “forced” subtitles. For example, when Jabba the Hutt speaks in Star Wars or somebody speaks Russian in a TV show. In these cases, you can “burn in” a track so that it’s now part of the picture.
But how do you know which track has the “foreign audio” subtitles? Handbrake makes it easy – select “Foreign Audio Search” along with “Forced Only” and “Burned In”. This will search subtitle tracks for anything that plays 10% or less of the time (which is usually the forced subtitles). If it finds anything meeting this criteria, it’ll burn it right into the picture so that it’s always there no matter what device it’s playing on. The only downside is that if you add regular subtitles too, they’ll overlap while the video plays. So if you’re burning in “forced subs”, you may want to consider leaving out any others.
The benefit to “Foreign Audio Search” is that if you’re not sure whether your video had a scene or two with some foreign audio, you can turn this on anyway – if there was, handbrake will find it. If there wasn’t any, nothing will be added.
Note that in some sources, subtitles are already burned-in to the picture. A good example is the US-region BluRay for Lord of the Rings (Extended Edition). So don’t panic if you don’t see a separate subtitle track in your video… it might already be burned in.
Audio:
Handbrake will list the audio tracks from your source and automatically add the one it believes is the main one (usually English with the most channels). You can add more tracks if you’d like – often there will be a Main 5.1ch of sorts, a Main 2.0 channel, perhaps a few 2-channel with director’s commentary, other languages, etc.
For the audio codec, most devices will play either AAC or MP3. AAC is generally considered to be superior in quality nowadays, although most people won’t notice the difference.
For AAC, the “CoreAudio AAC” codec is generally considered to be the best. However, it’s limited to those encoding on the Mac (it will play on anything that supports AAC though, including Windows machines). If you’re stuck on Windows, the “faac AAC” is the best option here, unless you’re willing to use something like MeGUI instead of Handbrake (which supports a Nero AAC encoder which is considered as good as CoreAudio)
Dolby Pro Logic II is a common mixdown option – it’ll play on anything in 2-channel, and is alright when it comes to “faking it” if you play it on say.. a home theater system with multiple channels, though you want to read further for “passthru” details which you may prefer.
Samplerate – you can generally leave it at “Auto”. If you have a reason for specifying something specific (like 44.1), go ahead and do so, but note that by manually setting it, you risk low-samplerate audio being needlessly upsampled, and vice-versa.
Bitrate – 160 is common. 128 is often considered too low (a number of people can tell the difference between 128 and 160). You could push higher, but some devices aren’t rated for it. It’s very tough to distinguish bitrates above 160, and insanely difficult to distinguish anything above 192. Note that if you’re adding “commentary” tracks, it can be a good idea to drop the bitrate of those simply so you don’t waste space – the quality of a couple people talking isn’t as critical as the main movie track, you don’t need a high bitrate to get good quality of simple voice anyway, and they often aren’t listened to frequently.
There are also “Passthru” options – these are a little riskier to use since it will depend on device support to play them. For example, you can passthrough AC3, or DTS, but if your player doesn’t support it, you might be out of luck. In addition, these don’t compress the audio stream, so passthrough is a terrible idea if you’re aiming for low-filesize encodes. If you play your content extensively through a 5.1 channel Home Theater system though, passthrough may be your best option.
Video:
For the codec, x264 (hopefully you didn’t read this far without committing to it!).
For the framerate, “Same As Source” (Variable Framerate) is generally best unless you have a very good reason to target a specific rate. This goes double if you do anything like detelecing the source. Really, “same as source” is awesome. Setting something manually just runs the risk of creating issues.
Constant Quality vs Avg Bitrate – Both work in a similar fashion. They both vary the bitrate throughout the encode – using more bits when necessary, and less bits when they’re not needed.
The difference is that Constant Quality targets a certain level of quality whereas Average Bitrate essentially targets a file-size.
Note that “compression-type” improvements in the advanced settings tend to affect these in different ways. With Constant Quality, higher settings (like going from 1 to 5 reference frames) will tend to maintain the quality level you set, but decrease the file size. With an Average Bitrate, an improvement (like going from 1 to 5 reference frames) will tend to maintain the file size you chose, but increase the quality.
A great example of a benefit of CQ here is if you’re encoding a TV series with Constant Quality. Episode 10 will look as good as Episode 1, even if Episode 10 had a zillion explosions, lots of movement, etc. Sure, Episode 10 might end up being a bit larger, but Episode 15 which had people standing around talking for most of the episode was probably a bit smaller.
On the other hand, had you used an Avg Bitrate instead, Episodes 1, 10, and 15 would probably be roughly the same file size. Episode 1 might look good, but Episode 10 might look terrible. Episode 15 might look the same as Episode 1, but could be larger than it otherwise would have been if you’d used Constant Quality instead.
Really, the only tangible benefit to Avg Bitrate is if you’re targetting a specific filesize. If you absolutely require all your shows to be 350mb so that you can fit 2 per CD, pulling out a calculator and calculating the Average Bitrate is the only way you’re going to be able to do it easily. And because Average Bitrate needs 2-pass to perform best (since it has to figure out how exactly it should pack all the bits optimally into the file-size bottle), you’re also spending more time during the encode – had you gone with Constant Quality (which doesn’t need a 2nd pass), you would have saved time – time you could have put into a higher quality advanced setting if nothing else.
Constant Quality does look more confusing on the surface at first. You have an RF setting, and if you’re new to this, you probably have no idea what it means. To start, lower settings here mean higher quality. RF:16 will be much better quality (and larger in size) than RF:24 for example.
As a basic guideline, RF:20 is a common starting point for DVD encodes and RF:22 for BluRay encodes. If you’re a real stickler for quality, 16-18 for a DVD might be more ideal (or even lower numbers if you’re determined to make it indistinguishable). On the other hand, if you’re looking for really low filesizes and are willing to accept that it won’t look as good as the source, 22-25 can work for DVD’s.
After a few encodes with Constant Quality, you should have a good idea as to what setting you prefer, whether you’re looking for high-quality, or are looking for low filesizes.
If you do need Avg Bitrate though, go with 2-pass. The encoder really needs that 1st pass to learn which scenes are complex (and will need more bits), and which scenes are simple (and will need fewer bits) before it actually goes and starts allocating things.
Think of it this way. If you’re hosting a party and have 350mb of pizza to go around (i know pizza isn’t measured in MB – bear with me), it’s good to know how many people are arriving beforehand, and ideally how many are kids (small eaters) and how many are adults (big eaters). 2-pass is like that – it does some research beforehand (during the 1st pass) so that it can cut up the pizza properly so that everybody is fed (during the 2nd pass). Without that research, you might start handing out too many portions to people at the beginning and run out when the adults arrive later.
Ok, not the greatest analogy (better than the “milk” one I was going to use mind you), but you get the idea. 2-pass is good if you’re going Average Bitrate. If encode time is an issue, you can use “Turbo first pass” – it does less thorough research beforehand, but is still much better than none.
Video Filters
(Recommended)
Detelecine: Default
Decomb: Default
Deinterlace: Off
Deniose: depends
Deblock: Off (usually)
Handbrake is beautiful in this area.
For both Detelecine and Decomb, at the default settings Handbrake looks for telecined and interlaced content, and then detelecines/deinterlaces as necessary (and only IF it detects these things). That means you can set-and-forget. If you have a really weird issue with an encode you can go and turn these on manually, but 99% of the time there’s no need to. Set them to default and let Handbrake do the work of determining whether they’re needed.
Denoise…. I’ve gone into details in a long post here. UPDATE: A new, better post with images/video here. The short version is that If you have noise (or film grain) in your SOURCE that you want to get rid of, start with the “Weak” setting. It will “smooth” your image some, but will usually at least reduce the noise/film. If “Weak” isn’t enough, I strongly suggest reading the write-up and using custom settings because “medium” and “strong” tend to soften the image too much, making people look like Ken & Barbie dolls.
It’s worth noting that because denoise smooths out detail, it also reduces the filesize (or increases quality) of your encode. If you’re ok with the results of the “Weak” filter, it’s a great trick to bump down the file size of your encode rather substantially. However, you do run the risk of over-smoothing or banding so don’t be overzealous.
Deblock…. this is supposed to remove “blocking” that exists in your SOURCE. It really smoothes out video to the point where it probably causes more damage than it fixes (I can’t stand it). If your source has heavy blocking for some reason, it may be worth the trade-off to use it.
Note that the Deblocker in handbrake has a similar effect to high de-noise settings. Because it drastically smoothes, it tends to destroy grain and other noise. That means you could effectively use it as a denoiser. In some cases it will do a better job denoising than the denoiser.
Picture
I’ll assume you’re not trying to resize the video (if you are, I’m sure you’re capable of figuring out how).
Anamorphic is almost always used, since it acts the way a DVD would, and plays well with both computer software players and various devices. Reading up on the Handbrake site is probably the easiest way to go here for further details on what it means.
It used to be that Anamorphic LOOSE was recommended because it makes everything divisible by 16 for the encoder. However, from what I gather the encoder has improved, and Anamorphic STRICT is generally the preferred way to go now (since loose might do some slight resizing which we usually don’t want).
Cropping – Automatic is usually fine. Handbrake basically looks for (and then chops off) any black bars in the source. Nearly every player will add it’s own black bars (since the video is set to Anamorphic), so encoding them is senseless.
You can of course manually set these if you have a good reason to.
—
Well, that’s that. All on one (really long) page, so you’re not exposed to a zillion ads in a multi-page article.
I should end by noting that this may not all be 100% correct. I’ve gathered the information from as many sources as possible, but chances are I read something I shouldn’t have taken at face value.
So take it with a grain of salt, and do your own tests before you spend a week encoding a TV series only to find that it all went horribly wrong because I made a mistake somewhere :p
Good luck!
But I forced subtitles into Star Wars III to get any alien speech to come through
However it also burned in the Directors name at the top of the screen every time someone new in the Directors Cut spoke
The audio didn't contain the commentary, as I didn't want it, but i now have a copy with Directors names coming up every couple of minutes or so
Any way to get the alien subtitles I want without the commentary names?
I figure this would happen with most DVDs that have a commentary track
Yes, that's a bit of an edge case. Handbrake scans every subtitle track for something that appears 10% of the time or less. Usually it works great but as you found, if they found some other reason to display subtitles less than 10% of the time... not so great.
One thing that *should* work (though time consuming) is to play part of the DVD through something like VLC (it's free, plays just about everything) and figure out which subtitle track contains the forced subtitles. While the DVD is playing in VLC, in the top menu, choose "Video / Subtitle Track" and swap through them, preferably around the time that Jabba is talking. My guess is that you'll probably find 2 subtitle tracks that play for his voice - one that's only forced subs, and another that has everything. At that point, you can try to match up the correct one to the subtitle list in Handbrake.
Do a fast encode the first time (just in case you didn't match it up quite right).
If for whatever reason you're still having problems let me know - I encoded Star Wars a long time ago, but I can dig up the DVD's again and see if I can narrow things down for you if need be.
i used handbrake 0.9.8, and i remember in handbrake 0.9.5 it had option to used small (custom file size). any idea matt?
thanks for your reply :)
any idea to make the size smaller (half of before) but not reduced the image quality at all?
thanks for your reply
note: from your setting above, the size of my tv series file now 80% of the previous size
That said, a few things you could try...
-turn on the denoise filter (weak or custom) in picture settings. This will likely soften the picture a little, but should help reduce the file size. Make sure it looks acceptable.
-use 16 b-frames
-use as many reference frames as you can. Note that this will make the encode take longer (and if you use too many, it might only play on the computer & not on portable devices)
-turn up the RF to as high as you can bear.
Keep in mind that if your xvid videos are already small in size (low bit rate) it is going to be very very hard to reduce the filesize further without noticeably hurting image quality when recoding. It's much easier if using a larger size xvid with a higher bitrate (or ideally, the source bluray or DVD which will have a huge bit rate). The more bits in the source you're using, the better job handbrake & x264 can do!
Best of luck.
If you're using something like "Playon" to stream your movies to a PS3, Google TV or WII (or even your Tablet or Phone), it's usually not a good idea to "Pass Through" a DTS encoded Audio, since it tends to cause jittering or pausing of the video and other Sync issues with DLNA devices. The same is true with MKV containers. It's best to stick with MP4. As for the audio, Probably your best bet would be to encode in either AAC or AC3, which leads me to another issue. You need a minimum of 320 to 384Kbits/s in order to preserve the full 5.1 surround sound, so if you're planning on hearing the woosh of the Millenium Falcon pass first from your left front speaker to your left rear speaker, 160Kbits/s isn't going to cut it. The channels tend to get merged when there isn't enough bandwidth to keep them separate. Depending on your source, you can usually encode AAC to up to about 320 and AC3 to around 640.
Generally what I tend to do is take DTS and encode it to AC3, then choose 640Kbits/s
Something has been implentend in x264 which is called 'Macroblock Tree Ratecontrol' (mbtree). This is enabled by default. And if it's enabled, it screws dark scenes. To switch it off, there is the setting no-mbtree that has to be set to 1:
no-mbtree=1
Just add this to the 'advanced option string' box. Then it might look something like this, for example:
weightp=1:subq=9:rc-lookahead=10:trellis=0:b-adapt=2:deblock=-1,-1:no-mbtree=1
There is no checkbox for the mbtree thingy, so you have to do this via the advanced string. For me, this setting worked wonders for dark scenes. At least for my Madame Bovery DVD :-)
http://forum.doom9.org/showthread.php?t=159259
Someone wrote:
"[...] I have noted that with mb-tree on the encode at the same bitrate as the no-mbtree one has lower quality in dark grainy areeas, [...]"
And another guy:
"[...] MB-tree basically tracks detail through time. Something that "is there" for several frames ... is more important than something that's there for only one frame.
Grain, per quasi-definition, is "detail that changes every frame". So it's not difficult to imagine what MB-tree "thinks" about grain. And of course, in a dark scenery every unwanted deviation is much more obvious [...]"
Just to let people know about my encoding testing:
I came to the conclusion that 2-pass encoding combined with no-mbtree=1 is a much better idea for movies in which dark scenes are a problem. Especially when you have movies in which darks scenes are sort of grainy and hazy. For instance, my Madame Bovary DVD is rather poor source material, the movie is from 1991 and it looks washed out. A Bluray would be much better of course. But I only have a DVD as of now.
How did I tackle it? I set no-mbtree=1 in the advanced options string box. Then I used 2-pass encoding and restricted the bitrate. Because if you set no-mbtree=1, the bitrate for each frame increases -- not only for the dark scenes, but also where no-mbtree=1 is not needed. So with constant quality encoding, you'd end up with a significant bigger file size. In order to control this, the bitrate has to be restricted. But what bitrate to use? Well, I simply made a few tests with constant quality encoding, rendered 1 or 2 chapters of the dvd to find out what the expected file size might be. Then, with a bitrate calculator, I got the average video bitrate. There are plenty of bitrate calculators on the Internet. I used this one:
http://www.dr-lex.be/info-stuff/videocalc.html
Then I entered the video bitrate for the 2-pass encoding, set all the other settings in the encoding settings (important: because of the dark scenes, Subpel & ME Mode should be set to 9 at least) and started to encode. And the result was very satisfying: resonable file size and good or at least acceptable quality also in difficult dark scenes.
Besides, thanks a lot! Your infos were very helpful. Before I discovered your blog article, I didn't know anything about the fine tuning of Handbrake's encoding settings. After reading your rundown, I understood much more and was able to dig for more myself. Now I'm able to achieve much better encodings at same or lower file size.
Note that if by "stuck" you mean stuttering, depending on the file size, it could simply be that your hard drive can't keep up with the data rate the video needs - particularly if another program is accessing the hard drive in the background. This also applies if the file is badly fragmented, though this generally only becomes an issue in OSX if your hard drive is starting to get really full. Of course, if you're using an external USB2 hard drive, there's alwyas the chance that USB2 speeds aren't enough to keep up with the rate.
If you end up suspecting it's a data rate issue, you can try pumping up the RF value (lowering the quality, but also decreasing the data rate & file size in the process). If you're using an RF of say... 18, try bumping it up to say... 25 for a test run. If it plays fine at RF25, you can start tweaking from there until you find a good balance between not-stuttering & looking-good.
One other possibility I should probably mention (though it's somewhat unlikely)... I've heard that adding metadata (MetaX for example) can sometimes make videos act up in some players. So you could try playing the file in iTunes right after the encode - don't run it through MetaX. If it works, you may want to try something like iDentify instead of MetaX - it contains an option in the preferences to "Optimize files after tagging" which will re-write the file to help avoid that particular edge-case with tagging.
Good luck!
i also think its a hard drive problem. but it works fine with VLC. I have compared my video with video from itunes store. my video has a total bitrate of 3574 kbps, video from store have 412 kbps. so that might b the problem. So how can i set bitrate mode to constant not variable & how to set the total bitrate in handbrake? Is there any difference between birate mode and frame rate mode? one more, any difference between 'bitrate' and 'total bitrate'?
Sorry for my bad english
THANKS in advance
"Total bitrate" is specific, and would generally refer to the average bitrate across the entire video (3574 in your case). "Bitrate" on it's own isn't as specific, and it's meaning will depend on the context.
Bitrate and framerate are entirely different things that aren't directly related to one another. I suspect you might be looking at "RF" and perhaps incorrectly reading it as "frame rate". RF actually means "rate factor", and the higher you set it the lower the bitrate will be.
You asked how to set the bitrate mode to constant in your encode, but to be honest you probably don't really want that. It results in huge files that tend to look very poor when you get to complex high-motion scenes. Essentially, it wastes bits on scenes where it doesn't need many and it doesn't have enough bits when you get to scenes that need a lot. It's also a lot harder to even do/use in Handbrake - I believe there are ways to mimic it via some Advanced Option Strings (setting a min/max variable rate), but there's nothing in the GUI. Your best bet is probably to simply choose a lower Average Bitrate (this will be your new "total bitrate"), or if you've been using Constant Quality turn up the RF value to a higher number.
i tried this
CABAC Entropy coding, 8×8 Transform, Weighted P-Frames, Pyramid B-Frames, CABAC => All turned off
Ref frames, Maximum B-frames =>2
Adaptive Direct Mode: Auto
Motion Estimation = Uneven Multi-Hexagon
Subpixel ME & Mode Decision = 10
Quality=> Avg bitrat, 4122 kbps
frame rate: constant, 29.97
Now itunes plays it nicely and the file size is ok to me(105min movie is 3.57GB), anyway i dont know much about what those settings does..
and again thank u, the master of Handbrake
If my source file is an AVC TS file (Level Main 3.1) with 2 references frames, is there any benefit of pushing it past 2 in Handbrake? Thanks.
I just ran into a snag if you can help me out please. I am backing up my Bluray, video is VC1 Advanced@L3, when I encoding using these settings I end up with a High@L3.1 (I also resize down to 720p). Is there a way to encode this and result to High@L4.1?
Thanks for all your knowledge and great site :)
I have recently started to capture and encode 1080i Sports content(NRL in Australia) for archival purposes and would like to get the best quality possible! Without having enormous file sizes obviously.
I'm now using your settings as a template :)
Do you suggest any further adjustments that will be more effective specifically with sports?
After reading through I am guessing I should set the Motion Estimation Range to at least 64.
Deblocking to -1, -1?
rc-lookahead to at least 60.
Any suggestions would be great and thanks for this amazing guide!
I'd be inclined to double check and make sure decomb and detelecine are set to default - you could try experimenting with a couple trial runs to see if you get much difference between that and manually setting deinterlacing, mind you.
If you're going for archival, you might want to go with a lower RF setting than you normally would (higher quality). You'll have larger file sizes, but because sports broadcasts are something you can't exactly go into the store 10 years later and buy a DVD/BluRay of... you really want to make sure the quality will stand up over time. You kinda only get 1 chance with that type of content (once you've deleted the source, you'll have a hard time finding it again), so make sure you're happy with it.
Yes I was originally using Deinterlace until I read this. Then I checked it with Decomb and it was fine; looked the same and the log showed that it de-interlaced every frame except 1.
I might try testing encode times to see if Deinterlace is faster(maybe because it doesn't have to check each frame) seeing as I know the source video is interlaced anyway.
That's great advice regarding the quality settings, you've convinced me to go down to RF 19 or maybe even 18. I was originally doing RF 20 and getting file sizes of about 6.5g but I'm happy to use a bit more space with that in mind. It's impossible to get old games here, unless it's a final, and even then you'd be lucky to get it if it was 10 years old.
I spent some time last night testing different setting on my sample file. I recorded all details such as encode times and file sizes.
My original assumption was that because I am using CRF the quality of the video would be the same, but the file size would change with each adjustment.
This was generally the case but there was one anomaly, being Psychovisual Trellis; when I increase this to 0.15(from default of 0) it actually increased the file size by 4%. Is this increasing the quality of the video, even though I am using CRF?
Also, when I changed the Deblock(-1 -1) and Motion Estimation Range (16, 24, 32 and 64) the file size stayed the same in all instances, so I'm guessing it's not picking up any further movement(MER) or artifacts(Deblock).
I am really new to all this so all of the above assumptions could be totally incorrect. I will send my results through in a new post and you can put it up if you think someone might find it useful.
I only tested Reference Frames; B Frames; Motion Estimation Range; Subpixel ME & Mode Decision/Trellis (combined); Psychovisual Trellis; and Deblock.
First of all, Deblock did not alter the file size or increase encode times.
Reference Frames:
4 - (base value)
9 - 40% Increase in encode time ; 0.35% Reduction in file size
B-Frames:
4 - (base value)
16 - 32.5% Increase in encode time ; 1.27% Reduction in file size
Motion Estimation Range did NOT alter the file size, but did increase encode times:
MER 24 - (base value)
MER 16 - 3% Decrease in encode time
MER 32 - 6.5% Increase in time
MER 64 - 23.5% Increase in time
Subpixel ME & Mode Decision/Trellis (combined) had the biggest beneficial impact on the file size:
9 & Encode Only - (base)
10 & Always - 26.5% Increase in time ; 5.96% Decrease in file size
Psychovisual Trellis (Increased file size instead of reducing):
0 - (base value)
0.15 - 6.5% Increase in encode time ; 3.97% Increase in file size
Obviously this is only minor testing, and everyone could come up with different results depending on their source video.
Just to be clear, while CRF tends to maintain the quality, it's not always the case. In particular, things like Psychovisual Trellis (stuff that moves around bits to try to increase perceived quality) can throw a wrench into things, as you noticed. Visually there's probably a difference too between the encode with 0 and the one with 0.15 though it's probably slight since you're using a low CRF value (maybe not even enough to notice visually). Making things more exciting, one won't necessarily be "better" than the other either - whether people like the result of perceived-quality-enhancements often comes down to personal preference. Incidentally, if you try to compare x264 against other encoders and compare SNR between them, from what I remember PSY Trellis is one of the things you're not supposed/allowed to use.
Changes to reference/B-frames, motion estimation, etc should all maintain the same visual quality though.
I should have probably mentioned in the writeup... the Deblock in the advanced settings (listed as 0,0 etc) from what I remember actually stores information that's sent to the decoder when you're playing the file, so it doesn't (or shouldn't anyway) have an effect on the file size - it just tells the decoder how much to deblock the final video. I suppose I could have saved you a bit of time if I'd been more specific about that in the write-up (sorry!). The deblock in "video settings" however will have a substantial impact on file size if used, since it deblocks the source before the encode (though it looks terrible most of the time imo - don't use it!).
Sweet, so PSY Trellis is increasing the perceived quality, I had a quick look and couldn't notice any differences but I'll check on the TV rather than Monitor.
All good with the Deblock, I can now run some tests with the file on my media player and see if I notice any differences, so thanks for that info too, and for confirming on the other settings.
It's interesting to know that changing the reference frames was actually the worst cost/benefit ratio out of those settings, considering it is the more commonly known one. Maybe this is only the case with sports.
I should also mention that I am encoding to 720p but you probably figured that out because I used 9 ref frames to test. If I do 1080p at CRF 20 it gives me a 12 gig file :0
I'm archiving every game of the season for the team I follow so I can't afford to use that much space; encoding time doubles as well.
From what I can gather a 6-8g file looks better in 720p, even on my 52". A file that size in 1080p would only be about CRF 24-25 (not sure because I used two pass when comparing resolutions) so it seems logical I guess.
Once again, thanks for your help, I'll continue to play around with the settings. Hopefully I can finally make a decision so that I can get rid of these 20g original capture files from last season :)
Just wanted to drop you a big thank-you for putting together this Handbrake guide - it is the clearest, most complete of its kind that I have found online, and has been incredibly helpful in the task of converting my movie collection to files!
First of all. Great Handbreak guide!
I have a question about the subs.
I use the "basic settings" for a high profile mp4 rip with strict anamorphic and automatic cropping. When I watch the movie with the subs on in VLC, the subs are moved up into the movie. About the same distance as when its uncropped.
Can I do anything to place the subtitles in the correct position so the don't cover the movie?
(I'm from Sweden so please don't judge my english :D )
That said, it may be possible to add some black "padding" to the bottom of the video during playback - you'd have to browse through the advanced settings in VLC, but if you add enough padding, the subs should make their way down there. (Edit: I suppose if your source has black bars already, another option would be to disable the cropping in Handbrake's picture settings, though be aware that encoding black bars often isn't ideal due to the window-boxing you'll get on some displays).
The other option is to use another video player - VLC isn't known for being very flexible when it comes to subtitles, but some other media players are.
Thanks!
b-adapt=2:rc-lookahead=120:direct=auto:trellis=2:ref=4:bframes=16:me=umh:subq=10:merange=64:analyse=all:psy-rd=1.0,0.15:deblock=-1,-1:nr=200Note:
- ref=4 is for a 1080p BluRay so that it'll play on my AppleTV, iPad3, etc. I've pushed it up to ref=12 for DVD's (480p) but every so often get a few garbled macro blocks on the AppleTV and Quicktime/iTunes, so I knock it down to 9 if I don't think I'll be watching right away to make sure it survived.
- nr=200 I'll commonly use because I can't tell the difference in visual quality. Where I'm trying to pump the filesize down even more (TV series or movies I don't care as much about), I'll step this up to 400. If the source is really noisy I'll use 800 without much hesitation.
- When feeling impatient, I'll reduce motion estimation & subpixel to their defaults (Hexagon, and 7) to speed up the encode.
- I tend to make use of Custom Denoise settings in the "Picture Options" because dancing-pixels drive me insane, so it cleans that up while dropping the file size. 0:0:3:2, 0:0:2:1, and 0:0:4:1 are a few of the settings I'll frequently use on nearly any source (just the temporal denoising - I won't use spacial unless it's a noisy source). Very rare that I won't use anything here.
Keep in mind that especially when it comes to stuff like the psy-rd settings, it becomes just as much an art as it is a science - your personal preferences are going to start coming into play.Custom Profile
b-adapt=2:rc-lookahead=50:bframes=16:ref=4:direct=auto:me=umh:subq=10:merange=24:analyse=all:trellis=2:deblock=-1,-1
High profile shouldn't be bumping it up like that assuming you're using the same RF value for both - see if it added a 2nd audio track when you selected it (after selecting a preset it's often a good idea to look through the options and make sure no audio tracks were added and the resolution wasn't changed).
Does it sound right that it would take 2-2.5x times as long to encode using the custom settings vs Normal or High profile?
2.5 hours is somewhat long for a 30-minute episode though (I'm going to venture a guess that you're not on an Ivy/Sandy-bridge i5/i7). If you're going to drop something to reduce the time, I'd probably start with the B-frames and the Subpixel ME / Mode Decision (drop it to 7, similar to the high profile default). That should get you closer to the encode times you were seeing with High Profile.
Keep in mind that if you're using "Constant Quality" (RF), dropping those things probably won't affect the quality. You'll just be looking at larger file sizes - since you're ballparking within the 315-341MB area anyway (not a wide gap), the time might be more important to you than the ~25-30mb.
I have a question about your "start-point" advanced option string. Aren't most of those settings the same ones that are set via dropdown menus and sliders in Handbrake's Advanced panel? For example, isn't "ref=" the same as the "reference frames" dropdown? Isn't "deblock=" the same as the two "Deblocking" dropdowns? As far as I can tell, the only unique options in your string are rc-lookahead and nr.
If they are the same, then why is it necessary to repeat these parameters in the string? And if you set different parameters for the same option in the panel versus the string (e.g., setting the reference frames dropdown to 6 but writing "ref=4" in the string), which takes precedence?
Finally: do you ever use vbv-bufsize or vbv-maxrate? I noticed that they come up automatically in the string for the High Profile setting but everything I've read online indicates that both reduce picture quality. Any thoughts?
Thanks! Much appreciated!
Indeed that option string is derived from the dropdowns in the advanced panel. Filling out the advanced panel is what actually propagates that string (I manually added the "nr" as you noticed).
I'd pasted it because Zac had specifically asked for the code at the bottom of the advanced tab - it's possible he was looking for a short line summing up everything I used that he could manually convert to dropdowns.
To your question about repeating those dropdown parameters in the string, Handbrake does it automatically. You shouldn't manually repeat them or anything: just rely on the dropdowns where you can (most settings), and manually add anything that there aren't dropdowns for that you may want to use (nr, etc).
As for vbv-bufsize and vbv-maxrate, I don't manually assign them - these are filled automatically based on the profile and level. If you omit them (perhaps in addition to omitting "level=x.x"), your video might cause certain devices to choke out. For example an iPhone 4 is only rated to support Main level 3.0. That'll give advanced options that include "level=3.0:vbv-bufsize=10000:vbv-maxrate=10000". If you remove those values (or increase them), the video might choke out when playing on the iPhone 4.
As far as quality is concerned, what vbv-bufsize and vbv-maxrate actually do is "cap" the buffer size and instantaneous bitrate. So in a situation where the encoder actually wants to exceed that cap (but can't), yes, you'll generally lose quality. But in situations where the encoder wasn't going to reach that cap anyway, it'll have 0 impact on quality.
You can see an extreme example of this by encoding a short clip (say 10 seconds) of a video at Main Level 1.0 . It'll restrict the bitrate so much (vbv-bufsize=175:vbv-maxrate=64) that the video will either look awful or won't have enough bitrate to even work. Higher levels raise the limit, but a level too high (or not using any level) can cause the video complexity to be high enough that it won't play on some devices.
Hope that helps!
Thanks so much!!!
I did wonder what happened to the video panel's encoder options once the advanced options box is ticked. You mentioned that "tune" basically matches the advanced sliders. So then adding strings for level and the vbv's are the only way to override those defaults that appear grayed out ("x264 Unparse"), correct? Does the same apply for "Preset" and "Profile" - you need strings?
Also, I do not have an option for "Motion Estimation Range" in my advanced panel (Handbrake 0.10.0). I can't find anything online about why it's missing. Was this option discontinued with v.10? I suppose I could add it as a string as shown in your example.
Thanks again for your detailed help - it is very much appreciated! I have used Handbrake in the past and have been pleased with it, but I'm trying to understand the options now to achieve better quality results. Your posts have helped a LOT!
Keep in mind that certain profiles also restrict some things like reference frames, b-frames etc. So combining profiles with advanced settings may get to be a bit perilous... as an example if you set a profile that only supports 3 reference frames but manually select 16 reference frames in the advanced options, I don't know which takes precedence. It's one of the reasons (of which there are a few) that I've shifted towards using the x264 presets and only delving into the advanced options nowadays when I'm looking to do something pretty specific. The guide you're reading here was done back before the x264 presets were around, and also before I really started caring about playback on non-PC devices. Some of the stuff I've listed here may certainly be helpful when playing/learning/understanding but when it comes to actually pumping out encodes (particularly for playback on devices) the presets make life a whole lot easier.
The "Motion Estimation Range" (again, 1.0.7) only shows up on the higher Motion Estimation Methods (UMH, Exhaustive, Transformed).
Thanks again for helping me out. I have now run many test conversions using both your advanced settings and the presets, just to compare file size, playback, quality, etc. I have found that CQ18 results in a file about the same size as the original, while CQ22 is about half the size. The reference frame quantity is the main factor in processing time. The slower preset was the closest time-wise to your advanced settings while veryslow took about 20 minutes more (probably the 16 ref frames).
I did have one odd observation to share with you. I have been using reference frames in the 6-8 neighborhood (SD conversions from DVD). I am primarily on a Mac, which plays the Handbrake exports with no trouble. However, on my Windows computer (Windows 7 ultimate), neither Windows Media Player nor RealPlayer can handle Handbrake MP4s with more than 6 reference frames. The picture is blocky, horribly pixelated, breaks up....unwatchable. I have confirmed that it is definitely the reference frame setting.
I could probably download a codec pack that would fix it but it was interesting to me that a fairly recent OS on a decent computer would choke on the reference frames. It was my understanding that this was more of an issue with older devices and that computers were more advanced in their support for profiles and levels. Have you ever come across any issue like this? It's enough to convince me to stick with 6 as my reference frames value. :-)
Thanks again - your Handbrake posts were absolutely invaluable as I learned this program!
Jen
This could matter if the Profile is higher than the CPU/GPU decoder allows but the video player is trying to pump videos through them anyway rather than falling back to software.
You could potentially test for this by creating 2 low-resolution videos (drop them to say... around 430x240), use Main/3.0, and rely on the speed presets. In video #1 use a speed that will push reference frames >= 7 (probably slow, veryslow, or placebo but watch the ref=x line to verify). In video #2 either use a faster speed that'll keep reference frames < =6 OR keep the speed preset the same and manually type something like "ref=5" into the "Additional options" box (hit Enter after or change another option to ensure it's picked up in the un-parse).
As for seeing issues that are very similar, the Apple TV 2 & 3 (don't know about aTV 4) have a bug that prevents them from playing videos with 16 reference frames. Or at least of mine do. 15 reference frames work fine. Best guess is somebody at Apple slipped up on a 1-16 -> 0-15 -> 1-15 situation that sometimes happens when coding loops, but I can only speculate here.
Any tips on getting my encoded files to look like they do on my DVD player?
vbv-maxrate=25000:vbv-bufsize=31250
-Neil
No matter what the settings it seams, I still experience a subtle issue with judder during movement that pans across a screen. It is always worse with DVD encodes than BluRay. I have a dual core 3GHz w/ 6GB RAM along with an NVIDIA GeForce 210 510mb running HDMI to a Denon Receiver and then to a 55" LED LCD. I've tried bumping up the priority of VLC to high in Task Mgr. I've also tried bypassing the receiver. These same encodes work flawlessly on my slower laptop when copying the file to the local drive.
Some have mentioned that AC3 Passthru Audio could be the problem. I've considered that and tried different audio formats but it doesn't seam to make a difference. The advantage to AC3 Passthru, as written in the Handbrake guide, is that you do not lose the Subwoofer channel as you would in other formats. Without pass-through you end up with something like Dolby 5.0 sound.
I've also tried copying the file to the local OS Hard drive (over from the "green" data drive, also internal) and tested it there where it is a SSD. So IO isn't an issue it seams.
I've already upgraded the video card once and would again if I knew it would help. Or I can consider building a beefier machine with a quad core 64. The current Dual Core processor is an Intel and the OS is running 64bit. VLC is a 64 bit version. It APPEARS that the playback from Windows Media Player may be slightly superior, but it doesn't play the AC3 Passthru audio. When testing an encoded movie on Windows Media Center that has AAC for example, there is still some judder, albeit slightly reduced.
Any suggestions anyone can offer would be greatly appreciated. I've spent countless hours researching and trying to get to the bottom of it. Thanks again for a great video.
If that is the case (you're just dealing with a 2.35:1 movie), the answer to your question about a simple work-around is essentially "no", but if you were intent on doing it anyway, you'd basically have 3 options. You could:
- Crop some off the left/right side of the video (it's in picture settings) which is tantamount to chopping off part of the picture. To make this movie completely fill the screen on your iPad2 you'd need to crop off approximately 126 pixels from the left and 126 pixels from the right (if Handbrake already chopped off from the top/bottom, leave those values alone).
- Choose the aspect ratio in Handbrake (again, picture settings) and try to get it to something that resembles 1.33:1 (the total aspect ratio of your iPad). This will result in everything being vertically stretched. You'd have to experiment here - just setting it to Anamorphic None might be enough, although if the iPad still letterboxes it, you might have to also turn off "Keep Aspect Ratio" and set it to 468x352. Alternately, you could try "Custom Aspect Ratio" and play around with the PAR width and PAR height.
- Mix a custom aspect ratio with cropping. Don't crop off as much, and don't adjust the aspect ratio as much. Notion here is that things might look slightly less bad than if you went full-tilt in one of those directions.
Cropping is the least terrible option in my opinion, but still isn't great - you have to cut off a *lot* of picture to get from 2.35:1 down to 1.33:1 (your iPad's aspect ratio). For reference your MBP if recent is probably 1.6:1 .To be honest, if you can deal with it, I'd leave it be. Beyond the massive amount of work/time it takes (and the fact that by the time you're done it'll probably look bad on everything except an iPad2), cutting out or stretching parts of the picture has never sat well with me to begin with.
Edit: just messed with a 2:35:1 video on my iPad3 and noticed there's a button that resembles a "zoom" function located beside the time slider. That's probably the easiest thing to use - the end result is similar to cropping, but it is quicker and you aren't required to butcher the video itself.
Relying heavily on your excellent guide, I felt for a time like I was getting pretty slick at hitting my file size / quality targets, when ripping my blu-rays. I was happy to get older, grainier movies down around 7 to 10 GB, and newer films around 4 to 6 GB. That is until I acquired an .mp4 of a recent movie, made by the torrent guy / group YIFY. It really blew my wig off - 1h58 runtime, 1.72 GB video stream, at 1080p with practically no loss of quality. The picture might be a bit softer than the original source (pure speculation, I have not seen the original) and the audio is definitely not up to my standards (142 Kbps max. stereo AAC). Some colour accuracy may have been lost. But man... it's still WAY better than I've been able to pull off in Handbrake.
There is some stuff online about the YIFY technique, but nothing terribly detailed or convincing.
Restricting to 1 core improves quality? Really? I'm skeptical...
Anyway - Any opinions on how YIFY does their thing?
Cheers
cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1862 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Note that this was only 1 encode that I came across (from 2012 though), and are just the settings somebody posted on TPB (probably pulled via MediaInfo or another similar program). It's very possible that their encodes all vary - usually release groups have multiple contributors and submissions are based on minimum guidelines & "scene rules".
As to the single-core bit, I'd be highly skeptical too. You'd have to ask on the doom9.org forums to be sure, but as far as I'm aware, the quality impact of multiple threads is extremely marginal unless you have a *lot* of threads being utilized (which only happens by default if you have a lot of cores). According to the x264 wiki, above 16 threads, which from what I understand wouldn't happen unless you had greater than an 11-core system. And even then I doubt the effect would be noticeable. Actually in the YIFY encode I'd pulled up, from the settings posted it looked like they ran 3 threads, so they were presumably using a dual-core machine.
All that said, from what I recall, YIFY's encodes (as well as most groups) tend to be a little softer - probably just a result of x264 dropping detail as you get to low bitrates, but it's always possible they preprocess their stuff, running it through a de-noiser or something beforehand to help keep things looking good at a low bitrate. You could try simply encoding your source at a similar bitrate to the one you found and see how it looks - if it doesn't look similar start tweaking some options. If you end up using identical settings to the ones they've used and are seeing different results, chances are that they're doing some preprocessing (or fudging the encoder values stored in the metadata though from what I gather that's usually frowned upon in the community).
1. my tute's based on getting the max outta everythin, ander summthymes, 2kb lessis 2kb les
2. eyeffa updated the postal clear the confucius, now anna mate it clear dat 4 single thread encodes speedier than a single 4 threaded encode, so y u low cumme sum slackware?
3. (tired of talking in slang, so) apparently the YIFY group uses a unified setting that is updated centrally, but the thing that bugs me is that sometimes they seem to do RF based encodes while other times they do bitrate based encodes (such as their 720p encode of TPBAFK is 699mb), and bitrate based encodes piss me off.
4. Since I'm not affiliated with nor endorsed by YIFY, I'll just assume they use magic to make videos bitrate friendly so that they could offer low bitrate videos without losing compatibility with certain devices.
5. obviously i don't have real insight on how x264 works other than "it turn my dvd into a pretty little 300mb file", but i'd imagine there's that setting that puts a multicore CPU to 100% full load which results in quality reduction
6. not related but Youtube's 1080p SUCKS! i dunno about you but i think the guy with the high performance PC should be able to get better quality than the guy with the tablet, i hate CUDA encodings dammit!
1) A single-threaded run might very well shave off a few KB (or add a few KB worth of quality) - only way to know for sure would be to pop the question to one of the x264 devs or do some SSIM/PSNR testing at threads=1 and compare to the default on a multi-core system. I'm personally skeptical because if there was really something tangible to be had by limiting the threads I would have expected them to throw that in the --placebo preset. But either way, using 1 thread/core certainly can't *hurt* quality.
2) Fair point. Actually if doing this with a batch encode and multiple instances, I'd be very inclined to try threads=1 here simply because there shouldn't be any downside anymore (and even if you only end up saving a couple KB, you didn't lose anything to get it).
3) The attachment to bitrate-based encodes to hit certain file sizes is understandable. For a very long time, XviD at 350/700MB was standard (with large movie being broken up into multiple 700mb files) and a lot of people built their storage and set-ups around that. When release groups started transitioning from XviD -> x264 it didn't go over well with everyone and I expect the other remnants like target filesizes to be around for a while yet. Release groups can transition quickly, but their... uhh.... "customers".... aren't always ready for the latest tech.
4) Don't know if I'd go so far as to say "magic" ;) . Peeking on your write-up it looks like debblocking is set to 6,6 which is actually quite soft. You can get away with a much lower bitrate using something like that as opposed to say -1,-1 because any artifacts and/or macroblocking will be nicely smoothed out.
5) Haven't checked, but I wouldn't be surprised if some of the faster presets do. Then again, from my experience, using another H264 encoder (not x264) tends to peg CPU usage and ends up with worse quality than x264 more often than not, so technically that might count ;)
6) I agree - YouTube's encodings are pretty poor quality in general. That said, according to their stats they have 72 hours of video uploaded per minute. Which is over 1 hour per second. And let's face it, you need pretty beefy hardware to transcode over an hour of video per second even at a low resolution. For 1080p, they're also transcoding to numerous lower resolutions at the same time. Their options are going to be either to have huge file sizes (that most "high speed" connections won't handle in realtime), or to drop the quality to keep the bandwidth reasonable. Trying to drastically reduce size while maintaining quality just requires too much compute power. I doubt phones/tablets are the issue here - most of the current stuff has hardware H264 decode built in that they could (and probably do) make use of which handily outperforms the decoding power of a lot of 2-3 year old PC's. The only issue you run into with current smartphones/tablets tends to be when you get move past H264 Level 4.1 - most won't do 60fps at 1080p for instance which might be why YouTube hasn't adopted that yet. But that's a whole other discussion.
2) Seems like I learn something new every day. First thing I'm gonna try the next time I transcode something, is to add thread=1 to the command line (look at me here, surprising people by the amount of stuff i don't know). i'm tired of x264 immobilizing my computer every-time I run handbrake.
3) Here's another possibility (based on a totally unprofessional guess)-in an YIFY encode, sometimes artifacts are obvious while other times artifacts are less visible. I think YIFY could be doing bitrate based encodes on purpose and with a crappier method of determining the distribution of bits so that not only do they save time on encoding, but the slightly uneven quality distribution would mean that while some parts of the video would look crappy, other parts of the video would look really nice, and those are the segments that net them that V10
4) "Magic" obviously means an external software that optimizes a video for encoding by making is bitrate friendly.
as for deblocking=6,6 I've experimented with this a little more, and found that while external filters (such as handbrake's built in filter) soften up your video to a really noticeable extent, deblock=6,6 does not soften up a video that much. Instead it really just improves visual quality without jeopardizing detail, and also helps greatly when viewing a low res video at higher resolutions.
5) brings back some memories- the first h264 transcoding i ever did was on a software called "ultra video converter", took me two days to "convert" a yify-like 720p encoding of South Park BLU into mkv format on a coppermine based celeron 733. Other than that the only other h264 software i've used is format factory, which uses x264 (I think). I've also exported a video project via quicktime h264, but that was just meh. So no I actually don't have any experience with h264 encoders other than x264, and therefore can't really comment on that
6) while encoding speed is definitely a reason, you don't have to drop too much quality to keep bandwidth reasonable. I tried using a normal preset (ref=1:weightp=1:subq=2:rc-lookahead=10:trellis=0:8x8dct=0) in handbrake to transcode an 11GB brrip of total recall 130min 1080p (2012) to RF23, and the resulting file size was less than 2.5GB and the quality was quite good and the transcoding time took 1 hour on my ULV processor. the quality of youtube's 1080p CUDA encoding @ 3000kbps is just unacceptable for videos with motion, and i often find that the 480p versions are much more watchable provided there is no intense detail in the video.
The option also definitely worked, because before my (Win 7 64 showing) 8 cores were all fully occpied resulting in a 96 to 99% total CPU load. With the option added the total CPU-load was only jumping between 20 and 30%.
The file was a 30 second preview of a DVD series. Using denoise=ultra light and RF 20 with x264 preset very slow, the file size without thread limitation was 4.028.992 bytes and with threads=1 was 4.022.272 Bytes.
Despite the smaller result, I won’t limit the threads to 1 in the future though, because the resulting improvement of 0.1% doesn’t justify increasing the rendering time by factor 4 to 5.
http://mewiki.project357.com/wiki/X264_Settings
threads
Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)
Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16). The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases.
x264 currently has an internal limit on the number of threads set at 128, realistically you should never set it this high.
Thanks for explaining some of the behind-the-scenes voodoo.
I do have a couple of questions though -
Could you explain some of the denoise settings that you mentioned in earlier posts? If there is anything that bugs me is to have a transcode that suddenly turns to garbage when there is a cut to a dark scene....
I also read somewhere (don't remember where, could have been the HB forums) where it was indicated that the order in which settings were entered in the x264 encoder options box. Is there any merit to that?
Thanks!
Sorry for the post. I found the "denoise" discussion. That is what I get for just staying in handbrake discussion.
The quest
It's an app for Xbox 360 and Windows 8... Dunno about Windows Phone, though.
Looking at file properties in my downloaded collection, I see that the visible standards for h264 scene releases, after the switch from XviD and AVI, gradually settled on 720x404 for (non 720p) HDTV rips with a frame rate of 23.97 and total data rates of only 1000 or so. As a result, I have been saving TV recordings using 720x404 at 23.97 fps (variable), 1000kbps dual pass, AAC (faac) audio at 48 hz and 128 kbps, and then all the Handbrake default settings on the advanced tab. Using these settings, I'm able to convert a trimmed (advertisement free) 42 minute TV show from 4.5 gb to around 330 mb in about 15-20 minutes, assuming my computer is doing nothing else (Intel Core I-7, 16 gb RAM, Win 7, 64-bit, Intel SSD). I'm generally happy with the results, and they compare in quality fairly well with scene releases, but thanks to this guide, I hope to be improving them soon! So far, I have experimented by changing only the advanced settings to the values recommended above. Sadly, the quality improvements in a recorded re-broadcast of an old episode of Matlock did not justify the near quadrupling of the encoding time. Any advice would be appreciated!
I have been working the under the assumption that the 23.97 frame rate was a critical part of achieving decent quality at lower file sizes, since 23 fps would seem to require a lot less data than 30 fps, which, I think, is what most of my TV recordings start off as.(I opened a recording of a recent episode of "Touch" that I was having difficulty with and the information tool I was using reported that the WTV file was 60 FPS! I don't know much about this stuff, but that seemed unlikely to me!) Anyway, after reading this I am questioning my settings because Matt seems to be a great fan of using the original frame rate. Could anyone comment on the difference between frame rates as it relates to the quality/size calculus? As far as I know, the human eye should not be able to tell the difference, but I've never really looked into it, so most likely, I'm wrong!!!
Anyway, thanks for this great guide, and I'm sure I will return to it often as I try to improve my encodes.
However, it sounds like you've been content with the quality you were getting before. If that's the case, you may want to figure out a target encode-time you'd still be happy/content with, and start bumping up the settings until you hit it.
On the framerates, I'll take a wild stab at it and guess that the 60fps you saw was from a 1080/60i broadcast (common for OTA broadcast in the US/Canada anyway - not sure about the rest of the world). Often for old TV shows, it's 30fps content that's simply interlaced to get the 60i. For movies broadcast at 1080/60i (usually 24fps by default), it tends to be telecined to 30fps and then interlaced to 60i.
In any case, I'm certainly a fan of sticking with the original framerate (after it's been de-interlaced and de-telecined by Handbrake). For a TV recording it *should* usually come out to either 30fps or 24fps in the end assuming all went as expected. I don't like changing the frame rate for a couple reasons... First, I don't remember how HB/x264 goes about it, but it's got to be either dropping or blending frames (probably the former). The effect of this can range from screen stutter during pans to worsened high-motion scenes to... well, a number of things. Some content can get away with it pretty well, but other content can suffer.
Second, because of the way x264 works, it won't necessarily equate to the size reduction you might expect. For example, when dropping something from 30fps to 24fps you might expect a file that's 80% the size. But in reality x264 does a great job of re-using frame data (that's what all those B-frames and reference frames are for!) and you're unlikely to see things pan out that well. You could of course test this to see how much of a size reduction you get - I could of course be wrong, but I suspect the size reduction won't be that substantial.
many thanks for the great guide
That said, the nightlies may have changed somewhat - I haven't grabbed one in ages, and thus can't say for sure one way or the other. If all the options in the GUI still "match up" to what I'd written, it's probably safe to assume there haven't been any significant changes. IIRC much of the development towards nightlies last time I took a peek appeared to be geared towards the inclusion of OpenCL (or was it Intel's QuickSync....? my memory is failing me) which shouldn't make anything here obsolete, but might add a few additional options in the GUI that you'd want to look into if that were the case.
thank you so much.. :)
Differently from most of others settings, when increasing the number of B-frames and GOP sizes, (b+p frames), despite increasing codec efficiency, you actually lose a very little tiny bit of fine detail. B and P frames cumulates rounded lossy compression motion information, thus, lose original fine picture information, the more you have of then, and the larger the GOP, the more fine information will be cumulative lost. This is specially true on noisy/grainny sources like a DSLR high-iso footage. They do however increase overall compression efficiency, and thus, on a restriced file size, overall quality. However, on a constant quality setting on a cenario where overall quality is more important than compression efficiency, one should consider the possibility of using a small number of b frames or even none at all, in the expense of (much) larger file sizes. This is a scenario common with low budget and semi-amaterus videographers (like me) preparing "masters" files to be edited. The Panasonic GH2 Camera is well know for it's hacked firmware where users can fine tune the codec settings for producing the best quality possible files encoded internally. Most of the firmwares that seeks this best quality in the restrained bitrates a SD card can handle, usually implements the lowest GOP sizes as possible (like 2 or 4 b/p frames for every i frame).
Still there is one question left: HB can use Profiles h.264 mainline + high or the advanced tab. Is there a way to encode in 10 bit (high 10), instead of high without losing the advanced tab? Maybe a console parameter?
To my knowledge, Handbrake doesn't yet support 10-bit. Been a while since I've looked into things, but last I recall, it's an entirely different x264 binary (which works for other x264 front ends that simply call x264's CLI and can swap between binaries, but isn't as easy to implement in Handbrake because it uses libx264). I doubt it's on the priority list for the HB devs to implement since 10-bit H.264 decoding support is virtually non-existant in standalone hardware/devices, and devices probably won't support 10-bit until hardware H265 (HEVC) decoding becomes mainstream.
Someone can correct me if I'm wrong, but I suspect you'll have to use another front end that'll funnel your source directly through the 10-bit x264 binary.
I already see the difference between one sourcefile on 720p and 8/10 bit. Like 350MB for 8bit and 294MB for 10 bit - same or even slightly better quality. The funny thing is, that my good old Samsung Galaxy S2 can playback it just fine, as can all android devices which have a decent speed. I used that file on my TV and it did play it back as well, maybe a fallback mode of some kind? I tried to follow that up and ended with the theory, that the encoder picks up the usually 8bit source, encodes it with 10bit precision, then leaves the output in 8bit. If I'm correct, that would mean, that the only limiting factor for the playback is the speed of the device, and maybe some fancy options, like styled subs have to be tweaked or at least considered.
I know that I can use the x264.exe in the console or for example megui to encode in 10 bit, if I change the binary, but that one is even more complicated then a console version. That said, I will not waste hours trying to figure it out when handbrake does a decent job. In my humble opinion, handbrake is the most advanced of the truely free encoders out there. Others like to limit your options or even worse: change your file with ads to be displayed in the encoded video stream.
Great article but I'm looking at this from sort of the opposite direction ie maximum file and as near to the original as possible. Any suggested set ups for this please?
Thanks!
If the file size doesn't matter at all, things become quite simple:
- If you're using "Constant Quality", push the RF slider to the right (smaller number).
- If you're using "Average Bitrate", increase the bitrate.
...actually if you push the RF slider all the way up to "0", the new video will be identical to your source video (unless you turned on denoising, changed the resolution, etc), although the file size will be insanely large - much bigger than your original source was, usually.On the other hand, if you want the file size to be reasonably sane, RF:10 will usually give something in the ballpark of your original source size, and unless you carefully spend a few minutes examining both videos side-by-side when paused, you probably won't see much of a difference.
When pushing the RF value near these levels, most of the advanced options won't matter much if you're truly not caring about the filesize. You may want to set the deblocking flag to -1/-1 (film/3D) or -2/-2 (grainy film) to make sure things stay sharp on playback.
In the event that you decide that size matters at least a little... an RF value in the RF18-RF10 range is probably going to get you something looking quite close to the original anyway. Select "No DCT Decimation" just to make sure blocks aren't dropped. Manually typing in "no-dct-decimate" (no quotes) is probably worth doing too, as it shouldn't have a speed-downside attached at the high bitrates these RF values tend to be at.
1) Rule out the player: Play the video in a different player (VLC) to see if it still occurs.
2) Rule out the source: Try encoding a completely different video (download an mp4 from https://sample-videos.com/ and encode it)
3) Rule out the Handbrake version: Try a different version of Handbrake.
4) Rule out the settings: Do a test encode using a very easy preset (a low resolution device at 30fps frame rate for example).
5) Rule out the machine: Try encoding the same video on another computer, using the same player, Handbrake version, and settings.
I suspect one of those will result in a working video, and will help give an indication where the issue was.