virtualenv/FFmpeg
1
0
Fork 0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-18 03:19:31 +02:00
Code Issues Releases Activity
398467f519
FFmpeg/tests/ref/fate/matroska-avoid-negative-ts

42 lines
2.0 KiB
Plaintext
Raw Normal View History

avformat/matroskaenc: Don't write \0 unnecessarily Writing the duration SimpleTag is special: It's size is reserved in advance via an EBML Void element (if seekable) and this reserved space is overwritten when writing the trailer; it does not use put_ebml_string(). The string to write is created via snprintf on a buffer of size 20; this buffer is then written via put_ebml_binary() with a size of 20. EBML strings need not be zero-terminated; if not, they are implicitly terminated by the element's length field. snprintf() always zero-terminates the buffer, i.e. the last byte can be discarded when using an EBML string. This patch does this. The FATE changes are as expected: One byte saved for every track; the only exception is the matroska-qt-mode test: An additional byte is saved because an additional byte could be saved from the enclosing Tags length field. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2023-08-08 16:25:39 +02:00
dede1d72a28c7eb0a849acf230b08247 *tests/data/fate/matroska-avoid-negative-ts.matroska
973072 tests/data/fate/matroska-avoid-negative-ts.matroska
fate/matroska: Add test for avoiding negative timestamps This tests the issue from tickets #4536, #5784; the output of this test is currently broken. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-01-18 16:47:56 +02:00
#extradata 0: 22, 0x2885037c
#tb 0: 1/1000
#media_type 0: video
#codec_id 0: mpeg2video
#dimensions 0: 352x288
#sar 0: 12/11
#tb 1: 1/1000
#media_type 1: audio
#codec_id 1: mp3
#sample_rate 1: 44100
#channel_layout_name 1: mono
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>
2022-01-18 20:56:14 +02:00
0, -37, 43, 40, 9156, 0xe5bd034a, S=1, 40
fate/matroska: Add test for avoiding negative timestamps This tests the issue from tickets #4536, #5784; the output of this test is currently broken. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-01-18 16:47:56 +02:00
1, 0, 0, 26, 417, 0x7198c15e
0, 3, 3, 40, 1740, 0x29ac4480, F=0x0
1, 26, 26, 26, 417, 0x3c67c32d
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>
2022-01-18 20:56:14 +02:00
0, 43, 123, 40, 3672, 0x98652013, F=0x0
fate/matroska: Add test for avoiding negative timestamps This tests the issue from tickets #4536, #5784; the output of this test is currently broken. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-01-18 16:47:56 +02:00
1, 52, 52, 26, 417, 0x8c24b1ca
1, 78, 78, 26, 417, 0x6ee576b7
0, 83, 83, 40, 2532, 0xa2c42769, F=0x0
1, 104, 104, 26, 417, 0x407603db
0, 123, 203, 40, 1728, 0xae823d3b, F=0x0
1, 130, 130, 26, 417, 0xcf2804d2
1, 156, 156, 26, 417, 0xcf2804d2
0, 163, 163, 40, 1028, 0x286ac52a, F=0x0
1, 182, 182, 26, 417, 0xcf2804d2
0, 203, 283, 40, 1916, 0xd378899e, F=0x0
1, 208, 208, 26, 417, 0xcf2804d2
1, 235, 235, 26, 417, 0xcf2804d2
0, 243, 243, 40, 1168, 0x424e12cf, F=0x0
1, 261, 261, 26, 417, 0xcf2804d2
0, 283, 363, 40, 1660, 0x5cec156c, F=0x0
1, 287, 287, 26, 417, 0xcf2804d2
1, 313, 313, 26, 417, 0xef163d04
0, 323, 323, 40, 1004, 0xac0dce29, F=0x0
1, 339, 339, 26, 417, 0x2a009b3a
0, 363, 443, 40, 3008, 0x0fc798bf, F=0x0
1, 365, 365, 26, 417, 0xbedccb9d
1, 365, 365, 26, 417, 0x2214be3f
1, 391, 391, 26, 417, 0x8953b878
Reference in New Issue Copy Permalink