HandBrake

Discuss the 0.10.5 release here.

Release Announcement

What happened to 0.10.4

Skipped it. We decided to include an extra patch and the x265 update after we'd initially tagged.

Does this only effect Android profiles then?

It affects all of the device presets on windows and linux. osx is unaffected because it has always used coreaudio for aac encoding.

Just to be clear. The LibAV AAC encoder is still present although sadly it does not support HE-AAC. (This affects windows and linux). Mac has Core Audio which is default anyway so is unaffected by this change.

Is there a way to plug fdk-aac library into the new binary?
Is there a replacement on the way that will hold its own against fdk?

musicvid wrote:Is there a way to plug fdk-aac library into the new binary?

No, compile from source with --enable-fdk.

musicvid wrote:Is there a replacement on the way that will hold its own against fdk?

Lack of options with faac already out due to licensing. Perhaps ffmpeg if they swap out libav for ffmpeg entirely, or porting the recent ffmpeg aac improvements to libav.

Basically, if you're not on a Mac you're going to have a [Censored] time.

I guess I'll stick with .10.3 for now.
I used Handbrake only for Youtube until fdk was added.
Now that I can use it for delivering my musical shows, I'm not keen on stepping backward.
Really, there are only a handful of decent AAC encoders in the wild, licensing constraints notwithstanding.
Very little development going on, unfortunately. Fraunhoffer was an exception to general mediocrity.

The compilation guide (https://trac.handbrake.fr/wiki/CompileOnWindows) says to build libhb (on Linux) and the GUI (on Windows) separately.

I take it that the FDK AAC library is in libhb, so I will only need to recompile it and copy it to the HandBrake directory?

There could be a time where I need features from 0.10.6 or 0.11.x, and will have to compile the code.

Does this version include the stable version of LibAV AAC?

https://www.ffmpeg.org/index.html#aac_encoder_stable

Not yet, no.

vassie wrote:Does this version include the stable version of LibAV AAC?

https://www.ffmpeg.org/index.html#aac_encoder_stable

LOL, the same page says to use fdk for fewer licensing headaches:

If you are currently using libaacplus, start using FDK AAC (libfdk_aac) with an appropriate profile option to select the exact AAC profile that fits your needs. In both cases, you will enjoy an audible quality improvement and as well as fewer licensing headaches.

nhyone wrote:The compilation guide (https://trac.handbrake.fr/wiki/CompileOnWindows) says to build libhb (on Linux) and the GUI (on Windows) separately.

I take it that the FDK AAC library is in libhb, so I will only need to recompile it and copy it to the HandBrake directory?

Yes, you should need to just replace the "hb.dll" (says it is called libhb.dll on https://trac.handbrake.fr/wiki/CompileOnWindows but I can't find a libhb.dll anywhere) once you have made your changes and compiled it, but I don't know how to compile it in windows. I guess a VM is your best bet unless someone can find a guide or makes one.
If you get to that step you'll need to know what to change: https://trac.handbrake.fr/changeset/6da ... 1ee1214bbf

Unfortunately due to circumstances beyond our control we can no longer include binary distributions of HandBrake which include the FDK-AAC encoder.

I fully understand the reasons behind this decision, but, I imagine like most other Windows users, am none too happy to hear about it.

I registered here just to ask this question, which might be ignorant and stupid, but here goes.

Is it possible for Handbrake to hand-off high-quality AAC encoding to a separately-installed, proven-quality 3rd party application? I'm thinking of the various Apple QuickTime encoders for Windows such as QAAC, or even the newly "stable" native FFmpeg. I'm guessing that this would also require you to separate the video and audio encoding tasks, then apply a final MUX phase at the end.

Ultimately, the main source of concern (and backlash) that you are about to endure is based on the quality of the AAC encoding now presented by your Fraunhofer-less builds. Self-compiling to restore FDK is not a viable option for the AAC-encoding multitudes who have chosen Handbrake as a "simple" solution. I've already seen various "WTF?" threads elsewhere about the evaporation of FDK from Handbrake, so it will only get worse once the auto-updates start biting.

Would high-quality AAC encoding through a 3rd-party child process work, both technically and from a licensing standpoint?

Short answer:
You can encode and remux the audio using third party applications, not included with Handbrake.
MP4B ox and MakeMKV are examples of muxers, although they are different in a lot of respects.
Handbrake does not spawn or invoke "child" processes, except through an umbrella script that you would devise.

One of the good things imo is that HB does not use external applications.

What is described above is pretty much megui.

I find it hilarious that FDK-AAC was removed due licensing issues with the GPL while you need the proprietary Visual Studio Community 2015 to compile it on your own on Windows.

Keep also in mind that to get VSC2015 will eat 6 till 22GB!!! of your SSD. I mean WTF? 6GB for a plain IDE?

Even a full featured Qt develop environment including Qt Creator, MinGW-w64 and MSYS2 targeting both x86_32 and x86_64 take up 10GB when you're not keen on disk space.

Time to give HandBrake a plugin system?

justincase wrote:Time to give HandBrake a plugin system?

It is a common misconception that you can work around gpl license compatibility with plug-ins. Plug-ins have to meet very limited criteria in order to satisfy gpl compatibility. See http://www.gnu.org/licenses/gpl-faq.en. ... AndPlugins

Basically, when there is a license incompatibility, the "plug-in" must be a stand-alone program who's only "api" is to invoke it with a basic set of command-line-like parameters. Any output would have to go to intermediate files that would then have to be read back into the HandBrake main process. It's very hackish and likely to be fragile.

That's even more sad. I thought GPL was about freedom, but it turns out to be PR talk.

justincase wrote:That's even more sad. I thought GPL was about freedom, but it turns out to be PR talk.

It's a distinctive flavour of freedom. Like most socialist concepts, it requires a certain element of force to get everyone to "cooperate". In the case of the gpl, this force is the license limitations. But of coarse, once everyone is "cooperating", then all software is free.

Is there any chance to have FDK-AAC HE in HB WinGUI?
Just to be clear, does "compiling" option work for WinGUI too? or is it just Linux?
I mean if we compile it, can we have fdk-aac?
is there any way at all?

If not, can you guys make another exception for this like what you've done with 10bit encoding dlls too?
We put some dll in HB directory and use HE-AAC right away. not a "plugin system" per se, but just one exception.

If I use makemkv to rip a dvd I own, using fdk-aac for the audio, can I then use the latests Handbrake to transcode (and reduce the file size) as Handbrake would simply be copying the audio?

Message deleted by user.

We put some dll in HB directory and use HE-AAC right away. not a "plugin system" per se, but just one exception.

Not a plugin system? It would be by definition a plugin so we can't link against the library, we can't make an exception. Any expedition and we'd be back to square one and on the receiving end of another complaint.


The x265 dll are not due to a license issue. We can if we decide distribute them with HandBrake although given it's limited use case and somewhat niche use-cases right now, there is not a lot of point.