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

[Yoav Steinberg]

Michael Niedermayer wrote:
> On Thu, Nov 13, 2008 at 06:59:17PM +0200, Yoav Steinberg wrote:
> [...]
>>> 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.
> 
> so, fix the parser

I don't see how the parser can detect such a case. If the tag data is 
inside the frame's data the parser will see a valid frame. It has no way 
(afaik) to check for this specific case at the end of the data either 
since the parser never really knows when the data ends.
The the demuxer in mp3.c on the other hand does know when the data ends. 
So it can check for this case when we reach the last 128 bytes of the 
stream (or for seekable streams, it can avoid it in advance, which is 
way simpler). The logic being that if the demuxer know to avoid sending 
the header to the parser it can also avoid sending the footer (even when 
the footer is seemingly hidden inside a valid mp3 frame).
One other note is that unlike the case of vbr tags being hidden in 
frames, id3v1 tags are located in the last 128 bytes of the file and not 
  on any specific frame boundary, so the parser cannot look into the 
frame data at a specific offset to try to see if there's an id3v1 tag in 
it (and even if it could it would be wrong to do so since the id3v1 
'TAG' marker can be valid data inside a frame).