On 04/03/2011 06:15 PM, Ronald S. Bultje wrote: > Hi, > > 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. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
