#16027 new Bugs

Rapid chapter skipping of MKVs causes certain chapters to repeat for lavf-muxed files

Reported by: Drag0nFly Owned by: FernetMenta
Priority: 4 - Normal
Component: Video playback (inc. audio in video and codecs) Version:
Severity: Normal Keywords: mkv chapter rapid skip repeat lavf
Cc: fritsch Blocked By:
Blocking: Platform: Linux


This is a somewhat strange issue I have encountered on three different systems; two Ivy Bridge (HD2500 & HD4000) and one Haswell (Intel Iris Graphics 5100), and verified with recent versions of Kodi (last revision tested: 15.0-BETA2 Git:2015-06-02-83c870b):

When rapidly chapter-skipping certain MKV-files, the chapters start repeating instead of proceeding to the next. This always occurs with the same chapter number for each file (although the chapters affected are different between files.)

It appears to be related to the writing library used to generate the MKV files. Files generated using the older libmkv lib are fine, as are files which are written with MakeMKV (using libmakemkv as the writing library)

MKV files written with lavf however (i.e, with FFmpeg or recent Handbrake versions) consistently introduce issues.

I have tried to get some meaningful debug output, but obviously realize that this could be hard to track down without a clip (which would be quite large, unfortunately, as it requires a certain length to trigger). But the issue appears to be reproducible with all FFmpeg-generated MKVs I've tested, and tests I've done with HandBrake which also uses lavf.

Also; when re-muxing the files with Mkvtoolnix the issue still persists, but when rewriting with MakeMKV the issues go away, which leads me to believe there is some weirdness in how lavf-written files are handled.

The files themselves are fine, and the chapter can be skipped if waiting for a couple of seconds (or if simultaneously doing a FF and hitting chapter-skip)

Debug log is here:


Sample clip here (chapter repeat occurs with chapter 3->4, "While you're out, pick up some AA-batteries")


Change History (9)

comment:1 Changed at 2015-06-07T08:19:58+01:00 by mkortstiege

  • Cc fritsch added

comment:2 Changed at 2015-07-26T14:44:10+01:00 by Drag0nFly

Verified that this issue is a regression; chapter skip works properly in 13.1 Git:20140604-84725b0 (June 4th, 2014 build) Same behaviour on Linux and OSX. (And no, I haven't done a bisect yet;)

Was starting to wonder if this was a bug introduced in FFmpeg.

comment:3 Changed at 2015-07-28T09:34:26+01:00 by Drag0nFly

Performed two git bisects on this issue, unfortunately with mixed results. First attempt was done with @FernetMenta's branch (didn't notice this until it was too late)–which failed near the end with two steps left. The second with the mainline branch, which also failed in pretty much the exact same way.

The error appears to indicate a change in FFmpeg; as the last working compile is directly before [dbad269d649c5e029b2002937a9304ea0ed30bda] 'remove ffmpeg from tree'.

I am providing the full bisect log below - comments welcome.

[email protected] xbmc $ git bisect start
Already on 'master'
Your branch is up-to-date with 'origin/master'.
[email protected] xbmc $ git bisect bad
[email protected] xbmc $ git bisect good 84725b0
Bisecting: a merge base must be tested
[ba63a2b5440a23b97319f898afd8fce8792088bd] ActiveAE: increase max buffer size from 80ms to 100ms

[email protected] xbmc $ git bisect good
Bisecting: a merge base must be tested
[ab0aec4057992edc875e4cd733eb80dc79dbfb4a] Merge pull request #4312 from wsoltys/pvrfix

[email protected] xbmc $ git bisect good
Bisecting: a merge base must be tested
[e27fc38758702d3d97b71ba643f3509acd0f1a37] settings: fix conflict of <minimum> and <maximum> for CSettingList

[email protected] xbmc $ git bisect good
Bisecting: a merge base must be tested
[cd5aba3d2e03b094723a680405ab9b5d1931d806] [ios] - only use the native keyboard if tvout is not used (native keyboard doesn't work with hdmi/tvout on ios) - fixes #14966

[email protected] xbmc $ git bisect good
Bisecting: 3890 revisions left to test after this (roughly 12 steps)
[fbab09b3c14d3b4a5cf9b3c9dab30a12e3b619b6] [win32] remove non-existing header files from project files

[email protected] xbmc $ git bisect bad
Bisecting: 1945 revisions left to test after this (roughly 11 steps)
[5a31feb816ee4dfecf1637f4f0d043028a63b925] Merge pull request #5038 from xhaggi/pvr-invalid-window-on-channel-switch

[email protected] xbmc $ git bisect bad
Bisecting: 972 revisions left to test after this (roughly 10 steps)
[da52147ff4cc607d86820774430a3a3f416b4f72] [addonversion] drop Print()

[email protected] xbmc $ git bisect bad
Bisecting: 485 revisions left to test after this (roughly 9 steps)
[2357c0bc57ceb717c62982091f91daf368358bed] Merge pull request #4587 from fritsch/xbmc-upstream

[email protected] xbmc $ git bisect good
Bisecting: 241 revisions left to test after this (roughly 8 steps)
[5cf64af37ef131369c41323efdeda53950cd063a] Merge pull request #4002 from Karlson2k/httpheader_add_01

[email protected] xbmc $ git bisect bad
Bisecting: 121 revisions left to test after this (roughly 7 steps)
[0bd44ffce320fee25f9cd361e24053957bb2c9ae] X11: set ExposureMask on gl window, fixes not updated areas

[email protected] xbmc $ git bisect bad
Bisecting: 60 revisions left to test after this (roughly 6 steps)
[af34a0a125611eb8797759d8f930beef8d4b3dee] Merge pull request #4565 from xhaggi/epg-grid-cleanup

[email protected] xbmc $ git bisect good
Bisecting: 30 revisions left to test after this (roughly 5 steps)
[11fa64ef68089e278d8a6098799e3fdf6f0fba3a] [jenkins] - enable-neon for android

[email protected] xbmc $ git bisect bad
Bisecting: 14 revisions left to test after this (roughly 4 steps)
[01f1cfe2a92fcb8e6f7eafee621eb4274425736c] ffmpeg: bump version to 2.2

[email protected] xbmc $ git bisect bad
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[fe82084c40af493bfb55718196b3e243e7227a64] remove ffmpeg dlls from generated headers not removing win32 as this might still be needed?

[email protected] xbmc $ git bisect bad
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[dbad269d649c5e029b2002937a9304ea0ed30bda] remove ffmpeg from tree

As well as an excerpt from where the compilation fails due to the missing FFmpeg tree:

CPP     xbmc/cores/DllLoader/coff.o
CPP     xbmc/cores/DllLoader/dll.o
CPP     xbmc/cores/DllLoader/DllLoader.o
CPP     xbmc/cores/DllLoader/DllLoaderContainer.o
CPP     xbmc/cores/DllLoader/dll_tracker.o
CPP     xbmc/cores/DllLoader/dll_tracker_file.o
CPP     xbmc/cores/DllLoader/dll_tracker_library.o
CPP     xbmc/cores/DllLoader/dll_util.o
CPP     xbmc/cores/DllLoader/LibraryLoader.o
CPP     xbmc/cores/DllLoader/SoLoader.o
CC      xbmc/cores/DllLoader/mmap_anon.o
CC      xbmc/cores/DllLoader/ldt_keeper.o
ldt_keeper.c: In function ‘Setup_LDT_Keeper’:
ldt_keeper.c:258:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   *(void**)array.base_addr = ldt_fs->prev_struct;
AR      xbmc/cores/DllLoader/dllloader.a
make -C lib
make[1]: Entering directory `/home/martin/mainline.test/xbmc/lib'
make -C ffmpeg
make: Entering an unknown directory
make: *** ffmpeg: No such file or directory.  Stop.
make: Leaving an unknown directory
make[1]: *** [ffmpeg] Error 2
make[1]: Leaving directory `/home/martin/mainline.test/xbmc/lib'
make: *** [dvdpcodecs] Error 2

real	4m44.114s
user	12m16.560s
sys	0m47.603s

comment:4 Changed at 2015-08-06T17:55:14+01:00 by Drag0nFly

Let me know if there is a chance for me to finish the last two bisect steps (or gleam further info, as I would be happy to do more debugging.) Obviously the bug originates from the change in ffmpeg, and should be easy to reproduce with the clip I've referenced in the ticket as it affects all recent (post feb-2005) Kodi releases.

I spent a whole weekend trying to nail this one down (doubt I am the only one processing my MKVs with ffmpeg(?)).

comment:5 Changed at 2015-08-07T15:06:00+01:00 by Drag0nFly

Performed another test by compiling today's git snapshot of Kodi with '--with-ffmpeg=auto' in order to compare behaviour with a custom-built FFmpeg (git:g9f4f578); but the problem still persists. Double-checked that it is indeed using the git version (all system-level FFmpeg/libavcodec stuff has been removed):

~/kodi.mainline/xbmc> strings xbmc/xbmc.a|grep avcodec /usr/local/include/libavcodec avcodec.h avcodec_register_all avcodec_register_all

~/kodi.mainline/xbmc> strings /usr/local/lib/libavcodec.a|grep "FFmpeg version N"

FFmpeg version N-73393-g9f4f578

~/kodi.mainline/xbmc> ffmpeg -version ffmpeg version N-73393-g9f4f578 Copyright (c) 2000-2015 the FFmpeg developers

Since this is the version used to encode the files (the 'encode' being a simple CRF re-encode of Blu-Ray-sourced MKVs with pretty much default values), it would be strange if it indeed was the culprit.

I hope there is a solution to this rather annoying chapter-skip issue, as it pretty much affects half of the library.

comment:6 Changed at 2015-08-10T12:44:57+01:00 by Drag0nFly

Last edited at 2015-08-12T13:55:03+01:00 by Drag0nFly (previous) (diff)

comment:7 Changed at 2015-08-14T11:41:05+01:00 by Drag0nFly

Although I seem to be talking to myself here (for 2 1/2 months), I thought I'd add that I've created a bug report for this issue with FFmpeg as well; as I am not sure if this behaviour is inherited from upstream or caused by Kodi itself.

=> https://trac.ffmpeg.org/ticket/4774

Again, any input from the devs would be appreciated so we can try to nail this issue down to the right component.

comment:8 Changed at 2015-08-14T17:52:20+01:00 by FernetMenta

I don't think this is a ffmpeg issue. Sorry, I don't have time to look into this. Holidays and hevc have higher prio.

comment:9 Changed at 2015-08-14T18:00:52+01:00 by Drag0nFly

Thanks for replying; I noticed too that you were working on hevc (which, I agree, has priority).

Some of the FFmpeg devs thought it might be related to the way the subtitles were muxed (from looking at the mkvinfo -v -v -v debug output from the test clip)

I will do some additional tests this weekend by muxing & re-encoding a stream w/o subs to see.

There were also complaints from mkvalidator for the ffmpeg-generated files relating to the timecodes for the cue entries (which do not show up in, e.g, a libmakemkv-generated or re-muxed file)

However, the seeking within Kodi might be thrown off by trying to seek within the non-spec subtitle cues.

I hope someone else has a chance to have a look at this if it indeed is caused by Kodi–hopefully there is an easy fix as this worked not too long ago.

Note: See TracTickets for help on using tickets.