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

Anton Khirnov wyskas
Sun Aug 22 12:25:51 CEST 2010


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.

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/20100822/48021e21/attachment.pgp>



More information about the ffmpeg-devel mailing list