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

Baptiste Coudurier baptiste.coudurier
Tue Mar 17 00:48:35 CET 2009


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.

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

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




More information about the ffmpeg-devel mailing list