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

From: Niklas Haas <ffmpeg@haasn.xyz>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2 02/13] avcodec: add extended AVCodec color metadata
Date: Sat, 14 Oct 2023 13:46:34 +0200
Message-ID: <20231014134634.GC89414@haasn.xyz> (raw)
In-Reply-To: <AS8P250MB074469156B0B9002222575A18FD2A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>

On Fri, 13 Oct 2023 19:10:33 +0200 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> 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).

Well, upon further consideration, I don't think this is enough to break
the cartesian approach, because RGB is always full range by convention.
Note how vf_scale, vf_zscale and vf_libplacebo all force the color range
for RGB inputs to full. So this is not an exception, rather it is the
rule. In other words, for RGB input, the colorspace and color_range
restrictions should simply be ignored, as they conceptually apply to YUV
formats only.

Note also that, thinking a little bit ahead, independent list would make
AVFilter negotiation *much* easier as we could just re-use
AVFilterFormats for each field without worry - whereas a "list of
tuples" approach requires introducing a new struct to group such
metadata, a new type of AVFilterFormats list + all supporting functions,
and a lot more boilerplate overall.

So we need to think very carefully if there actually are any
sufficiently strong motivating cases to introduce such heavy machinery.

> 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?

Note that ffmpeg cli presently initializes the filter graph well before
the AVCodecContext is set up with options, let alone opened. (Presently,
the logic for overriding the pixfmt list directly looks up the "strict"
field in the options dict)

So that limits the design space somewhat for elegant solutions here.
Either we make the "return list of supported formats" callback in
AVCodec simply accept the strict_std_compliance setting directly, or we
extend the static list of colorspaces itself by an extra strictness
field. Probably the former is better than the latter of these two
approaches.
_______________________________________________
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".