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 3C3B9468BA for ; Fri, 23 Jun 2023 18:56:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 99CAC68C19B; Fri, 23 Jun 2023 21:56:37 +0300 (EEST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 97ADB68C0CC for ; Fri, 23 Jun 2023 21:56:30 +0300 (EEST) X-GND-Sasl: michael@niedermayer.cc Received: by mail.gandi.net (Postfix) with ESMTPSA id C957FC0009 for ; Fri, 23 Jun 2023 18:56:29 +0000 (UTC) Date: Fri, 23 Jun 2023 20:56:29 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230623185629.GO3250409@pb2> References: <20230618222805.4054410-1-michael@niedermayer.cc> <20230623111728.GM3250409@pb2> <59E3CAAC-DA7F-424B-ABC1-1E300EA83571@remlab.net> <20230623181241.GN3250409@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio 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="===============6579818026611562939==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6579818026611562939== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kVcb4xucqmsYUpQy" Content-Disposition: inline --kVcb4xucqmsYUpQy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 23, 2023 at 08:17:16PM +0200, Paul B Mahol wrote: > On Fri, Jun 23, 2023 at 8:12=E2=80=AFPM Michael Niedermayer > wrote: >=20 > > Hi > > > > On Fri, Jun 23, 2023 at 06:37:18PM +0200, R=C3=A9mi Denis-Courmont wrot= e: > > > Hi, > > > > > > Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer < > > michael@niedermayer.cc> a =C3=A9crit : > > > >On Fri, Jun 23, 2023 at 10:34:10AM +0800, Kieran Kunhya wrote: > > > >> FFmpeg is not the place for SDR. SDR is as large and complex as the > > > >> entirety of multimedia. > > > >> > > > >> What next, is FFmpeg going to implement TCP in userspace, Wifi, > > Ethernet, > > > >> an entire 4G and 5G stack? > > > > > > > >https://en.wikipedia.org/wiki/Straw_man > > > > > > > >What my patch is doing is adding support for AM demodulation, the AM > > > >specific code is like 2 pages. The future plan for FM demodulation w= ill > > > >not add alot of code either. DAB/DVB should also not be anything big > > > >(if that is implemented at all by anyone) > > > > > > Literally every one of those layer-2 protocols has a lower-level API > > already on Linux, and typically they are, or would be, backends to > > libavdevice. > > > > > > (Specifically AM and FM are supported by V4L radio+ALSA; DAB and DVB = by > > Linux-DVB. 4G and 5G are network devices.) > > > > 4 problems > > * FFmpeg is not "linux only". > > * No software i tried or was suggested to me used V4L or Linux-DVB. > > * iam not sure the RSP1A i have has linux drivers for these interfaces > > * What iam interrested in was working with the signals at a low level, = why > > because i find it interresting and fun. Accessing AM/FM through some = high > > level API is not something iam interrested in. This is also because a= ny > > issues are likely unsolvable at that level. > > If probing didnt find a station, or demodulation doesnt work, a high > > level API likely wont allow doing anything about that. > > > > > > > > > > So I can only agree with Kieran that these are *lower* layers, that > > don't really look like they belong in FFmpeg. > > > > FFmpeg has been always very low level. We stoped at where the OS provid= es > > support that works, not at some academic "level". If every OS provides a > > great > > SDR API than i missed that, which is possible because that was never > > something > > i was interrested in. > > > > > > > > > > >If the code grows beyond that it could be split out into a seperate > > > >library outside FFmpeg. > > > > > > I think that the point is, that that code should be up-front in a > > separate FFmpeg-independent library. And it's not just a technical argu= ment > > with layering. It's also that it's too far outside what FFmpeg typically > > works with, so it really should not be put under the purview of > > FFmpeg-devel. In other words, it's also a social problem. > > > > > > The flip side of that argument is that this may be of interest to oth= er > > higher-level projects than FFmpeg, including projects that (rightfully) > > don't depend on FFmpeg, and that this may interest people who wouldn't > > contribute or participate in FFmpeg. > > > > The issue i have with this view is it comes from people who want nothin= g to > > do with this SDR work. > > I would see this argument very differntly if it would come from people = who > > want to work on that external SDR library. > > > > I mean this is more a "go away" than a "lets work together on SDR (for > > FFmpeg)" > > > > > > > > > > >The size of all of SDR really has as much bearing on FFmpeg as the s= ize > > > >of all of mathematics has on the use of mathematics in FFmpeg. > > > > > > On an empirical basis, I'd argue that FFmpeg mathematics are so > > fine-tuned to specific algorithmic use cases, that you will anyway end = up > > writing custom algorithms and optimisations here. And thus you won't be > > sharing much code with (the rest of) FFmpeg down the line. > > > > Iam not sure iam drifting off topic maybe but > > I frequently use code from libavutil outside multimedia > > > > thx > > > > > > > If you are not willing to listen to reviews than you can not collaborate = on > FFmpeg project. >=20 > I tried to tell you that using this code inside libavformat is mistake. B= ut > you keep ignoring that. You called me a liar. Which is unacceptable libavformat is open source code, anyone can add any feature that he wants. Iam in no way insisting to implement this in libavformat, but sofar its really the only place (even if the active code would be moved outside, its still interfacing in libavformat) Also iam not ignoring anyone. I just move forward and try to implement all suggestions that i can and that i agree with. Once thats done, we will look if we have a consensus what to do. That could be git master, it could be another place, it could include an external lib IF others want to work on this lib too. Maybe someone has an entirly different suggestion that we all= prefer, i dont know. We will see But ATM i find this sdr stuff a bit interresting and so i will continue to work on it. If me working on free software offends anyone, iam not sure what to say. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. --kVcb4xucqmsYUpQy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZJXq2AAKCRBhHseHBAsP q5FaAJ9qoWOxxDcYWbWHRD3hYHjYazRtnwCgk5iqTB8FiocNO+IR+bMCJJzEk3M= =ZG6k -----END PGP SIGNATURE----- --kVcb4xucqmsYUpQy-- --===============6579818026611562939== 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". --===============6579818026611562939==--