On 04/03/2011 07:23 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, Apr 3, 2011 at 4:15 PM, Justin Ruggles <[email protected]> > wrote: >> On 04/03/2011 06:15 PM, Ronald S. Bultje wrote: >>> On Sun, Apr 3, 2011 at 7:09 AM, Justin Ruggles <[email protected]> >>> wrote: >>>> On 04/02/2011 01:19 PM, Anton Khirnov wrote: >>>> >>>>> --- >>>>> libavcodec/avcodec.h | 29 ++++++++++---- >>>>> libavcodec/flacenc.c | 104 >>>>> +++++++++++++++++++++++++++++++++++++++++++------ >>>>> libavcodec/options.c | 18 +++++--- >>>>> libavcodec/version.h | 3 + >>>>> 4 files changed, 126 insertions(+), 28 deletions(-) >>>> >>>> >>>>> + { "min_prediction_order", NULL, offsetof(FlacEncodeContext, >>>>> options.min_prediction_order), >>>> >>>>> + { "max_prediction_order", NULL, offsetof(FlacEncodeContext, >>>>> options.max_prediction_order), >>>> >>>> I'm not against moving FLAC encoder options to the private context, but >>>> at least the 2 options above will also be used in the mpeg4-als encoder. >>> >>> The question is, I guess, "what do we do if private options exist in >>> more than one encoder?". I think that's OK, as long as they have >>> identical meaning. Do you agree? >>> >>> (Right now AVCodecContext is a mess and I welcome this cleanup.) >> >> >> That is indeed the question. If we do allow this, it would allow for an >> extensive overhaul of AVCodecContext. But it also falls under the >> category of code duplication since we would need to duplicate the >> options, per-option named values, and documentation. >> >> I don't know which would weigh as more important or if we could come up >> with some sort of compromise solution. > > I agree. What did you have in mind as "compromise solution"? I can > come up with weird stuff like a header file that contains the actual > private AVOption table entries as individual macros (#define > MIN_PREDICTION_ORDER_OPT { bla, bla, "bla", bla } ), and then using > that. That's a little ugly/evil though. Can you think of something > cleaner?
That's actually not too bad. Documentation would still be duplicated, but I guess that's part of the compromise. I was originally thinking more along the lines of a threshold for number of codecs using the option before it becomes shared, but your idea seems like less of a maintainance burden. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
