From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 6B34447864 for <ffmpegdev@gitmailbox.com>; Tue, 26 Sep 2023 18:03:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 657D368CA32; Tue, 26 Sep 2023 21:03:25 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7970F68C8D0 for <ffmpeg-devel@ffmpeg.org>; Tue, 26 Sep 2023 21:03:19 +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 38QI3HqQ004601 for <ffmpeg-devel@ffmpeg.org>; Tue, 26 Sep 2023 20:03:17 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id B0272EB5BD; Tue, 26 Sep 2023 20:03:17 +0200 (CEST) Date: Tue, 26 Sep 2023 20:03:17 +0200 From: Nicolas George <george@nsup.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <ZRMc5Y4lF8jSfpiW@phare.normalesup.org> References: <NZfwhAB--3-9@lynne.ee> <20230707150654.GX1093384@pb2> <168889764928.542.505537875908829599@lain.khirnov.net> <20230922092754.GV8640@pb2> <169571962013.20400.259576230656271580@lain.khirnov.net> <20230926150947.GM3543730@pb2> <169574221973.6638.5162903459684406928@lain.khirnov.net> <20230926171630.GN3543730@pb2> <10adc5a0-69f2-91f7-49b0-fbd42c4f23f4@gmail.com> MIME-Version: 1.0 In-Reply-To: <10adc5a0-69f2-91f7-49b0-fbd42c4f23f4@gmail.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Tue, 26 Sep 2023 20:03:18 +0200 (CEST) Subject: Re: [FFmpeg-devel] [RFC] Release 6.1 X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: multipart/mixed; boundary="===============5265172057999090138==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/ZRMc5Y4lF8jSfpiW@phare.normalesup.org/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> --===============5265172057999090138== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I3SDZsdMgscA1nRP" Content-Disposition: inline --I3SDZsdMgscA1nRP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable James Almer (12023-09-26): > We don't want you to resign anything. We want a proper discussion in how = to > handle SDR, if at all. Pushing it in a form that everyone agrees is not > ready for upstream is not a good idea. We can agree on this, if we consider that the opinion on whether it is ready of people who have made it clear they will never consider it =E2=80=9Cready=E2=80=9D is to be disregarded, just as much as somebody who = says =E2=80=9Cnak=E2=80=9D to a patch without reasons. > SDR is big, so its API needs to be designed carefully and in an extensible > way. > libavradio must absolutely not be libavdevice redux, and it must have its > own, versatile and extensible API that a lavd device can then work with, > even if not using its full potential, because libavradio can have other > users that will not be constrained to what lavf/lavd can do. SDR **will be** big. SDR **will need** to have its own versatile and extensible API. But the way to get there is to start small. First make it a module, with a very simple API to the rest. Then, as it grows, it acquires utility functions: an internal API that we can change as we discover what it needs. And progressively the API stabilizes and becomes good. Nothing successful starts as a library. Suggesting that a project starts as a library is either an expression of incompetence or a dishonest attempt at killing it. Regards, --=20 Nicolas George --I3SDZsdMgscA1nRP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmUTHOMACgkQcZVLI8pN xgyG7g/8D9kUEJVEoLdfJ6lZYBqtJD0mgAeaqXcSJ9K2WJVRL30aXzaTWZsrBg/k /QC+KY7KYdgychBZFZAcu0lWR+yWnruLAnRrpQKt+9C5I4+mcs0i7bLCgwfz/LDL +e1NzN1aCCHmSfogcANz9eVH030CDar2qemkFd8pLPvQuoQXRwmm4BnYofJdT7VW JCsSnWBprktq5+yooiNIqjo/5OF3Zu/cAWxaueATwFf9OfDgUXL/kbyJqWZ9B6qr usdDiLws+Wtd5SwVGKhWRTmtyYKHMj+F0cB53VPWCIkAa8NgyNnIEpceFOCVm38I yMWYCsMUCX4KqYEEaMSAaD1tWt6Ar95ndf89k3mjW+EA6ym2S0X+juPyRr54p9MY C4MnTt17sDQA2A/Q/tCzMqExI/hbtEeDm8DfmAPJdzVYMyloGJaC7Fw1daUVnu5R A2nx0Q9CE5V8W4Z/lMZPHzemtxkTckHJaInPaMdcE7M2GC5sOPoah3BAQYVBJqB8 1emxoOHL3gijQPm+gpNt/1A72eeVr++3tqvfkynW/8y3bL4Sk6Lg1WJPPgStAOFN wF4nXdTO7ujil7Oulim9VtJeBgK6qz8xXSInWFvLwSqAc7BEPUM5O6WiWVId37p2 WP84AeXPXlJTop7dvM8ZJZVmp4tuaQJYSv36IgLlfpwXbLHbx4Q= =2riq -----END PGP SIGNATURE----- --I3SDZsdMgscA1nRP-- --===============5265172057999090138== 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". --===============5265172057999090138==--