[FFmpeg-devel] [PATCH] metadata conversion API

Michael Niedermayer michaelni
Tue Mar 3 23:05:29 CET 2009


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

and iam sure there are also several uses of these in that 5000 that
are in speed relevant parts of the code



> 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


> I actually don't like having a
> common set of parameters for codecs because sometimes options with
> similar semantics need different data types for different formats. The
> char * way is far more flexible.
> 
> > Independant of this there is the seperate question about passing char*
> > to external libs where this is much easier than other ways of interfacing,
> > like with libx264. I do not strongly object to this but will not agree
> > unless there are at least 2-3 developers who want it.
> 

> I want Baptiste's proposal. I wanted it or something like it for
> per-codec defaults. I imagined the default values being specified as a
> string in AVCodec. Having to have separate files for _defaults_ is
> kind of clunky for distribution purposes. If they're in the binary,
> there's no issue with people messing them up, forgetting to add them
> to their distribution package, etc. Making sure people have the preset
> files when using x264 is already becoming a user issue.

What about my suggestion of a AVOptions array in AVCodec? that not
only has max & min but also default


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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- 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/20090303/7f66205b/attachment.pgp>



More information about the ffmpeg-devel mailing list