[FFmpeg-devel] [PATCH] set metadata conv tables at runtime

[Michael Niedermayer]

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
> values?)

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
> muxing.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091112/258cc441/attachment.pgp>