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

[Michael Niedermayer]

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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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-soc/attachments/20090709/5c795b92/attachment.pgp>