[FFmpeg-devel] [PATCH] set metadata conv tables at runtime
Thu Nov 12 13:33:15 CET 2009
On Thu, Nov 12, 2009 at 10:49:08AM +0100, Anton Khirnov wrote:
> On Thu, Nov 12, 2009 at 09:57:00AM +0100, Michael Niedermayer wrote:
> > On Thu, Nov 12, 2009 at 06:34:15AM +0100, Anton Khirnov wrote:
> > > On Wed, Nov 11, 2009 at 11:55:53PM +0100, Michael Niedermayer wrote:
> > > >
> > > > and where is the incompatibility?
> > > > the demuxer surely wont have a problem with having both 3 char and 4 char
> > > > in its array, also TYER+TDAT+TDRL dont seem to have anything incompatible
> > > > on them.
> > > >
> > > yes, the problem would be making a conversion table for all 3 versions.
> > > it'd be unnecessarily long
> > I dont see that effect, 3 tables or 1 table containing the entries of 3
> > should be the same size
> yes, but conversion would be slightly slower with big table =p
> (btw what is the intented behavior when the table contains duplicate
id say pick the first that matches
> anyway, if your point is that this patch is not needed for correct
> demuxing of id3v2, you're completely right, i've written it primarily
> for files that can contain completely different metadata formats and
for muxing if we really want to support several versions of id3 that could
be done with dummy muxers or by changing tags simply by C code in the muxer
or a system like yours but ATM i feel that this could as well be done once
we do have an actual use case that needs it.
For example it would be alot nicer if mp3s+id3s generated by ffmpeg work
on all players instead of having to make some version decission during muxing
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel