[PATCH] avformat/demux: avoid unconditional ID3v2 tag consumption
I have found a few instances of rawvideo files that coincidentally start with a header matching the ID3v2 header format, and ffmpeg consumes the header before demuxing, causing a decoding error. This happens even if "-f rawvideo" is specified. This patch limits the formats for which this automatic consuming of ID3v2 headers is done. Note: I am not an expert in ID3v2 by any means, and I'm happy to accept suggestions, both on the scope and mechanism of the solution. To reproduce, you can easily generate an example as follows: ``` ( echo "49 44 33 2B 98 3A 49 44 33 2B 98 3A 6A 44 54 2B" | xxd -r -p dd if=/dev/zero bs=1 count=115184 2>/dev/null ) > id3v2_320x240_yuv420p.yuv ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -i id3v2_320x240_yuv420p.yuv -f null - ``` This generates a 320x240 yuv420p file with a 16-byte header that matches the ID3v2 header format (this was copied from a real case I saw) and completed with zeroes for a total of 115200 bytes, the right size for this resolution and pixel format. On the master branch, I see: ``` [...] ID3v2.43 tag skipped, cannot handle version [...] [out#0/null @ 0x15700a6e0] Output file is empty, nothing was encoded(check -ss / -t / -frames parameters if used) frame= 0 fps=0.0 q=0.0 Lsize=N/A time=N/A bitrate=N/A speed=N/A ``` After the changes: it decodes as expected. ``` [...] frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=16.5x elapsed=0:00:00.00 ``` Thanks in advance, Nil
Hi, Pinging this patch from a couple weeks ago. To be clear, I am not sure how people typically use ffmpeg's ID3v2 support, so please let me know if the patch is missing something and I'm happy to iterate on it, but it does seem to me that trying to parse it from rawvideo inputs is wrong. Thank you, Nil On Tue, Jul 8, 2025 at 6:07 PM Nil Fons Miret <nilf@netflix.com> wrote:
I have found a few instances of rawvideo files that coincidentally start with a header matching the ID3v2 header format, and ffmpeg consumes the header before demuxing, causing a decoding error. This happens even if "-f rawvideo" is specified.
This patch limits the formats for which this automatic consuming of ID3v2 headers is done. Note: I am not an expert in ID3v2 by any means, and I'm happy to accept suggestions, both on the scope and mechanism of the solution.
To reproduce, you can easily generate an example as follows:
``` ( echo "49 44 33 2B 98 3A 49 44 33 2B 98 3A 6A 44 54 2B" | xxd -r -p dd if=/dev/zero bs=1 count=115184 2>/dev/null ) > id3v2_320x240_yuv420p.yuv
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -i id3v2_320x240_yuv420p.yuv -f null - ```
This generates a 320x240 yuv420p file with a 16-byte header that matches the ID3v2 header format (this was copied from a real case I saw) and completed with zeroes for a total of 115200 bytes, the right size for this resolution and pixel format.
On the master branch, I see: ``` [...] ID3v2.43 tag skipped, cannot handle version [...] [out#0/null @ 0x15700a6e0] Output file is empty, nothing was encoded(check -ss / -t / -frames parameters if used) frame= 0 fps=0.0 q=0.0 Lsize=N/A time=N/A bitrate=N/A speed=N/A ```
After the changes: it decodes as expected. ``` [...] frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=16.5x elapsed=0:00:00.00 ```
Thanks in advance, Nil
Hi, On Wed, Jul 23, 2025 at 10:51 AM Nil Fons Miret via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Pinging this patch from a couple weeks ago. To be clear, I am not sure how people typically use ffmpeg's ID3v2 support, so please let me know if the patch is missing something and I'm happy to iterate on it, but it does seem to me that trying to parse it from rawvideo inputs is wrong.
Anyone interested in testing this? Please see Nil's repro steps above. Otherwise, I'll merge this sometime next week. Thanks, Kyle
On Wed, Aug 20, 2025 at 2:09 PM Kyle Swanson <k@ylo.ph> wrote:
Hi,
On Wed, Jul 23, 2025 at 10:51 AM Nil Fons Miret via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Pinging this patch from a couple weeks ago. To be clear, I am not sure how people typically use ffmpeg's ID3v2 support, so please let me know if the patch is missing something and I'm happy to iterate on it, but it does seem to me that trying to parse it from rawvideo inputs is wrong.
Anyone interested in testing this? Please see Nil's repro steps above. Otherwise, I'll merge this sometime next week.
Will push tomorrow, thanks.
Hi, On Tue, Sep 2, 2025 at 9:41 AM Kyle Swanson <k@ylo.ph> wrote:
On Wed, Aug 20, 2025 at 2:09 PM Kyle Swanson <k@ylo.ph> wrote:
Hi,
On Wed, Jul 23, 2025 at 10:51 AM Nil Fons Miret via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Pinging this patch from a couple weeks ago. To be clear, I am not sure how people typically use ffmpeg's ID3v2 support, so please let me know if the patch is missing something and I'm happy to iterate on it, but it does seem to me that trying to parse it from rawvideo inputs is wrong.
Anyone interested in testing this? Please see Nil's repro steps above. Otherwise, I'll merge this sometime next week.
Will push tomorrow, thanks.
Pushed. Thanks, Kyle
On Wed, Sep 3, 2025 at 11:11 AM Kyle Swanson via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Hi,
On Tue, Sep 2, 2025 at 9:41 AM Kyle Swanson <k@ylo.ph> wrote:
On Wed, Aug 20, 2025 at 2:09 PM Kyle Swanson <k@ylo.ph> wrote:
Hi,
On Wed, Jul 23, 2025 at 10:51 AM Nil Fons Miret via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Pinging this patch from a couple weeks ago. To be clear, I am not sure how people typically use ffmpeg's ID3v2 support, so please let me know if the patch is missing something and I'm happy to iterate on it, but it does seem to me that trying to parse it from rawvideo inputs is wrong.
Anyone interested in testing this? Please see Nil's repro steps above. Otherwise, I'll merge this sometime next week.
Will push tomorrow, thanks.
Pushed.
Thanks, Kyle
Hi, Sorry for the late reply. From reading the patch, it seems like this dropped ID3v2 parsing for the wav format and unintentionally applied it to w64 instead (w64 happens to be at the end of wavdec.c, after the wav demuxer):
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index c65e0a2723..4c47a5f05c 100644 --- a/libavformat/wavdec.c +++ b/libavformat/wavdec.c @@ -1011,7 +1011,7 @@ static const AVClass w64_demuxer_class = { const FFInputFormat ff_w64_demuxer = { .p.name = "w64", .p.long_name = NULL_IF_CONFIG_SMALL("Sony Wave64"), - .p.flags = AVFMT_GENERIC_INDEX, + .p.flags = AVFMT_GENERIC_INDEX | AVFMT_FLAG_ID3V2_AUTO,
This was changed to flags_internal = FF_INFMT_FLAG_ID3V2_AUTO in a later patch, but the same issue persists (it's applied to w64 rather than wav). Probably this ought to be applied to the wav demuxer and removed from w64 (and maybe backported to 8.1?) It would also be nice to have a sample of such a file in FATE so testing could catch this sort of thing. Thanks, -- Daniel
Hi Daniel, thank you for reporting this. You are correct that I meant to set it for the wav format. I've put up a pull request to fix it: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23762. Agreed with backporting the fix to 8.1 once it is accepted. Thanks, Nil On Fri, Jul 10, 2026 at 4:14 AM Daniel Verkamp via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
On Wed, Sep 3, 2025 at 11:11 AM Kyle Swanson via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Hi,
On Tue, Sep 2, 2025 at 9:41 AM Kyle Swanson <k@ylo.ph> wrote:
On Wed, Aug 20, 2025 at 2:09 PM Kyle Swanson <k@ylo.ph> wrote:
Hi,
On Wed, Jul 23, 2025 at 10:51 AM Nil Fons Miret via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Pinging this patch from a couple weeks ago. To be clear, I am not sure how people typically use ffmpeg's ID3v2 support, so please let me know if the patch is missing something and I'm happy to iterate on it, but it does seem to me that trying to parse it from rawvideo inputs is wrong.
Anyone interested in testing this? Please see Nil's repro steps above. Otherwise, I'll merge this sometime next week.
Will push tomorrow, thanks.
Pushed.
Thanks, Kyle
Hi,
Sorry for the late reply. From reading the patch, it seems like this dropped ID3v2 parsing for the wav format and unintentionally applied it to w64 instead (w64 happens to be at the end of wavdec.c, after the wav demuxer):
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index c65e0a2723..4c47a5f05c 100644 --- a/libavformat/wavdec.c +++ b/libavformat/wavdec.c @@ -1011,7 +1011,7 @@ static const AVClass w64_demuxer_class = { const FFInputFormat ff_w64_demuxer = { .p.name = "w64", .p.long_name = NULL_IF_CONFIG_SMALL("Sony Wave64"), - .p.flags = AVFMT_GENERIC_INDEX, + .p.flags = AVFMT_GENERIC_INDEX | AVFMT_FLAG_ID3V2_AUTO,
This was changed to flags_internal = FF_INFMT_FLAG_ID3V2_AUTO in a later patch, but the same issue persists (it's applied to w64 rather than wav).
Probably this ought to be applied to the wav demuxer and removed from w64 (and maybe backported to 8.1?)
It would also be nice to have a sample of such a file in FATE so testing could catch this sort of thing.
Thanks, -- Daniel _______________________________________________ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
participants (3)
-
Daniel Verkamp -
Kyle Swanson -
Nil Fons Miret