avformat/mux: Preserve sync even if later packet has negative ts

write_packet() has code to shift the packets timestamps
to make them nonnegative or even make them start at ts zero;
this code inspects every packet that is written and if a packet
with negative timestamp (whether this is dts or pts depends upon
another flag; basically: Matroska uses pts, everyone else dts)
is encountered, this is offset to make the timestamp zero.
All further packets will be offset accordingly (with the offset
converted according to the streams' timebases).

This is based around an assumption, namely that the timestamps
are indeed non-decreasing, so that the first packet with negative
timestamps is the first packet with timestamps. This assumption
is often fulfilled given that the default interleavement function
by default interleaves per dts; yet there are scenarios in which
it may not be fulfilled:
a) av_write_frame() instead of av_interleaved_write_frame() is used.
b) The audio_preload option is used.
c) When the timestamps that are made nonnegative/zero are pts
(i.e. with Matroska), because the packet with the smallest dts
is not necessarily the packet with the smallest pts.
d) Possibly with custom interleavement functions.
In these cases the relative sync of the first few packet(s) is offset
relative to the later packets. This contradicts the documentation
("When shifting is enabled, all output timestamps are shifted by
the same amount").

Therefore this commit changes this: As soon as the first packet
with valid timestamps is output, it is checked and recorded whether
the timestamps need to be shifted. Further packets are no longer
checked for needing to be offset; instead they are simply offset.
In the cases above this leads to packets with negative timestamps
(and the appropriate warnings) instead of desync. This will mostly
be fixed in the next commit.

This commit also factors handling the avoid_negative_ts stuff out
of write_packet() in order to be able to return immediately.

Tickets #4536 and #5784 as well as the matroska-avoid-negative-ts-test
are examples of c); as has been said, some timestamps are now negative,
yet the ref file update does not show it because ffmpeg.c sanitizes
the timestamps (-copyts disables it; ffprobe and mkvinfo also show
the original timestamps).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

1 files changed, 3 insertions, 3 deletions

diff --git a/tests/ref/fate/matroska-avoid-negative-ts b/tests/ref/fate/matroska-avoid-negative-ts
index a687c8f63c..1b9b2f2786 100644
--- a/tests/ref/fate/matroska-avoid-negative-ts
+++ b/tests/ref/fate/matroska-avoid-negative-ts
@@ -1,4 +1,4 @@
-3349536550047c5c553215003ba2acb7 *tests/data/fate/matroska-avoid-negative-ts.matroska
+90cf5a330659140d47ec11208f525908 *tests/data/fate/matroska-avoid-negative-ts.matroska
 973070 tests/data/fate/matroska-avoid-negative-ts.matroska
 #extradata 0:       22, 0x2885037c
 #tb 0: 1/1000
@@ -12,11 +12,11 @@
 #sample_rate 1: 44100
 #channel_layout 1: 4
 #channel_layout_name 1: mono
-0,        -37,         24,       40,     9156, 0xe5bd034a, S=1,       40
+0,        -37,         43,       40,     9156, 0xe5bd034a, S=1,       40
 1,          0,          0,       26,      417, 0x7198c15e
 0,          3,          3,       40,     1740, 0x29ac4480, F=0x0
-0,         24,        123,       40,     3672, 0x98652013, F=0x0
 1,         26,         26,       26,      417, 0x3c67c32d
+0,         43,        123,       40,     3672, 0x98652013, F=0x0
 1,         52,         52,       26,      417, 0x8c24b1ca
 1,         78,         78,       26,      417, 0x6ee576b7
 0,         83,         83,       40,     2532, 0xa2c42769, F=0x0