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

["Rémi Denis-Courmont" <remi@remlab.net>]

Le sunnuntaina 25. kesäkuuta 2023, 1.19.04 EEST Nicolas George a écrit :
> Michael Niedermayer (12023-06-23):
> > * What iam interrested in was working with the signals at a low level, why
> >   because i find it interresting and fun.
> 
> Then this is what you should be spending your time on, and to hell with
> anybody who says otherwise.

Straw man much? The argument is that SDR does not belong in FFmpeg master, not 
that Michael cannot do SDR in his free time.

> Unless you have commitments that we are not privy of, nobody can tell
> you how you are supposed to be spending your time and skills.

FYI https://fflabs.eu/about/

> Nobody can force you to manage releases and fix fuzzing bugs and do all the
> things you do that are necessary to the project. Necessary to a conception
> of the good of the project that is not even your own I think.

Same straw man argument.

> Nobody can prevent you from hacking the things that motivate you. At
> worst, they can prevent you from committing the resulting code into
> official FFmpeg. That would be the project's loss,

Not cluttering an open-source project is generally considered to be a win, not 
a loss. Less maintainance work and smaller code size.

> and you can still
> publish it on a private branch. But they do not have the power to block
> you from pushing.

> It is not even clear they have the authority do block
> you, more so if the code is really good and fits FFmpeg well.

...which it doesn't.

"A complete, cross-platform solution to record, convert and stream audio and 
video" is how the official website defines FFmpeg...

Radio waves (outside the visibible spectrum) are neither audio nor video.

[Gratuitous slander removed]

> I am especially annoyed by the “it's too hard” naysayers

Nobody said that it was too hard. The complexity argument was that DAB & DVB 
is much more complicated than AM and FM, which they indeed are by any 
reasonable objective metric, not that Michael wouldn't be able to implement 
them.

> They do not realize they reveal more about their own skills than anybody
> else.

It only tells that they have (at least) a rudimentary understanding of radio 
waves to figure out that DAB or DVB are much more complex signals than FM or 
AM.

Maybe among the general public that would be telling some. Among ffmpeg-devel, 
I think it really tells nothing because just about everybody here would know 
or be able to guess that much.

> But the whole attitude who wants FFmpeg to be a Serious OpenSource TM
> Project, who needs to make releases and worry above all about ABI
> stability, is really the attitude who is killing all the fun in working
> on FFmpeg.

Michael, you or really anyone is more than welcome to fork and have their fun 
coding on FFmpeg *outside* the community project, if they cannot have it 
within the framework that is that community.

Meanwhile, they are dozens of people, ostensibly including Michael himself, 
that depend on FFmpeg being "Serious OpenSource TM" in some way, for their 
livelihood, and millions for their computer use. You don't get to ruin that, 
and if you try, you will first be blocked by the TC, and if you try harder, you 
will be kicked by the CC.

It looks to me that some people need to learn that not every piece of code 
they write or intend to write belongs in upstream FFmpeg.

> Hey, people, realize FFmpeg does not exist to be a Serious OpenSource TM
> Project, FFmpeg does not exist to serve other projects, to serve
> companies who benefit from it give the bare minimum back.

It also does not exist to be your playground, especially not at the expense of 
other people. And it has certainly not evolved that way for the past 20 or so 
years.

> FFmpeg exists because some day a dude thought it would be fun to write a
> MPEG decoder.

> And everybody else told him it would be too hard,
> everybody else told him to use an existing library and to leave it to
> the professionals. He did not believe them and proved them utterly
> wrong, and the rest, as the saying goes, is history.

And? That is completely irrelevant to the question whether (and if so how) SDR 
should be integrated in FFmpeg.

> So I will say it explicitly. We — me, and everybody who agrees with me —
> do not want to just maintain a bunch of wrappers for the convenience of
> others, we want to have fun writing interesting code, trying new ways of
> doing things, inventing original optimizations. We can find a balance
> and work on useful things too. But if you want us to work only on the
> boring useful things, if you want to bar us from working on fun things,
> then just fork you.

To paraphrase you, the fact that you can throw such an argument with a 
straight face tells a lot.

So what if, for the sake of the argument, people's subjective notion of 
discretionary fun is writing FFmpeg code in a project that excludes you?


This is tiring, I'll leave it at that.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



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