Re: [FFmpeg-devel] [PATCH v2 02/13] avcodec: add extended AVCodec color metadata

[Anton Khirnov <anton@khirnov.net>]

Quoting Andreas Rheinhardt (2023-10-13 19:10:33)
> 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 here anyway, we might as well add all of
> > the metadata, which I foresee seeing more use in the future (e.g.
> > automatic conversion from HDR to SDR when encoding to formats that don't
> > support AVCOL_TRC_SMPTE2084, ...)
> > ---
> >  doc/APIchanges       | 4 ++++
> >  libavcodec/codec.h   | 7 +++++++
> >  libavcodec/version.h | 4 ++--
> >  3 files changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 9b109e6fa7..f91e855e70 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -2,6 +2,10 @@ The last version increases of all libraries were on 2023-02-09
> >  
> >  API changes, most recent first:
> >  
> > +2023-10-xx - xxxxxxxxxx - lavc 60.23.100 - avcodec.h
> > +  Add AVCodec.csps, AVCodec.color_ranges, AVCodec.chroma_locs, AVCodec.primaries,
> > +  AVCodec.trcs.
> > +
> >  2023-10-06 - xxxxxxxxxx - lavc 60.30.101 - avcodec.h
> >    AVCodecContext.coded_side_data may now be used during decoding, to be set
> >    by user before calling avcodec_open2() for initialization.
> > diff --git a/libavcodec/codec.h b/libavcodec/codec.h
> > index 8034f1a53c..5bc8f21868 100644
> > --- a/libavcodec/codec.h
> > +++ b/libavcodec/codec.h
> > @@ -235,6 +235,13 @@ typedef struct AVCodec {
> >       * Array of supported channel layouts, terminated with a zeroed layout.
> >       */
> >      const AVChannelLayout *ch_layouts;
> > +
> > +    /* Extended colorspace support metadata */
> > +    const enum AVColorSpace *csps;                  ///< array of supported color spaces, or NULL if unknown, array is terminated by AVCOL_SPC_UNSPECIFIED
> > +    const enum AVColorRange *color_ranges;          ///< array of supported color ranges, or NULL if unknown, array is terminated by 0
> > +    const enum AVChromaLocation *chroma_locs;       ///< array of supported chroma locations, or NULL if unknown, array is terminated by 0
> > +    const enum AVColorPrimaries *primaries;         ///< array of supported color primaries, or NULL if unknown, array is terminated by 0
> > +    const enum AVColorTransferCharacteristic *trcs; ///< array of supported transfer characteristics, or NULL if known, array is terminated by 0
> >  } AVCodec;
> >  
> 
> This design has several drawbacks:
> 1. It adds stuff that will only be set by a tiny minority of AVCodec's
> to all of them.
> 2. It is based around the underlying assumption that the set of
> permissible states (tupels) is a cartesian product of a set of color
> spaces, a set of color ranges etc. This is wrong: E.g. VP9 disallows
> limited-range RGB (it is syntactically impossible to set the color range
> when using RGB color space).
> 3. I don't see how the MJPEG encoder behaviour where the valid formats
> de facto depend upon strictness can be encoded in this way; isn't the
> aim to get rid of the necessity of the workaround in ffmpeg cli?
> 
> 1. and 2. suggests using some form of function that returns a list of
> supported tupels;

Another argument in favor of a function instead of arrays directly in
AVCodec is that for some codecs this is determined at runtime. A
function would allow us to get rid of FFCodec.init_static_data and make
FFCodec const.

-- 
Anton Khirnov
_______________________________________________
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".