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

[Baptiste Coudurier]

Hi Michael,

On 3/18/2009 7:00 AM, Michael Niedermayer wrote:
> On Mon, Mar 16, 2009 at 05:09:43PM -0700, Baptiste Coudurier wrote:
>> On 3/16/2009 5:01 PM, Michael Niedermayer wrote:
> [...]
>>>   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
>> Besides, everybody calls it "metadata".
> 
> First rule of science and mathematics, if everybody agrees it must be true

I don't see how mathematics apply to "metadata".

>>> 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.
> 
> So, because you want it in AVMetadata everything that wouldnt work is
> irrelevant?

Having it in AVMetadata does not mean this feature will not be possible.
I said that "No we don't need full support for ffmpeg".

> [...] 
> 
> ffmpegs job is to transcode between containers, how can it be
> braindead to convert (aka decode + encode) a cover to a matching format?
> whats the difference to converting video & audio tracks?

It's braindead to use a "track" in _libavformat_ because the mechanism
used by FFmpeg is what is is.

> what would the alternative be? some new system to dump metadata to files and
> a seperate one to load it (of corse duplicated in all applications besides
> ffmpeg.c)
> and between the manual dump & load the user by hand converts the image to the
> correct format (of course the user also must know which format that is for
> each container ...)

No, a transcode cover art feature. This does not enforce at all the
usage of an AVStream in libavformat semantics, and I believe many
application wouldn't deal with it this way.

> IMHO this is not convenient.

Dumping in a file, IMHO this is not convenient either, and this is _not_
what I propose.

> Yes decode & encode maybe messy but if ffmpeg is to support covers it should
> do the convert and for that tracks are much more convenient.

> Besides, its not a big step from a jpeg to a animated gif.
> art, you still would conside that not a track?

Animated gif case is special IMHO. I'm talking about the design of
containers
and everybody chose to not consider using "cover art" or "attachment" as
"tracks" in their own semantics.

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