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