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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 4073 bytes --]

On Sun, Jun 18, 2023 at 02:59:37PM +0200, Lynne wrote:
> Jun 17, 2023, 20:37 by michael@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.

Can you elaborate on how that would work ?

Lets take an example, if i press the right arrow with the current code
it picks the next station to the right which it has previously probed
This may involve reconfiguring the hardware if that station is outside
the captured frequency range.
if there is no such station it will instruct the hardware to move the
vissible frequcny window to the right for 3-4 blocks and then move to
the right again and so on until a suitable station is detected.

if libavformat gets the data from the hardware and libavfilter demodulates
this becomes much more complex because both components need to act together
for moving to the next station

next problem:
with DAB /DVB the output from demodulation is compressed AAC/H.264 and such
we would have a AAC output from a libavfilter. That needs to go to libavcodec
or a muxer.
if everything is in a demuxer as in the patch, that would just work. But from
libavfilter theres no clean way to do this currently as libavfilter sits
after the decoder and now would need to get data in before the decoders.

Also there are a few little issues here and there, like channels starting and
stoping transmission (for example air traffic control and pilots do not
continously transmit but just when they speak and also depending on distance
with aircrafts moving, so channels would increase over time.
a demuxer can easily add channels later, iam not sure how well libavfilter
can do this ATM


> There are applications for which you'd
> like to store the raw Mhz/Ghz audio data as well as the
> decoded data.

That is actually already possible (it had some bugs in the patch submitted so
i need to submit a v2) you can just use the "-dumpurl" option to store the raw
data prior to any processing.



> Additionally, filters can receive commands, while demuxers can't,
> so switching stations would be simpler.

That can be fixed if needed

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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