[FFmpeg-trac] #4774(ffmpeg:new): Incompatibilities between XBMC/Kodi & mkvalidator relating to how FFmpeg muxes MKVs

FFmpeg trac at avcodec.org
Sun Aug 16 16:11:55 CEST 2015

#4774: Incompatibilities between XBMC/Kodi & mkvalidator relating to how FFmpeg
muxes MKVs
             Reporter:  Drag0nFly    |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  ffmpeg
              Version:  git-master   |               Resolution:
             Keywords:  mkv muxer    |               Blocked By:
  timecode chapter                   |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |

Comment (by Drag0nFly):

 Not sure if the questions are addressed to me, as I am not a developer,
 but I'll attempt to answer as best I can.

 I had the impression that the packet durations were embedded in the
 pgssubs themselves, but this does not seem to be the case. In the most
 recent clip I provided above, Mkvtoolnix removed the pgssubs entirely (not
 just the tags), which caused the file to play back without issues. So that
 was not a good example clip at all.

 I have also tested these files with other players, including VLC/MPlayer,
 etc. – in addition to comparing the behaviour with other software doing
 x264/avc or x265/hevc re-encodes (such as Handbrake, which does not
 exhibit this problem), as well as re-muxing affected files with MakeMKV
 which corrects the issue (and produces no errors or warnings with

 This leads me to conclude that there is clearly something suboptimal in
 the way FFmpeg muxes MKVs/generates these cue entries, as for the majority
 of my library which has been processed through FFmpeg (again; due to its
 excellent batch functionality and no-nonsense approach); mkvalidator
 reports warnings with the cue entries and, more often than not, 'block at
 nnn is not a keyframe' errors.

 One can obviously argue that XBMC/Kodi is somwhat picky in not playing
 these files correctly, but the bottom line is that this would not occur
 had the FFmpeg muxer conformed to spec, like MakeMKV/Handbrake/MkvToolnix
 all do.

Ticket URL: <https://trac.ffmpeg.org/ticket/4774#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list