Re: [FFmpeg-devel] What is FFmpeg and what should it be

[Nicolas George <george@nsup.org>]

Tomas Härdin (12023-07-31):
> As far as I recall libxml2 does not enable the fancier features of XML
> unless told to do so. And if it can't disable things like DTD then a
> ticket should be opened with them to make that possible.

You are missing the point: even if all these features are entirely
disabled (which we cannot be really sure), the code and data structure
have to be designed to make them possible. That means significantly more
complex code, much more prone to bugs, including security-relevant.

> It is foolish to spread scarce developer time more thinly.

For that, see below.

> It almost certainly means worse security, not better.

I am quite sure your estimation in this is wrong.

> The same goes for all things that FFmpeg reimplements. HTTP has already
> been mentioned. How many developer hours have been wasted on it when
> libcurl could be used instead, and a fraction of those hours going to
> improving it rather than a duplicate implementation?
> 
> I have been accused of being a "bean counter". But what are these beans
> that I count? They are developer time, the sole source of value of the
> free software movement as a whole. When I see things like HTTP or MXF
> being reimplemented I don't see features. I see liabilities.

You are neglecting a very important point here:

The time of other people is not yours to count.

You are not a boss directing the time of your employees towards the task
most profitable for you. Michael is not hacking software defined radio
to be profitable for somebody, he is having fun with it (probably
because he recently got his hands on the hardware). And I want to write
a <foo bar="qux"> parser because it is an interesting challenge. But
since Michael is a very talented hacker, the result of he having fun
ends up being code that is in some way already better than existing
alternatives.

As a member of a community project, you do not have the authority to
choose what other developers work on. The only authority you have is to
decide whether you will welcome the fruit of their work as an useful new
feature (while being vigilant about code quality) or whether you will be
so annoying about it that they give up trying to contribute to FFmpeg.

As of now, you seem to be making the wrong choice.

And I can tell you about my own situation: for several months now, the
attitude of some developers here, including you very strongly, has
mostly disgusted me from contributing to FFmpeg.

The stupid farmer kills the goose with the golden eggs by opening up her
belly. The smart farmer kills the goose with the golden eggs by trying
to force her to lay on a schedule.

> Layering is not an end in itself as you rightfully point out. It is a
> tool. To what end?

> In the free software world we don't layer and segregate things for no
> reason. We do it so that programs can interact with each other through
> standardized interfaces. The effect is a comedy of the commons. More
> can be done with less labour. For an FM receiver program the
> appropriate interfaces are ALSA, PulseAudio and/or JACK. That way its
> audio can be piped to many programs.

As you point: layering is not an end. “The scope” is not the reason, it
is only a quick summary of the reasons when they are obvious and we all
agree.

So please stop invoking “the scope” as a reason.

Second, layering is indeed something to wish for in a complex project,
but it has to come organically, it has to appear progressively as the
code becomes more complex and the useful boundaries and interfaces
appear.

When people start with layering, the result looks like the OSI model for
network stacks: it makes a few nice paragraphs in textbooks and is
completely worthless in practice.

> It is true that we can add more features, and it is also certainly true
> that these are useful for a non-empty set of users. But is it a good
> use of scarce developer time? Were SDR limited to only Michael's time
> then there would be no problem. But it isn't. It unavoidably touches
> many other parts of the code, as we are already seeing.

It is the second time you say this, and it is the second time I have to
tell you: no, it is not true at all.

We are seeing exactly the opposite: Michael's code is big, but it is
self-contained and completely optional.

Furthermore, it is not wasting any developer time. Only these sterile
objections are wasting precious time.

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