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. _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
