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

[Robert Swain]

On 17/3/09 00:09, Baptiste Coudurier wrote:
> 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.

I agree. An album art image is definitely metadata.

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

+1

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

The artist, album, title etc are also displayed when listening to the 
music/audio as well. These are not part of the presentation, they are 
metadata related to the music/audio. The same applies to an album cover 
image. It is not required to listen to the music, but it is nice extra 
information to have alongside 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.
>
> No we don't. metadata copying would be enough. This is braindead.

Indeed. One should already have the image prepared for 'injection' as 
metadata, ffmpeg doesn't need to do anything special other than accept a 
file name of a jpg/png/whatever is valid and read that file or read the 
data from the source metadata field and store that data in an 
appropriate metadata field of the output file if supported.

Regards,
Rob