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)
If the code grows beyond that it could be split out into a seperate
library outside 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.


> All without any separation of layers (the problem you currently have)?

Lets see where the review process leads to.
It is possible iam missing some things, its possible others are missing
some factors.
Ultimately sdr is more similar than it is different from existing input
devices and demuxers.
The review process may identify possible solutions that benefit other
input devices too. It might identify shortcommings in FFmpeg that
could lead to improvments.
I dont really enjoy the review process ATM, no ;) but lets see where it
leads to.

Thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato