[FFmpeg-devel] [PATCH] metadata conversion API
Wed Mar 4 00:02:59 CET 2009
On Tue, Mar 03, 2009 at 02:20:47PM -0800, Baptiste Coudurier wrote:
> On 3/3/2009 2:05 PM, Michael Niedermayer wrote:
> > On Tue, Mar 03, 2009 at 09:35:09PM +0000, Robert Swain wrote:
> >> 2009/3/3 Michael Niedermayer <michaelni at gmx.at>:
> >>> On Mon, Mar 02, 2009 at 06:25:30PM -0800, Baptiste Coudurier wrote:
> >>>> I however volunteer to add key/value as char* options to AVFormatContext
> >>>> and AVCodecContext and use them.
> >>> You said that already but there is no relation between that and such validity
> >>> checks, its not going to solve this problem.
> >> OK, so maybe this is off topic for this thread.
> >>> Things added to svn have to be justified and their advantages and
> >>> disadavatanges weighted against each other. Also once a technical discussion
> >>> happened its the decission of the maintainer(s). Or in exceptional
> >>> circumstances a vote (or consensus for thouse prefering the terminology)
> >>> overriding the maintainer.
> >>> The arguments brought forth so far in favor of it, where that you want to
> >>> export ".mov/width" with a value that could be scaling or croping. And that
> >>> some advanced users may be able to make more sense out of it then we. And
> >>> that you prefer not to export the croping information in the existing
> >>> fields for this puprose.
> >>> And you want to export a field (whichs name you have not revealed yet)
> >>> that only has 2, 4 and 8 as valid values.
> >>> Have i missed some? I remember alot of flaming and trolling and some
> >>> unsuccessfull attempts at provocating me but little actual discussion
> >>> about it.
> >>> The arguments against, being a roughly 10x increase in memory consumtion,
> >>> similar or worse increase in cpu consumtion for access and the loss of a
> >>> common set of parameters for codecs. Each could have their own flag to
> >>> enable b frames ...
> >> The CPU loss should be minimal and it's only a set up cost. How many
> >> cycles are really spent on option parsing?
> > we directly access fields from AVCodecContext currently just try
> > grep avctx libavcodec/*.c | grep -v av_log
> > there are over 5000 matches
> > i do not want to replace 5000 single instruction reads with 5000 function
> > calls doing a search through a table of strings.
> > Especially considering that i dont see what we would gain by this
> I don't see how this relates to using char */char * as options, you can
> set AVCodecContext fields if you want.
thats what we have currently
av_set_string() takes a name & value char * and sets the corresponding field
> Although almost every codec has its own context anyway, point is to
> factorize when it's actually needed and not by principle.
So would you agree that the char * are only allowed to be used for things
that are used by just one muxer/demuxer or encoder/decoder ?
> >> Also, we can still enforce
> >> some sort of option naming consistency.
> > I cant even enforce some decission about where to store the croping
> > information now. And i am listed as maintainer of mov
> Well you share maintainership, and please stop saying this, it is not
> true, if you want to store croping into something actually used, I
> already said you were free to do so.
then stop phonily offering to store it in some wrong place
> Please don't focus on this "width" thing, this might apply to any
> information people find useful.
so far people have not found anythig else though,
external libs and mov/width being the only.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel