Encoding our Blu-ray library (Update on Handbrake-cli encoding tests)

  • Posted on: 17 October 2018
  • By: charm
Original on left, encoded file on right side

If you rip Blu-rays using MakeMKV the resulting file size can be huge. File sizes of Blu-ray movies in our collection range from 16GB to over 36GB. This was fine a year ago when we added an 8TB hard drive to our KODI server, but in less than a year we managed to whittle the free space on that drive down to 250GB. Buying more/larger drives is one approach to solving the free space problem, but we've already done this several times, going from a 1TB drive to a 2TB drive, then a 3TB drive, and another 3TB drive, before replacing them all with the 8TB drive. Another approach, the one we ulimately decided would be the right solution for us, was to encode those files - in this case using handbrake-cli, the command-line version of handbrake.

Last Monday we wrote about Handbrake-cli encoding tests using the x265 codec. We learned a few lessons from those experiments:

  • Use the latest version of Handbrake-cli from the web site, it has more presets.
  • The x265 codec takes a really long time to encode big files (approximately 12-13 hours for a 36GB file).
  • The x265 codec produces some extremely small files and looked good with some of the smaller files we tested with, but larger files with a lot of black showed significant artifacts.
  • The x264 codec produced small files and the files looked better using the same 1080p MKV container.
  • It's important to use MKV as a container if you like subtitles. The MP4 container will let you take an .SRT file and hardcode (burn it) into the video, but MKV lets you keep all the subtitles in the container (letting you choose at the time you play the video which language subtitle you want to display).
  • The x264 codec encodes in about half the time it takes x265.

We've been looking at and using Handbrake for awhile and also found some interesting observations about Handbrake:

  • Handbrake is optimized for up to 6 CPU cores with diminishing returns thereafter.
  • Handbrake supports Intel QuickSync meaning that a Haswell or newer Intel processor will generally work a bit faster than a similar AMD one. That said, clock speed helps, as our AMD A8-5600K significantly outperformed the slightly newer Intel i3-4010U, but lagged behind the older i5-2300 (see our Handbrake-cli encoding tests article for more details).
  • There are a zillion switches for handbrake-cli, but you can use presets to simplify a lot and still maintain good quality.

We're still just beginning to encode our Blu-ray files. When MakeMKV rips a Blu-ray it doesn't (as far as we know) do any kind of file compression or encoding, it simply dumps the video into a readable MKV container (file). Multiple languages are spoken in our household, so subtitles with multiple languages are particularly important to us.

Just to be completely clear, we're using handbrake-cli to encode MKV files we've already ripped from a Blu-ray originally using MakeMKV to do the ripping. Handbrake isn't quite there yet for the entire process of ripping a Blu-ray, so for now the steps are:

  1. Rip the Blu-ray with MakeMKV
  2. Encode the resulting file using Handbrake-cli (or the Handbrake GUI if you prefer)

Keeping all these things in mind, here are the 2 lines of code in the bash script we're using to encode our Blu-ray MKV files. We put these lines inside a file and called it hb.sh:

HandBrakeCLI -i "$1" -o "${1%.*}-264.mkv" --preset="H.264 MKV 1080p30" -s "1,2,3,4,5,6,7,8"

The first line simply tells bash it's a bash shell script. The second line is a bit more complicated, but not overly. The first part of the second line runs HandBrakeCLI (the executable name of the handbrake-cli software package). When you run this shell script you'll run it with an argument, that argument is the name of the file you want to encode. So if the file is called Omar.mkv you would type: hb.sh Omar.mkv. The -i "$1" part of the lines above takes that argument (filename) as input. Similarly, the -o part just after is the output. The outputed file name will be the same name as the inputed name, but with -264 added to the end of the filename. The reason for this added -264 addition is both to help denote the codec used, but to prevent .mkv files simply being replaced by themselves and you ending up with a small file containing nothing. The --preset switch lets you use one of the presets in Handbrake. If you've used the graphical version of Handbrake these are the settings along the right hand side of the user interface, presets like Apple iPod, Normal, etc. We liked the quality of the H.264 MKV 1080p30 preset. It was the perfect blend of quality and speed for us. (That said, none of our TVs are 4k, we're still 1080p). The last switch -s "1,2,3,4,5,6,7,8" captures the first 8 subtitles and embedds them in the container (MKV file). It doesn't burn them into the screen, so if you're watching on something like KODI you'll have to actually activate the subtitle you want. If the Blu-ray didn't originally have 8 subtitles Handbrake-cli will just add the titles it has (for example: 4 subtitles).

We put our hb.sh shell script in a subdirectory called scripts and then added that path to our .bashrc:

echo "PATH=$PATH:/home/charm/scripts" >> .bashrc

You would substitute /home/charm/scripts for the directory you put the hb.sh script. Also don't forget to add execute permission to your hb.sh shell script before running it:

chmod ugo+x hb.sh

If you find better/faster settings that include subtitles please drop us an email or hit us up on one of the social networking sites above and let us know. Incidentally the image at the top of this article compares the original image on the left and the x264 file on the right. Keep in mind this JPEG image has been compressed, so the actual quality is much better, but for the purposes of this article it provides a picture of how close the resulting file is to the original.