[FFmpeg-trac] #5784(avformat:new): Regression: mkv encoder DTS discontinuity

FFmpeg trac at avcodec.org
Wed May 2 22:36:59 EEST 2018


#5784: Regression: mkv encoder DTS discontinuity
-------------------------------------+-------------------------------------
             Reporter:  mbat         |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  dts mkv      |               Blocked By:
  edts mov regression                |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by mkver):

 This is a duplicate of #4536: The video is 25p and uses two reordering
 frames; an edit list makes sure that the pts of the first video sample is
 zero while its dts is -80ms. The audio meanwhile has an edit list that
 shows that indicates that the first aac frame is encoder delay, i.e. the
 actual first frame (that should not be output) has
 pts=dts=-1024/48000=-21.3333...ms. Given that negative pts in Matroska
 aren't allowed, ffmpeg shifts them, but the code for shifting is in
 write_frame and the smaller the dts the earlier the packets get to this
 function. The first two packets that are fed to write_frame are the first
 two video frames in coding order -- they have pts of 0 and 160ms
 respectively which doesn't require shifting because they are already
 positive. But the next packet according to dts is the first audio packet
 which has a negative pts and therefore everything is shifted by to make it
 non-negative. And "everything" only means everything that comes next, the
 first two frames (in coding order) aren't affected, because they have
 already been dealt with. So frame 0 and 4 have not been shifted and so the
 durations of frames 0 (21ms too long), 3 (21ms too short) and 4 (21ms too
 long) are not what they ought to be.

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


More information about the FFmpeg-trac mailing list