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 D699B468C0 for ; Sun, 23 Jul 2023 22:56:50 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3F41068C632; Mon, 24 Jul 2023 01:56:48 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8177868C5B8 for ; Mon, 24 Jul 2023 01:56:41 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 93365FF804 for ; Sun, 23 Jul 2023 22:56:40 +0000 (UTC) Date: Mon, 24 Jul 2023 00:56:39 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230723225639.GN7802@pb2> References: <20230722192957.703-1-michael@niedermayer.cc> <20230722192957.703-5-michael@niedermayer.cc> <20230723152304.GJ7802@pb2> <1eba1389c52dead477fa1fd445d5ae918be25951.camel@haerdin.se> <72ef7953-2723-7ffa-eab9-021a84d0e481@gmail.com> MIME-Version: 1.0 In-Reply-To: <72ef7953-2723-7ffa-eab9-021a84d0e481@gmail.com> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support 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="===============7939157627318010802==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7939157627318010802== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7fwXp2o0gOrkU5lS" Content-Disposition: inline --7fwXp2o0gOrkU5lS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 23, 2023 at 04:01:16PM -0300, James Almer wrote: > On 7/23/2023 3:49 PM, Tomas H=E4rdin wrote: > > s=F6n 2023-07-23 klockan 17:23 +0200 skrev Michael Niedermayer: > > > On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote: > > > > Jul 22, 2023, 21:30 by michael@niedermayer.cc: > > > >=20 > > > > > This avoids keeping diffs to fftools in the libavradio repository > >=20 > > No to this entire patchset. > >=20 > > > > > --- > > > > > =A0fftools/ffmpeg.c=A0=A0=A0=A0 |=A0 7 +++++ > > > > > =A0fftools/ffplay.c=A0=A0=A0=A0 |=A0 6 ++++ > > > > > =A0fftools/ffprobe.c=A0=A0=A0 |=A0 6 ++++ > > > > > =A0fftools/opt_common.c | 66 > > > > > ++++++++++++++++++++++++++++++++++++++++---- > > > > > =A0fftools/opt_common.h | 27 ++++++++++++++++++ > > > > > =A05 files changed, 107 insertions(+), 5 deletions(-) > > > > >=20 > > > >=20 > > > > Do you think we should keep this out of the 6.1 branch? > > > > I don't expect packagers to start packaging libavradio immediately, > > > > so I don't feel that strongly about it, but maybe we should let > > > > users test it first in git master for a bit? > >=20 > > Users can test libavradio's master if they wish. Do not assume merging > > this fork will happen, especially not without TC approval, nor that > > trying to sneak it in won't be noticed and opposed. > >=20 > > This patchset makes an even stronger case why this fork should have its > > own mailing list and not pretend it's part of the main project. > >=20 > >=20 > > > about packagers and libavradio. The (more vocal members of the) > > > community > > > wanted sdr in a seperate library and not libavdevice, its likely that > > > distributions will eventually package it, wherever it is. > >=20 > > Why would they package it when there already are mature programs like > > gqrx, dablin etc?=A0Programs that feature separation of concerns. See f= or > > example hacktv which uses ffmpeg, libhackrf and libsoapysdr without > > insisting on being part of either > >=20 > > Another problem is that this would almost certainly cause headaches for > > packagers. I know this because it's going to cause headaches for this > > project to care about maintaining compatibility with a fork that > > doesn't want to pretend it's a fork. >=20 > What bothers me is that even though it's added outside of lavd, it's being > added as a brand new lavd, with all the drawbacks this implies, including= it > being tied to lavf in an awful way. And all for a single "device" > AVInputFormat. It's completely overkill. Its outside because people asked for it to be outside. I thought its bad but its fine really if you look a bit forward >=20 > Why is this libavradio not designed as a standalone library, with its own, > carefully designed API for general radio usage, that can be then glued to > lavd as an AVInputFormat relying on said external library? Doing that wou= ld > also make it usable in other projects that don't want to use the lavf/lavd > API. Because 2 things matter. 1. the final result 2. how to get there efficiently The first step is a demuxer/input device. Whereever it is. (thats what we h= ave now) DAB & DVB can be added too or could be added later No new API is here, so no API can be misdesigned and no API can require to be replaced. Theres also no API we will need to deprecate If we do API first we will have to redo and deprecate it 100% certainly. We have had to frequently redo APIs and that was with things we understood much better. So if we do an SDR API now, probably we would ha= ve to redo it more than once, more so if some of the community boycotts the design or implementation process The second step is users, improvments, bugfixes, figure out what people use= /want/need AFTER this. We are in a position to design the API without being certain th= at we have to redo it immedeatly And here comes the 3rd step, connect libavfilter to libavradio, move the co= mponents into libavfilter. Do demodulation and probing in filters. filters will not need to deal with mpeg-ts or AAC because they would be used by libavradio and return mpeg-ts / AAC to its "caller" And then the 4th step (which can be switched with teh 3rd) Make all the parts available though a new API. At that time we will have a much better understanding of what there is inside libavradio (because its actually implemented) and also what developers want from a libavradio API Here we are in a much better position to actually design a good API. Also at this point many parts can be already used through libavfilter, you need a stereo FM demodulator? there would be a avfilter for that probab= ly. There are other pathes forward but thats the current plan _IF_ this isnt ki= lled off by the community and _IF_ others join and enjoy working on this. Also nothi= ng is cast in stone, this plan is intended to be adapted as needed on the way. I originally just intended to do AM&FM demodulation, and this has become a much bigger project. We already have RDS & metadata support for example But fact is, libavradio exists now. Now the question is will people join and make more out of it or kill it off. Ultimately I cannot do this alone especially not if 90% of replies tell me to fuck off. Theres a point where i will move on and switch the bulk of my time to "not FFmpeg" and just do payed work here. Again, i understand that radio needs an API beyond libavdevices, and i agree but IMO this comes after we have feedback from users what they need&want. And that requires users which requires it to be in a release. thx > A standalone library can link to lavu for any utils it may need. A lavd > device using it wouldn't be the first module using an external library th= at > generates a circular dependency with other lav* libraries. [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. --7fwXp2o0gOrkU5lS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZL2wIwAKCRBhHseHBAsP q/0rAJ4yWxcS4JIekw7aATdd+zjsehQ1VQCeNbSNcQoBuQno8EVTFxp3ILxOuZs= =oVbb -----END PGP SIGNATURE----- --7fwXp2o0gOrkU5lS-- --===============7939157627318010802== 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". --===============7939157627318010802==--