On 12/11/17, Ronald S. Bultje <rsbul...@gmail.com> wrote:
> Hi,
> On Sat, Dec 9, 2017 at 10:37 AM, Paul B Mahol <one...@gmail.com> wrote:
>> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>>      uint8_t max_lowres;                     ///< maximum value for lowres
>> supported by the decoder
>>      const AVClass *priv_class;              ///< AVClass for the private
>> context
>>      const AVProfile *profiles;              ///< array of recognized
>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
>> +    int color_range;                        ///< supported color range by
>> encoder, 0 means any is supported
>>      /*****************************************************************
>>       * No fields below this line are part of the public API. They
> First: please use the properly typed enum (enum AVColorRange).
> Second: so I understand what you're trying to do here. For decoders, if
> they only support one range (or colorspace, or whatever), we can set it in
> the decode function. But for encoders, we need some introspectable way to
> make sure the input to the codec is of the proper format, else we can only
> error, right? So, if some codec only supports mpeg range but the input is
> jpeg, something needs to convert it.
> Are we going to do that for all other color-related properties also? What
> if vp8 only supports bt601 but the input is bt709? Will we add a
> color_space to AVCodec? Or do we need a more generic mechanism to validate
> an input AVFrame config (AVFrame without data)? If we want a more generic
> design, we'd better do it now before we add 10 new ints to AVCodec and then
> remove them again... (Same is true for audio also, what if the codec only
> supports some samplerates/channel configs etc? Maybe something more generic
> is useful there too.)

Endless bikeshed...

Audio already have what it have and its working fine.

Do you propose to make another struct or what?

I hate how people can be so ignorant these days.
ffmpeg-devel mailing list

Reply via email to