[FFmpeg-devel] [PATCH] fixes in mpeg audio parsing

Yoav Steinberg yoav
Thu Nov 13 17:59:17 CET 2008

Michael Niedermayer wrote:
>> It _might_ be possible to change read_packet to always buffer the last 
>> 128 bytes of data and return them with a delay after more data is 
>> available. 
> Thats no "might", thats certainly possible. But thats not what i mean.
> First why do you not detect the id3v1 tag? i mean check if there is a mp3
> frame or a id3v1 tag by looking at the header.

The last 128 bytes of the file contain the tag (if there is a tag). This 
means that without looking at those bytes you cannot know if there's a 
tag available. That's why the existing code does not attempt to check 
for such a tag on non seekable streams.

> One certainly could have concatenated 2 mp3 files with a id3v1 ending in
> the middle it would be nice if the parser & decoder would skip/ignore this
> trash in the middle.
> To me it seem that it shouldnt be too hard to make the parser skip
> this, unless a valid id3v1 tag can also be a valid mp3 frame.

The current parser will, in most cases, skip id3v1 tags in the stream 
which is good. But in one case the parser does actually think the tag is 
part of a frame and does not skip it. This is when the tag was put 
inside (overwriting) a frame's data. This isn't strictly valid, but it 
turns out there are such files out there.

More information about the ffmpeg-devel mailing list