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

[Michael Niedermayer]

On Tue, Sep 29, 2009 at 11:21:10AM -0700, Jason Garrett-Glaser wrote:
> A very simple implementation of a string option system, with x264
> completed as an example.  Not implemented in ffmpeg.c yet.
> 
> Eventual goal: eliminate [nearly] all options in AVCodecContext and
> revert entirely to codec-specific options.
> 
> Potential improvements: add a .help() command as well to return help
> information on the options for a specific codec.
> 
> I think practically everyone agrees that this needs to be done at some
> point.


this has been discussed previously and some minimal requirements have been
created
I might misremember but i think the following where part of it
* 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.
* 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)
* 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.
* 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.



>  If bikeshedding results in some variant of this not being
> committed within the next week, I will commit without discussion.  At

> a minimum, I think the (or a similar) API should go in as soon as
> possible so that we can start writing interfaces to it and converting
> more codecs to use it.

i have no problem with such API in principle but i think this specific API
here fails all requirements that we have.
It just seems to be a quick hack to allow x264 style options and defaults,
i do think this can be done much better, in that sense i think this code
needs more work before it can be commited

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20090930/e5304fd6/attachment.pgp>