HandBrake: Best Practices for Encoding to h.264

I have used the 'Film' preset with very good results. That preset transcodes into H.264 inside an MKV. Quality is (at least on my equipment) visibly the same as the original.

You really need to experiment because encoding results are pretty subjective. There are a lot of settings and your head can spin looking at all of them. I decided that a "Constant Quality" (not a variable bitrate) worked best for me. I played with different levels and settled on "RF: 16 (69%)". To be honest not really sure what it means.

I also use "Fast" deinterlacing on 1080i rips. I left all the H.264 settings to the defaults. They have a wiki page that describes some of those parameters here.

There is a sticky thread at the handbrake forums where people post their settings, and more importantly why they chose those settings (quality, disk space, etc). Have a look there.

I've done a good deal of research and arrived at what I am satisfied with.
Video: Framerate=same, 2 pass turbo, Bitrate 2000 for SD and 6000 for HD.
H.264: ref=6:trellis=2:analyse=all:no-fast-pskip=1:no-dct-decimate=1:me=umh:merange=64:filter=-2,-1:direct=auto

Save it as your own profile on the right.

1. See above. Start with the "Film" preset, experiment and save your preset when you find something that you're happy with. There's a good overview of some x264 settings in the mencoder manual and this wiki describes all of the settings available.
2. Yes.
3. Not sure what you mean. If you mean editing the video, then yes you will have to use another program. A good comparison of video editing software is here.

I hope drkdiggler doesn't mind if I add my similar question to this thread while we are talking about Handbrake encoding parameters.

Does anyone have any recommendations with regards to best Handbrake settings when trying to transcode 1080p Bluray backups to something that doesn't require so much disk space without visibly losing picture quality?

Actually I didn't realize they came out with a new release this week until this thread made me go to their web site. In their notes about this release:


This is the setting I was referring to above - I use a constant quality of 16(RF). I re-encode bluray rips when the video is in vc1 because my installed ffmpeg/mplayer with LinHES does not play them with the ffvc1vdpau decoder. Plus I re-encode because it's a Microsoft format

I'm doing an encode now - I will report later in the day the resulting file sizes. I still say video quality is so subjective - to me these re-encodes look great - but to someone else they may say it is not great. At least you will get an idea on the file size difference.

I decided to give handbrake a try. The only system that can handle encoding has Mythbuntu 8.10 on it, and I couldn't find a version that would install. After some searching and installing special packages, I got the latest version to install.

I am trying it with one of my MythTV recordings. My first try resulted in an unplayable file, so I used quatumstate's settings. The encoding says that it will take +17 hours! Is this normal?

That depends, what input file are you using (mpeg2, vc1, h.264, 480i/p, 576i/p, 720p, 1080i/p) and what cpu do you have this running on?

I only use Handbrake to transcode DVD to mkv. Usually 8-9 hours on a 3GHz dual-core. (E8400)

Mythbuntu is a non-starter, AFAIC. Yeah it's easy, but I suggest a real distro.

It's an Asus Pundit, with an AMD Athlon 64 X2 Dual Core Processor 4600+. If I recall, it is 2.4GHz x2.

The input file is a MythTV recording, so it is a standard HDTV recording. This one looks like a 720p recording, that is an hour in length.

I did notice that I didn't have a "Film" preset, so maybe that is something that got missed when I compiled it. I had to compile the GUI seperately, so I'll look at the other folders to see what else is there.

Quantumstate: Mythbuntu is just Ubuntu with MythTV added in. It uses the horrible XFCE desktop, but that is easily fixed. I know that for some reason you don't like Ubuntu. But it is a fully funtioning derivative of Debian, in fact I like it better than Debian.

Transcoding a DVD (movie chapter only) to MKV took about 8 hours on my 3.2GHz P4HT. I'm about to upgrade my HTPC (finally) to a Core i5 so we'll see what that can do.

OK, so maybe my encoding time isn't that far off. It seems that using ffmpeg may be quicker, though I haven't tried to do a h.264 encode with it. I did compile that (on an ION PC), so it includes h.264 support (I think).

Those times seem reasonable to me. I don't encode with handbrake on my HTPCs as they are busy enough. I use my desktop which is a quad-core beast.

In round numbers DVDs usually take 2x realtime (2hr movie = 4 hrs encode). I use handbrake to encode our home movies from my Sony HD camcorder (1440x1080i recordings) which are probably 3x or 4x realtime. The files tend to actually be a bit bigger but I do deinterlace them.

As I mentioned above I was doing an encode of a vc1 bluray rip - unfortunately handbrake core dumped so I cannot report on disk size and encode time. That has happened 1 or 2 times the last year.

Well, I've had some pretty interesting results ripping a 2.5 hr blu-ray and squeezing it all the way down to 1.5 GB. It took my dual-core 2.4 GHz around 24 hrs for a 2-pass run with video VBR ~1200 Kbps and scaled to 720p. Don't hate me because I did it in windows -- my drive space is limited ATM, and that's where I ripped it. The x264 settings are listed in the attached mediainfo file, and a 150 MB sample clip is here --> http://www.filedropper.com/test1_4. It's in an MP4 container with 6-channel AAC audio because I was testing streaming to a flash player, also (which works beautifully, btw).

Oh, and yes the "film" preset has been removed from Handbrake, so use "High Profile".

 

mediainfo.txt 3.1884765625k . file

