[FFmpeg-devel] [PATCH] metadata conversion API

[Baptiste Coudurier]

Michael Niedermayer wrote:
> 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 ...

It's up to the application to populate or not muxer's metadata, and up
to muxer to take this information into account. Some muxers override
information stored in given AVCodecContext because this information is
not reliable, and fetch information from the bitstream.

Besides AVOutputFormat could still have a list of "honored" metadata.

> 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");

Yes, I prefer the user to able to do this, instead of not having this
information at all. Like said in my previous mail, our ignorance should
not prevent the user to manipulate information he knows about.

>    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

Maybe, maybe not, you cannot be 100% sure with .mov

> 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.
> 

This is a specific example, and not the general concept.

Feel free to implement this if it works, I'm only proposing to export
"width" so I can automatically crop in ffmpeg.c, not anything else.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org