From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
	by master.gitmailbox.com (Postfix) with ESMTP id 1667A46356
	for <ffmpegdev@gitmailbox.com>; Sat, 14 Oct 2023 11:46:44 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
	by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 07F2168C898;
	Sat, 14 Oct 2023 14:46:42 +0300 (EEST)
Received: from haasn.dev (haasn.dev [78.46.187.166])
 by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E5C0268BD6B
 for <ffmpeg-devel@ffmpeg.org>; Sat, 14 Oct 2023 14:46:34 +0300 (EEST)
Received: from haasn.dev (unknown [10.30.0.2])
 by haasn.dev (Postfix) with ESMTP id 95BA441EC3
 for <ffmpeg-devel@ffmpeg.org>; Sat, 14 Oct 2023 13:46:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail;
 t=1697283994; bh=1EUDwCuXyGsDryn3Tb35BxmqdSEjod5gX32x/cIX5ZI=;
 h=Date:From:To:Subject:In-Reply-To:References:From;
 b=Mizg0ELQZNlbqnHSMdNSRBC2l6sBCR3hStvBI/jo3K/LWx8rkRNhSaVU7PTI8VL1l
 c4ajOXyvubL2/YxRcxMwaag/POAM7eUBvRi0Fjo0s/wulVHnPlf5YfS6N5Nv5TlnuM
 XLWyYta55DR0AEOAEnfbqJcpZy3DZqCaWYM/VFOw=
Date: Sat, 14 Oct 2023 13:46:34 +0200
Message-ID: <20231014134634.GC89414@haasn.xyz>
From: Niklas Haas <ffmpeg@haasn.xyz>
To: ffmpeg-devel@ffmpeg.org
In-Reply-To: <AS8P250MB074469156B0B9002222575A18FD2A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>
References: <20231013142706.23971-1-ffmpeg@haasn.xyz>
 <20231013142706.23971-3-ffmpeg@haasn.xyz>
 <AS8P250MB074469156B0B9002222575A18FD2A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [FFmpeg-devel] [PATCH v2 02/13] avcodec: add extended AVCodec
 color metadata
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20231014134634.GC89414@haasn.xyz/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.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".