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 4F3E345FE8 for ; Fri, 28 Apr 2023 13:53:07 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AB8D068BFE2; Fri, 28 Apr 2023 16:53:04 +0300 (EEST) Received: from nef.ens.fr (unknown [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 797E568BF10 for ; Fri, 28 Apr 2023 16:52:57 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 33SDquFm017196 for ; Fri, 28 Apr 2023 15:52:56 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id 8BE96EB5C0; Fri, 28 Apr 2023 15:52:56 +0200 (CEST) Date: Fri, 28 Apr 2023 15:52:56 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20230427142601.2613-1-anton@khirnov.net> <20230427142601.2613-8-anton@khirnov.net> <4d9e2ce9-fdfb-3fcd-bd7d-07d9bbe5860d@gmail.com> MIME-Version: 1.0 In-Reply-To: <4d9e2ce9-fdfb-3fcd-bd7d-07d9bbe5860d@gmail.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Fri, 28 Apr 2023 15:52:56 +0200 (CEST) Subject: Re: [FFmpeg-devel] [PATCH 08/21] fftools/ffmpeg_filter: add filtergraph private data 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="===============3765909058146185563==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============3765909058146185563== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rIgKTTCHGpbnkV0l" Content-Disposition: inline --rIgKTTCHGpbnkV0l Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable James Almer (12023-04-28): > The longtime goal of this work is to have completely standalone modules > within the CLI and each of them threaded. So while ffmpeg may not be a > library, clearly defining what fields should be accessed from "the outsid= e" > and which shouldn't would have the same effect and benefits as if it was > one, particularly ensuring no future accidental usage of fields that shou= ld > not be touched. The decoder side for example has no need to touch a frame > the filtering side is using internally, and more so if it could result in > races. >=20 > There's also the fact Anton is maintaining this code and this helps him k= eep > track of the nature of each field, plus the fact this same change has been > done before elsewhere, so if you're going to argue you don't like it beca= use > in your opinion it's unnecessary, then that's not enough grounds to block > it. (As Anton repeatedly said he does not accept the usefulness of the role of maintainer, invoking that last argument feels a little like trying to have it both ways. But since I do acknowledge the usefulness of maintainers, I do accept it.) Thanks. This is slightly more convincing than what was explained until now. But there are ways of clearly stating which fields are internal and which fields are ok for outside access without littering the code with casts, because fgp_from_fg() and co. are exactly that. And during the work of turning all into threads, opportunities to split the structure in more logical ways with less code noise will almost certainly present themselves. Anyway, I find it sad that in the recent years FFmpeg has more and more followed =E2=80=9Cgood practices=E2=80=9D not because, being good, they bri= ng actual benefit to the code but just because they're =E2=80=9Cgood practices=E2=80= =9D. We are not underskilled Java developers following the rules from the textbook without understanding their purpose; we are FFmpeg, we try new and original ways of writing code to make it more efficient and more elegant. FilterGraphPriv is neither efficient nor elegant. But if I failed to convince you or others with this mail, I will not fight this anymore. Regards, --=20 Nicolas George --rIgKTTCHGpbnkV0l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmRLz7YACgkQcZVLI8pN xgzA5RAAq3s9EGA/g+stiwcoEDsrsJUWpsf2FKPC7kGaBh2HD0Kn0++9jCmZl0K/ VrFMRyvTElEcM7aOSJq8qtgvuzENnERUpspOQWx/me5lvQ4zsM9G8dOIYu5UwtoU MNqne+467gPcBAVBlFctMumc2Zt4HaB5ZDIlhlikC2lDj3RQb7RdE5jbY/RWOKqJ 8+BbqK4ovL0GBgHyR+bxQr5RHf/CBVA31S1bP32Zs8sXruPbwsrGM+J0pi/5X5pu GLujqCBOlU4UxIp71c5ygNAYvvSlxdBCPGI9ujANCCZqX6ClRtrctlDlFkTVCkDS sqZoAiwoC7CFCkandtaYQqQ5IsQZlWnyoufwH3QL14mOyT3UBN88SycsI/ACc3De 95+S6ZaKKIZhZTPEU/zzwgZtsPSLjbKsSImj+fQ1hmCr4/+w/2es5e70EzI8owmv dDIUcAuvpl+4w6NwryOY3zdUQKAyUf0a2rHaKDXjv/YcjIWztjNqYqCUY8x8MXPC gpJ/aPhj9t5cqkYUsqrWoS1xq15vnl4j6kOqUjotL+Dl5LD58xttZGQpPMC298zi 2B/wrfyl9OvRSRqp9qe+1ef6pxB9NTUoGQjy8lz+nFi2g6Zb2p9vB2HZAsYK8S4I XidljAxFMZ8x9TIn4JR23dRo7JXjb5Vsq4rdFylHTFu2YAftKXs= =LHwF -----END PGP SIGNATURE----- --rIgKTTCHGpbnkV0l-- --===============3765909058146185563== 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". --===============3765909058146185563==--