On 6/23/2023 4:10 PM, Paul B Mahol wrote:
On Fri, Jun 23, 2023 at 8:56 PM Michael Niedermayer <mich...@niedermayer.cc>
wrote:
On Fri, Jun 23, 2023 at 08:17:16PM +0200, Paul B Mahol wrote:
On Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer <
mich...@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 <
mich...@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.
You called me a liar. Which is unacceptable
libavformat is open source code, anyone can add any feature that he wants.
Iam in no way insisting to implement this in libavformat, but sofar its
really the only place (even if the active code would be moved outside, its
still interfacing in libavformat)
Also iam not ignoring anyone. I just move forward and try to implement all
suggestions that i can and that i agree with. Once thats done, we will look
if we have a consensus what to do. That could be git master, it could be
another place, it could include an external lib IF others want to work on
this lib too. Maybe someone has an entirly different suggestion that we
all prefer,
i dont know. We will see
But ATM i find this sdr stuff a bit interresting and so i will continue
to work on it. If me working on free software offends anyone, iam not
sure what to say.
Yes your patches, not just this one, offend all of us:
1. breaks existing functionality and introduces subtle bugs
2. ignoring fixing various bugs and regressions reported on trac
3. introducing new changes and broken features that very fast becomes
unmaintainable.
Feel free to work on own fork/project as you ever want.
Or you could stop being so inflammatory all the time. There are much
more productive ways to prevent or fix all of the things you complain
about above than throwing accusations around.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
