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

[FFmpeg]

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

Comment (by Drag0nFly):

 Just to be clear: I wrote early on that I preferred FFmpeg, which would
 effectively rule out what you suggest above. It did however appear pretty
 clear that the devs weren't all too concerned about the defects and the
 differences in result after processing identical files with
 MakeMKV/Handbrake/mkvtoolnix vs. FFmpeg.

 And yes, I do know both Handbrake and FFmpeg employs lavf; that was in the
 title of my bugreport to them; http://trac.kodi.tv/ticket/16027

 I am disappointed that the Kodi devs haven't addressed it, but I know the
 person who usually takes care of it (FernetMenta) is busy implementing
 hevc acceleration via vaapi in, strangely enough, FFmpeg.

 But this frankly does not change much. There are other errors in the MKV
 files FFMpeg generates, apart from the one I have reported here, that it
 is effectively unusable for this purpose. I have provided examples of
 those errors as well in the same report, as I am somewhat skeptical as to
 the effectiveness of opening up separate bug reports for those.

 Luckily, the broken files can be corrected by remuxing them with MakeMKV,
 provided the stream is h264 and not hevc, in which case it will need to be
 re-encoded.

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