I am a big fan of HandBrake and have ripped over 500 DVD’s with it onto external hard drives. Not surprisingly I haven’t used it for a while!! That said, I need to rip a few in the next week or so was interested to read about 0.9.4
“Creation comes out of imperfection.”
A large portion of these speed, size, and quality improvements come to us for free, from the x264 project. The past year, like every year, has seen some massive improvements for that video encoding engine. As always, it has been further hand-optimized for better performance. But it has also gained new features like macroblock tree rate control and weighted P-Frame prediction. The end result? Better picture quality, at a smaller size, faster.
So, if x264 alone gives us smaller, better, faster encodes…what have HandBrake’s developers been doing over the past year?
Oh, all sorts of things 🙂
New build system
HandBrake has a new, much improved compilation system, which allows easy 64-bit and parallel builds, as well as providing easy extendability for future improvements to the application. 64-bit builds tend to perform approximately 10% better than their 32-bit brethren. There is no Snow Leopard magic here: the performance gains can also be realized on Intel Macs running 10.5, as well as Linux systems.
HandBrake can now include subtitle tracks that can be turned on and off, instead of rendering them onto the video track permanently (which also reduces video compression). This means you can include Closed Captioning data from DVDs and TV broadcasts, or find SRT text subtitle files on the ‘net and include them. When using the Matroska container, you can also store the graphical subtitle images (VobSubs) from a DVD as a separate track. An added benefit is that multiple subtitle tracks can be included in the same output video.
Ever wished you could test HandBrake settings before spending hours on a full encode? Now, you can.
The picture settings and preview sheet has been broken out into a filters and picture settings inspector, and a preview window. The preview window can show you still frames from your source, like always. But it also lets you start to encode a short clip from the current preview with the currently selected settings, and view the results right there inside of HandBrake.
Better input support, for DVD and non-DVD sources alike
HandBrake now uses a better DVD reading library called libdvdnav. This means it can now read some DVDs it had trouble with before, and it can also select different angles on a DVD. As well, some bugs in underlying libraries have been patched.
For non-DVD sources, HandBrake now offers improved transport stream support, especially for high definition sources. A number of decoding bugs have been resolved as well, so Windows users will no longer need fear AAC audio, nor Mac users fear VC-1 video.
Constant quality encoding
No more looking for the perfect bitrate for a source–HandBrake is migrating to quality-based encoding. This means that instead of telling encoders to use a specific size and vary quality to meet it, we tell the encoder to vary size to meet a given quality level. Overall quality improves, since bits are spent only when they are needed, and are saved when they are not. While this means output size is somewhat unpredictable, the results in picture quality speak for themselves.
As part of this change, the quality slider has been made more prominent, and now works off the quality values used by the video encoders, instead of a confusing, custom, percentage scale.
Another result is that 2-pass encoding is not needed. A single pass at a constant quality provides just as much compression efficiency as two passes at an average bitrate.
There are no more presets for the PSP, PS3, or Xbox 360. Quite frankly, they didn’t work well. None of the development team members own the devices, so testing was minimal and support was nonexistent. Keeping up with the firmware vagaries and ambiguous specifications of these devices was not fun–we get enough of that from Apple’s kit, and those we all have around to test on. The new “Normal” preset should work perfectly fine on any device that supports standard Main Profile H.264 with AAC-LC audio in an MP4 file, which the PS3 and 360 ostensibly do.
There are no more Film, Animation, or Television presets. Instead of a confusing series of content-targeted presets, there is now a single, constant quality, High Profile preset with automated filtering and all the H.264 bells and whistles. This preset should work on the PS3 and 360 too, although we make no promises.
It is now possible to import individual presets in all the graphical interfaces, and to export them as well, in the Mac and Linux GUIs.
Focus on what we do best
As we’ve had on our roadmap for quite awhile now, one of our goals for version 0.9.4 was to refocus on HandBrake’s key strengths and to remove dead weight. As part of this process, several containers and a codec have been removed from HandBrake.
AVI: AVI is a rough beast. It is obsolete. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. Furthermore, HandBrake’s AVI muxer is vanilla AVI 1.0 that doesn’t even support large files. The code has not been actively maintained since 2005. Keeping it in the library while implementing new features means a very convoluted data pipeline, full of conditionals that make the code more difficult to read and maintain, and make output harder to predict. As such, it is now gone. It is not coming back, and good riddance.
OGG/OGM: HandBrake’s OGM muxer is just as out of date. It hasn’t been actively maintained in years either, and it too lacks support for HandBrake’s best features. It requires conditionals to work around missing functionality too…only this one gets tested so infrequently the conditionals were never even put in the code, so it just fails when you try to do anything advanced. This one is not coming back either. And yes, we’re aware of HTML 5. For patent-free muxing, HandBrake still has Matroska, which is a much better container anyway.
XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. This makes it rather…superfluous to include two different encoders for an older codec, MPEG-4 Part 2. When choosing between FFmpeg’s and XviD’s, it came down to a matter of necessity. We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. Meanwhile, XviD’s build system causes grief (it’s the most common support query we get about compiling, after x264’s requirement of yasm). Since we mainly use MPEG-4 Part 2 for testing/debugging, and recommend only H.264 for high quality encodes, Xvid’s undisputed quality edge over FFmpeg’s encoder is inconsequential, while FFmpeg’s speed edge over XviD is important to us.
But wait, there’s more!
Audio-video synchronization has been further improved.
HandBrake can now pass-through DTS audio from a source when encoding to the Matroska container, just like it has previously for AC3 audio.
Mac users can now encode AAC audio using OS X’s Core Audio, rather than using the open source libfaac. Core Audio offers far superior audio quality.
A new custom anamorphic mode allows precise control of all parameters, for power users.
Decomb now offers an optional, slower, better quality deinterlacing method called EEDI2.
Library updates for (besides x264) FFmpeg, libtheora (1.1), libmp4v2, libfaac/faad, libvorbis, and libmkv.
Of course, there have also been countless improvements to the user interfaces, and many technical changes under the hood to improve things like sample interleaving and framerate shaping.