[FFmpeg-devel] [PATCH] metadata conversion API

Robert Swain robert.swain
Tue Mar 3 22:35:09 CET 2009

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? Also, we can still enforce
some sort of option naming consistency. 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.

I wanted the mencoder option method or similar. Option sets being
grouped are more logical and, in my opinion, if implemented correctly
should reduce user error due to changing semantics of options based on
their position throughout the command line.


More information about the ffmpeg-devel mailing list