[FFmpeg-trac] #10065(ffmpeg:new): Gap in video by -c copy in mkv opus

[FFmpeg]

#10065: Gap in video by -c copy in mkv opus
------------------------------------+----------------------------------
             Reporter:  yumu        |                    Owner:  (none)
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  ffmpeg
              Version:  git-master  |               Resolution:
             Keywords:  mkv opus    |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+----------------------------------
Comment (by mkver):

 1. Your ticket contains several tests and some additional claims, namely
 that each time you repeat step 3, audio and video go out of sync. Did you
 verify that master still behaves as your additional claims say? Because I
 can no longer reproduce this.
 2. When I say "master", I mean anything recent enough to include
 8913539a5d2a81a77980b45455b1eb144827fd96, which a build from November
 (using the then-master) is.
 3. copyts is not a muxer/demuxer option, it is an option for the ffmpeg
 cli tool.
 4. Encoding audio often involves "encoder delay", i.e. if one decodes the
 encoded output, there is no one-to-one correspondence of the input samples
 (fed to the encoder) to the samples output by the decoder. Instead there
 are some padding samples at the beginning and only afterwards do output
 samples correspond to input samples (in a one-to-one manner). The libopus
 encoder uses 312 padding samples (corresponding to 6.5ms at 48kHz) by
 default (see initial_padding=312 in your ffprobe output). The player needs
 to discard these samples for accurate playback.
 Matroska typically only supports nonnegative timestamps; with one
 exception: It has a header field "CodecDelay" that allows to support
 negative timestamps if the data with negative timestamps corresponds to
 encoder delay (i.e. if the data with negative timestamps are to be
 discarded lateron). This is Matroska-internal, i.e. the audio packet
 leaves the demuxer with a negative timestamp (and the stream contains the
 information that the first 312 samples are padding samples).
 The ffmpeg cli tool likes to normalize streams so that they start at zero
 (without breaking the relative sync of them). So if the first audio packet
 has a timestamp of -7ms (-6.5ms rounded to ms precision), it will shift
 all streams by 7ms, which happens when creating a_opus_copy.mkv. It won't
 do this when using -copyts.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10065#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker