[FFmpeg-devel] [PATCH] metadata API is now ready to be part of public API
Wed Mar 18 20:10:37 CET 2009
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
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
> 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
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
More information about the ffmpeg-devel