On Sat, Jun 24, 2023 at 10:27:13PM +0200, Rémi Denis-Courmont wrote: > > > Le 23 juin 2023 20:12:41 GMT+02:00, Michael Niedermayer > <mich...@niedermayer.cc> a écrit : > >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". > > And then what? Whether you like it or not, radio signal processing sits on > top of OS-specific APIs to access whatever bus or hardware. You can't make > this OS-independent whether it's in FFmpeg or elsewhere. > > At best you can write or reuse platform abstraction layers (such as libusb). > Maybe. > > In other words, whether this ends up in FFmpeg or not has absolutely no > bearing on this "problem" as you call it. > > But it doesn't end here. Audio input on Linux is normally exposed with ALSA > modules (hw/plughw if the driver is in kernel, but it doesn't have to be), > and other OSes have equivalent APIs. A sound (pun unintended) implementation > of AM or FM would actually be an ALSA module, and *maybe* also PA and PW > modules. (They don't have to be kernel mode drivers.) > > ...Not an FFmpeg device or demux. >
speaking of layers. IMHO the kernel and driver layer should end with the IQ data for SDR. Thats OS specific. After that the whole chain should be largely OS and HW independent turning IQ data to a decoded video and audio stream for DVB is the same on every OS as complex as it may be. We could feed this back into ALSA on linux but i doubt that would be used alot more likely players would link to the library directly that turns IQ -> video+audio even more so because for the player it would be the same on every platform otherwise the player would have to support platform specific interfaces and not just one per platform either i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
signature.asc
Description: PGP signature
_______________________________________________ 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".
