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".