Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3064 bytes --]

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 <michael@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 <michael@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 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".