transcode-video uses libmp3lame when outputting an mkv

[samhutchins]

I don't have a mac handy to test with I'm afraid, but on Windows (native windows, using CMD) the following command outputs with an mp3 stereo track:

transcode-video title_t03.mkv -o "output.mkv"

This command, however, outputs with an aac stereo track instead:

transcode-video title_t03.mkv -o "output.mp4"

I'm not sure if this is intended behaviour or not, but I doubt it is. Apologies for not noticing this before now. I used to always output to an mp4, so I always got aac, and by the time I'd switched to outputting mkv files I'd also specify to use fdk_aac.

I'm using HandBrakeCLI 1.1.2

MKV log:
output.mkv.log

MP4 log:
output.mp4.log

[lisamelton]

@samhutchins Holy crap! Did they change the default audio format for Matroska output in version 1.1.2? Can you try this with version 1.1.0 or 1.1.1 as well? And can anyone else using Windows confirm this?

[lisamelton]

@samhutchins BTW, this is probably due to a change I made back in June to "Modify transcode-video to no longer pass a named audio encoder to HandBrakeCLI in order to select AAC since that's the default audio format anyway." Obviously I was wrong about the default on Windows!

https://github.com/donmelton/video_transcoding/commit/477d342302764097cbd925b5081d8774864d872a

[lisamelton]

@samhutchins I'll back out that change which will, no doubt, fix this bug. I'll also look at any other optimizations I may have done elsewhere which might be causing further problems. And I'll add the workaround for the new mixdown default in nightly builds which you and I have been discussing out of band.

My apologies that you ran into the situation. Thanks for catching this!

[lisamelton]

@samhutchins Stupid question: Do you still have to specify av_aac on Windows to get the FFmpeg/Libav AAC encoder or can you use the generic aac name and still avoid getting the old LibFacc encoder (which I think was removed in HandBrakeCLI version 0.10.0)?

[samhutchins]

@donmelton

1.1.0 has the same behaviour
1.0.0 also has the same behaviour, and I presume everything in between does too

Using Handbrake 1.0.0+ with transcode-video, I can pass -H aencoder=ac3,aac and it uses the libav encoders:

[17:19:54]  * audio track 1
[17:19:54]    + decoder: English (FLAC) (5.1 ch) (track 1, id 0x1)
[17:19:54]      + samplerate: 48000 Hz
[17:19:54]    + mixdown: 5.1 Channels
[17:19:54]    + encoder: AC3 (libavcodec)
[17:19:54]      + bitrate: 640 kbps, samplerate: 48000 Hz
[17:19:54]  * audio track 2
[17:19:54]    + decoder: English (FLAC) (5.1 ch) (track 1, id 0x1)
[17:19:54]      + samplerate: 48000 Hz
[17:19:54]    + mixdown: Dolby Pro Logic II
[17:19:54]    + encoder: AAC (libavcodec)
[17:19:54]      + bitrate: 160 kbps, samplerate: 48000 Hz

[samhutchins]

I've also just tested using WSL, and I don't have this problem. This seems to only affect Windows, and not Mac/Linux users

[lisamelton]

@samhutchins Thanks! Yeah, I really screwed things up with that optimization back in June. But at least the fix can be just a single line by using the aac alias.

And I'm so glad Linux users aren't affected by this! Thanks for testing that, too!

I'll probably have a release with the fix later today.

[samhutchins]

I wonder why HandBrake defaults to mp3 on Windows, but not anywhere else...

[lisamelton]

@samhutchins Good question! Apparently their defaults are a lot less stable and/or predictable than I thought. Ugh.

BTW, I decided to restore all the complicated code which reads the output of HandBrakeCLI --help to determine the actual encoder name (i.e. ca_aac or av_aac) than use the generic aac name because... 1) I know that worked and 2) I worry that they'll remove the generic name in the future.

[lisamelton]

@samhutchins OK, I've committed the fix:

https://github.com/donmelton/video_transcoding/commit/6a7d0202ad2ff1ffceb92009f75b955ba18c5e76

[samhutchins]

Sweet, just tested and it works :-D

[19:27:34]  * audio track 1
[19:27:34]    + decoder: English (FLAC) (5.1 ch) (track 1, id 0x1)
[19:27:34]      + samplerate: 48000 Hz
[19:27:34]    + mixdown: 5.1 Channels
[19:27:34]    + encoder: AC3 (libavcodec)
[19:27:34]      + bitrate: 640 kbps, samplerate: 48000 Hz
[19:27:34]  * audio track 2
[19:27:34]    + decoder: English (FLAC) (5.1 ch) (track 1, id 0x1)
[19:27:34]      + samplerate: 48000 Hz
[19:27:34]    + mixdown: Dolby Pro Logic II
[19:27:34]    + encoder: AAC (libavcodec)
[19:27:34]      + bitrate: 160 kbps, samplerate: 48000 Hz

[lisamelton]

@samhutchins Whew. :) And thanks for the quick testing!

I'll get this released as soon as I get that workaround for HandBrake nightly builds done that we discussed out of band.

[samhutchins]

@donmelton No problem!

Good luck with the other audio issues too. Apologies for emailing about those, I should have opened an issue here instead (which I can do if you like). For some reason it didn't trigger the "file a bug" code path in my head

[lisamelton]

@samhutchins No worries. I didn't think to open an issue either. :)

The good news is that the patch for that is done. The bad news is that although I think it works, testing it thoroughly will take awhile.

[lisamelton]

@samhutchins Aaaaand... In the process of testing that bug fix, I found other unrelated breakage when using the HandBrake nightly builds. Dammit.

This will definitely take awhile.

[lisamelton]

@samhutchins OK, I committed the mixdown workaround:

https://github.com/donmelton/video_transcoding/commit/5f2aa55226320d2f1fabd9822441fff16e4dcbe1

Working on the next workaround now...

[lisamelton]

@samhutchins OK, I released the Gem. Thanks, again!