@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-11-xx - xxxxxxxxxx - lavc 60.37.100 - avcodec.h
+ Add AVCodec.color_ranges and AVCodec.color_spaces.
+
2023-11-xx - xxxxxxxxxx - lavfi 9.16.100 - buffersink.h buffersrc.h
Add av_buffersink_get_colorspace and av_buffersink_get_color_range.
Add AVBufferSrcParameters.color_space and AVBufferSrcParameters.color_range.
@@ -235,6 +235,12 @@ typedef struct AVCodec {
* Array of supported channel layouts, terminated with a zeroed layout.
*/
const AVChannelLayout *ch_layouts;
+
+ /**
+ * Array of supported YUV color formats. Ignored for RGB/Gray formats.
+ */
+ const enum AVColorRange *color_ranges; ///< terminated by AVCOL_RANGE_UNSPECIFIED
+ const enum AVColorSpace *color_spaces; ///< terminated by AVCOL_SPC_UNSPECIFIED
} AVCodec;
/**
From: Niklas Haas <git@haasn.dev> This is motivated primarily by a desire for YUVJ removal, which will require signalling the supported color ranges as part of the codec capabilities. But since we're adding YUV range, we might as well add the YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only support certain values. I decided to preserve the ambiguous and misleading "color_spaces" name, for symmetry with AVFrame.colorspace. (Though this would IMO be better called "color_matrix" or "color_system") I also decided to omit the other AVColor* fields for now, because vf_scale cannot handle auto-conversion between primaries/transfer/etc. There is little value in adding metadata we cannot do anything with, and no harm in extending the API again in the future. In theory, vf_scale can handle conversion between chroma locations, but also the signalling for this is annoying, so I'll defer it to a future commit. --- doc/APIchanges | 3 +++ libavcodec/codec.h | 6 ++++++ 2 files changed, 9 insertions(+)