[FFmpeg-devel] [PATCH] fixes in mpeg audio parsing
Yoav Steinberg
yoav
Thu Nov 13 20:10:41 CET 2008
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).
More information about the ffmpeg-devel
mailing list