[FFmpeg-devel] [PATCH] metadata conversion API

[Michael Niedermayer]

On Fri, Feb 27, 2009 at 03:29:49PM -0800, Baptiste Coudurier wrote:
> On 2/25/2009 5:13 PM, 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.
> 
> First, thanks for your work Aurel, this is greatly appreciated.
> 
> I have a few ideas:

> Would it be possible to also export container information as "metadata" ?
> Like aspect ratio, width, height. This would avoid duplicating fields
> from AVCodecContext, and make this information available as a simple way
> to user wanting for example to use libavformat to retrieve media
> information.

this has 2 very serious flaws
1. if the mov demuxer injects width&height metadata then the next muxer will
   mux this metadata while its container width/height will no longer match
   remux that back to mov with a differnt tool and you have a mess ...
2. what is the container width & height? Do you have a clear container
   independant definition? if not what use is it for an application?
   each app would need code like
   if(demuxer == mov && codec == H263)
       croping.width = get_metadata("container_width");
       croping.height= get_metadata("container_height");
   and i suspect above is not correct anyway but rather mov stores alot
   of parameters that define how to rotate sheer, squeeze, crush slice, dice
   crop and scale an image and the mov demuxer really should export these
   or part of them instead of exporting width/height that possibly by
   mere coincidence happen to be croping for most h263s, i would not
   be surprised if the width&height could also be scaling with no croping
   given some differences in other atoms

In that light i wonder why you do not export the croping
rectangle for H263 videos in the fields that exist for this purpose?
If there is a problem in the existing API for this, it should be fixed
not just ignored and each demuxer then exporting information in a
different way.

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

It is not what we do, but why we do it that matters.
-------------- 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/20090228/cba682c5/attachment.pgp>