virtualenv/FFmpeg
1
0
Fork 0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-12 19:18:44 +02:00
Code Issues Releases Activity
84e669167d
FFmpeg/tests/ref/fate/cover-art-mp3-id3v2-remux

55 lines
1.3 KiB
Plaintext
Raw Normal View History

fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
94946f0efd5f9bb0061ac1fbff7d731f *tests/data/fate/cover-art-mp3-id3v2-remux.mp3
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
399346 tests/data/fate/cover-art-mp3-id3v2-remux.mp3
#tb 0: 1/14112000
#media_type 0: audio
#codec_id 0: mp3
#sample_rate 0: 44100
#channel_layout_name 0: stereo
#tb 1: 1/90000
#media_type 1: video
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
#codec_id 1: bmp
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
#dimensions 1: 263x263
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
#sar 1: 0/1
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
#tb 2: 1/90000
#media_type 2: video
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
#codec_id 2: mjpeg
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
#dimensions 2: 263x263
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
#sar 2: 96/96
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
#tb 3: 1/90000
#media_type 3: video
avformat/id3v2: Don't reverse the order of id3v2 APICs When parsing ID3v2 tags, special (non-text) metadata is not applied directly and unconditionally; instead it is stored in a linked list in which elements are prepended. When traversing the list to add APICs (or private tags) at the end, the order is reversed. The same also happens for chapters and therefore the chapter parsing code already reverses the chapters. This commit changes this: By keeping pointers to both head and tail of the linked list one can preserve the order of the entries and remove the reordering code for chapters. Only the pointer to head will be exported: No current caller uses a nonempty list, so exporting both head and tail is unnecessary. This removes the functionality to combine the lists of special metadata read from different ID3v2 tags, but that doesn't make really much sense anyway (and would be trivial to implement if desired) and allows to remove the now unnecessary initializations performed by the callers. The FATE-reference for the id3v2-priv test had to be updated because the order of the tags read into the dict is reversed; for id3v2-priv-remux only the md5 and not the ffprobe output of the remuxed file changes because the order of the private tags has up until now been reversed twice. The references for the aiff/mp3 cover-art tests needed to be updated, because the order of the attached pics is reversed upon reading. It is still not correct, because the muxers write the pics in the order in which they arrive at the muxer instead of the order given by pkt->stream_index. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-13 01:24:03 +02:00
#codec_id 3: png
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
#dimensions 3: 263x263
avformat/id3v2: Don't reverse the order of id3v2 APICs When parsing ID3v2 tags, special (non-text) metadata is not applied directly and unconditionally; instead it is stored in a linked list in which elements are prepended. When traversing the list to add APICs (or private tags) at the end, the order is reversed. The same also happens for chapters and therefore the chapter parsing code already reverses the chapters. This commit changes this: By keeping pointers to both head and tail of the linked list one can preserve the order of the entries and remove the reordering code for chapters. Only the pointer to head will be exported: No current caller uses a nonempty list, so exporting both head and tail is unnecessary. This removes the functionality to combine the lists of special metadata read from different ID3v2 tags, but that doesn't make really much sense anyway (and would be trivial to implement if desired) and allows to remove the now unnecessary initializations performed by the callers. The FATE-reference for the id3v2-priv test had to be updated because the order of the tags read into the dict is reversed; for id3v2-priv-remux only the md5 and not the ffprobe output of the remuxed file changes because the order of the private tags has up until now been reversed twice. The references for the aiff/mp3 cover-art tests needed to be updated, because the order of the attached pics is reversed upon reading. It is still not correct, because the muxers write the pics in the order in which they arrive at the muxer instead of the order given by pkt->stream_index. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-13 01:24:03 +02:00
#sar 3: 1/1
avformat/framecrcenc: print basic side data information again This partially reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57. Signed-off-by: James Almer <jamrial@gmail.com>
2021-05-11 22:07:41 +02:00
0, -353590, -353590, 368640, 417, 0x15848290, S=1, 10
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
1, 0, 0, 0, 208350, 0x291b44d1
2, 0, 0, 0, 15760, 0x71d5c418
avformat/id3v2: Don't reverse the order of id3v2 APICs When parsing ID3v2 tags, special (non-text) metadata is not applied directly and unconditionally; instead it is stored in a linked list in which elements are prepended. When traversing the list to add APICs (or private tags) at the end, the order is reversed. The same also happens for chapters and therefore the chapter parsing code already reverses the chapters. This commit changes this: By keeping pointers to both head and tail of the linked list one can preserve the order of the entries and remove the reordering code for chapters. Only the pointer to head will be exported: No current caller uses a nonempty list, so exporting both head and tail is unnecessary. This removes the functionality to combine the lists of special metadata read from different ID3v2 tags, but that doesn't make really much sense anyway (and would be trivial to implement if desired) and allows to remove the now unnecessary initializations performed by the callers. The FATE-reference for the id3v2-priv test had to be updated because the order of the tags read into the dict is reversed; for id3v2-priv-remux only the md5 and not the ffprobe output of the remuxed file changes because the order of the private tags has up until now been reversed twice. The references for the aiff/mp3 cover-art tests needed to be updated, because the order of the attached pics is reversed upon reading. It is still not correct, because the muxers write the pics in the order in which they arrive at the muxer instead of the order given by pkt->stream_index. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-13 01:24:03 +02:00
3, 0, 0, 0, 165671, 0x7c1c8070
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
0, 15050, 15050, 368640, 418, 0x46f684a4
0, 383690, 383690, 368640, 418, 0x46f684a4
0, 752330, 752330, 368640, 418, 0x46f684a4
0, 1120970, 1120970, 368640, 418, 0x46f684a4
[STREAM]
index=0
codec_name=mp3
DISPOSITION:attached_pic=0
TAG:encoder=Lavf
[/STREAM]
[STREAM]
index=1
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
codec_name=bmp
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
DISPOSITION:attached_pic=1
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
TAG:comment=Band/Orchestra
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
[/STREAM]
[STREAM]
index=2
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
codec_name=mjpeg
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
DISPOSITION:attached_pic=1
fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
2023-04-26 10:51:38 +02:00
TAG:comment=Other
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
[/STREAM]
[STREAM]
index=3
avformat/id3v2: Don't reverse the order of id3v2 APICs When parsing ID3v2 tags, special (non-text) metadata is not applied directly and unconditionally; instead it is stored in a linked list in which elements are prepended. When traversing the list to add APICs (or private tags) at the end, the order is reversed. The same also happens for chapters and therefore the chapter parsing code already reverses the chapters. This commit changes this: By keeping pointers to both head and tail of the linked list one can preserve the order of the entries and remove the reordering code for chapters. Only the pointer to head will be exported: No current caller uses a nonempty list, so exporting both head and tail is unnecessary. This removes the functionality to combine the lists of special metadata read from different ID3v2 tags, but that doesn't make really much sense anyway (and would be trivial to implement if desired) and allows to remove the now unnecessary initializations performed by the callers. The FATE-reference for the id3v2-priv test had to be updated because the order of the tags read into the dict is reversed; for id3v2-priv-remux only the md5 and not the ffprobe output of the remuxed file changes because the order of the private tags has up until now been reversed twice. The references for the aiff/mp3 cover-art tests needed to be updated, because the order of the attached pics is reversed upon reading. It is still not correct, because the muxers write the pics in the order in which they arrive at the muxer instead of the order given by pkt->stream_index. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-13 01:24:03 +02:00
codec_name=png
fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2021-04-10 21:20:00 +02:00
DISPOSITION:attached_pic=1
TAG:comment=Other
[/STREAM]
Reference in New Issue Copy Permalink