[FFmpeg-devel] [PATCH/RFC] Per-codec option system

[Jason Garrett-Glaser]

> * parameters that are semantically identical between a pair of codecs,
> ?must use the same parameter name, they also must use a compatible
> ?parameter value system. That makes some sense because, well, its nice if
> ?users dont have to releaern a new system for each codec in ffmpeg.

IMO this should be handled internally to codecs, not by literally
sharing the parameters.  In other words, it should be a policy: codecs
should use the same name for parameters when it makes sense.  It
should be enforced by rules, not code.

> * parameters that are used by more than 1 codec must be conventional fields
> ?in AVCodecContext (this is vastly more efficient in terms of access speed
> ?and amount of memory needed)

Why does access speed matter for setting parameters?  This is stupid.

> * as a consequence of above it also must be possible to transparently move
> ?a name/value parameter into AVCodecContext, this can be done by extending
> ?AVOptions.

I don't see why AVCodecContext even needs to exist in the first place.
 There is not a *single parameter* in the context that applies to all
codecs.

> * If there exists an established parameter name/value for something like
> ?a paremeter in lame or x264 then these should in addition to the standard
> ?system in ffmpeg be supported.

So you want to have two redundant systems for passing options to an
encoder, each with different naming schemes?  This is a usability
disaster.

I agree that it shouldn't be committed unless it fulfills
requirements; the statement was rather that if we agree that it
satisfies the requirements but people won't stop bickering over
trivial aspects, I will commit it anyways.

Dark Shikari