@cnrd Thanks for the patch!

Unfortunately, the version of fdk_aac available in HandBrake 0.10.2, the official release, is much slower than av_aac. And I don't want to introduce a performance regression for Windows and Linux users.

However, the nightly builds of HandBrake do have a faster version of fdk_aac. So, when those nightly builds finally become the official HandBrake release, I'll consider taking your change.

Oh, i hadn't noticed.

I'm using a Core i5 6600k (Skylake) @ 4.4 GHz and I was encoding at about 70-80 FPS, just changed to the latest nightly of HandbrakeCLI and now it is encoding at 200-220 FPS.

So I can see why you did not add the fdk_aac audio encoder!

@cnrd Now I'm curious as to what performance you were getting with the old av_aac codec. :)

BTW, there's a chance the new av_aac encoder, which I believe is really just libav, will be much improved in quality soon, too.

Yeah i found the problem, the nightly version of Handbrake changed the preset to veryfast.

That was why i was seeing such high FPS. :-)

I'm only seeing an improvement of 0-15 FPS when forcing the medium preset (Doing some small edits to transcode-video)

EDIT: I know that this is a bit off topic, but am i right to assume that video FPS is capped at 30 FPS?

I have some stuff recorded from TV at 50 FPS which seems to be converted to 30 FPS unless I use the option "-H -rate=50".

@cnrd The HandBrake team changed the default x264 preset? It's still medium for me with my nightly build.

Yes, the default frame rate is 30 fps. That's intentional because it works for most DVDs and Blu-ray discs.

That is what I'm seeing using: HandBrake 20160105201345-ee1167e-master on Windows 10 with version 0.3.0 of the scripts.

I'm using this line to start the conversion: transcode-video -H rate=50 --preset medium

No modification except fdk_aac patch: http://pastebin.com/Yk1sP4Bb

I then modified transcode-video:
#when 'medium'
# @handbrake_options.delete 'encoder-preset'
when 'ultrafast', 'superfast', 'veryfast', 'faster', 'fast', 'medium', 'slow',

The result: http://pastebin.com/kWeA1XA4

@cnrd OK, I just tested with the nightly build as well and I'm seeing the same behavior. No idea why they changed because veryfast is often of dubious quality.

I'll consider making the same change to transcode-video, i.e. removing the medium optimization there. But also enforcing that preset.

Sounds like a good idea.

I know that the edit I made is not really optimal as it requires the --preset medium flag every time, just did it for testing :-)

@cnrd BTW, you can work around this without your change just by adding -H encoder-preset=medium to your command line.

I did something that seems better here: #36

@cnrd Thanks, but I don't plan on taking that yet. I'm not sure the HandBrake team intended this new behavior. And it's likely I'll file a bug on them and see if they'll make the change first.

@cnrd Since the Fraunhofer FDK AAC encoder has been disabled in HandBrake version 0.10.5 due to licensing incompatibilities, it seems for the future that only users who are willing to build their own HandBrake will have access to fdk_aac anyway. So, maybe this change won't be all that risky going forward? Something for me to think about at least.

In the meantime, for those using versions of HandBrake older than 0.10.5 and those building their own HandBrake, maybe I should add an explicit way to access the fdk_aac codec with a new option? Here's what the help text might look like:

    --aac-encoder NAME
                    use named AAC audio encoder (default: platform dependent)

What do you think? Would you use this?

Yeah that seems like a nice middle ground, give power users the option to choose, while not changing anything for users who just want stuff to be simple.

I guess it would enable people to choose whatever aac encoder they want to use?

@cnrd Yes, technically users could choose any AAC encoder they wanted but for all practical purposes there is only one available per platform now, either ca_aac on OS X or av_aac on Linux and Windows. Although for some older versions of HandBrake, faac might still be available. And in the future, av_aac might be made available on OS X.

I'm not sure whether this option should allow selection of an HE-AAC encoder as these are not particularly compatible with many playback systems. Any opinions on that?

@cnrd BTW, I'll probably add a similar option to the convert-video tool since the AAC encoder licensing situation with FFmpeg is just as big of a disaster as with HandBrake.

@donmelton

Sorry for the wall of text and any spelling errors, currently finishing a report I have to hand in, so this is me procrastinating with something that is still kinda related :-)

I'm always pro choice, which would mean that the user should be allowed to choose any encoder they wish. If the user knows that all of their equipment supports HE-AAC they could choose that.

My main concern with allowing HE-AAC is if it will even add anything useful?
Did a quick google search (https://developer.apple.com/library/ios/technotes/tn2236/_index.html, https://www.reddit.com/r/audiophile/comments/18b0yg/aac_vs_heaac_what_is_the_difference_which_should/, https://trac.ffmpeg.org/wiki/Encode/AAC) which from fast-skimming tells me that it is mostly useful for lower bit-rate files. This would mean that if you wanted to support HE-AAC encoders on the same level as AAC encoders, the rate-control system would also need to be updated to gain any benefit from such encoders.

Personally I probably wouldn't use HE-AAC mainly because of the compatibility problems, as my media is hosted on a pretty weak Plex server that is barely able to transcode a single video + audio stream (Blows up whenever more than one family member is connecting remote and does not do a direct stream) therefor I want the most compatible files possible.

My current system is MP4 container with a single 2 channel AAC audio stream, as I have no need for multi-channel audio and MP4 is great for streaming to iOS + Web.

I don't really use the convert-video, but it would probably be a good idea, just for being consistent.

I'm pretty sure you already thought of this but: You should definitely make sure that the encoder is available and give a helpful error if it is not, instead of just failing silently or failing with the HandBreak error :-) Also a way that I at least think is helpful would be listing the available encoders, as even fdk_aac can be named differently on different systems (I think I have seen at least 2 different ways it's named, depending on how ffmpeg/handbreak was compiled/sourced).

@cnrd No apologies necessary. And good luck with that report!

Yeah, I think your assessment of HE-AAC is spot on. It's for low bitrates. And, being a Plex user as well, I'm worried about the problems there too. So it's likely HE-AAC won't be allowed. At least not for now.

You make a good point about warnings. Although HandBrake already gives a good one if you try to use an encoder that's not available. Now, I would love to preflight availability on the user's choice, but that's not always possible with HandBrake, oddly enough. But I'll noodle on it.

Thanks for the feedback!

@cnrd OK, I've implemented the --aac-encoder option in version 0.8.0 of transcode-video. Update now to get it. I'll close this since I won't be taking your actual patch.

Thanks again!