Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support

From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Date: Tue, 25 Jul 2023 11:33:12 +0200
Message-ID: <ZL+W2ECto5x+bTqn@phare.normalesup.org> (raw)
In-Reply-To: <8396bdd379b9244a79ee045bb85f9e96b2fbfee6.camel@haerdin.se>

[-- Attachment #1.1: Type: text/plain, Size: 2732 bytes --]

Tomas Härdin (12023-07-24):
> Features either are or aren't in scope. I don't see how you can
> compromise on that.

The scope is what we decide it is, collectively, based on arguments.
Your conception of the scope is only a small part of that, and even
smaller if you cannot sustain it with arguments.

“I don't see how you can compromise on that” is called dogmatism and has
no place in this project.

The way I see it, avradio has about as much or as little its place in a
project that historically contained software implementations of the
major and minor multimedia codecs as hardware acceleration.

Yet support for hardware acceleration has been added, to the convenience
and satisfaction of everybody.

> The Linux kernel also has separation of concerns. It has a concept of
> userland for example, unlike say TempleOS. Not everything is in scope
> for the Linux project.

Yet features have repeatedly made back and forth between kernel and
userland and mixed implementations, searching for the sweet spot of
compromise between performance, security and convenience.

Proof that “the scope”, even when there is a much more clearly
delineated frontier, is fluid and a matter of compromise.

If you cannot accept compromise, then your opinion should not be taken
into consideration in a functioning collective project.

> I have 63 forks of ffmpeg alone. I don't see the problem.

I am doubtful whether this is to be considered a good thing or a bad
thing, but I am rather leaning towards bad.

> As for me being loudest, someone has to be. As a licensed amateur radio
> operator I also happen to have domain knowledge, which is why I know
> radio stuff will affect the code in profound ways, as we are already
> seeing evidence of. These are hard-gotten learns.

Well, if you are right, then we will see patches on the mailing list
that will affect the code in profound ways, and you will be able to
object to them then.

But far from “already seeing evidence” of the apocalypse you predict, we
see that the avradio code already delivers features while being
self-contained and only required extending the signal processing
abilities of our libraries a little, and in ways that are useful to
other developers.

So I guess it proves being licensed to operate something does not make
you qualified to evaluate the difficulty in implementing the software of
that thing. What a surprise.

I will add that “affect the code in profound ways” was actually true for
hardware acceleration, requiring a big mess in the code and significant
to the internal API and even public API and user interface. Yet nobody
is objecting to them.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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