[FFmpeg-devel] [PATCH] Metadata

Uoti Urpala uoti.urpala
Tue Jan 6 21:20:53 CET 2009


On Tue, 2009-01-06 at 20:30 +0100, Michael Niedermayer wrote:
> On Mon, Jan 05, 2009 at 03:40:06PM -0800, Baptiste Coudurier wrote:
> > How would you specify to the user that data stored in value is raw data
> >  (like jpeg cover),
> 
> This first leads to the question if a cd cover is metadata at all instead of
> actual data.
> But in that light iam not against adding a
> int or char* type if this is really usefull and needed in reality, iam just
> slightly afraid that we could overshoot the goal qute a bit and end up with a
> overcomplicated API where 98% is not used by anyone or anything ...
> 
> 
> 
> > encoded in UTF8/16, special like '\r' line ended ?
> 
> IMHO we should only support UTF-8 and and a single type of line ending
> (de)muxers using a different formating should convert to/from it

I agree that only UTF-8 should be supported in fields that FFmpeg in
some sense "understands". But OTOH I think it's desirable to be able to
export all data from each demuxer where possible, even if FFmpeg has no
framework to represent that data in a generally meaningful form or
convert it to any other container. For example such jpeg covers stored
as metadata or arbitrary byte strings used as keys with no correct way
to convert them to UTF-8. There's also various other container-specific
data with no general framework in FFmpeg.

IMO the best way to avoid API complexity is to have a way to export such
data in as raw a form as possible and leave all interpretation and
conversion to the user application which needs access to such data. The
FFmpeg-level API would be just "container-specific data", with all
details determined by the demuxer/muxer in question (though in some
cases additional conventions would make sense). The muxer/demuxer would
import/export raw data in some reasonable form, possibly using some
common container data structures.





More information about the ffmpeg-devel mailing list