A Deep Dive into HandBrake and Video Transcoding | Hacker News Reader

A Deep Dive into HandBrake and Video Transcoding

robservatory.com

161 pointstambourine_man59 comments

This isn't really a deep dive into HandBrake or video transcoding, it's more of an examination of presets that wrapper provides.

You'd be better off diving into the foundation of HandBrake and using it directly:

https://trac.ffmpeg.org/wiki

Also, in before, "ffmpeg is too complicated for the average user ..." It isn't, you just need to RTFM.

Ever wondered about the toolset of pirate movie groups?

Typically it involves demuxing the source with eac3to, decoding and indexing the video stream for avisynth (often with ffms2 for Blurays), filtering (such as resizing with a spline kernel, debanding, fixing dirty lines, fixing double range compression, correcting aliasing, removing edge enhancement artifacts, deinterlace/ivtc for DVDs etc.), followed by piping it out through avs2yuv to the x264 encoder. x264 parameters are often hand-tuned over a series of short test encodes at a fixed bitrate. Audio streams are left as is, stripped to the core (DTS-HD MA -> DTS) or transcoded to AC3 (Sony Soundforge), DTS (DTS-HD Master Audio Suite), AAC (qaac/fdkaac) or FLAC. Bitmap subtitles are ripped to text .srt files with subextractor/suprip/SubtitleEdit/ and spell-checked. Finally everything is muxed back together with mkvmerge.

Some of these groups really mess up the sound volume of their releases in the conversion process... you have to set the volume to 150% to get a decent volume level and not all programs allow you to do that (and they probably lost more sound quality then they needed to somewhere in the process).

The encodes are made to replicate the source as faithfully as possible, generally that means not touching the audio and disabling all forms of dynamic gain (which both affects the quality, and reduces the quietness of the quiet moments and reduces the loudness of the loud moments).

I am quite certain that no audio quality is lost, as the explicit goal is to keep the audio at maximum fidelity.

Not sure what setup you are using, but most cinematic players have a way to do auto-dynamic gain. Or, if you do want a more faithful overall experience, all you really need is a better amp.

Probably because in theatre the audio often has a big dynamic range, and the groups are aiming for a "cinematic" result. (There might be only one or two loud points in the film)

I would rather have the various tools, command lines, and settings used than the pirated content. Insert obligatory "why not both?" here but seems like the secret sauce is closely-guarded IP (is this irony?).

It's not really that much about secrecy. Most of the tools are free or open source (with the exception of audio tools which can be for the most part substituted with eac3to).

The problem is that the "body of knowledge" is rather extensive if you want to cover all the corner cases and imaginative ways in which authoring houses screw things up. To be able to filter the video correctly you need to know a bit how the h264 codec works, learn your color formats, color spaces, a little signal processing, a few tables from ITU-R recommendations and some proficiency in RPN wouldn't hurt. As such it is difficult to put it all down in one guide. To make it worse, as with every niche community there are disagreements and transient "fashions". At the end of the day though this is very much chasing rapidly diminishing returns.

Just trying to point out that a great way to learn more would be to review exactly how each release was put together. Even without the "why" this would be a useful learning opportunity.

Very interesting insights, thank you!

The average user knows (barely) how to use a browser and Microsoft Word. ffmpeg absolutely is too complicated for that user.

Your definition of an average user cannot use HandBrake, either.

I haven't looked too deep into Handbrake in a few years (so someone correct me if I am wrong), but I don't think they use ffmpeg. Their core, the codec libraries, is mostly the same as ffmpeg, but ffmpeg is not the "foundation" of Handbrake

They use libx264 for H.264 video encoding (and maybe libx265 for HEVC).

What do you think they use to split the video from the audio in the source file, decode the source video frames, resize and crop every frame, and then mux the resulting new video stream with the (possibly also recompressed) audio stream?

If the task requires anything more complex than simple transcoding or encoding, then ffmpeg will require a user to understand DSP to some extent to be used successfully.

Of course this is no fault of ffmpeg, but a lot of frustrated users end up thinking that anyway.

