[FFmpeg-devel] [PATCH] metadata conversion API
Sat Feb 28 02:11:50 CET 2009
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
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");
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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel