With upcoming changes to data protection and privacy laws in Europe coming into effect soon, we thought this would be a good time to remind everyone that we do have a privacy policy.
This applies to all users and visitors world-wide.

We have made a few changes to the language to make it clearer in relation to this new regulation but fundamentally, the terms and your rights are unchanged.

If you have any questions about this, please feel free to ask in the General Forum

Conversion Hangs on larger audio bit-rates

Support for HandBrake on Linux, Solaris, and other Unix-like platforms
Forum rules
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.
Post Reply
yarkot
Posts: 4
Joined: Thu Nov 30, 2017 5:42 pm

Conversion Hangs on larger audio bit-rates

Post by yarkot » Thu Nov 30, 2017 6:03 pm

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 -

Code: Select all

Paste log text between these markers.
[code][/i]

rollin_eng
Veteran User
Posts: 2737
Joined: Wed May 04, 2011 11:06 pm

Re: Conversion Hangs on larger audio bit-rates

Post by rollin_eng » Fri Dec 01, 2017 8:21 am

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

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

mduell
Veteran User
Posts: 5953
Joined: Sat Apr 21, 2007 8:54 pm

Re: Conversion Hangs on larger audio bit-rates

Post by mduell » Fri Dec 01, 2017 3:43 pm

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.

yarkot
Posts: 4
Joined: Thu Nov 30, 2017 5:42 pm

Re: Conversion Hangs on larger audio bit-rates

Post by yarkot » Fri Dec 01, 2017 4:53 pm

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
Last edited by yarkot on Fri Dec 01, 2017 8:03 pm, edited 1 time in total.

User avatar
BradleyS
Moderator
Posts: 1279
Joined: Thu Aug 09, 2007 12:16 pm

Re: Conversion Hangs on larger audio bit-rates

Post by BradleyS » Fri Dec 01, 2017 5:40 pm

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.

yarkot
Posts: 4
Joined: Thu Nov 30, 2017 5:42 pm

Re: Conversion Hangs on larger audio bit-rates

Post by yarkot » Fri Dec 01, 2017 5:50 pm

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?

User avatar
JohnAStebbins
HandBrake Team
Posts: 5117
Joined: Sat Feb 09, 2008 7:21 pm

Re: Conversion Hangs on larger audio bit-rates

Post by JohnAStebbins » 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".

yarkot
Posts: 4
Joined: Thu Nov 30, 2017 5:42 pm

Re: Conversion Hangs on larger audio bit-rates

Post by yarkot » Fri Dec 01, 2017 10:06 pm

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.

Post Reply