[FFmpeg-devel] [RFC] SDR

[James Almer]

On 6/22/2023 11:57 AM, Michael Niedermayer wrote:
> Hi all
> 
> My humble opinion(s) and plan(s) about SDR
> 
> FFmpeg as a multimedia framework should support SDR.
> 
> The only practical way to support SDR in FFmpeg ATM is through a demuxer (or equivalent)
> Not everyone is happy about a SDR demuxer.
> 
> The "active" code could be in the demuxer itself or an external library.
> 
> I think the 2 important factors for external vs internal are
> 1. Does it support features beyond what a multimedia framework needs?
> 2. How many active developers work on it
> 
> If we support just audio and video (de)modulation it fits nicely in FFmpeg
> maybe we should consider improving the APIs we have so we have better places
> than demuxers for functionality like this, but thats a long term goal that
> requires a team effort or a dedicated volunteer. Its not a bad idea at all and
> I certainly am in favor for improving the APIs.
> 
> OTOH if we support things beyond audio/video, maybe wifi packets, bluetooth
> and so forth then SDR should be a seperate library.
> 
> Also this choice is not a constant, we can easily start out inside libavformat
> and
> * if sdrdemux grows beyond what makes sense in FFmpeg split it out into an external
>    libraray
> * if APIs in FFmpeg evolve so that other places become possible, move it into
>    libavfilter or whatever other place fits better
> 
> What i would suggest is:
> * get the current code or revission of it into the git master branch as a demuxer.
> * see how many people enjoy working on SDR and how far these people want to take it
> * keep an open mind about the future of this code, and move it elsewhere when it
>    makes sense to do so.
> * ATM i think incubating this SDR stuff in FFmpeg and have it grow makes more sense
>    than having it in a seperate place and a demuxer in FFmpeg depending on that.
> 
> PS: Also something like plugins would help for things like this. As one could then
> maintain code like a sdr-demuxer outside the main repository. So noone who doesnt
> like it needs to touch it in any way while users who want it can easily enable
> it ...
> 
> Thx

Add it as an input device in lavd, since it's after all a capture 
device. Share the common code with the "file" demuxer in lavf using 
avpriv, since lavd and lavf are completely intertwined.

Just my 2 cents.