virtualenv/FFmpeg
1
0
Fork 0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-23 12:43:46 +02:00
Code Issues Releases Activity
326cc01de9
FFmpeg/tests/ref/fate/ffmpeg-streamloop-transcode-av

152 lines
8.2 KiB
Plaintext
Raw Normal View History

tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
#tb 0: 125/2997
#media_type 0: video
#codec_id 0: rawvideo
#dimensions 0: 1280x718
#sar 0: 1/1
#tb 1: 1/48000
#media_type 1: audio
#codec_id 1: pcm_s32le
#sample_rate 1: 48000
#channel_layout_name 1: stereo
0, 0, 0, 1, 1378560, 0xbaf121ba
1, 0, 0, 1024, 8192, 0x00000000
1, 1024, 1024, 1024, 8192, 0x00000000
0, 1, 1, 1, 1378560, 0xbaf121ba
1, 2040, 2040, 1024, 8192, 0x00000000
1, 3048, 3048, 1024, 8192, 0x00000000
0, 2, 2, 1, 1378560, 0x6579d31a
1, 4072, 4072, 1024, 8192, 0x00000000
1, 5096, 5096, 1024, 8192, 0x00000000
0, 3, 3, 1, 1378560, 0xca1deba8
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 6120, 6120, 1024, 8192, 0x00000000
1, 7128, 7128, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 4, 4, 1, 1378560, 0xd4eed467
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 8208, 8208, 1024, 8192, 0x00000000
1, 9232, 9232, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 5, 5, 1, 1378560, 0xd6e1d5b7
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 10248, 10248, 1024, 8192, 0x00000000
1, 11256, 11256, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 6, 6, 1, 1378560, 0x0b574d39
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 12280, 12280, 1024, 8192, 0x00000000
1, 13304, 13304, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 7, 7, 1, 1378560, 0x1bdd4d61
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 14328, 14328, 1024, 8192, 0x00000000
1, 15336, 15336, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 8, 8, 1, 1378560, 0x3b28f549
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 16360, 16360, 1024, 8192, 0x00000000
1, 17384, 17384, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 9, 9, 1, 1378560, 0x45b2f57b
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 18408, 18408, 1024, 8192, 0x00000000
1, 19416, 19416, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 10, 10, 1, 1378560, 0x8955570e
tests/fate/ffmpeg: silence the audio for fate-ffmpeg-streamloop-transcode-av Fixed-point AAC decoder currently does not produce the same output on all platforms. Until that is fixed, silence the audio stream using the volume filter. Also, actually use the aac_fixed decoder as was the original intent.
2023-06-19 15:32:27 +02:00
1, 20440, 20440, 1024, 8192, 0x00000000
1, 21464, 21464, 1024, 8192, 0x00000000
1, 22488, 22488, 1024, 8192, 0x00000000
1, 23496, 23496, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 12, 12, 1, 1378560, 0x9c598000
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 25536, 25536, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 13, 13, 1, 1378560, 0xbaf121ba
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 26560, 26560, 1024, 8192, 0x00000000
1, 27576, 27576, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 14, 14, 1, 1378560, 0xbaf121ba
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 28600, 28600, 1024, 8192, 0x00000000
1, 29624, 29624, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 15, 15, 1, 1378560, 0x6579d31a
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 30648, 30648, 1024, 8192, 0x00000000
1, 31656, 31656, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 16, 16, 1, 1378560, 0xca1deba8
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 32736, 32736, 1024, 8192, 0x00000000
1, 33760, 33760, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 17, 17, 1, 1378560, 0xd4eed467
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 34776, 34776, 1024, 8192, 0x00000000
1, 35784, 35784, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 18, 18, 1, 1378560, 0xd6e1d5b7
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 36808, 36808, 1024, 8192, 0x00000000
1, 37832, 37832, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 19, 19, 1, 1378560, 0x0b574d39
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 38856, 38856, 1024, 8192, 0x00000000
1, 39864, 39864, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 20, 20, 1, 1378560, 0x1bdd4d61
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 40888, 40888, 1024, 8192, 0x00000000
1, 41912, 41912, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 21, 21, 1, 1378560, 0x3b28f549
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 42936, 42936, 1024, 8192, 0x00000000
1, 43944, 43944, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 22, 22, 1, 1378560, 0x45b2f57b
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 44968, 44968, 1024, 8192, 0x00000000
1, 45992, 45992, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 23, 23, 1, 1378560, 0x8955570e
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 47016, 47016, 1024, 8192, 0x00000000
1, 48024, 48024, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 24, 24, 1, 1378560, 0x9c598000
0, 25, 25, 1, 1378560, 0xbaf121ba
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 50064, 50064, 1024, 8192, 0x00000000
1, 51088, 51088, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 26, 26, 1, 1378560, 0xbaf121ba
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 52104, 52104, 1024, 8192, 0x00000000
1, 53128, 53128, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 27, 27, 1, 1378560, 0x6579d31a
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 54152, 54152, 1024, 8192, 0x00000000
1, 55176, 55176, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 28, 28, 1, 1378560, 0xca1deba8
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 56184, 56184, 1024, 8192, 0x00000000
1, 57264, 57264, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 29, 29, 1, 1378560, 0xd4eed467
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 58288, 58288, 1024, 8192, 0x00000000
1, 59304, 59304, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 30, 30, 1, 1378560, 0xd6e1d5b7
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 60312, 60312, 1024, 8192, 0x00000000
1, 61336, 61336, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 31, 31, 1, 1378560, 0x0b574d39
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 62360, 62360, 1024, 8192, 0x00000000
1, 63384, 63384, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 32, 32, 1, 1378560, 0x1bdd4d61
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 64392, 64392, 1024, 8192, 0x00000000
1, 65416, 65416, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 33, 33, 1, 1378560, 0x3b28f549
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 66440, 66440, 1024, 8192, 0x00000000
1, 67464, 67464, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 34, 34, 1, 1378560, 0x45b2f57b
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 68472, 68472, 1024, 8192, 0x00000000
1, 69496, 69496, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 35, 35, 1, 1378560, 0x8955570e
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 70520, 70520, 1024, 8192, 0x00000000
1, 71544, 71544, 1024, 8192, 0x00000000
1, 72552, 72552, 1024, 8192, 0x00000000
0, 37, 37, 1, 1378560, 0x9c598000
1, 74592, 74592, 1024, 8192, 0x00000000
1, 75616, 75616, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 38, 38, 1, 1378560, 0xbaf121ba
fftools/ffmpeg: rework keeping track of file duration for -stream_loop Current code tracks min/max pts for each stream separately; then when the file ends it combines them with last frame's duration to compute the total duration of each stream; finally it selects the longest of those durations as the file duration. This is incorrect - the total file duration is the largest timestamp difference between any frames, regardless of the stream. Also change the way the last frame information is reported from decoders to the muxer - previously it would be just the last frame's duration, now the end timestamp is sent, which is simpler. Changes the result of the fate-ffmpeg-streamloop-transcode-av test, where the timestamps are shifted slightly forward. Note that the matroska demuxer does not return the first audio packet after seeking (due to buggy interaction betwen the generic code and the demuxer), so there is a gap in audio.
2023-10-11 17:43:51 +02:00
1, 76632, 76632, 1024, 8192, 0x00000000
1, 77656, 77656, 1024, 8192, 0x00000000
0, 39, 39, 1, 1378560, 0xbaf121ba
1, 78680, 78680, 1024, 8192, 0x00000000
1, 79704, 79704, 1024, 8192, 0x00000000
0, 40, 40, 1, 1378560, 0x6579d31a
1, 80712, 80712, 1024, 8192, 0x00000000
1, 81792, 81792, 1024, 8192, 0x00000000
0, 41, 41, 1, 1378560, 0xca1deba8
1, 82816, 82816, 1024, 8192, 0x00000000
1, 83832, 83832, 1024, 8192, 0x00000000
0, 42, 42, 1, 1378560, 0xd4eed467
1, 84840, 84840, 1024, 8192, 0x00000000
1, 85864, 85864, 1024, 8192, 0x00000000
0, 43, 43, 1, 1378560, 0xd6e1d5b7
1, 86888, 86888, 1024, 8192, 0x00000000
1, 87912, 87912, 1024, 8192, 0x00000000
0, 44, 44, 1, 1378560, 0x0b574d39
1, 88920, 88920, 1024, 8192, 0x00000000
1, 89944, 89944, 1024, 8192, 0x00000000
0, 45, 45, 1, 1378560, 0x1bdd4d61
1, 90968, 90968, 1024, 8192, 0x00000000
1, 91992, 91992, 1024, 8192, 0x00000000
0, 46, 46, 1, 1378560, 0x3b28f549
1, 93000, 93000, 1024, 8192, 0x00000000
1, 94024, 94024, 1024, 8192, 0x00000000
0, 47, 47, 1, 1378560, 0x45b2f57b
1, 95048, 95048, 1024, 8192, 0x00000000
1, 96072, 96072, 1024, 8192, 0x00000000
0, 48, 48, 1, 1378560, 0x8955570e
1, 97080, 97080, 1024, 8192, 0x00000000
tests/fate: add a test for -streamloop with transcoding video+audio
2023-06-02 21:26:52 +02:00
0, 49, 49, 1, 1378560, 0x9c598000
Reference in New Issue Copy Permalink