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

Tomas Härdin git at haerdin.se
Sat Jun 24 12:51:57 EEST 2023

fre 2023-06-23 klockan 23:18 +0200 skrev Michael Niedermayer:
> Hi Tomas
> On Fri, Jun 23, 2023 at 10:10:29PM +0200, Tomas Härdin wrote:
> > No. Absolutely not.
> > 
> > Radio stuff belongs in radio projects such as GNU Radio. This is
> > extreme scope creep.
> > 
> > I can throw an AM detector together in 15 minutes. That doesn't
> > mean it
> > belongs in FFmpeg. You are also treading into modem territory,
> > among
> > other things. Please contribute to actually existing free radio
> > projects instead.
> And DSP belongs in DSP projects, mpeg decoding belongs in libmpeg2
> png, ogg, vorbis belong in their respective projects
> in fact FFmpeg shouldnt exist we should all have been contributing to
> gstreamer
> Wouldnt that be the same line of thought ?
> But seriously there are 2 things.
> Theres myself and what is fun for me to work on (you suggest i
> shouldnt have fun?)
> And there is FFmpeg that is missing any and all SDR support
> Are you planing to add SDR support through some library like GNU
> radio
> to FFmpeg ?

This is begging the question. I don't care what you think is fun, this
is outside the scope of the project. Not everything needs to be
shoveled into FFmpeg master. The UNIX pipe was invented for a reason.
Use radio tools to do radio stuff, then pipe the resulting bitstream or
audio stream into FFmpeg if you need to say transcode DAB to Opus for
streaming on the Web or something.

> I think GNU radio is a poor choice, even just the base package has
> "Installed-Size: 407 MB" that would be huge dependancy to avoid ATM 2
> pages
> of modem code

Ridiculous justification for increasing technical debt in the project.
Modern computers have more than enough disk. GNU Radio supports
offloading processing to on-board FPGAs among other very useful
features for radio work. There are more light-weight options if you
just want AM/FM, that can then be piped to FFmpeg by various means
(jack or named pipes). gqrx for example, which in Debian (gqrx-sdr)
comes to 25 megs of downloads (152 megs on disk) including all
dependencies, which includes gnuradio, gnuradio-dev, gr-osmosdr etc

> also GNU Radio is not LGPL, i think FFmpeg generally prefers
> LGPL over GPL.

This is a non-issue when using pipes.

> Not that i personally have anything against GPL, I like GPL
> but thats not the preferred license in FFmpeg
> do you suggest we should create a libavradio ?
> or can you suggest an existing library that would fit the C + clean
> LGPL style that FFmpeg tends to prefer ?

I am suggesting you follow the UNIX philosophy of having programs that
do one thing well.


More information about the ffmpeg-devel mailing list