[FFmpeg-devel] skip multiple id3v2 headers

Michael Niedermayer michaelni
Thu Sep 9 15:05:57 CEST 2010

On Thu, Sep 09, 2010 at 05:31:30AM -0700, David Byron wrote:
> Michael Niedermayer wrote:
> > > could you explain what kind of conflict exists in there?
> > > Its easier for discussion as you alraedy know than if
> > > all interrested parties download the file and have to
> > > analyze it
> My primary concern isn't the actual metadata, though maybe it should be.
> I'm concerned that av_read_frame returns packets that don't contain audio
> data.  From this perspective it doesn't matter whether the additional id3v2
> tags are parsed or not, and it seems simpler not to.  That's also what
> ffmpeg does today so it seems like a good first step.

if you want to see a patch applied
that skips half of the metadata such thing must be justified and shown to
be neccessary compared to parsing all metadata which is also simpler in code.
and no i dont care what is closer to current buggy behavior.

> > well, the tags could have differing artist/album/title
> > etc.

they could, they also could be equal or could be missing in one but not
the other header, they also could be wrong or even contain the next lottery

> > field, which one should ffmpeg chose? Or export both
> > sets?

until we have samples that have conflicts (i asked) or understand what tools
generate such files under which circumstances its not easy to say what to do
but skiping existing data seems wrong to me

> >
> > One "rule" could be to pick up as much from all tags, but
> > favoring earlier tags over later.
> Yes, but to me this is complicated.  Since ffmpeg doesn't look at the

i see nothing complicated on it but i see your patch contains complicated code
that is just there to avoid parsing them, and that code is what i do not like
to accept without knowing why aka an actual case that needs it

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/20100909/561553f0/attachment.pgp>

More information about the ffmpeg-devel mailing list