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?
Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
