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

[Tomas Härdin]

lör 2023-06-24 klockan 23:01 +0200 skrev 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:
> > > 
> > > 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.

If you want to listen to AM broadcasts then there are already plenty of
programs to do that. If you want to skim the bands for interesting
broadcasts there are tools for that as well. Have you even done basic
research to see what is out there?

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

Yeah because different applications call for different tools. You
cannot do RADAR or WiFi on the CPU. Hence why there's a sophisticated
set of tools for doing radio stuff already. Tools that could use more
developer effort.

> where ATM its just 2 pages of modem related code

All the better reason to nip it in the bud.

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

Fun for you is technical debt for everyone else.

> 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

More technical debt is worse, not better.
> > 

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

Why would anyone use ffmpeg to do radio stuff when there already are
superior tools for doing it? Tools that play better with ALSA etc.

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

This already exists. Ask your local radio amateurs and they will point
out oodles of programs for you. or apt search amateur radio

> autodetecting modulations and demodulating the selected station.

lol

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

You are suggesting writing a skimmer that somehow figures out what
modulation is used. Meanwhile what people actually do is rely on the
band plan, because shit is difficult enough as it is. Broadcast FM
channels can be mono, or stereo, or forego stereo for subcarriers in
different languages. Plus you have digital data in there, and
mechanisms for emergency broadcast switchover.

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

There is no reason why your own personal experiments should contaminate
master.

/Tomas