Re: [FFmpeg-devel] [RFC] SDR

[Thilo Borgmann <thilo.borgmann@mail.de>]

Am 22.06.23 um 17:01 schrieb 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.

I'd like it and prefer to have SDR natively in FFmpeg. I also think it makes sense to consider it an lavd device, like James.

-Thilo
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".