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 18B2544449 for ; Sat, 10 Sep 2022 17:06:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9AD1768BB24; Sat, 10 Sep 2022 20:06:44 +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 8C00D68B613 for ; Sat, 10 Sep 2022 20:06:37 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id BABBC240002 for ; Sat, 10 Sep 2022 17:06:36 +0000 (UTC) Date: Sat, 10 Sep 2022 19:06:35 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220910170635.GL2088045@pb2> References: <20220908173911.GA2088045@pb2> <20220908202528.GB2088045@pb2> <20220909145558.GE2088045@pb2> <20220910152931.GI2088045@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale/input: Avoid calls to av_pix_fmt_desc_get() 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="===============8999965345887109841==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============8999965345887109841== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FhLCAOpkK55HfMa0" Content-Disposition: inline --FhLCAOpkK55HfMa0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 10, 2022 at 06:34:43PM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Fri, Sep 09, 2022 at 08:15:22PM +0200, Andreas Rheinhardt wrote: > >> Michael Niedermayer: > >>> On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote: > >>>> Michael Niedermayer: > >>>>> On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote: > >>>>>> Michael Niedermayer: > >>> [...] > >>>>> To me if i look at the evolution > >>>>> of isBE() / code checking BE-ness it become more messy over time > >>>>> > >>>>> I think it would be interresting to think about if we can make > >>>>> av_pix_fmt_desc_get(compile time constant) work at compile time. > >>>>> or if we maybe can return to a simpler implementation > >>>>> > >>>> > >>>> We could put the av_pix_fmt_descriptors array into an internal header > >>>> and use something like > >>>> > >>>> static av_always_inline const AVPixFmtDescriptor > >>>> *ff_pix_fmt_descriptor_get(enum AVPixelFormat fmt) > >>>> { > >>>> if (av_builtin_constant_p(fmt)) > >>>> return &av_pix_fmt_descriptors[fmt]; > >>>> return av_pix_fmt_desc_get(fmt); > >>>> } > >>> > >>> yes thats what i was thinking of too. > >>> > >> > >> Seems like Anton is away for a week or so. I am sure he has an opinion > >> on the above approach. I think we will wait for him or shall I apply t= he > >> patches as they are given that they do not block any later alternative > >> solution? > >=20 > > please dont apply code like "IS_BE(BE_LE)"=20 > > iam sure it makes sense to you today but it requires an additional step > > for the reader to understand > > simplest is a seperate endianness and isbe variable. on the wrapper > > that should be less code too but quite possibly you see a better and > > cleaner way > >=20 >=20 > I actually thought that my solution is superior to the one you seem to > have in mind; after all, the parameter for isbe is redundant: It can > also be derived from the pixfmt-name. your solution is supperior in some sense. But iam concerned that it is less readable for a small gain. Maybe BE_LE and others can be renamed to make it immedeatly clear >=20 > >=20 > >> (There is one thing I already don't like about the alternative solutio= n: > >> It relies on av_builtin_constant_p, which not every compiler supports.) > >=20 > > Thats why i didnt suggets to use av_builtin_constant_p() i was hoping y= ou > > saw a better way to achieve it. > >=20 >=20 > Well, without av_builtin_constant_p() the only other way for this would > be to add two systems to get the information, one for compile-time > constants and one for not-constants. Ensuring that the former is only > used for compile-time constants will be a challenge, to say the least. I dont think its a challenge, but iam still quite unsure if this would lead to other issues. For example, if we add a constant lookup function that has direct access to the table. We assue that will only be used where constants are the arguzment. Now its easy to add a extra field to that table and then grep the binary for that. If its found it was either used with a non constant or the compiler failed to optimize it out. This could be a fate test. If it works 100% thats simple but if it works 99% it will be a pain and is not a direction i would suggest, it would be more pain than its worth. So really this is just for discussion at this point, far from a plan with understood consequences thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. U= ser questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. --FhLCAOpkK55HfMa0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYxzEFwAKCRBhHseHBAsP qwAcAJ9aysCp31GVWS74Jyj609wowoPFIACfX7wJpauVMaayYa/Vejl/irGsvWU= =AxcN -----END PGP SIGNATURE----- --FhLCAOpkK55HfMa0-- --===============8999965345887109841== 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". --===============8999965345887109841==--