[FFmpeg-devel] skip multiple id3v2 headers

Michael Niedermayer michaelni
Wed Sep 15 00:22:10 CEST 2010


On Tue, Sep 14, 2010 at 09:48:25AM -0700, David Byron wrote:
> > the question is why the tags parsing code fails to begin
> > with.  The awnser is because you changed a field to an
> > invalid value with a hex editor, the solution is dont do
> > that.
> 
> It's fine to tell me not to do that, but it's harder to enforce that on the
> entire world of mp3 files.

thats why we try to support files from "Out there" but not files intentionally
created by the patch submitter.

you should once in a while try to change a byte in the ELF header and then try
to get a patch into all ELF utils that work with your new header


> 
> > if the code fails you do NOT know if you are at the end,
> > after the end or in the middle of the frame.
> 
> If you believe the length at the beginning of the frame you do.  In the
> files I've used so far, the length is valid so I believe the length.  If the
> length isn't valid then I'd leave the pointer at the beginning and not try
> to parse any of it.
> 
> > It makes alot of sense to opt toward a earlier position
> > than a later one and let the mp3 parser extract what it
> > can
> 
> I agree with this though I think there's enough information that we don't
> have to guess here.  We know where the id3v2 tag ends.

no you dont
you know parsing the id3v2 tag failed you dont know why it failed.

you only "know" it because you changed one field and not the other by hand.


> 
> > > 2. the code that follows that determines what's mpeg
> > > audio isn't correct since av_read_frame returns a packet
> > > with a bunch of leading zeroes.  I'm fine to work on
> > > this angle as well.
> > 
> > dont waste your time, the code works as it is intended to work.
> 
> The code does not work for my use case, which is....take an mp3 file as
> input and have packet.size and packet.data as reported by av_read_frame
> contain only the audio data from the file.  At the moment it doesn't do
> that.  The docs for av_read_frame currently say:
> 
>  * Return the next frame of a stream.
> 
> Maybe the bug is only in the documentation,

yes, ive fixed that

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100915/899352c1/attachment.pgp>



More information about the ffmpeg-devel mailing list