While true, one should always remember, "If it makes a mistake, it's because I screwed it up."

To be fair using ffmpeg today is a world easier than it was 10 years go when Handbrake first came about.

'RTFM' doesn't help much if it requires a strong background in signal processing to make sense of it ;)

A "strong background in signal processing" is not required to generate the results detailed in this article using ffmpeg.

Nor does this article provide any information enhancing the user's understanding of the encoding options employed by the various presets discussed or the ultimate effects they hold in regard to signal processing.

Some interesting analysis here, but I think you are analysing a video far too heavily in the spatial space i.e at frame level, this doesn't particularly give reliable results as compression and hence artifacts can vary according to frame in time.

Video needs to be analysed ideally in the temporal space (i.e as a sequence). I see no mention of the GOP structure or length of the encoding chosen, which would need to be considered.

For example the one frame you have chosen to compare could be an I frame in some of the video compression or could be a P or B frame which would result in slight variance in quality and artifacts.

Also, reading back, this is a huge huge red flag:

> "I dumped all the images into separate PNG files, and then used sips to convert the PNGs to somewhat-more-reasonably sized JPGs"

You are adding further compression to the PNGs (the frame grabs) by using JPEG (I assume you are using it in lossy mode), which is basically adding another form of compression to your results.

The fact you used JPEGs (further compression) for comparison basically null and voids all the results I am afraid.

That was a huge "WTF" moment, and the point I basically gave up on the article. I was hoping for an interesting deep dive, not a layman fiddling with stuff.

There are much better ways and tools for comparing encoded videos.

Yes, it's too bad that the author lacks basic understanding of signal processing. I respect his effort though, it's not an easy topic - you have to start somewhere.

Not only that, if the color space is different between the original video, the PNG files (RGB), and the final output video, there can be lossy effects from that as well.

When I open Handbrake, it's usually because I have a video that won't play in some device/program. For example, I have an mkv but my Chromecast only supports MP4. I found out recently that Handbrake isn't always the best option.

Oftentimes you want to remux the video, which means copying it to a new container format without touching the underlying stream. Handbrake doesn't support remuxing (no idea why); you have to turn to ffmpeg on the commandline [1]. Remuxing works if the video and audio codecs are supported by your target but the container isn't, and is very fast—about as fast as copying the file.

With remuxing you still have the option of changing the order of the audio tracks. For example, you can take a Cantonese film with a Mandarin dub and make the Mandarin dub primary so you don't have to fiddle with it (protip if you're learning Mandarin: all the good movies are in Cantonese but they all have Mandarin dubs).

[1] There are GUI options that I haven't explored, see below.

Explore MKVMerge in the MKVtoolnix set. It can de-mux and re-mux really well, and has a good GUI.

Thanks for the tip!

I keep a random google doc of some of my magical ffmpeg incantations that have worked in the past. I usually use it for cutting video segments out of longer vids. Seems like different versions have had different ways of handling things, and/or I really don't know what I'm doing!

I would vehemently disagree with "good GUI", although I'm not entirely sure we're talking about the same tool -- mine is called 'MKVToolnix GUI', but I can't find any GUI utility going by the name 'MKVMerge'. Anyway, it is a very useful tool for this, though Avidemux has a similar feature set and in my opinion is easier to use.

I realise you didn't ask, but having tried a bunch of macOS demuxers, I've found MP4tools to be the best fit for me:

http://www.emmgunn.com/mp4tools-home/

Adding to the list: I've been using Subler for many years to mux to MP4 (and to transcode AC3 to AAC if needed), and it hasn't let me down:

https://subler.org/

I have a command line script for doing this exact thing in ffmpeg

for i in *mkv; do ffmpeg -i "$i" -vcodec copy -acodec copy "${i%.mkv}.mp4"; done;

Yup this is my favourite way too. The annoying thing is that the audio and video codecs are supported most likely by the problem device just the container that is not. My Samsung TV (KS8000) supports MKV though which is superb for me.

