HandBrake

Description of problem or question

In about 10% of my files (5 out of 44), conversion seems to hang indefinitely, at about the same location in the process.
This shows in either `handbrake` or `HandBrakeCLI`.

In version 0.10.2, I was able to manually modify the "Normal" presets, eliminating the "-B" option, and the hangs all disappeared.
In the current (1.0.7-master github HEAD) version I built, this doesn't work for "CLI Default" presets (nor the old "Normal" presets) - rather, I tried manually setting "-B": "-B 96" still hangs, but "-B 48" proceeds.

Any hints on how / where to instrument this to help lead to a patch / fix would be appreciated.


Steps to reproduce the problem (If Applicable)

I am converting from webm to m4v (to mp4 also shows this; I've tried no other conversions to reproduce, as yet).

`HandBrakeCLI -Z "CLI Default" -O -I -i problem.webm -o out.m4v`


HandBrake version (e.g., 1.0.0)

HandBrake 20171128162442-c34d437-master (built from github);
Also happened in:
handbrake/xenial 0.10.2+ds1-2build1 amd64

Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.3 High Sierra, Windows 10 Creators Update)

Ubuntu 16.04.3 LTS

Error message text or screenshot (If Applicable)

Conversion hangs / stops -- at apparently same position in each hanging file.

Provide a URL from any image hosting site.

Privately generated (screen captured) videos.

HandBrake Activity Log ***required*** (see How-to get an activity log)

[17:49:50] gtkgui: HandBrake 20171128162442-c34d437-master (2017112901) - Linux x86_64 - https://handbrake.fr
[17:49:50] hb_init: starting libhb thread
[17:49:50] hb_init: starting libhb thread
[17:49:50] hb_init: starting libhb thread


Use any pastebin website and provide the URL it generates
- or -

Could you please post your failed encode logs, instructions can be found here:

https://handbrake.fr/docs/en/latest/hel ... y-log.html

An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.

I see the source of the confusion: it looks like ~/.config/ghb/Activity.log.* is just from the GUI, and the stream of activity to the hang is simply what y'all are looking for. Got it. Here (just repeated): https://pastebin.com/VpxeEGLs

Could be that the bit rate is too high for the sample rate (16kHz in this case), but we do have constraints for this under the hood; possibly a bug there.

That said, lots of stream errors in your source, not uncommon for over-the-air recordings. I’m guessing that’s the larger problem.

Thanks for your reply.

Yes - it was a recording of an online course, as it was given (by the presenter)... so over-the-air.

I'll note that in 0.10.2+ds1-2build1, removing the -B option resulted in defaults (driver?) working;
Not so in the 1.0.7 (really: master HEAD of a few days back - 20171128162442-c34d437-master) - whatever the driver defailts w/o a -B option go to hangs. Anything / anyplace I can stick / turn on instrumentation to help nail this? Provide more data?

It's probably just another case of "libav aac encoder sucks". It's probably suck in a loop some place trying to achieve the specified bitrate and no matter how hard it tried it can't generate enough bits to do it. Afraid there's not much we can do about it for the moment aside from telling you to just use a lower bitrate. If you're technically inclined, you could build HandBrake from source and enable the better fdk-aac encoder. It can't be distributed in binary form due to licensing conflicts, but it's a much better aac encoder.

But if you are able to provide the sample so we can reproduce it, I could at least verify that "libav aac sucks".

JohnAStebbins wrote: ↑Fri Dec 01, 2017 9:02 pm It's probably just another case of "libav aac encoder sucks". It's probably suck in a loop some place trying to achieve the specified bitrate and no matter how hard it tried it can't generate enough bits to do it. Afraid there's not much we can do about it for the moment aside from telling you to just use a lower bitrate. If you're technically inclined, you could build HandBrake from source and enable the better fdk-aac encoder. It can't be distributed in binary form due to licensing conflicts, but it's a much better aac encoder.

But if you are able to provide the sample so we can reproduce it, I could at least verify that "libav aac sucks".

Oh! John! You _nailed_ it (thanks).

I (now) build w/ `./configure --launch-jobs=4 --enable-fdk-aac --launch` --- and all is well. With -B 48, result size is smaller, of course, but that's not the point. The point is, apparently, "libav aac sucks". Heh.