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.
110678 Commits
37 Branches
400 Tags
465 MiB
Tag: Branch: Tree: 247e977953
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '247e977953'
${ noResults }
FFmpeg/tests/ref/fate/cover-art-mp3-id3v2-remux

55 lines
1.3 KiB
Raw Normal View History Unescape

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.
2 years ago
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>
4 years ago
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.
2 years ago
#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>
4 years ago
#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.
2 years ago
#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>
4 years ago
#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.
2 years ago
#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>
4 years ago
#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.
2 years ago
#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>
4 years ago
#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>
4 years ago
#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>
4 years ago
#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>
4 years ago
#sar 3: 1/1
avformat/framecrcenc: print basic side data information again This partially reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57. Signed-off-by: James Almer <jamrial@gmail.com>
4 years ago
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.
2 years ago
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>
4 years ago
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>
4 years ago
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.
2 years ago
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>
4 years ago
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.
2 years ago
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>
4 years ago
[/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.
2 years ago
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>
4 years ago
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.
2 years ago
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>
4 years ago
[/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>
4 years ago
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>
4 years ago
DISPOSITION:attached_pic=1
TAG:comment=Other
[/STREAM]