Avidemux is probably the best tool around for remuxing (between any containers). It can do encodes too, but I've never really played with it.

I've done shedloads (500+ discs) of rips through hand brake, mostly DVDs and some Blu-Rays.

What I discovered was, that unless you are rippling losslessly, your results will vary greatly from film to film.

The advice I give out is:

1. Start with the recommended defaults in Handbrake.

2. Rip a film you know well.

3. View that film on ALL platforms you are likely to view it on. [a]

If you are happy. You are done - keep ripping discs.

If not:

4. Adjust quality up/or down goto #2. Repeat until happy.

Do the above for each GENRE of film - Bright Action movies need different ripping specs compared to period dramas.

[a] I did not do this step originally, and the first batch of rips I did, looked good on my 24" monitor, good on my 50" plasma, and awful on my 9ft projector screen!

This is good advice, but I'd add:

Pay special attention to videos whose source is TV (as opposed to film) because those sources tend to be interlaced, and you need to play around with the detelecine, decomb, and deinterlace settings. Unfortunately AFAIK Handbrake cannot detect this condition, and if you don't manually account for it, you'll get that ugly horizontal "comb" effect on output, during scenes showing motion.

For non-HD sources, I highly recommend MeGUI [1][2] (only on Windows, unfortunately). It's a bit more manual as compared to HandBrake, but they have an interface for AviSynth's interlace detection [3], which works pretty well.

[1] https://sourceforge.net/projects/megui/

[2] https://en.wikibooks.org/wiki/MeGUI/Tools/One_Click_Encoder

[3] http://avisynth.nl/index.php/Interlace_detection

Agreed. I've ripped a lot of old Dr Who, and Decomb has been a lifesaver.

I was using Handbrake to rip the DVDs of a certain low-budget 90's TV show (I am too embarrassed to say which) and noticed that certain special effects could confuse/anger Handbrake. Specifically, some cheap effect used to give a flat image the illusion of depth by making its outline gyrate back and forth combined with a lens flare, the effect was muted/eliminated when Handbrake ripped it, as though Handbrake was trying to stabilize the video or something. The effect was still visible on the raw MKV rip, but not after Handbrake's transcode.

They could have generated the effect at 60i instead of 30fps (* actually 29.97fps). Handbrake won't do interlaced encodes, for good reason, so deinterlace will remove half the motion.

You can switch to "bob" deinterlace if that's an option and it will come out 60fps.

You're confusing ripping with encoding.

Ripping from DVD and Blu-rays is a lossless process involving the removal of DRM.

Encoding is where the space-saving magic happens, and where settings, and more importantly, bitrate, can lead to varying levels of quality.

It may be slightly more accurate to refer to this "space-saving magic" as transcoding rather than just encoding.

DVD/BluRay content is compressed (already encoded).

For most people, 'ripping' infers 'encoding'.

Both of this tools use the same encoders under the hood, what you see here is just comparing different settings in default presets they provide. If you would like to experiment yourself with x264 encoding you can find descriptions of possible options here http://www.chaneru.com/Roku/HLS/X264_Settings.htm

Also this guide looks good for some general advice: https://www.reddit.com/r/trackers/comments/wevh2/good_beginn...

I've used ffmpeg/x264 professionally and personally and I'd not suggest this for the average user. It's a bitch to get all the settings right.

If you're building an automated system to transcode video ffmpeg/x264 is great (or better yet, use an online transcoding service). For an average user go with Handbrake.

I really can't say enough about how great the transcode-video library is in terms of "set it and forget it".

When I cut the cord I started down the path of figuring out how to do all the optimizations myself, but quickly realized just how deep and technical that was. I stumbled upon Don Melton's library and have used it as a key piece of my batch processing pipeline ever since.

Definitely check it out if you are looking to convert arbitrary video files to be played back later on arbitrary devices:

https://github.com/donmelton/video_transcoding

Google Cache since I'm seeing a 500 error page:

http://webcache.googleusercontent.com/search?q=cache:robserv...

It is really confusing and super annoying that the author keeps calls 2 totally different tasks "ripping".

