[FFmpeg-trac] #2333(undetermined:closed): mkv + ac3 remux adds a little time

[FFmpeg]

#2333: mkv + ac3 remux adds a little time
-------------------------------------+-------------------------------------
             Reporter:  Squeeto      |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
                                     |  needs_more_info
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by mkver):

 * status:  new => closed
 * resolution:   => needs_more_info


Comment:

 I am closing this as needs_more_info, because there have been no samples
 provided. Nevertheless, based upon the information from
 [https://ffmpeg.zeranoe.com/forum/viewtopic.php?p=4111#p4111 your post at
 zeranoe's forum] I can already guess what happened here. But for the
 record, here is the post I am basing my answer on:
 {{{
 Here is the first and last packets from:
 original mkv = zoutput.mkv
 original ac3 = zoutput_f.ac3
 mux = done2
 and demuxed = zvideo.mkv and zaudio.ac3

 [zoutput.mkv]
 [PACKET]
 codec_type=video
 stream_index=0
 pts=0
 pts_time=0.000000
 dts=N/A
 dts_time=N/A
 duration=N/A
 duration_time=N/A
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=238017
 pos=241
 flags=K
 [/PACKET]

 [PACKET]
 codec_type=video
 stream_index=0
 pts=255588
 pts_time=12.779400
 dts=254921
 dts_time=12.746050
 duration=667
 duration_time=0.033350
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=27305
 pos=27899741
 flags=_
 [/PACKET]

 [zoutput_f.ac3]
 [PACKET]
 codec_type=audio
 stream_index=0
 pts=0
 pts_time=0.000000
 dts=0
 dts_time=0.000000
 duration=2880
 duration_time=0.032000
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=1024
 pos=0
 flags=K
 [/PACKET]

 [PACKET]
 codec_type=audio
 stream_index=0
 pts=1154880
 pts_time=12.832000
 dts=1154880
 dts_time=12.832000
 duration=2880
 duration_time=0.032000
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=1024
 pos=410624
 flags=K
 [/PACKET]

 [done2]
 [PACKET]
 codec_type=video
 stream_index=0
 pts=67
 pts_time=0.067000
 dts=N/A
 dts_time=N/A
 duration=N/A
 duration_time=N/A
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=238017
 pos=705
 flags=K
 [/PACKET]

 [PACKET]
 codec_type=audio
 stream_index=1
 pts=12899
 pts_time=12.899000
 dts=12899
 dts_time=12.899000
 duration=32
 duration_time=0.032000
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=1024
 pos=28340735
 flags=K
 [/PACKET]

 [zvideo.mkv]
 [PACKET]
 codec_type=video
 stream_index=0
 pts=67
 pts_time=0.067000
 dts=N/A
 dts_time=N/A
 duration=N/A
 duration_time=N/A
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=238017
 pos=644
 flags=K
 [/PACKET]

 [PACKET]
 codec_type=video
 stream_index=0
 pts=12846
 pts_time=12.846000
 dts=12813
 dts_time=12.813000
 duration=33
 duration_time=0.033000
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=27305
 pos=27899931
 flags=_
 [/PACKET]

 [zaudio.ac3]
 [PACKET]
 codec_type=audio
 stream_index=0
 pts=0
 pts_time=0.000000
 dts=0
 dts_time=0.000000
 duration=2880
 duration_time=0.032000
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=1024
 pos=0
 flags=K
 [/PACKET]

 [PACKET]
 codec_type=audio
 stream_index=0
 pts=1154880
 pts_time=12.832000
 dts=1154880
 dts_time=12.832000
 duration=2880
 duration_time=0.032000
 convergence_duration=N/A
 convergence_duration_time=N/A
 size=1024
 pos=410624
 flags=K
 [/PACKET]
 }}}

 zoutput.mkv seems to be using two reorder frames (more on this later) and
 the very last packet in storage/coding order is not the last packet in
 display order, but only the second-to-last in display order. This both
 explains why the pts-dts-offset of the last packet (according to coding
 order) only amounts to one frame and why the duration of this file is
 12.85s (actually 12.7794s+2*0,03335s = 12.8461s).

 Before 9d4fdfe24c731d1880797dee65365154b41c1dea (fixing #4487), the
 timestamps (video and audio, keeping sync) would be shifted so that the
 dts is nonnegative which in case of reorder frames means that the very
 first pts can't be zero. In this case the shifting changed the first pts
 in done2 to 67ms (equal to two frames; hence me thinking that there are
 two reorder frames). This also adds 67ms to the duration (because FFmpeg's
 Matroska muxer uses max(timestamp + duration) (max over all packets) as
 duration; it does not subtract the lowest timestamp), explaining why the
 interleaved file is longer.

 When demuxing the audio from this file to an elementary stream (which does
 not have explicit timestamps at all), the shifting can't be preserved at
 all, hence you have the original duration again.

 But when remuxing the video to another Matroska file, the timestamps can
 be preserved; given that even the dts of the first packet is nonnegative,
 no further shifting is required and the timestamps of the remuxed video
 are the same as the timestamps in the interleaved file. The shifting adds
 the duration of two frames to the video's reported duration, resulting in
 12.91s (up from 12.85s (notice that 12.85s was rounded up from a more
 precise value which is the reason why adding 67ms to the duration results
 in a reported increase of only 60ms)).

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