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

Michael Niedermayer michaelni
Fri Jun 4 23:40:03 CEST 2010


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

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/20100604/4b6ed335/attachment.pgp>



More information about the ffmpeg-devel mailing list