On Fri, 13 Oct 2023 19:10:33 +0200 Andreas Rheinhardt <andreas.rheinha...@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-requ...@ffmpeg.org with subject "unsubscribe".
