[FFmpeg-soc] AAC Encoding - Where we stand, what's left

[Stefano Sabatini]

On date Thursday 2009-07-09 04:49:20 +0200, Michael Niedermayer encoded:
> On Wed, Jul 08, 2009 at 10:19:32PM -0400, Justin Ruggles wrote:
> > Michael Niedermayer wrote:
> > > On Wed, Jul 08, 2009 at 02:55:54PM -0700, Baptiste Coudurier wrote:
> > >> On 07/08/2009 02:06 PM, Michael Niedermayer wrote:
> > >>> On Wed, Jul 08, 2009 at 01:41:52PM -0700, Baptiste Coudurier wrote:
> > >>>> Hi Michael,
> > >>>>
> > >>>> On 07/08/2009 12:28 PM, Michael Niedermayer wrote:
> > >>>>> On Wed, Jul 08, 2009 at 01:12:20AM -0400, Alex Converse wrote:
> > >>>>>
> > >>>>> [...]
> > >>>>>
> > >>>>> Also if you need (per codec) options as you said, tell me which, ill add
> > >>>>> them
> > >>>> Do you have a per codec option system ready ? :)
> > >>> no, i need a list of requirements/goals/use cases first
> > >>> once i know what the system should do that AVCodecContext fields cannot,
> > >>> iam sure it shouldnt be that hard ...
> > >> What's needed:
> > >>
> > >> is custom options for encoders/decoders/muxers/demuxers which are only 
> > >> needed for one element.
> > >>
> > >> The idea of using AVCodecContext/AVFormatContext doesn't please some devs 
> > >> it seems (including Justin, Alex, and me).
> > >>
> > >> Of course global values used by all must be put in the global context.
> > >>
> > >> I think _devs_ would like to be able to have custom options not fitting 
> > >> everywhere else without poluting global context. This would also permit to 
> > >> have x264 and lame mapped commandlines options.
> > >>
> > >> Can this request be considered ?
> > > 
> > > yes, i just need to understand what people really want and why.
> > > Heres a try, thats different from what we do now and also is similar to it
> > > 
> > > give each codec/(de)muxer a foobar_opts.h file that lists its custom options
> > > and then put
> > > 
> > > #include "foobar_opts.h" inside AVCodecContext from avcodec.h
> > > 
> > > At a binary level its exactly the same, it also makes moving between custom
> > > and global options very easy, and it adds more seperation to the astronomic
> > > AVCodecContext.
> > 
> > Could we move current global options that are only used by 1 codec into
> > custom options at the next major version bump?
> 
> If the maintainer of that codec would request it and the option is belived
> to be specific to just that codec, i mean not an option that we just dont
> support for other codecs yet ...
> 
> 
> > 
> > I understand about adding fields to AVCodecContext with #include, but I
> > don't quite get how AVOption would fit in?  Would there be a custom
> > AVOption array added to AVCodec?  Or would they all have to go under the
> > global options[]?
> 
> global options, though they could use a similar #include system
> 
> 
> > 
> > Would there be a way for ffmpeg -h to indicate custom options in some
> > way or say what AVCodec they belong to?  Or would that have to be
> > appended to the AVOption help text?
> 
> it would have to be appended to the help text in the very basic suggestion
> i had in mind
> 
> 
> > 
> > > Does that look better to (Justin, Alex, and you) ?
> > > If not please all 3 of you be as elaborate as possible about what is good
> > > and bad on it
> > 
> > One minor downside could be name conflicts between codecs for custom
> > options that do different things.  But that would just have to be
> > avoided with careful and specific naming.
> 
> name conflicts like you describe can only happen when the names are
> exreemly poorly choosen
> 
> 
> > 
> > It also does not seem to allow for the case where a global option would
> > be appropriate because of shared functionality, but where different
> > codecs need to have different default/min/max values or help text.
> 
> My gut feeling says a different help text is indication of serious missuse
> of something.
> About min/max, no my suggestion does not touch these at all
> 
> Also instead of the #includes we could simply change avcodec.h to just
> group all options that are related to one codec together and add appropriate
> comments. This would also be nicer if we consider the global options[] array
> ...
> 
> About per codec min/max i need to think more but at first it seems a seperate
> issue

Maybe you may have a look at my mail "[RFC] New option system", it
should provide the required level of configurability, there is also a
patch by Art regarding per-codec options (let to define a specific
AVOption/AVClass context for every codec).

Regards.