[FFmpeg-devel] [PATCH 5/5] avformat: add sdr support

Lynne dev at lynne.ee
Sun Jun 18 16:45:37 EEST 2023

Jun 18, 2023, 15:30 by h.leppkes at gmail.com:

> On Sun, Jun 18, 2023 at 2:59 PM Lynne <dev at lynne.ee> wrote:
>> Jun 17, 2023, 20:37 by michael at niedermayer.cc:
>> > On Sat, Jun 17, 2023 at 08:08:11PM +0200, Paul B Mahol wrote:
>> > [...]
>> >
>> >> Which library handles compressed stuff?
>> >>
>> >
>> > For digital stuff like DAB/DVB/...
>> >
>> > sdrdemux in libavformat will demodulate, do error correction then return  AVPacket
>> > with H.264 / Mpeg2 video or AAC or wahetever
>> > That then will get passed to libavcodec, same as with any other demuxer.
>> >
>> > This code is not written yet. There is just analog AM demodulation. I posted
>> > this patch as soon as the first usecase worked
>> >
>> > usecase was "listen to random AM radio stations in ffplay" :)
>> > and it can also grab all AM stations in a 10Mhz window and demodulate all
>> > (that 10mhz is what my hw and usb bandwidth can do max)
>> >
>> > I intend to add FM demodulation, because it seems a fun thing to try to do.
>> >
>> > someone will need to add DAB/DVB support, I would be happy if someone else
>> > comes forth to do that. If noone does ill think about if i want to do it
>> > or not once FM is done and once this is in git.
>> >
>> > The initial reaction from some was a bit spicy, so i need to think
>> > how much fun this is in FFmpeg.
>> > But one thing i can say for sure, is, if i cannot use this in ffplay
>> > then it makes no sense for me to put more time into it
>> >
>> > We could implement seeking to next/previous stations differently but
>> > it seems a bit like creating extra work for everyone.
>> > I mean a new API in sdrdemux then ffplay needs to support that and then
>> > other players would need to support it and so on. While really the
>> > seeking on a realtime input has no other use
>> >
>> I like the new functionality, but I too think that libavformat
>> should just source the data from a device, and that libavfilter
>> should demodulate.
> And how do you deal with the prospect of future digital audio,
> outputting a compressed bitstream?

I don't think anyone has thought that far ahead yet. The goal of the
patch is to decode pure analog audio.

If I may theorize for a moment:
swr would return AVERROR(ENOSUP).
an encoder would do the decoding to a wrapped_avframe?
a new lavc api to decode avframes?
There was some work to unify avpackets into avframes in the libav days AFAIK.
Nothing good at all, pure guesswork.

Before someone starts bikeshedding, let me point out that
having lavfi demodulate does make the current patch better IMO
and that any discussion on compressed frames should be handled
*in a different thread*.

More information about the ffmpeg-devel mailing list