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

[Michael Niedermayer]

On Sat, Jun 24, 2023 at 11:51:57AM +0200, Tomas Härdin wrote:
> 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.

We will have to agree to disagree here.
all other sources of audio and video work conveniently in FFmpeg
I can also play a video and switch subtitle and audio streams with a
button not have to use a external demultiplxer and choose the streams
before starting the player.


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

somehow you swing between extreems here
first its pipes or nothing now we need FPGAs
where ATM its just 2 pages of modem related code


> 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

I think we somehow are not talking on the same frequency ;)
if i want just AM/FM i need 10 pages of code max and writing these
pages is a fun thing to do for me.
No external dependancy belongs in FFmpeg to avoid 10 pages of code
That dependancy causes us MUCH more pain than these 10 pages of code
in fact interfacing to that dependancy might need more code

A dependancy makes sense only if it provides an _advanatge_ for us


> 
> > also GNU Radio is not LGPL, i think FFmpeg generally prefers
> > LGPL over GPL.
> 
> This is a non-issue when using pipes.

How many users do use multimedia players with pipes ?
you sure can have decoder demuxer protocol and video display
and connect all by pipes. Why is noone doing that and just
calls vlc ?


> 
> > 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
> > ASM
> > LGPL style that FFmpeg tends to prefer ?
> 
> I am suggesting you follow the UNIX philosophy of having programs that
> do one thing well.

Sure, but again it doesnt do it

The 3 cases iam thinking of ATM are

1. A libavcodec / libavformat / libavfilter based player which allows going
through the radio spectrum, vissually displaying what is there autodetecting
modulations and demodulating the selected station.

2. FFmpeg being able to simply be given a piece of radio spectrum and detect and
demodulate everything in that part independant of what modulations are there and storing
that all in a multimedia file like matroska or nut.

3. as a fun excercise about SDR, modulations and related math.

I dont know how to do any of these even with pipes and unmodified ffmpeg

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230624/fac42ae6/attachment.sig>