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

[Anton Khirnov]

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.

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?

Anton Khirnov
-------------- 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/986403b9/attachment.pgp>