[FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 18.28.50 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > You can repeat the contrary as much as you want, we do not believe that
> > your SDR code fits in FFmpeg. Why do you not understand this?
> 
> We understand that very well. Once again, it is you who do not
> understand something: your BELIEF that SDR does not belong in ffmpeg is
> nothing more than that, a belief, an opinion, and it weighs nothing in
> front of the argument that some users want it.

"We understand that very well. Once again, it is you who do not understand 
something: your BELIEF tha SDR does beling in FFmpeg is nothing more than 
that, a belief, an opinion, and it weighs" very little in the face of repeated 
technical arguments by several members of the development community as well as 
common sense.

> it weighs nothing in front of the argument that some users want it.

Literally ABSOLUTELY ZERO *users* said that they wanted it, except for Michael 
himself. Other people (including you) did say that they wanted it, yes, but 
none of them were users or even potential users of SDR. Some even explicitly 
said that (although it sounded cool) they would not use it.

So you fail at logical argumentation again.

> > Like no, seriously. If you really want to generic support for AM and FM RX
> > in FFmpeg, then you should use implement frontends for the already
> > *existing* HAL (that would be V4L radio and ALSA on Linux), or perhaps,
> > write a new user- space HAL library that would accomodate both hardware
> > radio RX devices and SDR.
> 
> Did you miss the part where he explained he was not interesting in doing
> it like that?

He said that he did not want to join an existing SDR project. That's 
completely orthogonal.

And in any case, this is one of several technical argument. You cannot 
"disprove" it with the subjective opinions and authority fallacies.

> > In fact, the SDR code has quite a number of impediments that all but
> > guarantee that it will not "catch on" in FFmpeg:
> > - it requires niche hardware,
> 
> Like a few components of libavdevice, that is not an issue.

Err, it is very much an issue w.r.t. "catching on".

You even left the original quote up there. This makes your highly 
intellectually dishonest attempt at distorting my statements all the more 
blatant.

> > - it only works on some limited set of OSes (if not only Linux),
> 
> Like a few components of libavdevice, that is not an issue.

Same thing.

> > - it will be subject to all the FFmpeg processes and drama,
> 
> This problem does not come from SDR, it comes from you.

I was not the one to start this drama (on either side of the argument), and 
there have been plenty more people on my side than yours.  I am indeed part of 
the problem in a sense. Though if I follow that logic, you are a 
proportionally bigger part of the problem, FWIW.

Now you could argue that my argument si a self-realising prophecy. But 
regardless of who is to blame, my argument holds: the drame will continue 
(with or without me, by the way) unless Michael compromises and takes SDR out 
of FFmpeg.git and FFmpeg-devel.

> > - it will be obscured by FFmpeg's existing own fame, remaining an obscure
> > feature set that hardly anybody outside FFmpeg-devel knows about.
> 
> Like a lot of features.

Probably indeed like a lot of features, who failed to catch on and will 
continue to fail to catch on. My point exactly!
 
> Scrapping the bottom of drawers for arguments are you?

I think that I made it clear that this was about how/why SDR will not be 
*popular* inside FFmpeg.

Maybe those are bottom of the drawer arguments against SDR in FFmpeg. That 
does not exactly matter in this context, since that is not what they were 
about.

Also that's an ad hominem attack, which violates the CC.

-- 
Rémi Denis-Courmont
http://www.remlab.net/