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

[Baptiste Coudurier]

Hi,

On 3/17/2009 3:45 PM, Aurelien Jacobs 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.
> 
> Yes, it was added for mkv IIRC.
> What makes you think it is not in line with mkv structure ??

"Attachment" is not a "track" according to MKV sematics.

>> So remove this ugly hack and store a AVMetadata "cover" with full image
>> in it.
> 
> Cover is only on perticular case of attachment. In fact, any kind of
> file can be used as attachment. In practise, one of the main use of
> attachement is to store truetype font used by subtitles.
> But it could also contain a pdf file with the guitar tabs of the
> audio track.
> Do you suggest to store all of these in metadata ? (along with their
> mime type and filename ?)

For sure it would be more generic and flexible,

but, yes I guess we could add CODEC_ID_PDF, CODEC_ID_PSF (postscript
font), CODEC_ID_ODF, CODEC_ID_NONSENSE, CODEC_ID_CRAP, etc....

>>>> Any other mechanism ?
>>> You mean another mechanism which would also allows correctly remuxing
>>> the cover in other containers ? I don't think there is any.
>> I believe "cover" AVMetadata will fit mkv as well wouldn't it ?
> 
> Not really.
> An attachement can have metadata associated with it. This means that a
> mkv file can contain a "cover" attachement along with some metadata, such
> as the name of the photographer who took the photo on the cover, and so on.
> So storing "cover" into AVMetadata would require supporting some kind of
> recursive metadata...
> Also a mkv file can come along with multiple covers (front cover, back
> cover, CD cover...)

Well, I'm not the one arguing against having nested metadata,
but misuing AVStream for this seems really overkill.

Using "attachment-<filename>" as tag seems reasonable.

> Also a nice advantage of attachment tracks to store cover, is that a player
> can handle them almost the same as a normal video track containing only one
> still frame.

Assuming mime type is recognized and associated to a CODEC_ID, nice
generic api...

Does it actually _contain_ any frame ? It seems attachement is put in
extradata.....

This is IMHO a bit far to be inline with my definition of "track".

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