* [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
@ 2024-02-05 17:44 Niklas Haas
2024-02-05 17:44 ` [FFmpeg-devel] [PATCH 2/2] avcodec: set color_ranges for all video encoders Niklas Haas
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Niklas Haas @ 2024-02-05 17:44 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Niklas Haas
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 ++++++
libavcodec/version.h | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1f5724324a..7849ce47d9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-02-xx - xxxxxxxxxx - lavc 60.40.100 - avcodec.h
+ Add AVCodec.color_ranges and AVCodec.color_spaces.
+
2024-02-04 - xxxxxxxxxx - lavc 60.39.100 - packet.h
Add AV_PKT_DATA_AMBIENT_VIEWING_ENVIRONMENT.
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 8034f1a53c..8bd678de7a 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -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;
/**
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f2f14eaed1..19f3f4a272 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 39
+#define LIBAVCODEC_VERSION_MINOR 40
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.43.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* [FFmpeg-devel] [PATCH 2/2] avcodec: set color_ranges for all video encoders
2024-02-05 17:44 [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
@ 2024-02-05 17:44 ` Niklas Haas
2024-02-05 17:48 ` [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
2024-02-05 18:04 ` Andreas Rheinhardt
2 siblings, 0 replies; 13+ messages in thread
From: Niklas Haas @ 2024-02-05 17:44 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Niklas Haas
From: Niklas Haas <git@haasn.dev>
I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain an explicit
assignment of their supported color ranges, with codecs in category
4 being set to MPEG-only for safety.
It might be considered redundant to assign a list of all possible color
ranges to codecs in category 3, but in doing so we effectively
communicate that we can guarantee that these tags will be encoded, which
is distinct from the situation where there are some codecs that simply
don't have tagging or implied semantics (e.g. rawvideo).
A full list of codecs follows:
JPEG range only:
- amv
- roqvideo
MPEG range only:
- asv1, asv2
- avui
- cfhd
- cljr
- dnxhd
- dvvideo
- ffv1
- flv
- h261, h263, h263p
- {h263,vp8}_v4l2m2m
- huffyuv, ffvhuff
- jpeg2000
- libopenjpeg
- libtheora
- libwebp, libwebp_anim
- libx262
- libxavs, libxavs2
- libxvid
- mpeg1video, mpeg2video
- mpeg2_qsv
- mpeg2_vaapi
- mpeg4, msmpeg4, msmpeg4v2, wmv1, wmv2
- mpeg4_omx
- rv10, rv20
- snow
- speedhq
- svq1
- tiff
- utvideo
Explicitly tagged (MPEG/JPEG):
- {av1,h264,hevc}_nvenc
- {av1,h264,hevc}_vaapi
- {av1,h264,hevc,vp8,vp9,mpeg4}_mediacodec
- {av1,h264,hevc,vp9}_qsv
- h264_amf
- {h264,hevc,prores}_videotoolbox
- libaom-av1
- libkvazaar
- libopenh264
- librav1e
- libsvtav1
- libvpx, libvpx-vp9
- libx264
- libx265
- ljpeg
- mjpeg
- vc2
Broken (encoder ignores tags):
- {av1,hevc}_amf
- {h264,hevc,mpeg4}_v4l2m2m
- h264_omx
- libxeve
- magicyuv
- {vp8,vp9,mjpeg}_vaapi
N/A:
- ayuv, yuv4, y41p, v308, v210, v410, v408 (headerless)
- pgmyuv (headerless)
- prores, prores_aw, prores_ks (?)
- rawvideo, bitpacked (headerless)
- vnull, wrapped_avframe (pseudocodecs)
---
libavcodec/amfenc_av1.c | 1 +
libavcodec/amfenc_h264.c | 1 +
libavcodec/amfenc_hevc.c | 1 +
libavcodec/asvenc.c | 2 ++
libavcodec/avuienc.c | 1 +
libavcodec/cfhdenc.c | 1 +
libavcodec/cljrenc.c | 1 +
libavcodec/codec_internal.h | 4 ++++
libavcodec/dnxhdenc.c | 1 +
libavcodec/dvenc.c | 1 +
libavcodec/ffv1enc.c | 1 +
libavcodec/flvenc.c | 1 +
libavcodec/h261enc.c | 1 +
libavcodec/huffyuvenc.c | 2 ++
libavcodec/ituh263enc.c | 2 ++
libavcodec/j2kenc.c | 1 +
libavcodec/libaomenc.c | 1 +
libavcodec/libkvazaar.c | 1 +
libavcodec/libopenh264enc.c | 1 +
libavcodec/libopenjpegenc.c | 1 +
libavcodec/librav1e.c | 1 +
libavcodec/libsvtav1.c | 1 +
libavcodec/libtheoraenc.c | 1 +
libavcodec/libvpxenc.c | 2 ++
libavcodec/libwebpenc.c | 1 +
libavcodec/libwebpenc_animencoder.c | 1 +
libavcodec/libx264.c | 2 ++
libavcodec/libx265.c | 1 +
libavcodec/libxavs.c | 1 +
libavcodec/libxavs2.c | 1 +
libavcodec/libxeve.c | 1 +
libavcodec/libxvid.c | 1 +
libavcodec/ljpegenc.c | 1 +
libavcodec/magicyuvenc.c | 1 +
libavcodec/mediacodecenc.c | 1 +
libavcodec/mjpegenc.c | 2 ++
libavcodec/mpeg12enc.c | 2 ++
libavcodec/mpeg4videoenc.c | 1 +
libavcodec/msmpeg4enc.c | 3 +++
libavcodec/nvenc_av1.c | 1 +
libavcodec/nvenc_h264.c | 1 +
libavcodec/nvenc_hevc.c | 1 +
libavcodec/omx.c | 2 ++
libavcodec/qsvenc_av1.c | 1 +
libavcodec/qsvenc_h264.c | 1 +
libavcodec/qsvenc_hevc.c | 1 +
libavcodec/qsvenc_jpeg.c | 1 +
libavcodec/qsvenc_mpeg2.c | 1 +
libavcodec/qsvenc_vp9.c | 1 +
libavcodec/roqvideoenc.c | 1 +
libavcodec/rv10enc.c | 1 +
libavcodec/rv20enc.c | 1 +
libavcodec/snowenc.c | 1 +
libavcodec/speedhqenc.c | 1 +
libavcodec/svq1enc.c | 1 +
libavcodec/tiffenc.c | 1 +
libavcodec/utils.c | 12 ++++++++++++
libavcodec/utvideoenc.c | 1 +
libavcodec/v4l2_m2m_enc.c | 1 +
libavcodec/vaapi_encode_av1.c | 1 +
libavcodec/vaapi_encode_h264.c | 1 +
libavcodec/vaapi_encode_h265.c | 1 +
libavcodec/vaapi_encode_mjpeg.c | 1 +
libavcodec/vaapi_encode_mpeg2.c | 1 +
libavcodec/vaapi_encode_vp8.c | 1 +
libavcodec/vaapi_encode_vp9.c | 1 +
libavcodec/vc2enc.c | 3 ++-
libavcodec/videotoolboxenc.c | 2 ++
libavcodec/wmv2enc.c | 1 +
69 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index 3f164ccc59..9e55508979 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -485,6 +485,7 @@ const FFCodec ff_av1_amf_encoder = {
AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = ff_amf_pix_fmts,
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.p.wrapper_name = "amf",
.hw_configs = ff_amfenc_hw_configs,
};
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index bd544d12df..5b1ebc5637 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -539,6 +539,7 @@ const FFCodec ff_h264_amf_encoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = ff_amf_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.p.wrapper_name = "amf",
.hw_configs = ff_amfenc_hw_configs,
};
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 352564a301..4f936355a2 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -454,6 +454,7 @@ const FFCodec ff_hevc_amf_encoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = ff_amf_pix_fmts,
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.p.wrapper_name = "amf",
.hw_configs = ff_amfenc_hw_configs,
};
diff --git a/libavcodec/asvenc.c b/libavcodec/asvenc.c
index 50da46738c..a1f331782d 100644
--- a/libavcodec/asvenc.c
+++ b/libavcodec/asvenc.c
@@ -367,6 +367,7 @@ const FFCodec ff_asv1_encoder = {
FF_CODEC_ENCODE_CB(encode_frame),
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
};
#endif
@@ -382,5 +383,6 @@ const FFCodec ff_asv2_encoder = {
FF_CODEC_ENCODE_CB(encode_frame),
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
};
#endif
diff --git a/libavcodec/avuienc.c b/libavcodec/avuienc.c
index 8a093d3d19..b917caa226 100644
--- a/libavcodec/avuienc.c
+++ b/libavcodec/avuienc.c
@@ -99,6 +99,7 @@ const FFCodec ff_avui_encoder = {
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_EXPERIMENTAL |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_UYVY422, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.init = avui_encode_init,
FF_CODEC_ENCODE_CB(avui_encode_frame),
};
diff --git a/libavcodec/cfhdenc.c b/libavcodec/cfhdenc.c
index f447438491..cb8c22fc1f 100644
--- a/libavcodec/cfhdenc.c
+++ b/libavcodec/cfhdenc.c
@@ -872,5 +872,6 @@ const FFCodec ff_cfhd_encoder = {
AV_PIX_FMT_GBRAP12,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/cljrenc.c b/libavcodec/cljrenc.c
index 31ad5ce0cf..cc38b328f1 100644
--- a/libavcodec/cljrenc.c
+++ b/libavcodec/cljrenc.c
@@ -118,5 +118,6 @@ const FFCodec ff_cljr_encoder = {
FF_CODEC_ENCODE_CB(encode_frame),
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV411P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &cljr_class,
};
diff --git a/libavcodec/codec_internal.h b/libavcodec/codec_internal.h
index 130a7dc3cd..f2fc8feb08 100644
--- a/libavcodec/codec_internal.h
+++ b/libavcodec/codec_internal.h
@@ -327,4 +327,8 @@ static av_always_inline const FFCodec *ffcodec(const AVCodec *codec)
return (const FFCodec*)codec;
}
+extern const enum AVColorRange ff_color_range_jpeg[];
+extern const enum AVColorRange ff_color_range_mpeg[];
+extern const enum AVColorRange ff_color_range_all[];
+
#endif /* AVCODEC_CODEC_INTERNAL_H */
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index f52a2e9918..aa178dc1a2 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -1372,6 +1372,7 @@ const FFCodec ff_dnxhd_encoder = {
AV_PIX_FMT_GBRP10,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &dnxhd_class,
.defaults = dnxhd_defaults,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce21247081..e287e23ea8 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -1251,5 +1251,6 @@ const FFCodec ff_dvvideo_encoder = {
AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &dvvideo_encode_class,
};
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 2778c63012..48c93de325 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -1304,6 +1304,7 @@ const FFCodec ff_ffv1_encoder = {
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &ffv1_class,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP | FF_CODEC_CAP_EOF_FLUSH,
};
diff --git a/libavcodec/flvenc.c b/libavcodec/flvenc.c
index 6a96cb0f2f..77a6edffa8 100644
--- a/libavcodec/flvenc.c
+++ b/libavcodec/flvenc.c
@@ -105,5 +105,6 @@ const FFCodec ff_flv_encoder = {
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE},
+ .p.color_ranges = ff_color_range_mpeg,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
};
diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
index 438ebb63d9..e8cccd6d05 100644
--- a/libavcodec/h261enc.c
+++ b/libavcodec/h261enc.c
@@ -413,5 +413,6 @@ const FFCodec ff_h261_encoder = {
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
};
diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index b02b3c7a9a..d4999573c3 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -1094,6 +1094,7 @@ const FFCodec ff_huffyuv_encoder = {
AV_PIX_FMT_YUV422P, AV_PIX_FMT_RGB24,
AV_PIX_FMT_RGB32, AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
@@ -1127,6 +1128,7 @@ const FFCodec ff_ffvhuff_encoder = {
AV_PIX_FMT_RGB24,
AV_PIX_FMT_RGB32, AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
#endif
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index 97abfb3f45..09241303dd 100644
--- a/libavcodec/ituh263enc.c
+++ b/libavcodec/ituh263enc.c
@@ -907,6 +907,7 @@ const FFCodec ff_h263_encoder = {
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_H263,
.p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &h263_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
@@ -938,6 +939,7 @@ const FFCodec ff_h263p_encoder = {
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_H263P,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &h263p_class,
.p.capabilities = AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 5f95b772d1..abd3e229e4 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1863,6 +1863,7 @@ const FFCodec ff_jpeg2000_encoder = {
AV_PIX_FMT_PAL8,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &j2k_class,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index aa800834fe..03417eddf1 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1559,6 +1559,7 @@ FFCodec ff_libaom_av1_encoder = {
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_ENCODER_RECON_FRAME |
AV_CODEC_CAP_OTHER_THREADS,
+ .p.color_ranges = ff_color_range_all,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
.p.priv_class = &class_aom,
.p.wrapper_name = "libaom",
diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index 0711d9ab38..2ff66dabde 100644
--- a/libavcodec/libkvazaar.c
+++ b/libavcodec/libkvazaar.c
@@ -334,6 +334,7 @@ const FFCodec ff_libkvazaar_encoder = {
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_OTHER_THREADS,
.p.pix_fmts = pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.priv_data_size = sizeof(LibkvazaarContext),
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 6f231d22b2..8dabdafa34 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -445,6 +445,7 @@ const FFCodec ff_libopenh264_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.defaults = svc_enc_defaults,
.p.priv_class = &class,
.p.wrapper_name = "libopenh264",
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index 009c7a4377..f471a93355 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -785,6 +785,7 @@ const FFCodec ff_libopenjpeg_encoder = {
AV_PIX_FMT_XYZ12,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &openjpeg_class,
.p.wrapper_name = "libopenjpeg",
};
diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index 56539435a7..5565e7392b 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/librav1e.c
@@ -684,6 +684,7 @@ const FFCodec ff_librav1e_encoder = {
.p.priv_class = &class,
.defaults = librav1e_defaults,
.p.pix_fmts = librav1e_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS |
AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_RECON_FRAME |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 862192945b..01cf9549a2 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -700,6 +700,7 @@ const FFCodec ff_libsvtav1_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV420P10,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.defaults = eb_enc_defaults,
.p.wrapper_name = "libsvtav1",
diff --git a/libavcodec/libtheoraenc.c b/libavcodec/libtheoraenc.c
index 06eeaae006..cb14287bb0 100644
--- a/libavcodec/libtheoraenc.c
+++ b/libavcodec/libtheoraenc.c
@@ -390,5 +390,6 @@ const FFCodec ff_libtheora_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]){
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.wrapper_name = "libtheora",
};
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 80988a2608..ba37b8437b 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -2043,6 +2043,7 @@ const FFCodec ff_libvpx_vp8_encoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_AUTO_THREADS,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVA420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class_vp8,
.defaults = defaults,
.p.wrapper_name = "libvpx",
@@ -2114,6 +2115,7 @@ FFCodec ff_libvpx_vp9_encoder = {
.p.wrapper_name = "libvpx",
.priv_data_size = sizeof(VPxContext),
.init = vp9_init,
+ .p.color_ranges = ff_color_range_all,
FF_CODEC_ENCODE_CB(vpx_encode),
.close = vpx_free,
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
diff --git a/libavcodec/libwebpenc.c b/libavcodec/libwebpenc.c
index d6edd86603..bd758d6d4c 100644
--- a/libavcodec/libwebpenc.c
+++ b/libavcodec/libwebpenc.c
@@ -94,6 +94,7 @@ const FFCodec ff_libwebp_encoder = {
.p.id = AV_CODEC_ID_WEBP,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.p.pix_fmts = ff_libwebpenc_pix_fmts,
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &ff_libwebpenc_class,
.p.wrapper_name = "libwebp",
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE,
diff --git a/libavcodec/libwebpenc_animencoder.c b/libavcodec/libwebpenc_animencoder.c
index 8756231f23..e90d03e733 100644
--- a/libavcodec/libwebpenc_animencoder.c
+++ b/libavcodec/libwebpenc_animencoder.c
@@ -181,6 +181,7 @@ const FFCodec ff_libwebp_anim_encoder = {
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.p.pix_fmts = ff_libwebpenc_pix_fmts,
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &ff_libwebpenc_class,
.p.wrapper_name = "libwebp",
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE,
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 182e20f622..b96c91040d 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -1493,6 +1493,7 @@ FFCodec ff_libx264_encoder = {
#else
.p.pix_fmts = pix_fmts_all,
#endif
+ .p.color_ranges = ff_color_range_all,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP | FF_CODEC_CAP_AUTO_THREADS
#if X264_BUILD < 158
| FF_CODEC_CAP_NOT_INIT_THREADSAFE
@@ -1550,6 +1551,7 @@ const FFCodec ff_libx262_encoder = {
AV_CODEC_CAP_OTHER_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.p.pix_fmts = pix_fmts_8bit,
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &X262_class,
.p.wrapper_name = "libx264",
.priv_data_size = sizeof(X264Context),
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 447e6da25f..8593c1c166 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -902,6 +902,7 @@ FFCodec ff_libx265_encoder = {
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_OTHER_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.p.wrapper_name = "libx265",
.init = libx265_encode_init,
diff --git a/libavcodec/libxavs.c b/libavcodec/libxavs.c
index 6c29539f24..b53a8c24b5 100644
--- a/libavcodec/libxavs.c
+++ b/libavcodec/libxavs.c
@@ -435,6 +435,7 @@ const FFCodec ff_libxavs_encoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_AUTO_THREADS,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &xavs_class,
.defaults = xavs_defaults,
.p.wrapper_name = "libxavs",
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index c493ddc325..0e2fb597ce 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -301,6 +301,7 @@ const FFCodec ff_libxavs2_encoder = {
FF_CODEC_CAP_AUTO_THREADS,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &libxavs2,
.defaults = xavs2_defaults,
.p.wrapper_name = "libxavs2",
diff --git a/libavcodec/libxeve.c b/libavcodec/libxeve.c
index c10b7de023..adee1abe24 100644
--- a/libavcodec/libxeve.c
+++ b/libavcodec/libxeve.c
@@ -612,5 +612,6 @@ const FFCodec ff_libxeve_encoder = {
.p.profiles = NULL_IF_CONFIG_SMALL(ff_evc_profiles),
.p.wrapper_name = "libxeve",
.p.pix_fmts = supported_pixel_formats,
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP | FF_CODEC_CAP_NOT_INIT_THREADSAFE,
};
diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index aba875b6b8..c169e32edd 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -908,6 +908,7 @@ const FFCodec ff_libxvid_encoder = {
FF_CODEC_ENCODE_CB(xvid_encode_frame),
.close = xvid_encode_close,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &xvid_class,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.wrapper_name = "libxvid",
diff --git a/libavcodec/ljpegenc.c b/libavcodec/ljpegenc.c
index aa62beac71..141a65215d 100644
--- a/libavcodec/ljpegenc.c
+++ b/libavcodec/ljpegenc.c
@@ -328,4 +328,5 @@ const FFCodec ff_ljpeg_encoder = {
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
AV_PIX_FMT_NONE},
+ .p.color_ranges = ff_color_range_all,
};
diff --git a/libavcodec/magicyuvenc.c b/libavcodec/magicyuvenc.c
index ccd6a54936..a36e3833c7 100644
--- a/libavcodec/magicyuvenc.c
+++ b/libavcodec/magicyuvenc.c
@@ -689,5 +689,6 @@ const FFCodec ff_magicyuv_encoder = {
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVA444P, AV_PIX_FMT_GRAY8,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index 7eae542248..5b09f4d825 100644
--- a/libavcodec/mediacodecenc.c
+++ b/libavcodec/mediacodecenc.c
@@ -623,6 +623,7 @@ const FFCodec ff_ ## short_name ## _mediacodec_encoder = { \
| AV_CODEC_CAP_HARDWARE, \
.priv_data_size = sizeof(MediaCodecEncContext), \
.p.pix_fmts = avc_pix_fmts, \
+ .p.color_ranges = ff_color_range_all, \
.init = mediacodec_init, \
FF_CODEC_RECEIVE_PACKET_CB(mediacodec_encode), \
.close = mediacodec_close, \
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 508772987f..eb296bd7ab 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -659,6 +659,7 @@ const FFCodec ff_mjpeg_encoder = {
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &mjpeg_class,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
};
@@ -685,6 +686,7 @@ const FFCodec ff_amv_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_jpeg,
.p.priv_class = &amv_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
};
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 0135623c0e..0bf12c02c7 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -1245,6 +1245,7 @@ const FFCodec ff_mpeg1video_encoder = {
.p.supported_framerates = ff_mpeg12_frame_rate_tab + 1,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_SLICE_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
@@ -1264,6 +1265,7 @@ const FFCodec ff_mpeg2video_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_SLICE_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index d1e50612dd..8d2b483bbf 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -1403,6 +1403,7 @@ const FFCodec ff_mpeg4_encoder = {
FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
.close = ff_mpv_encode_end,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_SLICE_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/msmpeg4enc.c b/libavcodec/msmpeg4enc.c
index 119ea8f15e..47292fbba1 100644
--- a/libavcodec/msmpeg4enc.c
+++ b/libavcodec/msmpeg4enc.c
@@ -685,6 +685,7 @@ const FFCodec ff_msmpeg4v2_encoder = {
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_MSMPEG4V2,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &ff_mpv_enc_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
@@ -700,6 +701,7 @@ const FFCodec ff_msmpeg4v3_encoder = {
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_MSMPEG4V3,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &ff_mpv_enc_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
@@ -715,6 +717,7 @@ const FFCodec ff_wmv1_encoder = {
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_WMV1,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &ff_mpv_enc_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/nvenc_av1.c b/libavcodec/nvenc_av1.c
index 9f36796c4b..04d2c2fbe8 100644
--- a/libavcodec/nvenc_av1.c
+++ b/libavcodec/nvenc_av1.c
@@ -185,6 +185,7 @@ const FFCodec ff_av1_nvenc_encoder = {
.p.priv_class = &av1_nvenc_class,
.defaults = defaults,
.p.pix_fmts = ff_nvenc_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HARDWARE |
AV_CODEC_CAP_ENCODER_FLUSH | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
diff --git a/libavcodec/nvenc_h264.c b/libavcodec/nvenc_h264.c
index 85a13634a3..7e337ecf54 100644
--- a/libavcodec/nvenc_h264.c
+++ b/libavcodec/nvenc_h264.c
@@ -256,6 +256,7 @@ const FFCodec ff_h264_nvenc_encoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = ff_nvenc_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.p.wrapper_name = "nvenc",
.hw_configs = ff_nvenc_hw_configs,
};
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index 840df6da8a..98bed92fe9 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -232,6 +232,7 @@ const FFCodec ff_hevc_nvenc_encoder = {
.p.priv_class = &hevc_nvenc_class,
.defaults = defaults,
.p.pix_fmts = ff_nvenc_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HARDWARE |
AV_CODEC_CAP_ENCODER_FLUSH | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 82fd492071..4cb8a9a089 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -947,6 +947,7 @@ const FFCodec ff_mpeg4_omx_encoder = {
FF_CODEC_ENCODE_CB(omx_encode_frame),
.close = omx_encode_end,
.p.pix_fmts = omx_encoder_pix_fmts,
+ .p.color_ranges = ff_color_range_mpeg,
.p.capabilities = AV_CODEC_CAP_DELAY,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.priv_class = &omx_mpeg4enc_class,
@@ -968,6 +969,7 @@ const FFCodec ff_h264_omx_encoder = {
FF_CODEC_ENCODE_CB(omx_encode_frame),
.close = omx_encode_end,
.p.pix_fmts = omx_encoder_pix_fmts,
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.p.capabilities = AV_CODEC_CAP_DELAY,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.priv_class = &omx_h264enc_class,
diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
index c697845d7b..b4d30ad9c3 100644
--- a/libavcodec/qsvenc_av1.c
+++ b/libavcodec/qsvenc_av1.c
@@ -150,6 +150,7 @@ FFCodec ff_av1_qsv_encoder = {
AV_PIX_FMT_P010,
AV_PIX_FMT_QSV,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.defaults = qsv_enc_defaults,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 071a9a79e9..0b5527100d 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -202,6 +202,7 @@ const FFCodec ff_h264_qsv_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
AV_PIX_FMT_QSV,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.defaults = qsv_enc_defaults,
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index c5b7ac7cc4..99b43a4bea 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -405,6 +405,7 @@ const FFCodec ff_hevc_qsv_encoder = {
AV_PIX_FMT_VUYX,
AV_PIX_FMT_XV30,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.defaults = qsv_enc_defaults,
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
diff --git a/libavcodec/qsvenc_jpeg.c b/libavcodec/qsvenc_jpeg.c
index 2add12adc9..d47cfc7e65 100644
--- a/libavcodec/qsvenc_jpeg.c
+++ b/libavcodec/qsvenc_jpeg.c
@@ -93,6 +93,7 @@ const FFCodec ff_mjpeg_qsv_encoder = {
AV_PIX_FMT_BGRA,
AV_PIX_FMT_QSV,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.defaults = qsv_enc_defaults,
.p.wrapper_name = "qsv",
diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
index 22f1ff7c0d..57f16d68ea 100644
--- a/libavcodec/qsvenc_mpeg2.c
+++ b/libavcodec/qsvenc_mpeg2.c
@@ -105,6 +105,7 @@ const FFCodec ff_mpeg2_qsv_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
AV_PIX_FMT_QSV,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &class,
.defaults = qsv_enc_defaults,
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
index d0340ef94b..f8c4bcff85 100644
--- a/libavcodec/qsvenc_vp9.c
+++ b/libavcodec/qsvenc_vp9.c
@@ -117,6 +117,7 @@ const FFCodec ff_vp9_qsv_encoder = {
AV_PIX_FMT_QSV,
AV_PIX_FMT_XV30,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_all,
.p.priv_class = &class,
.defaults = qsv_enc_defaults,
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index 0933abf4f9..88ecfa1d4e 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -1127,6 +1127,7 @@ const FFCodec ff_roq_encoder = {
.close = roq_encode_end,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_jpeg,
.p.priv_class = &roq_class,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/rv10enc.c b/libavcodec/rv10enc.c
index 8a405b8686..105f7a9f08 100644
--- a/libavcodec/rv10enc.c
+++ b/libavcodec/rv10enc.c
@@ -78,4 +78,5 @@ const FFCodec ff_rv10_encoder = {
.close = ff_mpv_encode_end,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
};
diff --git a/libavcodec/rv20enc.c b/libavcodec/rv20enc.c
index dc26877d5e..ebb209a763 100644
--- a/libavcodec/rv20enc.c
+++ b/libavcodec/rv20enc.c
@@ -75,4 +75,5 @@ const FFCodec ff_rv20_encoder = {
.close = ff_mpv_encode_end,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
};
diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index c215215346..ce594c3fa7 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -2142,6 +2142,7 @@ const FFCodec ff_snow_encoder = {
AV_PIX_FMT_GRAY8,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &snowenc_class,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/speedhqenc.c b/libavcodec/speedhqenc.c
index 5b4ff4c139..0d0fa04d0c 100644
--- a/libavcodec/speedhqenc.c
+++ b/libavcodec/speedhqenc.c
@@ -294,6 +294,7 @@ const FFCodec ff_speedhq_encoder = {
FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
.close = ff_mpv_encode_end,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
+ .p.color_ranges = ff_color_range_mpeg,
.p.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE
diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
index 2e07af3688..ecd9de8269 100644
--- a/libavcodec/svq1enc.c
+++ b/libavcodec/svq1enc.c
@@ -758,6 +758,7 @@ const FFCodec ff_svq1_encoder = {
.close = svq1_encode_end,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV410P,
AV_PIX_FMT_NONE },
+ .p.color_ranges = ff_color_range_mpeg,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
index 06d7dcc99d..a8e5c6ba84 100644
--- a/libavcodec/tiffenc.c
+++ b/libavcodec/tiffenc.c
@@ -589,5 +589,6 @@ const FFCodec ff_tiff_encoder = {
AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.p.priv_class = &tiffenc_class,
};
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 39b83c7791..4ed3a4291b 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1100,3 +1100,15 @@ int64_t ff_guess_coded_bitrate(AVCodecContext *avctx)
return bitrate;
}
+
+const enum AVColorRange ff_color_range_jpeg[] = {
+ AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED
+};
+
+const enum AVColorRange ff_color_range_mpeg[] = {
+ AVCOL_RANGE_MPEG, AVCOL_RANGE_UNSPECIFIED
+};
+
+const enum AVColorRange ff_color_range_all[] = {
+ AVCOL_RANGE_MPEG, AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED
+};
diff --git a/libavcodec/utvideoenc.c b/libavcodec/utvideoenc.c
index 1fcb6854f2..a22ba53f01 100644
--- a/libavcodec/utvideoenc.c
+++ b/libavcodec/utvideoenc.c
@@ -675,5 +675,6 @@ const FFCodec ff_utvideo_encoder = {
AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_NONE
},
+ .p.color_ranges = ff_color_range_mpeg,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index e08db5d5d3..90598b6038 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -433,6 +433,7 @@ static const FFCodecDefault v4l2_m2m_defaults[] = {
.close = v4l2_encode_close, \
.defaults = v4l2_m2m_defaults, \
.p.capabilities = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
+ .p.color_ranges = ff_color_range_mpeg, \
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE | \
FF_CODEC_CAP_INIT_CLEANUP, \
.p.wrapper_name = "v4l2m2m", \
diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 5a9ff0f798..b1c7511100 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -946,6 +946,7 @@ const FFCodec ff_av1_vaapi_encoder = {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
},
+ .p.color_ranges = ff_color_range_all,
.hw_configs = ff_vaapi_encode_hw_configs,
.p.wrapper_name = "vaapi",
};
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 57b5ea2bab..30ee07eae1 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -1392,6 +1392,7 @@ const FFCodec ff_h264_vaapi_encoder = {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
},
+ .p.color_ranges = ff_color_range_all,
.hw_configs = ff_vaapi_encode_hw_configs,
.p.wrapper_name = "vaapi",
};
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 239ef2359a..aec3b9d2f7 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1509,6 +1509,7 @@ const FFCodec ff_hevc_vaapi_encoder = {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
},
+ .p.color_ranges = ff_color_range_all,
.hw_configs = ff_vaapi_encode_hw_configs,
.p.wrapper_name = "vaapi",
};
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
index c17747e3a9..0a69ecfd3f 100644
--- a/libavcodec/vaapi_encode_mjpeg.c
+++ b/libavcodec/vaapi_encode_mjpeg.c
@@ -583,6 +583,7 @@ const FFCodec ff_mjpeg_vaapi_encoder = {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
},
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.hw_configs = ff_vaapi_encode_hw_configs,
.p.wrapper_name = "vaapi",
};
diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
index d1904bf4f5..436b221b8d 100644
--- a/libavcodec/vaapi_encode_mpeg2.c
+++ b/libavcodec/vaapi_encode_mpeg2.c
@@ -706,6 +706,7 @@ const FFCodec ff_mpeg2_vaapi_encoder = {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
},
+ .p.color_ranges = ff_color_range_mpeg,
.hw_configs = ff_vaapi_encode_hw_configs,
.p.wrapper_name = "vaapi",
};
diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index 8a557b967e..723a9f2819 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encode_vp8.c
@@ -261,6 +261,7 @@ const FFCodec ff_vp8_vaapi_encoder = {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
},
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.hw_configs = ff_vaapi_encode_hw_configs,
.p.wrapper_name = "vaapi",
};
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
index c2a8dec71b..5d2e173d3e 100644
--- a/libavcodec/vaapi_encode_vp9.c
+++ b/libavcodec/vaapi_encode_vp9.c
@@ -314,6 +314,7 @@ const FFCodec ff_vp9_vaapi_encoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP,
.defaults = vaapi_encode_vp9_defaults,
+ .p.color_ranges = ff_color_range_mpeg, /* FIXME: implement tagging */
.p.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_VAAPI,
AV_PIX_FMT_NONE,
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index d978c67a3b..65b3d1e5cd 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1237,5 +1237,6 @@ const FFCodec ff_vc2_encoder = {
FF_CODEC_ENCODE_CB(vc2_encode_frame),
.p.priv_class = &vc2enc_class,
.defaults = vc2enc_defaults,
- .p.pix_fmts = allowed_pix_fmts
+ .p.pix_fmts = allowed_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
};
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index a7efd7ef3f..5d032a08f1 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2957,6 +2957,7 @@ const FFCodec ff_hevc_videotoolbox_encoder = {
AV_CODEC_CAP_HARDWARE,
.priv_data_size = sizeof(VTEncContext),
.p.pix_fmts = hevc_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.init = vtenc_init,
FF_CODEC_ENCODE_CB(vtenc_frame),
.close = vtenc_close,
@@ -2996,6 +2997,7 @@ const FFCodec ff_prores_videotoolbox_encoder = {
AV_CODEC_CAP_HARDWARE,
.priv_data_size = sizeof(VTEncContext),
.p.pix_fmts = prores_pix_fmts,
+ .p.color_ranges = ff_color_range_all,
.init = vtenc_init,
FF_CODEC_ENCODE_CB(vtenc_frame),
.close = vtenc_close,
diff --git a/libavcodec/wmv2enc.c b/libavcodec/wmv2enc.c
index 8eb56444a3..6fc748548b 100644
--- a/libavcodec/wmv2enc.c
+++ b/libavcodec/wmv2enc.c
@@ -248,6 +248,7 @@ const FFCodec ff_wmv2_encoder = {
FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
.close = ff_mpv_encode_end,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
+ .p.color_ranges = ff_color_range_mpeg,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
};
--
2.43.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-05 17:44 [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
2024-02-05 17:44 ` [FFmpeg-devel] [PATCH 2/2] avcodec: set color_ranges for all video encoders Niklas Haas
@ 2024-02-05 17:48 ` Niklas Haas
2024-02-05 18:04 ` Andreas Rheinhardt
2 siblings, 0 replies; 13+ messages in thread
From: Niklas Haas @ 2024-02-05 17:48 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Niklas Haas
It would make me happy if we could get this API addition in before 7.0,
even though it's non-functional on its own, as it sets the groundwork to
be able to start properly deprecating YUVJ.
After this series, the next steps are:
1. Make decoders stop outputting YUVJ frames
2. Mark the actual YUVJ pixel formats as deprecated, add a removal API
define, and guard internal usages by AV_NOWARN_DEPRECATED
3. After sufficient time passes, remove YUVJ formats fully
I have a branch prepared for each.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-05 17:44 [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
2024-02-05 17:44 ` [FFmpeg-devel] [PATCH 2/2] avcodec: set color_ranges for all video encoders Niklas Haas
2024-02-05 17:48 ` [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
@ 2024-02-05 18:04 ` Andreas Rheinhardt
2024-02-05 18:37 ` Niklas Haas
2024-02-09 12:11 ` Niklas Haas
2 siblings, 2 replies; 13+ messages in thread
From: Andreas Rheinhardt @ 2024-02-05 18:04 UTC (permalink / raw)
To: ffmpeg-devel
Niklas Haas:
> 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 ++++++
> libavcodec/version.h | 2 +-
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 1f5724324a..7849ce47d9 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
>
> API changes, most recent first:
>
> +2024-02-xx - xxxxxxxxxx - lavc 60.40.100 - avcodec.h
> + Add AVCodec.color_ranges and AVCodec.color_spaces.
> +
> 2024-02-04 - xxxxxxxxxx - lavc 60.39.100 - packet.h
> Add AV_PKT_DATA_AMBIENT_VIEWING_ENVIRONMENT.
>
> diff --git a/libavcodec/codec.h b/libavcodec/codec.h
> index 8034f1a53c..8bd678de7a 100644
> --- a/libavcodec/codec.h
> +++ b/libavcodec/codec.h
> @@ -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;
>
> /**
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index f2f14eaed1..19f3f4a272 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #include "version_major.h"
>
> -#define LIBAVCODEC_VERSION_MINOR 39
> +#define LIBAVCODEC_VERSION_MINOR 40
> #define LIBAVCODEC_VERSION_MICRO 100
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
This presumes the relevant states to be a cartesian product. Which need
not be true. A callback would be better; this would also allow to base
the list on other values already set in an AVCodecContext. And if this
were extended, it would also allow to remove init_static_data one day.
It is furthermore quite wasteful to store color_ranges in a list,
although there are only very few states for it.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-05 18:04 ` Andreas Rheinhardt
@ 2024-02-05 18:37 ` Niklas Haas
2024-02-08 11:30 ` Niklas Haas
2024-02-09 12:11 ` Niklas Haas
1 sibling, 1 reply; 13+ messages in thread
From: Niklas Haas @ 2024-02-05 18:37 UTC (permalink / raw)
To: ffmpeg-devel
On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> This presumes the relevant states to be a cartesian product. Which need
> not be true. A callback would be better; this would also allow to base
> the list on other values already set in an AVCodecContext. And if this
> were extended, it would also allow to remove init_static_data one day.
> It is furthermore quite wasteful to store color_ranges in a list,
> although there are only very few states for it.
What signature would you propose for such a callback?
I disagree with using a list for the range being wasteful. In terms of
binary size, they are shared (see ff_color_range_mpeg/jpeg definition).
At best you are saving a few bits from using an int bitmask instead of
a pointer.
The main reason to use a list is API simplicity and consistency. Working
with a bitmask is more awkward and would require more specialized code
as opposed to the current design which allows simply re-using macros
like DEF_CHOOSE_FORMATS in fftools, which is designed to handle lists.
Not to mention the equivalent libavfilter API also being list-based.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-05 18:37 ` Niklas Haas
@ 2024-02-08 11:30 ` Niklas Haas
2024-02-08 12:33 ` Andreas Rheinhardt
0 siblings, 1 reply; 13+ messages in thread
From: Niklas Haas @ 2024-02-08 11:30 UTC (permalink / raw)
To: ffmpeg-devel
On Mon, 05 Feb 2024 19:37:48 +0100 Niklas Haas <ffmpeg@haasn.xyz> wrote:
> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> > This presumes the relevant states to be a cartesian product. Which need
> > not be true. A callback would be better; this would also allow to base
> > the list on other values already set in an AVCodecContext. And if this
> > were extended, it would also allow to remove init_static_data one day.
> > It is furthermore quite wasteful to store color_ranges in a list,
> > although there are only very few states for it.
>
> What signature would you propose for such a callback?
Well, there are two fundamental approaches here:
1. The callback somehow sets or returns a list of supported colorspaces.
2. The callback accepts a particular configuration and simply returns if
it's supported or not, with fields set to AVCOL_*_UNKNOWN being
ignored.
The first case has the pro of simplicity, and the ability to enumerate
more easily, but the drawback of only being scalable if we return
a cartesian set (i.e. set each attribute list independently, rather than
generating one big list).
The second case has the pro of flexibility, and the ability to handle
non-cartesian use cases, but the con of being slightly more awkward to
recover a list (for e.g. filtering purpose). Fortunately, we can recover
the minimal cartesian superset of the actual supported set in O(n) time,
and then still verify the exact format chosen at encode time.
One possibility could be to add a `test()` callback which simply tests
if the current codec context has valid parameters. For example:
struct AVCodecContext {
...
int (*test)(const AVCodecContext *ctx);
}
But this suggests a very stateful API, where you have to mutate
AVCodecContext in order to query what formats would be supported.
I don't like this.
So probably it makes more sense to just directly ingest a new struct
for this purpose, which we can then extend easily. (Or should we just
ingest AVFrame directly, i.e. int (*test_avframe)(ctx, AVFrame *frame)?)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-08 11:30 ` Niklas Haas
@ 2024-02-08 12:33 ` Andreas Rheinhardt
2024-02-08 20:32 ` Niklas Haas
0 siblings, 1 reply; 13+ messages in thread
From: Andreas Rheinhardt @ 2024-02-08 12:33 UTC (permalink / raw)
To: ffmpeg-devel
Niklas Haas:
> On Mon, 05 Feb 2024 19:37:48 +0100 Niklas Haas <ffmpeg@haasn.xyz> wrote:
>> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
>>> This presumes the relevant states to be a cartesian product. Which need
>>> not be true. A callback would be better; this would also allow to base
>>> the list on other values already set in an AVCodecContext. And if this
>>> were extended, it would also allow to remove init_static_data one day.
>>> It is furthermore quite wasteful to store color_ranges in a list,
>>> although there are only very few states for it.
>>
>> What signature would you propose for such a callback?
>
> Well, there are two fundamental approaches here:
>
> 1. The callback somehow sets or returns a list of supported colorspaces.
> 2. The callback accepts a particular configuration and simply returns if
> it's supported or not, with fields set to AVCOL_*_UNKNOWN being
> ignored.
>
> The first case has the pro of simplicity, and the ability to enumerate
> more easily, but the drawback of only being scalable if we return
> a cartesian set (i.e. set each attribute list independently, rather than
> generating one big list).
>
> The second case has the pro of flexibility, and the ability to handle
> non-cartesian use cases, but the con of being slightly more awkward to
> recover a list (for e.g. filtering purpose). Fortunately, we can recover
> the minimal cartesian superset of the actual supported set in O(n) time,
> and then still verify the exact format chosen at encode time.
>
> One possibility could be to add a `test()` callback which simply tests
> if the current codec context has valid parameters. For example:
>
> struct AVCodecContext {
> ...
> int (*test)(const AVCodecContext *ctx);
> }
>
> But this suggests a very stateful API, where you have to mutate
> AVCodecContext in order to query what formats would be supported.
> I don't like this.
>
> So probably it makes more sense to just directly ingest a new struct
> for this purpose, which we can then extend easily. (Or should we just
> ingest AVFrame directly, i.e. int (*test_avframe)(ctx, AVFrame *frame)?)
Sorry for not answering earlier.
My intention is to allow users who only want to deal with the common
case of a cartesian product to continue to do so, but to also support
other usecases.
The public function would look like
int avcodec_get_supported_config(const AVCodecContext *avctx, const
AVCodec *codec, int **supported_configs, unsigned desired_configs,
unsigned flags, void *logctx);
avctx can be NULL (in which case this allows to return all potential
configurations, irrespective of e.g. the level of strictness).
codec can be omitted if avctx->codec is set, but if both are supplied
and avctx->codec is set, they have to match (like in avcodec_open2()).
desired_configs is a bitfield of configs that the user wants to get
information about; your patch would have to add flags for color_ranges
and color_spaces.
supported_configs will on return point to something like an array of
struct { int desired_config0, desired_config1,...;}. The order of the
entries will be fixed (say coincide with the order of the bits in the
desired_configs bitfields).
If one member is the unspec value for its type, then this means that it
works with everything.
supported_configs will be allocated; ownership passes to the user.
Using a multidimensional sentinel (that would depend on desired_configs)
is clumsy, so there will be two supported ways for this (depends upon a
flag to be supplied in flags): One method that really adds a
multidimensional sentinel, the other method that writes the number of
entries into **supported_configs, so that the first entry starts at
(*supported_configs)[1]. This allows users that only want to deal with
the factors of a cartesian product separately to continue to do so.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-08 12:33 ` Andreas Rheinhardt
@ 2024-02-08 20:32 ` Niklas Haas
2024-03-24 12:25 ` Andreas Rheinhardt
0 siblings, 1 reply; 13+ messages in thread
From: Niklas Haas @ 2024-02-08 20:32 UTC (permalink / raw)
To: ffmpeg-devel
On Thu, 08 Feb 2024 13:33:51 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> Sorry for not answering earlier.
> My intention is to allow users who only want to deal with the common
> case of a cartesian product to continue to do so, but to also support
> other usecases.
> The public function would look like
>
> int avcodec_get_supported_config(const AVCodecContext *avctx, const
> AVCodec *codec, int **supported_configs, unsigned desired_configs,
> unsigned flags, void *logctx);
>
> avctx can be NULL (in which case this allows to return all potential
> configurations, irrespective of e.g. the level of strictness).
> codec can be omitted if avctx->codec is set, but if both are supplied
> and avctx->codec is set, they have to match (like in avcodec_open2()).
> desired_configs is a bitfield of configs that the user wants to get
> information about; your patch would have to add flags for color_ranges
> and color_spaces.
> supported_configs will on return point to something like an array of
> struct { int desired_config0, desired_config1,...;}. The order of the
> entries will be fixed (say coincide with the order of the bits in the
> desired_configs bitfields).
> If one member is the unspec value for its type, then this means that it
> works with everything.
> supported_configs will be allocated; ownership passes to the user.
> Using a multidimensional sentinel (that would depend on desired_configs)
> is clumsy, so there will be two supported ways for this (depends upon a
> flag to be supplied in flags): One method that really adds a
> multidimensional sentinel, the other method that writes the number of
> entries into **supported_configs, so that the first entry starts at
> (*supported_configs)[1]. This allows users that only want to deal with
> the factors of a cartesian product separately to continue to do so.
OTOH this design will necessarily either result in exponential
explosion, or end up requiring the caller to make assumptions about
which fields are independent (and should thus be queried separately),
the moment a codec imposes *any* restriction (cartesian or not) on
multiple fields at the same time.
I also think that a `test()` callback, as I previously proposed, is also
overkill and doesn't actually solve anything. Codecs can already error
out on invalid configurations at open() time, and any practical use of
such an API would also end up having to make the cartesian assumption
one way or the other.
So in summary, I still think that we should enforce the assumption that
these fields form a cartesian set - it's simple, fast, useful and
doesn't overengineer for hypothetical constraints that we couldn't realistically
address one way or the other. Afaict, all current codecs support
a cartesian set of metadata, but feel free to correct me if I'm wrong.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-05 18:04 ` Andreas Rheinhardt
2024-02-05 18:37 ` Niklas Haas
@ 2024-02-09 12:11 ` Niklas Haas
2024-03-23 17:51 ` Niklas Haas
2024-03-24 13:04 ` Andreas Rheinhardt
1 sibling, 2 replies; 13+ messages in thread
From: Niklas Haas @ 2024-02-09 12:11 UTC (permalink / raw)
To: ffmpeg-devel
On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> This presumes the relevant states to be a cartesian product. Which need
> not be true. A callback would be better; this would also allow to base
> the list on other values already set in an AVCodecContext. And if this
> were extended, it would also allow to remove init_static_data one day.
> It is furthermore quite wasteful to store color_ranges in a list,
> although there are only very few states for it.
There is also the consideration to be made that using a callback is
inconsistent with the established design. Consider that framerates,
pix_fmts, samplerates, sample fmts and channel layouts are all currently
provided as static arrays in AVCodec. There is a natural symmetry
between these items and the ones I intend to add (yuv matrix, range,
chroma location, primaries and gamma) - all of them are descriptive of
the way data is encoded, and are therefore also (or should be)
negotiable filter link properties.
If we add a new callback API, should we then extend it to also include
all of the existing items from the above list? Is there a reason that
yuv range supports needs to be more dynamic than the others?
Food for thought: mjpeg is not the only codec that puts restrictions on
the format support based on the strictness level. For example,
yuv4mpegpipe_muxer errors out with a strictness warning if you use
a non-standard pixel format. And arguably, in this case, this is
**preferred** behavior over "silently" inserting a scale filter to
convert to a supported format, as the whole point of y4m2 is to
encapsulate raw data as-is.
Should we:
1. Add a new dynamic callback that can query lists for all of the above
in a way dependent on the strictness level, and use it as
a replacement for the static lists currently in AVCodec?
2. Continue with the status quo of having these lists be static, plus
dynamic checks at open() time, and continue using the "convenience
hack" of having ffmpeg_tools automatically restrict limited range mjpeg?
It is not immediately obvious to me that an automatic conversion to
a supported format is *necessarily* preferred to erroring out unless the
user specifies a lower strictness level.
As for an API, I think that rather than having an AVCodecContext-aware
callback at all, I would just make callbacks that directly ingest the
strictness level in AVCodec. That makes it far less of a black box about
which fields of the AVCodecContext are relevant here.
i.e.
struct AVCodec {
const enum AVColorRange (*get_color_ranges)(int strictness);
const enum AVColorSpace (*get_color_spaces)(int strictness);
// ditto for the other parameters?
}
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-09 12:11 ` Niklas Haas
@ 2024-03-23 17:51 ` Niklas Haas
2024-03-24 13:04 ` Andreas Rheinhardt
1 sibling, 0 replies; 13+ messages in thread
From: Niklas Haas @ 2024-03-23 17:51 UTC (permalink / raw)
To: ffmpeg-devel
On Fri, 09 Feb 2024 13:11:38 +0100 Niklas Haas <ffmpeg@haasn.xyz> wrote:
> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> > This presumes the relevant states to be a cartesian product. Which need
> > not be true. A callback would be better; this would also allow to base
> > the list on other values already set in an AVCodecContext. And if this
> > were extended, it would also allow to remove init_static_data one day.
> > It is furthermore quite wasteful to store color_ranges in a list,
> > although there are only very few states for it.
>
> There is also the consideration to be made that using a callback is
> inconsistent with the established design. Consider that framerates,
> pix_fmts, samplerates, sample fmts and channel layouts are all currently
> provided as static arrays in AVCodec. There is a natural symmetry
> between these items and the ones I intend to add (yuv matrix, range,
> chroma location, primaries and gamma) - all of them are descriptive of
> the way data is encoded, and are therefore also (or should be)
> negotiable filter link properties.
>
> If we add a new callback API, should we then extend it to also include
> all of the existing items from the above list? Is there a reason that
> yuv range supports needs to be more dynamic than the others?
>
> Food for thought: mjpeg is not the only codec that puts restrictions on
> the format support based on the strictness level. For example,
> yuv4mpegpipe_muxer errors out with a strictness warning if you use
> a non-standard pixel format. And arguably, in this case, this is
> **preferred** behavior over "silently" inserting a scale filter to
> convert to a supported format, as the whole point of y4m2 is to
> encapsulate raw data as-is.
>
> Should we:
>
> 1. Add a new dynamic callback that can query lists for all of the above
> in a way dependent on the strictness level, and use it as
> a replacement for the static lists currently in AVCodec?
>
> 2. Continue with the status quo of having these lists be static, plus
> dynamic checks at open() time, and continue using the "convenience
> hack" of having ffmpeg_tools automatically restrict limited range mjpeg?
>
> It is not immediately obvious to me that an automatic conversion to
> a supported format is *necessarily* preferred to erroring out unless the
> user specifies a lower strictness level.
>
> As for an API, I think that rather than having an AVCodecContext-aware
> callback at all, I would just make callbacks that directly ingest the
> strictness level in AVCodec. That makes it far less of a black box about
> which fields of the AVCodecContext are relevant here.
>
> i.e.
>
> struct AVCodec {
> const enum AVColorRange (*get_color_ranges)(int strictness);
> const enum AVColorSpace (*get_color_spaces)(int strictness);
> // ditto for the other parameters?
> }
Ping for review?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-08 20:32 ` Niklas Haas
@ 2024-03-24 12:25 ` Andreas Rheinhardt
0 siblings, 0 replies; 13+ messages in thread
From: Andreas Rheinhardt @ 2024-03-24 12:25 UTC (permalink / raw)
To: ffmpeg-devel
Niklas Haas:
> On Thu, 08 Feb 2024 13:33:51 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
>> Sorry for not answering earlier.
>> My intention is to allow users who only want to deal with the common
>> case of a cartesian product to continue to do so, but to also support
>> other usecases.
>> The public function would look like
>>
>> int avcodec_get_supported_config(const AVCodecContext *avctx, const
>> AVCodec *codec, int **supported_configs, unsigned desired_configs,
>> unsigned flags, void *logctx);
>>
>> avctx can be NULL (in which case this allows to return all potential
>> configurations, irrespective of e.g. the level of strictness).
>> codec can be omitted if avctx->codec is set, but if both are supplied
>> and avctx->codec is set, they have to match (like in avcodec_open2()).
>> desired_configs is a bitfield of configs that the user wants to get
>> information about; your patch would have to add flags for color_ranges
>> and color_spaces.
>> supported_configs will on return point to something like an array of
>> struct { int desired_config0, desired_config1,...;}. The order of the
>> entries will be fixed (say coincide with the order of the bits in the
>> desired_configs bitfields).
>> If one member is the unspec value for its type, then this means that it
>> works with everything.
>> supported_configs will be allocated; ownership passes to the user.
>> Using a multidimensional sentinel (that would depend on desired_configs)
>> is clumsy, so there will be two supported ways for this (depends upon a
>> flag to be supplied in flags): One method that really adds a
>> multidimensional sentinel, the other method that writes the number of
>> entries into **supported_configs, so that the first entry starts at
>> (*supported_configs)[1]. This allows users that only want to deal with
>> the factors of a cartesian product separately to continue to do so.
>
> OTOH this design will necessarily either result in exponential
> explosion, or end up requiring the caller to make assumptions about
> which fields are independent (and should thus be queried separately),
> the moment a codec imposes *any* restriction (cartesian or not) on
> multiple fields at the same time.
>
> I also think that a `test()` callback, as I previously proposed, is also
> overkill and doesn't actually solve anything. Codecs can already error
> out on invalid configurations at open() time, and any practical use of
> such an API would also end up having to make the cartesian assumption
> one way or the other.
>
> So in summary, I still think that we should enforce the assumption that
> these fields form a cartesian set - it's simple, fast, useful and
> doesn't overengineer for hypothetical constraints that we couldn't realistically
> address one way or the other. Afaict, all current codecs support
> a cartesian set of metadata, but feel free to correct me if I'm wrong.
Ok, the gain of non-cartesian sets don't warrant the complexity incurred.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-02-09 12:11 ` Niklas Haas
2024-03-23 17:51 ` Niklas Haas
@ 2024-03-24 13:04 ` Andreas Rheinhardt
2024-04-03 18:55 ` Niklas Haas
1 sibling, 1 reply; 13+ messages in thread
From: Andreas Rheinhardt @ 2024-03-24 13:04 UTC (permalink / raw)
To: ffmpeg-devel
Niklas Haas:
> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
>> This presumes the relevant states to be a cartesian product. Which need
>> not be true. A callback would be better; this would also allow to base
>> the list on other values already set in an AVCodecContext. And if this
>> were extended, it would also allow to remove init_static_data one day.
>> It is furthermore quite wasteful to store color_ranges in a list,
>> although there are only very few states for it.
>
> There is also the consideration to be made that using a callback is
> inconsistent with the established design. Consider that framerates,
> pix_fmts, samplerates, sample fmts and channel layouts are all currently
> provided as static arrays in AVCodec. There is a natural symmetry
> between these items and the ones I intend to add (yuv matrix, range,
> chroma location, primaries and gamma) - all of them are descriptive of
> the way data is encoded, and are therefore also (or should be)
> negotiable filter link properties.
>
> If we add a new callback API, should we then extend it to also include
> all of the existing items from the above list? Is there a reason that
> yuv range supports needs to be more dynamic than the others?
>
It should support everything; and I'd like to remove the other (public)
static lists, too (after the necessary deprecations).
> Food for thought: mjpeg is not the only codec that puts restrictions on
> the format support based on the strictness level. For example,
> yuv4mpegpipe_muxer errors out with a strictness warning if you use
> a non-standard pixel format. And arguably, in this case, this is
> **preferred** behavior over "silently" inserting a scale filter to
> convert to a supported format, as the whole point of y4m2 is to
> encapsulate raw data as-is.
>
> Should we:
>
> 1. Add a new dynamic callback that can query lists for all of the above
> in a way dependent on the strictness level, and use it as
> a replacement for the static lists currently in AVCodec?
>
> 2. Continue with the status quo of having these lists be static, plus
> dynamic checks at open() time, and continue using the "convenience
> hack" of having ffmpeg_tools automatically restrict limited range mjpeg?
>
I really want this convenience hack removed.
> It is not immediately obvious to me that an automatic conversion to
> a supported format is *necessarily* preferred to erroring out unless the
> user specifies a lower strictness level.
I agree. (In fact, on default strictness, the current code inserts a
scale filter even if one explicitly adds "-color_range tv".)
>
> As for an API, I think that rather than having an AVCodecContext-aware
> callback at all, I would just make callbacks that directly ingest the
> strictness level in AVCodec. That makes it far less of a black box about
> which fields of the AVCodecContext are relevant here.
>
> i.e.
>
> struct AVCodec {
> const enum AVColorRange (*get_color_ranges)(int strictness);
> const enum AVColorSpace (*get_color_spaces)(int strictness);
> // ditto for the other parameters?
> }
Your callbacks would hardcode that the only thing that matters is
strictness. And it would be very expensive, because these fields would
be in every AVCodec, even though only a minority of AVCodecs (namely
video encoders) would use them. (supported_framerates is even only set
by two encoders. What a waste.) Adding an API like
int avcodec_get_supported_config(const AVCodecContext *avctx, const
AVCodec *codec, void **supported_configs, unsigned *num_configs, enum
AVCodecConfigs desired_config,
unsigned flags, void *logctx);
(enum AVCodecConfigs would contain a value for pix fmts, sample fmts etc.)
allows to keep the details hidden and therefore use a compact way to
store it.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
2024-03-24 13:04 ` Andreas Rheinhardt
@ 2024-04-03 18:55 ` Niklas Haas
0 siblings, 0 replies; 13+ messages in thread
From: Niklas Haas @ 2024-04-03 18:55 UTC (permalink / raw)
To: ffmpeg-devel
On Sun, 24 Mar 2024 14:04:37 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> Niklas Haas:
> > On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> >> This presumes the relevant states to be a cartesian product. Which need
> >> not be true. A callback would be better; this would also allow to base
> >> the list on other values already set in an AVCodecContext. And if this
> >> were extended, it would also allow to remove init_static_data one day.
> >> It is furthermore quite wasteful to store color_ranges in a list,
> >> although there are only very few states for it.
> >
> > There is also the consideration to be made that using a callback is
> > inconsistent with the established design. Consider that framerates,
> > pix_fmts, samplerates, sample fmts and channel layouts are all currently
> > provided as static arrays in AVCodec. There is a natural symmetry
> > between these items and the ones I intend to add (yuv matrix, range,
> > chroma location, primaries and gamma) - all of them are descriptive of
> > the way data is encoded, and are therefore also (or should be)
> > negotiable filter link properties.
> >
> > If we add a new callback API, should we then extend it to also include
> > all of the existing items from the above list? Is there a reason that
> > yuv range supports needs to be more dynamic than the others?
> >
>
> It should support everything; and I'd like to remove the other (public)
> static lists, too (after the necessary deprecations).
>
> > Food for thought: mjpeg is not the only codec that puts restrictions on
> > the format support based on the strictness level. For example,
> > yuv4mpegpipe_muxer errors out with a strictness warning if you use
> > a non-standard pixel format. And arguably, in this case, this is
> > **preferred** behavior over "silently" inserting a scale filter to
> > convert to a supported format, as the whole point of y4m2 is to
> > encapsulate raw data as-is.
> >
> > Should we:
> >
> > 1. Add a new dynamic callback that can query lists for all of the above
> > in a way dependent on the strictness level, and use it as
> > a replacement for the static lists currently in AVCodec?
> >
> > 2. Continue with the status quo of having these lists be static, plus
> > dynamic checks at open() time, and continue using the "convenience
> > hack" of having ffmpeg_tools automatically restrict limited range mjpeg?
> >
>
> I really want this convenience hack removed.
>
> > It is not immediately obvious to me that an automatic conversion to
> > a supported format is *necessarily* preferred to erroring out unless the
> > user specifies a lower strictness level.
>
> I agree. (In fact, on default strictness, the current code inserts a
> scale filter even if one explicitly adds "-color_range tv".)
>
> >
> > As for an API, I think that rather than having an AVCodecContext-aware
> > callback at all, I would just make callbacks that directly ingest the
> > strictness level in AVCodec. That makes it far less of a black box about
> > which fields of the AVCodecContext are relevant here.
> >
> > i.e.
> >
> > struct AVCodec {
> > const enum AVColorRange (*get_color_ranges)(int strictness);
> > const enum AVColorSpace (*get_color_spaces)(int strictness);
> > // ditto for the other parameters?
> > }
>
> Your callbacks would hardcode that the only thing that matters is
> strictness. And it would be very expensive, because these fields would
> be in every AVCodec, even though only a minority of AVCodecs (namely
> video encoders) would use them. (supported_framerates is even only set
> by two encoders. What a waste.) Adding an API like
>
> int avcodec_get_supported_config(const AVCodecContext *avctx, const
> AVCodec *codec, void **supported_configs, unsigned *num_configs, enum
> AVCodecConfigs desired_config,
> unsigned flags, void *logctx);
> (enum AVCodecConfigs would contain a value for pix fmts, sample fmts etc.)
Having an extra `logctx` here seems redundant and inconsistent with
other avctx-taking functions, which log to the provided `avctx`.
>
> allows to keep the details hidden and therefore use a compact way to
> store it.
>
> - Andreas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2024-04-03 18:55 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-05 17:44 [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
2024-02-05 17:44 ` [FFmpeg-devel] [PATCH 2/2] avcodec: set color_ranges for all video encoders Niklas Haas
2024-02-05 17:48 ` [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec Niklas Haas
2024-02-05 18:04 ` Andreas Rheinhardt
2024-02-05 18:37 ` Niklas Haas
2024-02-08 11:30 ` Niklas Haas
2024-02-08 12:33 ` Andreas Rheinhardt
2024-02-08 20:32 ` Niklas Haas
2024-03-24 12:25 ` Andreas Rheinhardt
2024-02-09 12:11 ` Niklas Haas
2024-03-23 17:51 ` Niklas Haas
2024-03-24 13:04 ` Andreas Rheinhardt
2024-04-03 18:55 ` Niklas Haas
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git