Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support

[Paul B Mahol <onemda@gmail.com>]

On Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi
>
> On Fri, Jun 23, 2023 at 06:37:18PM +0200, Rémi Denis-Courmont wrote:
> > Hi,
> >
> > Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer <
> michael@niedermayer.cc> a écrit :
> > >On Fri, Jun 23, 2023 at 10:34:10AM +0800, Kieran Kunhya wrote:
> > >> FFmpeg is not the place for SDR. SDR is as large and complex as the
> > >> entirety of multimedia.
> > >>
> > >> What next, is FFmpeg going to implement TCP in userspace, Wifi,
> Ethernet,
> > >> an entire 4G and 5G stack?
> > >
> > >https://en.wikipedia.org/wiki/Straw_man
> > >
> > >What my patch is doing is adding support for AM demodulation, the AM
> > >specific code is like 2 pages. The future plan for FM demodulation will
> > >not add alot of code either. DAB/DVB should also not be anything big
> > >(if that is implemented at all by anyone)
> >
> > Literally every one of those layer-2 protocols has a lower-level API
> already on Linux, and typically they are, or would be, backends to
> libavdevice.
> >
> > (Specifically AM and FM are supported by V4L radio+ALSA; DAB and DVB by
> Linux-DVB. 4G and 5G are network devices.)
>
> 4 problems
> * FFmpeg is not "linux only".
> * No software i tried or was suggested to me used V4L or Linux-DVB.
> * iam not sure the RSP1A i have has linux drivers for these interfaces
> * What iam interrested in was working with the signals at a low level, why
>   because i find it interresting and fun. Accessing AM/FM through some high
>   level API is not something iam interrested in. This is also because any
>   issues are likely unsolvable at that level.
>   If probing didnt find a station, or demodulation doesnt work, a high
>   level API likely wont allow doing anything about that.
>
>
> >
> > So I can only agree with Kieran that these are *lower* layers, that
> don't really look like they belong in FFmpeg.
>
> FFmpeg has been always very low level. We stoped at where the OS provides
> support that works, not at some academic "level". If every OS provides a
> great
> SDR API than i missed that, which is possible because that was never
> something
> i was interrested in.
>
>
> >
> > >If the code grows beyond that it could be split out into a seperate
> > >library outside FFmpeg.
> >
> > I think that the point is, that that code should be up-front in a
> separate FFmpeg-independent library. And it's not just a technical argument
> with layering. It's also that it's too far outside what FFmpeg typically
> works with, so it really should not be put under the purview of
> FFmpeg-devel. In other words, it's also a social problem.
> >
> > The flip side of that argument is that this may be of interest to other
> higher-level projects than FFmpeg, including projects that (rightfully)
> don't depend on FFmpeg, and that this may interest people who wouldn't
> contribute or participate in FFmpeg.
>
> The issue i have with this view is it comes from people who want nothing to
> do with this SDR work.
> I would see this argument very differntly if it would come from people who
> want to work on that external SDR library.
>
> I mean this is more a "go away" than a "lets work together on SDR (for
> FFmpeg)"
>
>
> >
> > >The size of all of SDR really has as much bearing on FFmpeg as the size
> > >of all of mathematics has on the use of mathematics in FFmpeg.
> >
> > On an empirical basis, I'd argue that FFmpeg mathematics are so
> fine-tuned to specific algorithmic use cases, that you will anyway end up
> writing custom algorithms and optimisations here. And thus you won't be
> sharing much code with (the rest of) FFmpeg down the line.
>
> Iam not sure iam drifting off topic maybe but
> I frequently use code from libavutil outside multimedia
>
> thx
>
>
>
If you are not willing to listen to reviews than you can not collaborate on
FFmpeg project.

I tried to tell you that using this code inside libavformat is mistake. But
you keep ignoring that.

[...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The misfortune of the wise is better than the prosperity of the fool.
> -- Epicurus
> _______________________________________________
> 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".
>
_______________________________________________
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".