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

[Rémi Denis-Courmont]

Hi,

Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer <michael at 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.)

So I can only agree with Kieran that these are *lower* layers, that don't really look like they belong in FFmpeg.

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

>
>
>> 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
>
>[...]