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

[Robert Swain]

2009/9/30 Jason Garrett-Glaser <darkshikari at gmail.com>:
>> * 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.

I agree that it makes sense for semantically identical parameters to
use the same name, but I definitely agree with Jason that it does not
need to be the same declared variable. Items with the same semantics
can have different types. Sometimes items may share a (sane) name but
have different semantics and so should have different descriptions of
the variables.

>> * 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.

+1

This is for configuration. The long-running restriction on the
flexibility of configuration needs to be succeeded by something such
as is being proposed.

However, my issue with shared options in AVCodecContext is that they
have shared default values which make no sense in various codecs, that
their types may not be sufficient for reuse in new codecs and they
would then either need a new variant option or need to be moved out of
AVCC, that their ranges may differ per codec and so on. I _much_
prefer codecs doing their own option parsing of strings.

>> * 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.

Why is this necessary?

> 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.

Indeed. It's big, it's awkward to alter (API/ABI issues, strictness of
reusing variables as mentioned above) without breaking stuff and as
Jason notes, only parts of it are relevant to each codec.

>> * 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 hope that a sane new string parsing method (or similar) will
supersede the current system which is difficult to learn (CLI options
are order dependent which is unusual and confusing) and has a bad
policy with regard to what it does automatically and what the default
behaviour is. The default behaviour should be to produce good quality
output for all codecs, to negotiate mismatches between input and
output (frame rate, sample rate, resolution, pixel format, sample
format, channels, etc.) unless no sane solution can be found or unless
the user specifies otherwise. It should of course inform the user of
what it is doing in case it is not desired, and it should try not to
do anything if reasonably possible (e.g. input is 44.1kHz, output
needs 11025Hz/22050Hz, downsample to 22050Hz; output needs 44.1Khz do
nothing).

> 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.

It's unfortunate but sometimes it seems this is the way to get things
done around here.

Regards,
Rob