[FFmpeg-devel] Cover art semantics in libavformat (was: Re: [PATCH] metadata API is now ready to be part of public API)

[Jai Menon]

On Tue, Mar 17, 2009 at 5:31 AM, Michael Niedermayer <michaelni at gmx.at> 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
> * Metadata is data that is not directly part of the presentation but
> ?data about the presentation
> ?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
>
> 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.

I hate to rake up old threads, but did we resolve this? lavf user
applications would benefit from being able to grab album art from the
container. Though i personally would have preferred to export it in
AVMetadata, if the majority feel that it should be a stream, I could
still volunteer. Constructive comments welcome :)

-- 
Regards,

Jai