[FFmpeg-trac] #7927(undetermined:new): Video copy from mkv to mp4 causes variable frame rate from constant frame rate

FFmpeg trac at avcodec.org
Mon May 27 18:48:45 EEST 2019


#7927: Video copy from mkv to mp4 causes variable frame rate from constant frame
rate
-------------------------------------+-------------------------------------
             Reporter:  madsfoto     |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by mkver):

 The Matroska container doesn't store DTS (decoding timestamps), only PTS
 (presentation timestamps); but mp4 stores (i.e. requires) both DTS and
 PTS, so FFmpeg needs to guess the DTS. This guess works well when the
 amount of reorderes packets is known and there is no open GOP at the
 beginning. Your file has an open GOP at the beginning. Notice how the two
 frames from track 1 (the video track) that follow the first frame have a
 lower timestamp than the first frame:
 {{{
 I frame, track 1, timestamp 00:00:00.067000000, size 271247, adler
 0x89f7e858
 I frame, track 2, timestamp 00:00:00.000000000, size 79, adler 0xcf102aef
 P frame, track 1, timestamp 00:00:00.003000000, size 77940, adler
 0xa16fe9fe
 I frame, track 2, timestamp 00:00:00.003000000, size 71, adler 0x6f6b24b3
 I frame, track 2, timestamp 00:00:00.006000000, size 284, adler 0xc7e38d66
 I frame, track 2, timestamp 00:00:00.018000000, size 276, adler 0x5d1c87cb
 P frame, track 1, timestamp 00:00:00.036000000, size 46893, adler
 0xb38d083c
 I frame, track 2, timestamp 00:00:00.039000000, size 286, adler 0x728f8c1f
 I frame, track 2, timestamp 00:00:00.060000000, size 298, adler 0xaa5f9d36
 P frame, track 1, timestamp 00:00:00.170000000, size 150864, adler
 0xc434e645
 }}}
 I wouldn't be surprised if there were already a ticket for exactly this
 issue.

 PS: FFmpeg also guesses DTS when it e.g. remuxes to Matroska; so the
 conversion mkv->mkv suffers from the same issue.

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


More information about the FFmpeg-trac mailing list