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 2C7C449DC7 for ; Wed, 10 Apr 2024 22:09:15 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BDE5568D0B1; Thu, 11 Apr 2024 01:09:12 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0AED268C95A for ; Thu, 11 Apr 2024 01:09:06 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 0C66E240003 for ; Wed, 10 Apr 2024 22:09:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1712786946; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wE/0aln7r3YsNs5QpYz4aj5JOUsGvB1uQerYjwHuXpc=; b=oBB6R0y/74SVm+/WISuojdD9LQJdDZdETOWbxT5DL/DGHMVsdtGlZ79Pc08IlQv79tvk5a y33SGuivZa7+JxjLw3Uu9668OkCJXJPbNc+OkYk4gPbCTaRBu5Noszvn4boG5PMeYgmVwL 4/xeb+T+S5zjtnVCOLJR7IdppIQKRCBJuK0oA7teiLCHi8NA/NT0JR8+CaIo/q6K8wT/mx X6tPzPeHnJpPafp33eaMLLClqUHDsgohi2YAMi4KvKGWxodeIRRO6QEl82s03qeFLCbUlz lXqiNu0hm3L23z5AKsjTKACJL31g3KC2e8Nd27Ez5E7dd7JBOEwwK9UIRCNkUw== Date: Thu, 11 Apr 2024 00:09:05 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240410220905.GS6420@pb2> References: <20240405185721.111072-1-ffmpeg@haasn.xyz> <20240408201833.GI6420@pb2> <20240408235502.GB24382@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20240408235502.GB24382@haasn.xyz> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 01/11] avcodec: add avcodec_get_supported_config() 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: multipart/mixed; boundary="===============4382559529597203409==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4382559529597203409== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q0vf8v3lLTH58grx" Content-Disposition: inline --q0vf8v3lLTH58grx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 08, 2024 at 11:55:02PM +0200, Niklas Haas wrote: > On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer wrote: > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote: > > > From: Niklas Haas > > >=20 > > > This replaces the myriad of existing lists in AVCodec by a unified API > > > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite > > > substantially, while also making this more trivially extensible. > > >=20 > > > In addition to the already covered lists, add two new entries for col= or > > > space and color range, mirroring the newly added negotiable fields in > > > libavfilter. > > >=20 > > > I decided to drop the explicit length field from the API proposed by > > > Andreas Rheinhardt, because having it in place ended up complicating > > > both the codec side and the client side implementations, while also > > > being strictly less flexible (it's trivial to recover a length given > > > a terminator, but requires allocation to add a terminator given > > > a length). Using a terminator also presents less of a porting challen= ge > > > for existing users of the current API. > > >=20 > > > Once the deprecation period passes for the existing public fields, the > > > rough plan is to move the commonly used fields (such as > > > pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and vi= deo > > > configuration types, and then implement the rarely used fields with > > > custom callbacks. > > > --- > > > doc/APIchanges | 5 ++++ > > > libavcodec/avcodec.c | 51 +++++++++++++++++++++++++++++++++++= ++ > > > libavcodec/avcodec.h | 27 ++++++++++++++++++++ > > > libavcodec/codec.h | 19 +++++++++++--- > > > libavcodec/codec_internal.h | 21 +++++++++++++++ > > > libavcodec/version.h | 4 +-- > > > 6 files changed, 121 insertions(+), 6 deletions(-) > >=20 > > This patchset seems to overlap a bit with AVOptionRanges > >=20 > > I think ideally the user should at some point be able to query using so= me > > API on a AVCodecContext/AVCodecParameters/AVFormatContex/AVStream > > what for that specific instance are supported settings for each field > >=20 > > The API here seems to use a enum, which can make sense but it differs f= rom > > how AVOption works which doesnt use enums to identify fields >=20 > I didn't know AVOptionRanges exists; indeed it can be seen as somewhat > overlapping here. That said, there is a vital distinction here: AVOptionR= anges > represents *static* limits on what options can be set (e.g. via > `av_opt_set_int`), whereas this API represents *dynamic* limits on what c= an be > coded. AVOptionRanges where definitly not intended to be static see the docs: * The returned list may depend on other fields in obj like for example pro= file. that would not be static >=20 > In particular, the list of supported colorspaces etc. can *depend* on the= value > of other options. Currently, only strict_std_compliance, but I can easily= see > this list growing in the future (e.g. for different profiles, dolbyvision, > ...). >=20 > That aside, I personally find an API based on strings and doubles rather > cumbersome to use, especially when downstream clients expect an enum list. AVOption* is intended to be a generic API. For example something that an App can query to build a drop down menu in a = GUI for each parameter For this, it must be possible to iterate over all paremeters, then for each iterate over all possible settings if its a discrete type or range if its a continous type. And then present the user with the corresponding GUI elemen= ts thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri --q0vf8v3lLTH58grx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZhcN/QAKCRBhHseHBAsP q59bAJ9CR7nG8YjzQKs10kox9pegh0V7SQCgkZR7ToH0vE7MahRr4DKe/0Y3pLc= =HrW7 -----END PGP SIGNATURE----- --q0vf8v3lLTH58grx-- --===============4382559529597203409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============4382559529597203409==--