Chiebot-Mirror
/
FFmpeg
mirror of https://github.com/FFmpeg/FFmpeg.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
109658 Commits
37 Branches
400 Tags
465 MiB
Tag: Branch: Tree: b6219c9114
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b6219c9114'
${ noResults }
FFmpeg/tests/ref/fate/matroska-avoid-negative-ts

42 lines
2.0 KiB
Raw Normal View History Unescape

avformat/matroskaenc: Don't waste bytes to Write Tag length fields This is possible by using a dynamic buffer to write them; said dynamic buffer is (re)used and reset as appropriate. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2 years ago
fbe66be73d379073e0705891f290a6b2 *tests/data/fate/matroska-avoid-negative-ts.matroska
973055 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>
3 years ago
#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>
3 years ago
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>
3 years ago
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>
3 years ago
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>
3 years ago
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