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

[Aurelien Jacobs]

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

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

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

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.

Aurel