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
544631cab1
FFmpeg/tests/ref/fate/cover-art-mp3-id3v2-remux

56 lines
1.3 KiB
Plaintext
Raw Normal View History

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
c1b55a9a92226cd72d3f53ccd830d127 *tests/data/fate/cover-art-mp3-id3v2-remux.mp3
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 0: 3
#channel_layout_name 0: stereo
#tb 1: 1/90000
#media_type 1: 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 1: 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 1: 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 1: 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 2: 1/90000
#media_type 2: video
#codec_id 2: bmp
#dimensions 2: 263x263
#sar 2: 0/1
#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
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, -353590, -353590, 368640, 417, 0x15848290, S=1, 10, 0x034e0055
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
1, 0, 0, 0, 15760, 0x71d5c418
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
2, 0, 0, 0, 208350, 0x291b44d1
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
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=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
TAG:comment=Other
[/STREAM]
[STREAM]
index=2
codec_name=bmp
DISPOSITION:attached_pic=1
TAG:comment=Band/Orchestra
[/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