mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2024-12-18 03:19:31 +02:00
eb325324aa
Matroska generally requires timestamps to be nonnegative, but there is an exception: Data that corresponds to encoder delay and is not supposed to be output anyway can have a negative timestamp. This is achieved by using the CodecDelay header field: The demuxer has to subtract this value from the raw (nonnegative) timestamps of the corresponding track. Therefore the muxer has to add this value first to write this raw timestamp. Support for writing CodecDelay has been added in FFmpeg commitd92b1b1baband in Libav commita1aa37dd0b. The former simply wrote the header field and did not apply any timestamp offsets, leading to desynchronisation (if one uses multiple tracks). The latter applied it at two places, but not at the one where it actually matters, namely in mkv_write_block(), leading to the same desynchronisation as with the former commit. It furthermore used the wrong stream timebase to convert the delay to the stream's timebase, as the conversion used the timebase from before avpriv_set_pts_info(). When the latter was merged in82e4f39883, it was only done in a deactivated state that still did not offset the timestamps when muxing due to "assertion failures and av sync errors".a1aa37dd0bmade it definitely more likely to run into assertion failures (namely if the relative block timestamp doesn't fit into an int16_t). Yet all of the above issues have been fixed (in commits962d631573,5d3953a5dcand4ebeab15b0. This commit therefore enables applying CodecDelay, fixing ticket #7182. There is just one slight regression from this: If one has input with encoder delay where the first timestamp is negative, but the pts of the part of the data that is actually intended to be output is nonnegative, then the timestamps will currently by default be shifted to make them nonnegative before they reach the muxer; the muxer will then ensure that the shifted timestamps are retained. Before this commit, the muxer did not ensure this; instead the timestamps that the demuxer will output were shifted and if the first timestamp of the actually intended output was zero before shifting, then this unintentional shift just cancels the shift performed before the packet reached the muxer. (But notice that this only applies if all the tracks use the same CodecDelay, or the relative sync between tracks will be impaired.) This happens in the matroska-opus-remux and matroska-ogg-opus-remux FATE tests. Future commits will forward the information that the Matroska muxer has a limited capability to handle negative timestamps so that the shifting in libavformat can take advantage of it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
104 lines
3.7 KiB
Plaintext
104 lines
3.7 KiB
Plaintext
2ab987ba7bad94b27fae427cdff57723 *tests/data/fate/matroska-opus-remux.matroska
|
|
9355 tests/data/fate/matroska-opus-remux.matroska
|
|
#extradata 0: 19, 0x3a04048f
|
|
#tb 0: 1/1000
|
|
#media_type 0: audio
|
|
#codec_id 0: opus
|
|
#sample_rate 0: 48000
|
|
#channel_layout_name 0: mono
|
|
0, 0, 0, 20, 320, 0x58b9a88d
|
|
0, 21, 21, 20, 159, 0x6c9c4b4c
|
|
0, 41, 41, 20, 148, 0x0caf4b5d
|
|
0, 61, 61, 20, 139, 0xc5624226
|
|
0, 81, 81, 20, 146, 0x633c4937
|
|
0, 101, 101, 20, 153, 0x3d0b4f93
|
|
0, 121, 121, 20, 158, 0xe5c55641
|
|
0, 141, 141, 20, 156, 0xf2fd50ef
|
|
0, 161, 161, 20, 158, 0x93b15410
|
|
0, 181, 181, 20, 157, 0xb6f74f5f
|
|
0, 201, 201, 20, 159, 0x9aff4957
|
|
0, 221, 221, 20, 153, 0xfc5f4aba
|
|
0, 241, 241, 20, 158, 0x01e44f70
|
|
0, 261, 261, 20, 153, 0x227149cf
|
|
0, 281, 281, 20, 155, 0x312f4cf6
|
|
0, 301, 301, 20, 155, 0xafc54bae
|
|
0, 321, 321, 20, 151, 0x7b4252b3
|
|
0, 341, 341, 20, 155, 0x29074a75
|
|
0, 361, 361, 20, 149, 0x82c44bcd
|
|
0, 381, 381, 20, 150, 0x55c24eb5
|
|
0, 401, 401, 20, 156, 0xf71d4f33
|
|
0, 421, 421, 20, 153, 0x9b6c4ae5
|
|
0, 441, 441, 20, 156, 0x75954e51
|
|
0, 461, 461, 20, 155, 0x28ff4ff3
|
|
0, 481, 481, 20, 153, 0xc4424969
|
|
0, 501, 501, 20, 154, 0xfbf94cc8
|
|
0, 521, 521, 20, 155, 0x52c549af
|
|
0, 541, 541, 20, 150, 0x6f1e4b7a
|
|
0, 561, 561, 20, 158, 0xabb45566
|
|
0, 581, 581, 20, 157, 0xe61d4a99
|
|
0, 601, 601, 20, 159, 0xf45d4fac
|
|
0, 621, 621, 20, 159, 0xcd0553a5
|
|
0, 641, 641, 20, 156, 0xdb244e63
|
|
0, 661, 661, 20, 154, 0x78654c52
|
|
0, 681, 681, 20, 154, 0x9f804cc8
|
|
0, 701, 701, 20, 150, 0x1fdf4c80
|
|
0, 721, 721, 20, 155, 0x1adc4f89
|
|
0, 741, 741, 20, 155, 0x4b53511c
|
|
0, 761, 761, 20, 151, 0x8ff2546d
|
|
0, 781, 781, 20, 158, 0xb7e34f1b
|
|
0, 801, 801, 20, 154, 0x4d98474b
|
|
0, 821, 821, 20, 154, 0x14924ea8
|
|
0, 841, 841, 20, 153, 0x8d4752bf
|
|
0, 861, 861, 20, 149, 0x74785066
|
|
0, 881, 881, 20, 151, 0x36c94a4c
|
|
0, 901, 901, 20, 155, 0x82904f3b
|
|
0, 921, 921, 20, 154, 0xd76b4a45
|
|
0, 941, 941, 20, 159, 0x9fec548d
|
|
0, 961, 961, 20, 154, 0x9a084dcd
|
|
0, 981, 981, 20, 155, 0x90a54ac8
|
|
0, 1001, 1001, 20, 324, 0x8e34a2f5
|
|
0, 1021, 1021, 20, 268, 0x10f37203, S=1, 10
|
|
[PACKET]
|
|
codec_type=audio
|
|
stream_index=0
|
|
pts=0
|
|
pts_time=0.000000
|
|
dts=0
|
|
dts_time=0.000000
|
|
duration=20
|
|
duration_time=0.020000
|
|
size=320
|
|
pos=496
|
|
flags=K_
|
|
[/PACKET]
|
|
[PACKET]
|
|
codec_type=audio
|
|
stream_index=0
|
|
pts=21
|
|
pts_time=0.021000
|
|
dts=21
|
|
dts_time=0.021000
|
|
duration=20
|
|
duration_time=0.020000
|
|
size=159
|
|
pos=823
|
|
flags=K_
|
|
[/PACKET]
|
|
[PACKET]
|
|
codec_type=audio
|
|
stream_index=0
|
|
pts=41
|
|
pts_time=0.041000
|
|
dts=41
|
|
dts_time=0.041000
|
|
duration=20
|
|
duration_time=0.020000
|
|
size=148
|
|
pos=989
|
|
flags=K_
|
|
[/PACKET]
|
|
[STREAM]
|
|
codec_name=opus
|
|
initial_padding=312
|
|
[/STREAM]
|