First, the author calls extracting the video/audio of the movie from the Blu Ray (and circumventing the DRM) "ripping". Quote from Article "On the Blu-ray, the music video is 2:18 long. When I ripped it to the hard drive using MakeMKV, the final file size was 279MB."

But then the author also calls encoding the extracted video/audio using HandBrake or transcode-video "ripping". Quotes from the article: "I then fed this .mkv file to both HandBrake and transcode-video, running it through all 26 different conversion options. This table shows the results, sorted by ripping app first..." and "I then copied that same frame from all 26 of the ripped versions of the music video..."

No! No you didn't! You ripped the movie once, and then encoded that 26 times, each time using different options, to compare encode-time, size, and attempted to compare the output quality.

Honestly, confusing these 2 fundamental concepts makes me seriously question your entire experiment.

>Honestly, confusing these 2 fundamental concepts makes me seriously question your entire experiment.

Was it really that hard to see what they were doing?

I thought the analysis was well written, and the screenshots helped show what was going on, terminology problems aside.

No the article isn't hard to understand, but it shows that the author has no clue what is actually happening under the hood. He lacks basic understanding of video encoding. His article is well written and I respect the effort, but you can't learn much from his experiments.

Handbrake settings are hard. A few years ago I did a project that involved finding the appropriate settings to use[1]; it took me several weeks to go through all of the settings, look them up, figure out what they did, and test them to see what the correct value was. Some of the settings are (or were) really poorly documented--for example, why wouldn't you want iPod 5G support? Well, apparently it "breaks compatibility with certain players," though I couldn't find any data on which players would break.

[1]: http://www.linestarve.com/blog/post/rendering-html5-video-wi...

That's because the effects are hard... in general, I find it much easier than trying to fiddle with ffmpeg or similar.

I tend to rip most things with one of two configs I have.. one for br/1080p, another for DVD, and I have a tweaked DVD for bad content (Think Babylon 5)... It took a while to find settings I generally like. I've also taken to letting things run for h.265, since I'm pretty concerned about the space on my nas.

If you aren't trying to match YIFY on your sizes, then you can get away with being a bit more loose on your configs.

I always preferred StaxRip. It ties all the tools together like Handbrake but gave you all the power of the CLI. It looks like the author is trying to completely re-work it in x64 now: https://github.com/stax76/staxrip

The critical problem I see with encoded films is what happens in high-action scenes. Often the detail is "good enough" for me until all of a sudden things start happening and you can really see degradation.

Thus I don't find their method of looking at stills to be all that compelling.

That happens for BD or streaming because complex scenes hit the bitrate-per-second cap (VBV maxrate) and quality has to take a hit to fit all the bits in.

If you're working from a source without problems, and they're ending up in the result, Handbrake might be enforcing max rate to hit the H.264 "level" conformance, so "level 5.0" might help. Don't remember if it's got an option for that.

i'm comfortable using ffmpeg, i just wish people would share their secret formulas that can:

    - take a video of varying format (mov, mp4, webm, mkv)
    - give it the desired output resolution
    - give it the desired output quality preset (simple will do - hi, med, low)
    - output resulting file(s)
    - do it fast

i have a giant shell script of ffmpeg commands i've used in the past, but i have to stop myself from getting sucked in to trying to understand the whole process and losing a whole day at work

I spent a bit of time trying to understand ffmpeg last year (seems like you need to re-learn the codecs and best practices every few years!) and wrote some notes down on a blog post. Hope it helps someone other than me!

https://mjanja.ch/2016/07/video-encoding-for-the-web-in-2016...

In another post, the author mentions a particular Pioneer Blu-ray drive that he uses with his Mac. Are they all pretty much the same, or are some models preferred?

I've just bought random USB drives that don't advertise Mac compatibility at all and never had any issues with ripping nor burning. Brands like Buffalo and Logitec (no H). They're all basically the same ATAPI drives inside a generic USB controller.

Ah I thought this would be more about how it works. Oh well, pretty informative nonetheless.

Reply on news.ycombinator.com