HB-20190816180347 is taking significantly longer to do initials can of .mkv file. #2248
Comments
|
This new slower scanning may be correct and previous builds were not performing something they should have been. But reported the perf hit in case it wasn't expected. |
|
If this happens when encoding please attach some encoding logs. |
|
If this happens when scanning the file in the main window, probably something related to FFmpeg 4.2. |
Did you report this issue to ffmpeg people ? |
|
No, I haven't. I've never tested ffmpeg directly. Where does ffmpeg usually reside? I don't find it down inside the HB app bundle and don't find the tool on my system in a place that it seems HB would execute from. (for example, I do find a ffmpeg tool down inside the BlueJeans conference app, and down inside VMware Fusion, but no ffmpeg in my $path). How would I use current HB code with different ffmpeg tool versions to isolate whether it's HB or ffmpeg code impacting performance? |
|
I've found this bug report with same error message " exceeds containing master element ending at" |
The "exceeds containing master element ending at" error without initial "Invalid length" error is a different issue, "exceeds containing master element ending at" error being just a result of the first error in ticket 8083. "exceeds containing master element ending at" error alone is fixed in latest FFmpeg build AFAIK (I tested the command line in this post that reproduces the error and it is OK with FFmpeg git-master, see the long list of patches on Matroska decoder) IMO it would worth it to try latest builds of FFmpeg (for example from here, selecting "shared" linking and replacing FFmpeg libs in the current build of Handbrake). |
|
Please provide an input sample that allows to reproduce the issue. |
|
The input samples I was using for the HB logs attached are two HD mkv movie files, 27gb and 36.8gb in size. I can't upload those anywhere and even if I could my upload speed sucks. If I discover smaller example input file or file(s), I'll upload them via DropBox or somewhere they can be grabbed. |
|
Can you download MKVToolNix and upload the output of |
|
The right bug is https://trac.ffmpeg.org/ticket/8084 and fixed in the 4.2 branch. I'm waiting feedback from a friend whom have more big mkv files. |
|
@galad87 As handbrake use a static ffmpeg, the best for you is to patch ffmpeg 4.2 to fix this issue or wait for the next stable release. Patch is here here |
|
@marillat thanks for the pointer to the patch I've applied that patch in HandBrake git master. The next nightly build should include it. @devonhub, if you could test with the next nightly build (https://handbrake.fr/nightly.php) and let us know if it fixes your problem we can close this issue. |
|
will do. thanks! |
|
Did you have time to check if the issue is fixed? |
|
Closing for now. Feel free to provide feedback if the problem persists. |
FFmpeg 4.2.1 is released now, which includes this seeking fix. |
|
We have the patch locally anyway so it'll rollup when we upgrade. |
Description of the problem
When adding a new .mkv file to the queue, the initial scan is taking significantly longer using nightly 'HB-20190816180347' than the previous nightly build, 'HB-20190801141537'. The difference is scans that took several seconds now take several minutes.
HB-20190801141537
moviefile1.mkv 17 seconds
moviefile2.mkv 10 seconds
HB-20190816180347
moviefile1.mkv 4 mins, 35 secs
moviefile2.mkv 2 mins, 09 secs
HB-20190801141537-vs-HB-20190816180347 logs.zip
HandBrake version (e.g., 1.0.0)
HB-20190816180347
Operating system and version (e.g., Ubuntu 18.04 LTS, macOS 10.14 Mojave, Windows 10 1809)
macOS 10.11.6
macOS 10.14.6
Error message text or screenshot
not applicable
HandBrake Activity Log (see https://handbrake.fr/docs/en/latest/help/activity-log.html)
The text was updated successfully, but these errors were encountered: