[FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Neal Gompa]

On Sat, Sep 23, 2023 at 6:55 AM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Sat, Sep 23, 2023 at 02:49:47AM -0400, Neal Gompa wrote:
> > On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
> > <michael at niedermayer.cc> wrote:
> > >
> > > On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> > > >
> > > > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > > > Hi all
> > > > >
> > > > > As the 6.1 release is upcoming and as it was previously stated by me that sdr
> > > > > will be part of 6.1. Heres some update of what i intend to do about that.
> > > > >
> > > > > People previously agreed to including a SDR input device in libavdevice with
> > > > > SDR in a seperate library.
> > > > >
> > > > > If the community and the SDR code are happy with each other before the release
> > > > > then SDR will simply be merged and be part of 6.1 like any other feature.
> > > > >
> > > > > OTOH If a majority of people are against the SDR code at the time of
> > > > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > > > the SDR code and of course also provide security support
> > > > What does this mean? Does this mean an FFmpeg release containing code that
> > > > interfaces with your SDR library? Or does it mean the library fully
> > > > integrated into FFmpeg?
> > >
> > > It depends on the code at the time of release. ATM there is no seperate
> > > library, just a SDR input device.
> > > creating a separte library and the related API/ABI needs to be done with
> > > thought and care not something to rush quickly.
> > >
> >
> > What does this code *do*? All these arguments about the SDR code, and
> > I haven't seen it myself (because the email patch workflow really
> > makes it hard to track this stuff down, and I assume it was submitted
> > on list somewhere?)
> >
> > If it's just taking SDR devices as inputs and allowing you to encode
> > audio and video streams, I'm not sure why you *wouldn't* have this as
> > something in libavdevice or extended from it as a separate library.
>
> Yes thats correct
>
> Let me try to describe what it does in more detail. Ill keep the HW
> side very simplified here as it doesnt matter.
>
> The HW side:
> You start with an Antena (wire) connecting to a SDR dongle (which is
> basically a analog->digital converter capable to take a piece of
> radio spectrum and digitizing it) then generally a USB cable and
> then with some intermediate drivers follow our SDR code
> (The implementation of the HW is much more complex but that above
>  is what it does from a high level view)
>
> The libavdevice SDR code:
> The digital radio spectrum piece is then analyzed. AM and FM stations
> identified and demodulated into AVStreams. The user can ask for all or
> one station to be demodulated. Digital metadata (RDS) is demodulated too
> and put in AVStream.metadata
> Optionally, the radio spectrum can also be returned in the form of a video
> stream so one can see where radio stations are within the piece of the
> spectrum (like a spectrum analyzer). And the seek keys can be used to
> move between stations and to move the piece of the radio spectrum returned
> by the hardware (giving also the functionality of an old radio with next/prev
> station buttons)
>

So it's not *really* SDR in the sense that most people talk about it,
it's actually more about classical radio in software. That seems more
than reasonable to support in FFmpeg. If we were talking about some of
the crazy things people do with SDR, I would think that's
inappropriate. But being able to decode AM/FM/SiriusXM and listen to
it on a Linux machine is nice enough.

I suppose the logical extension would be to be able to integrate
support for handling analog and digital TV signals, eventually?

I can see the argument that it'd be better as a separate project, but
offhand I actually don't know of any that do this now...

I guess this would be called libavradio or something like that?





--
真実はいつも一つ！/ Always, there's only one truth!