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.)
Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
