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

[Yoav Steinberg]

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.