From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id B2AF7493D7 for ; Fri, 9 Feb 2024 12:11:49 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B869568CE06; Fri, 9 Feb 2024 14:11:46 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5139668CA86 for ; Fri, 9 Feb 2024 14:11:39 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1707480698; bh=2ZM47YVZ+lPiApilvL4/lz9QT5HiD8Tfk0lwm/pX2OE=; h=Date:From:To:Subject:In-Reply-To:References:From; b=HfRqUwokz6VZasLoH6z//QQ1IPt7T6PVoxTbV97pe1B7wvlEL6soEVXHRv3eUH7su wO2Xn3MQRF+1Ts62p3sQt8RPaYUFHHLxKTVLV3vGtWMYLuKXUtfkObwaIO3YiyIo0b 0AwR19Csywo+tAquTOqGKm8qRg4JFFPMfaHyfTmI= Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 9E4CE417E1 for ; Fri, 9 Feb 2024 13:11:38 +0100 (CET) Date: Fri, 9 Feb 2024 13:11:38 +0100 Message-ID: <20240209131138.GB12126@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: References: <20240205174413.92730-1-ffmpeg@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt wrote: > This presumes the relevant states to be a cartesian product. Which need > not be true. A callback would be better; this would also allow to base > the list on other values already set in an AVCodecContext. And if this > were extended, it would also allow to remove init_static_data one day. > It is furthermore quite wasteful to store color_ranges in a list, > although there are only very few states for it. There is also the consideration to be made that using a callback is inconsistent with the established design. Consider that framerates, pix_fmts, samplerates, sample fmts and channel layouts are all currently provided as static arrays in AVCodec. There is a natural symmetry between these items and the ones I intend to add (yuv matrix, range, chroma location, primaries and gamma) - all of them are descriptive of the way data is encoded, and are therefore also (or should be) negotiable filter link properties. If we add a new callback API, should we then extend it to also include all of the existing items from the above list? Is there a reason that yuv range supports needs to be more dynamic than the others? Food for thought: mjpeg is not the only codec that puts restrictions on the format support based on the strictness level. For example, yuv4mpegpipe_muxer errors out with a strictness warning if you use a non-standard pixel format. And arguably, in this case, this is **preferred** behavior over "silently" inserting a scale filter to convert to a supported format, as the whole point of y4m2 is to encapsulate raw data as-is. Should we: 1. Add a new dynamic callback that can query lists for all of the above in a way dependent on the strictness level, and use it as a replacement for the static lists currently in AVCodec? 2. Continue with the status quo of having these lists be static, plus dynamic checks at open() time, and continue using the "convenience hack" of having ffmpeg_tools automatically restrict limited range mjpeg? It is not immediately obvious to me that an automatic conversion to a supported format is *necessarily* preferred to erroring out unless the user specifies a lower strictness level. As for an API, I think that rather than having an AVCodecContext-aware callback at all, I would just make callbacks that directly ingest the strictness level in AVCodec. That makes it far less of a black box about which fields of the AVCodecContext are relevant here. i.e. struct AVCodec { const enum AVColorRange (*get_color_ranges)(int strictness); const enum AVColorSpace (*get_color_spaces)(int strictness); // ditto for the other parameters? } _______________________________________________ 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".