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

From: Kieran Kunhya <kierank@obe.tv>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Date: Fri, 23 Jun 2023 19:36:53 +0800
Message-ID: <CAK+ULv7mwASCnfwpmGQCFgjDPAWtDANyV8WKaj5QByrh7_vBwg@mail.gmail.com> (raw)
In-Reply-To: <20230623111728.GM3250409@pb2>

On Fri, 23 Jun 2023, 19:17 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> 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

It's not a straw man, I'm asking why you want to add layers far below
multimedia to ffmpeg. All of those examples are similar examples of
physical layers.

> 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)
> If the code grows beyond that it could be split out into a seperate
> library outside FFmpeg.
>

Then just put it in a library outside of FFmpeg to begin with. DVB-T2 and
S2 are very complex to implement well. AM and FM are toys in comparison.

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

I have no idea what this means, mathematics is needed in multimedia, SDR is
not.

> > All without any separation of layers (the problem you currently have)?
>
> Lets see where the review process leads to.
> It is possible iam missing some things, its possible others are missing
> some factors.
> Ultimately sdr is more similar than it is different from existing input
> devices and demuxers.
> The review process may identify possible solutions that benefit other
> input devices too. It might identify shortcommings in FFmpeg that
> could lead to improvments.
> I dont really enjoy the review process ATM, no ;) but lets see where it
> leads to.
>

No input device needs to do active mathematical processing on the data at a
analogue layer. SDR isn't similar at all.

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