mythmaster, thanks for sharing, I checked out the test clip and I must say the picture quality is stunning, especially considering how compressed the clip is.
I have spotted only once in it some slight compression artifacts and I was specifically looking for them.

You say you used Windows, but what software, it doesn't appear to be Handbrake?

I used HDConvertToX (freeware) from doom9 forum which isn't loading right now for some reason. Here's an alt link which also has a link to the doom9 thread which should eventually be back up (labeled "Download (author site)"): http://www.videohelp.com/tools/HDConvertToX

There's a nice guide here: http://www.adubvideo.net/how-to/how-...h-hdconverttox

It's dependent on other software such as avisynth, etc. (the OP in the author's thread has links to everything), but I think that the only thing stopping it from working in wine is the audio decoder that it uses. It should work just fine in a vm, though.

It's an excellent tool for converting/compressing a vc-1 or h.264 m2ts and putting it in an mkv. Then you can use BDInfo (without scanning for bitrates) to get the playlist information and add it into the mkv. I've done a few of those and just copied the ac3 or dts-core over without issue.

I had some problems with this one though: after the encoding was finished it didn't mux the mp4, and the AAC channels weren't correct. The *.h264 file was spot-on, though. So I had to pull out the ac3 audio with tsMuxeR, convert it to 6-channel AAC with the Nero codec in BeHappy, and then mux the mp4 with MP4Box.

Most people will never run into this issue, though, and it could have easily been "operator error". Like I said, I needed it to be h.264+AAC in an mp4 in order to test streaming to the flash player (JW Player).

It's not that I don't like Ubuntu. Were it not for Debian, that would be my second choice. But it tries to do too much and its stability record is quite spotty (like 50% of releases), so not much respect.

This is off topic, but maybe you would like Hannah Montana Linux better.
aka:Hannabuntu

http://hannahmontana.sourceforge.net/Site/Home.html

For the noobs reading, please be aware that Canonical (distributor of Ubuntu) has always said that non-LTS releases contain software that may be unstable in order to introduce new software or new features as soon as possible in their release schedule. They are supposed to be cutting edge and therefore may be unstable or buggy. I don't know how many other major distros stick with a rigid 6 month major release schedule, rather than yearly or so.

I guess what I'm saying is, when evaluating a timed-release distro like Ubuntu (vs a rolling release distro like Arch), it's probably more fair to separate out the LTS releases vs the interim releases when evaluating stability/bug issues.

I think Ubuntu's track record with LTS releases has been better than 50% "success", though there are fewer LTS releases vs non-LTS by definition, of course.

Moral of the story- go from LTS to LTS release with Ubuntu, or wait several months after an interim release (9.04, 9.10) has been on the streets so that patches from Canonical and workarounds in the online community can catch up. I don't think most people need to update every 6 months- once a year or more is probably sufficient.

My 3GHz C2D will transcode a DVD to h.264 in just about real time. I use single-pass CRF at 65%, and I can't tell the difference from the original. Most movies end up between 1.5GB and 2.5GB.

Not many people bother transcoding Blu-ray unless you're also lowering the resolution at the same time. The space savings without apparant quality loss just isn't worth the time required for the conversion. Blu-rays use VC-1 encoding, which is very efficient to begin with. Recompressing to h.264 doesn't save you much - maybe 5-10GB on a 30GB movie. Lowering the resolution to 720p is a different story. You can easily get the file size down around 5GB while still maintaining a beautiful picture. It takes a while, but it's still worth it for an 80% reduction in file size.

Wow- that sample is quite impressive, and a prime example of what can be done at low bitrates with 720p HD when encoded by a knowledgeable operator

I recall a series of WSR magazine articles around 1998-2000 where Joe Kane advocated an HD disc format that simply used stock red laser DVD9 at 720p. His scheme was similar to how DTS 24/96 is encoded vs the base 20/48 DTS- delta bits are added to the base 20/48 DTS data to add the extra resolution. Joe Kane wanted the 'extra" 720p bits on the second layer, with the base 480i/p bits on the first layer- would cause continuous layer changing of course.

I have long been an advocate for 720p HD over 1080i/p- more space efficient and for most people, 720p is capable of resolving all the detail most people care about- not talking about pixel-count hounds or AV-philes.

...further example of how wasteful 1080p generally is.

Handbrake has a CLI so you should be able to put it in a shell script with whatever settings and add it as a transcode job in MythTV.

Requested this be made sticky due to relevance and interest in h/x264 encoding, and importance of improving video tools in Linux.

Figured this was the best thread for this.

So i tried my first transcode with the new version of handbrake. Went very nicely. Only took about 50 minutes on my Core i5 using the "High profile" preset. I did change the .mp4 container to the .MKV container and set the audio to AC3 passthrough. I left the quality slider at 20 where it was preset and left everything else alone. The picture turned out really nice! Looks exactly the same on my (SD) 42" CRT RPTV.

Something odd though: I don't have AC3 audio. It's stereo. I used XBMC to play the Video_TS rip of the DVD and I get digital 5.1. When I play the .MKV transcode, I only get stereo audio. I transcoded the movie twice and doubled checked the audio setting (AC3 Passthrough 5.1) to be sure but no dice.

How come I'm not getting 5.1 audio?

^^^ What does it say in the Audio/Video tab for the properties of the encoded file.

That should at least tell us if you selected the right audio track when you did the encode.

In Handbrake or using the file browser? I will check when I get home but I remember choosing "AC3 5.1 Pass Through" in the audio tab. The only other option there was "Dolby Prologic II" and I know that ain't right.