On Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer <mich...@niedermayer.cc> wrote:
> Hi > > On Fri, Jun 23, 2023 at 06:37:18PM +0200, Rémi Denis-Courmont wrote: > > Hi, > > > > Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer < > mich...@niedermayer.cc> a écrit : > > >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 will > > >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 any > 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 provides > 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 argument > 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 other > 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 nothing 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 size > > >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. I tried to tell you that using this code inside libavformat is mistake. But you keep ignoring that. [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The misfortune of the wise is better than the prosperity of the fool. > -- Epicurus > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
