[FFmpeg-devel] [PATCH] metadata API is now ready to be part of public API

[Baptiste Coudurier]

On 3/16/2009 5:01 PM, Michael Niedermayer wrote:
> On Mon, Mar 16, 2009 at 04:48:35PM -0700, Baptiste Coudurier wrote:
>> On 3/16/2009 4:39 PM, Aurelien Jacobs wrote:
>>> On Sun, Mar 15, 2009 at 07:34:39PM -0700, Baptiste Coudurier wrote:
>>>> Aurelien Jacobs wrote:
>>>>> Hi,
>>>>>
>>>>> I think the new metadata API is now ready to be used in the wild.
>>>>> So attached patch makes it officially part of public API.
>>>>> Note that all (de)muxers are now using this new API.
>>>>>
>>>>> The only step left for this transition is to disable old API for
>>>>> next major version, and to document this deprecation.
>>>>>
>>>> Btw, is there a mechanism to use AVMetadata with pure data ?
>>>> A char * is limited to strings unless we put a length field in it.
>>> Metadata is limited to zero terminated strings...
>>> If you desperatly want to store binary data in it, you can use base64,
>>> but I doubt it would be a good idea.
>>>
>>>> I'm thinking of covers in .m4a files. This is a whole jpeg.
>>>> I bet someone will answer to use CODEC_TYPE_ATTACHMENT,
>>> Now, you do both the question and the answer... Great :-)
>>>
>>>> however I will need to create separate track only for this.
>>> And, so what ?
>> This is ugly and clearly not in line with mov/mp4/3gp structure.
>> I checked the code, and it seems is not even in line with mkv structure,
>> I may be wrong though but this hack was added for mkv IIRC.
>>
>> So remove this ugly hack and store a AVMetadata "cover" with full image
>> in it.
> 
> Its IMHO semantically wrong to store cd covers in AVMetadata
> * AVMetadata is stuff that can be displayed to the user by dumping its
>   char[] to the screen

No, I don't agree with this at all. Semantically it is wrong to
associate char * to all "metadata". Other applications _actually_ using
much metadata knows it, and use different flags to specify to type of
the value.

> * Metadata is data that is not directly part of the presentation but
>   data about the presentation

IMHO "presentation" in case of audio is the "sound" produced. not the cover.

>   like who made it, when was it made, what type of camera was used,
>   what encoder, ...
>   This is in contrast with the actual presentation and a cd cover is displayed
>   by some mp3 players for example so i consider it part of the presentation
>   not data about it

Besides, everybody calls it "metadata".

> Also if images are put in AVMetadata we also need full support for ffmpeg
> to encode, decode and "-vcodec copy" them as well as ffplay to display them
> i suspect this will be uglier than 2 lines of code to create a seperate
> stream for the cover.

No we don't. metadata copying would be enough. This is braindead.

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