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 DD1F94A1B5 for ; Sat, 23 Mar 2024 17:51:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C1BE168D41E; Sat, 23 Mar 2024 19:51:08 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AC00C68D384 for ; Sat, 23 Mar 2024 19:51:02 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1711216262; bh=tqC8jIrr3UBTAKdyESCvOGv1Qo1u+XPK/1J/nBXldMg=; h=Date:From:To:Subject:In-Reply-To:References:From; b=T9wFzXh8a9z64IPs7+645bOl5wJfDA7UxAknV23J/LJCSpFykla3SVbszwYnVjmTH tyewUkO8I+6SXcs9MJG6aQm5t3t1FkrWmXdfA43vypvfT+UuaiLPIooAGQ0sYFwdLK 7MLwyDiW0CK62m2PbiW1ves6tpL1MoAZw5YchJq4= Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 7652240015 for ; Sat, 23 Mar 2024 18:51:02 +0100 (CET) Date: Sat, 23 Mar 2024 18:51:02 +0100 Message-ID: <20240323185102.GF28382@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: <20240209131138.GB12126@haasn.xyz> References: <20240205174413.92730-1-ffmpeg@haasn.xyz> <20240209131138.GB12126@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 Fri, 09 Feb 2024 13:11:38 +0100 Niklas Haas wrote: > 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? > } Ping for review? _______________________________________________ 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".