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

Michael Niedermayer michaelni
Wed Mar 18 15:00:31 CET 2009


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


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

There are many different image formats, png and jpeg are just 2, some
containers will per spec allow formats that differ from others, its the
same as mpeg-ps for VCDs will not work wit huffyuv as codec.

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?

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

IMHO this is not convenient.
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?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090318/865e90d2/attachment.pgp>



More information about the ffmpeg-devel mailing list