[FFmpeg-devel] [PATCH] metadata conversion API

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Fri, Feb 27, 2009 at 04:44:29PM -0800, Baptiste Coudurier wrote:
>> On 2/27/2009 4:30 PM, Aurelien Jacobs wrote:
>>> 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.
>>> You're welcome :-)
>>>
>>>> I have a few ideas:
>>>> Would it be possible to also export container information as "metadata" ?
>>> This is definitely possible.
>>>
>>>> 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.
>>> I think it highly depends on the target usage of the various fields you
>>> want to export. If those fields are mostly targeted for textual user
>>> information, using metadata is probably the way to go. But if the fields
>>> are mostly targeted for numerical parameters to the software, then
>>> metadata may not be the most practical way go.
>> It would be easy atoi/atoll value though.
>> I will propose again my solution to have some "type" field where we
>> could set "INT", "INT64", "UTF8", "RATIONAL", etc...
> 
> what is the difference between a string representing INT and INT64 ?
> if atoi() is no problem then it also should be no problem to check if
> a string is a number. This has the advantage that it can be muxed
> in containers that do not support storing such information.

The advantage is a direct mapping atoi/atoll. If the muxer wants to take
the risk to store INT64 into INT it will check the value.

> Or how would you store these types? If they are lost on remuxing or their
> types are randomized then they arent particularely usefull IMHO
> 
> 
>> I don't think it might be too bloated, and would be really generic and
>> useful. We have too many fields in AVCodecContext IMHO.
> 
> I dont mind at all if information is exported using some name-value system
> but there are some things that are very important
> 1. it must be simple & clean & small & fast
> 2. These fields would be the public API and as such would be constraint
>    by the same compatibility issues that apply to fields in AVCodecContext
>    And it seems to me you do not realize this at all due to your
>    example useage, but a demuxer could  under no circumstances export 
>    a random "width" "720" that differed in meaning from a "width" value
>    of another demuxer.

"width" in .mov is "width" in .mov, not "width" in .mkv.

Well I think 100% mapping between containers is _impossible_, and
therefore I don't see a need to find a common denominator.

I don't see the need to "restrict" a metadata to a meaning.
Someone who knows even more the format can retrieve this value if he
wishes and do whatever he wants with it.
I certainly don't understand 100% of .mp4/.mov, I don't see why user
should be restricted by my ignorance, while I can export everything in
"udta" assuming the formating is standardized.

User can retrieve "width" in .mov if he wants, a simple check on input
format is enough.

Yes, this would be part of public api, I don't see this a problem.

> Thus i belive that in the end this thing is adding alot of shiny layers
> that do nothing at all. But feel free to proof me wrong ...

Many people wants to use FFmpeg to display information about a file,
including metadata. This is IMHO a good and simple way to achieve it.

I'm proposing to implement the one I propose.

> If each demuxer maintainer exports whatever values with whatever names
> he feels like then the values would be a nightmare to use for a user
> app. not to mention remuxing a "width" "720" video when that wasnt the true
> width.

See above.

> So what would this all really solve?
> * Fewer inactive fields, currently large parts of AVCodecContext are unused
>   for some codecs though the bigger codecs probably use most.
> * No psychological issue with adding field to a large struct, though people
>   would have to add them to a equally long documentation that documented the
>   exact meaning and format, who is allowed to set (app/lavc/lavf), ...
> 
> What does it not solve?
> * exporting mov croping rectangle with a API that differs from mpeg1/2
>   and h264 croping rectangles.

It can solve this issue, if user wants to honor it, user can because he
has access to it. Granted he knows what the value means, but again our
ignorance should not prevent him from acheiving his goal.

> * allowing demuxer maintainers to export fields with arbirary name and
>   value, insted each addition would need to be discussed to find the
>   format for the value and the name that is best for most demuxers.

I don't agree with this, see above. "width" in .mov != "width" in .mkv,
IMHO that's an utopy to try to make everything fitting in the same shape.

> * decrease the memory requirement, string & values malloced take a
>   lot more space than a few unused ints. malloc() alone has considerable
>   overhead

This could be enabled by AVFMT_EXPORT_METADATA, if user do not want to
waste this memory.

> * more compatibility for apps, apps already can through AVOptions
>   set and get by name and enumerate fields.

AVOptions uses OPT_<type> isn't it ? Why don't you want to apply this to
AVMetadata ?

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