[FFmpeg-devel] [PATCH] metadata conversion API
Michael Niedermayer
michaelni
Thu Feb 26 04:35:17 CET 2009
On Thu, Feb 26, 2009 at 02:49:01AM +0100, Aurelien Jacobs wrote:
> Michael Niedermayer wrote:
>
> > On Thu, Feb 26, 2009 at 02:13:51AM +0100, Aurelien Jacobs wrote:
> > > Hi,
> > >
> > > There is one last and important issue I want to address with the new
> > > metadata API.
> > > Old API allowed client apps and muxers to get a few select well known
> > > tags (title, author...). With the new API, there is no simple way to
> > > do that, right now. For example, if you demux an ASF file, and want to
> > > get the name of the album, av_metadata_get(..., "album", ...) won't
> > > give you any results, because ASF stores this information in a tag
> > > named "AlbumTitle". There are lots of examples with various demuxers,
> > > even for simple common tags. This also prevent correct remuxing between
> > > different containers.
> > >
> > > One simple solution would be to force any demuxers to export their tags
> > > respecting a well defined list of known common key names (for all tags
> > > that have a corresponding common name). But this have issues which makes
> > > this impractical. It looses information. The client app can't retrieve
> > > the actual key names used in the original file. And this would prevent
> > > lossless remuxing in the same container.
> > >
> > > So I built up another solution. The principle is to allows (de)muxers
> > > to associate a conversion table to a AVMetadata. This table describe
> > > the correspondence between the native format key names and the generic
> > > common key names. Then with this conversion table,
> > > av_metadata_get(..., "album", ...) is able to get the native tag
> > > corresponding the the generic "album" key. And a muxer is able to
> > > convert a whole AVMetadata to it's own native format.
> > >
> > > First patch implements this conversion table API.
> > > Second patch just shows a simple example of usage of this API (yes
> > > I know it duplicates the ff_asf_metadata_conv table and I don't
> > > intend to apply it as is, it's only a simple incomplete and unclean
> > > example for now).
> > >
> > > Also note the the av_metadata_get_conv() function which may look useless
> > > in this patch set, is in fact required for applications such as ffmpeg,
> > > to "copy" the conv table from input format ctx to output format ctx.
> > >
> > > And finally, here is a concrete example of what this API allows. A simple
> > > stream copy of those Matroska tags:
> > > LEAD_PERFORMER: Tori Amos
> > > ALBUM: Under the Pink
> > > generates the following ASF tags:
> > > AlbumArtist: Tori Amos
> > > AlbumTitle: Under the Pink
> >
> > IMHO The correct way to implement such conversion table is
> > by adding it to AVInputFormat & AVOutputFormat
> > and adding a simple av_metadata_conv() that takes the input metadata and
> > both tables to produce outpt metadata.
> > Thi convertion, which is just a single line of code would be called by the
> > user app.
> > muxers would only store exactly the metadata tags given to them and demuxers
> > would only read exactly the metadata tags, convertion would be entirely
> > outside of them.
>
> I've thought about this possibility too. But then, do you think we should also
> add a conversion table to AVStream, AVChapter, etc... ?
> We may need to have a conversion table to handle their metadata in a different
> way than the main metadata...
I think the table should be opaque to the user app (for the momemt, the details
can be exported later when they have stabilized)
and could contain AVStream/AVChapter information, it could even contain more
complex translation info, i mean theres no guarantee for a 1:1 mapping
for example one format might store per stream authors, while the other might
support only per file authors the convertion code could together with these
tables convert between these 2.
Key point here is to keep the complexity out of the (de)muxers, we also dont
do colorspace convertion in (de/en)coders
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/20090226/6886317e/attachment.pgp>
More information about the ffmpeg-devel
mailing list