[FFmpeg-trac] #2333(undetermined:closed): mkv + ac3 remux adds a little time
FFmpeg
trac at avcodec.org
Sun Dec 22 07:52:56 EET 2019
#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
More information about the FFmpeg-trac
mailing list