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

[Michael Niedermayer]

On Mon, Aug 23, 2010 at 04:57:56PM +0200, Anton Khirnov wrote:
> On Mon, Aug 23, 2010 at 03:39:21PM +0200, Michael Niedermayer wrote:
> > 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
> yeah, but these formats also support author1, auth0r, ?????, ??, etc.
> i don't think we'll be able to devise a system that handles them all.

"we cant do all" is no argument to favor "doing none" over "doing 99%"


> 
> luckily we don't have to, as all the formats i know of have a set of
> standard tags that everybody uses => the problem you're proposing
> doesn't exist. or do you have an example of a real existing issue
> related to this?

id3v2 has
composer,performer,lyricist,involved people list,original artist/performer
original lyricist, lead pereformer, publisher

which of these would be mapped to author depends on what of them is set
also if its converted to a format that supports generic tags all information
should be preserved and at the same time standard fields maybe should be
filled like author. After that you have a file that can have author and artist
set
i doubt very much thats the only case where there is no clear mapping, just
look at natural languages there are words that dont translate to exactly one
word. Assuming that this wontg happen with metadata is kinda poor design

[...]
-- 
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/20100824/223ef69b/attachment.pgp>