[FFmpeg-devel] [PATCH 4/8] metadata: add callbacks to conversion system.

[Michael Niedermayer]

On Sun, Aug 22, 2010 at 12:25:51PM +0200, Anton Khirnov wrote:
> On Fri, Jun 04, 2010 at 11:40:03PM +0200, Michael Niedermayer wrote:
> > On Fri, Jun 04, 2010 at 06:57:50AM +0200, Anton Khirnov wrote:
> > > On Fri, Jun 04, 2010 at 01:35:45AM +0200, Michael Niedermayer wrote:
> > > > On Wed, Jun 02, 2010 at 03:16:01PM +0200, Anton Khirnov wrote:
> > > > [...]
> > > > > diff --git a/libavformat/metadata.h b/libavformat/metadata.h
> > > > > index 309147d..24296c4 100644
> > > > > --- a/libavformat/metadata.h
> > > > > +++ b/libavformat/metadata.h
> > > > > @@ -42,6 +42,10 @@ typedef struct AVMetadataConvTable {
> > > > >  
> > > > >  struct AVMetadataConv {
> > > > >      const AVMetadataConvTable *conv_table;
> > > > > +    /** Convert tags from src to generic/native format either a) in place, so they'll pass
> > > > > +     *  through the table next or b) remove them from src and store results in dst. */
> > > > > +    void (*conv2generic)(AVMetadata **src, AVMetadata **dst);
> > > > > +    void (*conv2native)( AVMetadata **src, AVMetadata **dst);
> > > > >  };
> > > > 
> > > > this does not seem very practical, each (de)muxer would just have a blackbox
> > > > convert to/from native and no 2 would be able to work with the same callback.
> > > > The system i suggested where AVMetadataConvTable entries have a convert
> > > > callback could share individual convertion functions like year<->date
> > > > between several (de)muxers. Also it would be less blackboxish as one would
> > > > know which tags are passed unchanged and which are changed
> > > > 
> > > 
> > > I don't think such an approach would solve the problem. First, we need
> > > to be able to merge tags (done by the id3v2 patch) and conversely split
> > > them (e.g. if we wanted to encode id3v2.3). Your concept assumes one
> > > output tag for one input tag and anything else would look like an ugly
> > > hack in it i think. Second, as shown by the matroska patch (convert tags
> > > to uppercase), we want to apply arbitrary transformation to ALL tags,
> > > not just the few ones we know about.
> > > 
> > > OTOH my system doesn't prevent us from factorizing common code into a
> > > function and calling it from several (de)muxers if it's needed.
> > 
> > Your system doesnt solve mapping between author<->artist if the more
> > correct tag is unsupported in the destination format, mine does.
> > and spliting /merging could be done in the muxer/demuxer
> > 
> > i dont mind a system like yours if it supported author<->artist and
> > any other issue we are aware of
> > 
> 
> What do you mean by that? I'm not aware of any formats that define both
> artist _and_ author tags and give them different meanings. And if they
> have identical meaning, the conversion table solves that.

any format that supports tags in form of string=string supports both
iam sure there are quite a few

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/20100823/15c5d8bf/attachment.pgp>