[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