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 519CF46A70 for ; Wed, 2 Aug 2023 14:20:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8F78668C63C; Wed, 2 Aug 2023 17:20:34 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 14AD068C62C for ; Wed, 2 Aug 2023 17:20:28 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 6E8AF20003 for ; Wed, 2 Aug 2023 14:20:27 +0000 (UTC) Date: Wed, 2 Aug 2023 16:20:26 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230802142026.GI7802@pb2> References: <20230802125521.GG7802@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] What is FFmpeg and what should it be 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="===============2985704683706787774==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2985704683706787774== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xU0InBYDQy8cK3qi" Content-Disposition: inline --xU0InBYDQy8cK3qi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 02, 2023 at 02:59:11PM +0200, Jean-Baptiste Kempf wrote: > On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote: > > the code already is in a seperate repository. And is basically isolated > > in a single demuxer and single input device. >=20 > But it's not a library in that repository, like swscale, swresample or si= milar libraries. >=20 > If it was, with an API, it would be trivial to add support to this option= al library as an FFmpeg module, and noone who complain. There are multiple problems but the real problem is that How many people discuss an SDR API ? (0) How many people propose an SDR API ? (0) How many people say what they want an SDR API to be able to do ? (0) This is not a simple question ? enumerate devices, set options, open, read frames, close ? That does no= t differ from the existing input device / demuxer API. If one cannot state a single difference in the API requirements from th= e existing input device API, how can one design that API ? If the existing input device API suposedly is not good Is it bad just because it is the existing API ? And it would be perfect= ly fine if it just had different function names ? In other areas the community collaborates to create APIs here all energy is spend to block patches (the latest set blocked are pure = bugfixes) Also swresample and swscale are simpler in what they need to provide API wi= se. My very first patch i sent btw was blocked with the claim that it used an external library and did not do the processing nativly. Thats exactly what you suggest now IMHO, People who want to use this API, or want to implement this API should help with the API design and implementation And if there are 0 people wanting to use the API then why should i design that API ? who for ? SDR in FFmpeg has 500+ users who want it, the API iam not sure has a user People who have no intend to use the API or SDR or implement either should not represent 99% of whom approv / reject the code This is a problem, because it leads to bad code. The people telling me what to do dont care about the results one day its "not external lib", then its "external lib" then its "libavfilter" then its "not libavfilter" Again we had 0 that is ZERO discussions about an SDR API. where does it start ? a hw enumerate, a soapy device, a void * representing a SDR data stream from something like soapy soapy is full of bugs, for the code to work we need to know where the data came from and we need to interact with the hw should we provide a layer over all of libsoapy ? should we support only libsoapy and take a device from libsoapy as input should we have a generic input support that libsoapy is one of several options ? I cannot design this API with this. because 3 out of 4 choices will get attacked and blocked if not all 4, if someone just implements it. because people are unwilling to think about anything they just think they know how it must be done and they dont discuss anything they just demand and attack and wait how the next patchset looks. Eventually everyone then looses interrest and a patchset goes through but thats not good design. So again, IMHO people should help design and implement this API if they want an API. If i have to design an API by trial and error until it gets no unspecific objections by people not interrested in using it thats not going to be an API that anyone will want to use. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopp= ed=20 leading them. They have either lost confidence that you can help or conclud= ed=20 you do not care. Either case is a failure of leadership. - Colin Powell --xU0InBYDQy8cK3qi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZMpmJgAKCRBhHseHBAsP qy6jAJ4ucYU+BJwUORBnhtTes/pC4mCNfgCfVZLuXw9CmUcHOWDDUVbx+WrHdFI= =U9XL -----END PGP SIGNATURE----- --xU0InBYDQy8cK3qi-- --===============2985704683706787774== 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". --===============2985704683706787774==--