[FFmpeg-devel] Project orientation

[Nicolas George]

Jean-Baptiste Kempf (12020-07-05):
> You are missing the point here:
> Lego Racers demuxer is in the scope of "play everything under the sun"
> that the FFmpeg project is, while AMQP/ZMQ is not.
> 
> The issue is not usefulness, but correctly defining the scope of the
>  project (aka the orienttation). If you don't, you will integrate a
>  webserver, an email sender, a full webRTC stack with p2p and a coffee
>  controller.
> 
> Some codecs and formats are not useful, sure, but they are in the
> scope, and there is little debate about it.
> But custom protocols or complex filters that bring huge dependencies
> are very debatable, and I doubt they are the consensus.

I understand your point, but I see it as less a problem than another
similar but not identical issue.

Whether they are an actual multimedia protocol, format or codec, and
therefore "in the scope of the project" or something else and stranger,
and therefore not "in the scope", components are not in the way. They
are just a few extra C files to compile, possibly a few extra library
dependencies (i.e. NEEDED fields in ELF objects). They can be disabled,
and when they are they cost nothing. If they become a burden, if they
fail to build for example, they can be removed in a few seconds. In the
build tree, they are just leaves.

It can be said they cause a little namespace pollution, but that is all
there is technically. The major objection to accepting strange and
fringe components is not technical, it is us holding ourselves to a
higher standard: once something is in, it is in for good, it must be
maintained. If a patch on the framework breaks it, it must be repaired
or the patch is not accepted.

We do not have to do that. We do not have to hold ourselves to such
unattainable standards that they hamper development.

We could just say: we accept your fringe codec/format/filter/whatever,
but you have to maintain it: if it breaks we disable it, and either you
fix it or we remove it. Such components could be in sub-directories of
their respective libraries, there could be a global configure flag
--enable-fringe, etc.

The issues of components is not the hardest issue when it comes to
project orientation.


What is hardest, in my opinion, is changes that affect the way we do
things.

Let me develop one of the things I had in mind when starting this
discussion: strings.

Despite FFmpeg not being a project about handling text, it uses strings
in many places. And these strings are almost always basic NUL-terminated
C strings, either in constant-size on stack or mallocated. It is costing
us efficiency, code complexity (all the "if (!str) return
AVERROR(ENOMEM);".

I have drafted a proposal for a better API to handle strings (see
AVWriter in the archives). I think it is a good proposal: it was a long
time brewing, it includes several original ideas that should make it all
at once convenient, efficient and maintainable. See my points above
about creativity in programming.

But for people who work on parts of the code where there are not many
strings, the benefit does not exist. For them, there is only the hassle
of learning a new, non-default API. Even if this hassle is tiny, it is
still a hassle, and people do not want it, they oppose.

On the other hand, I could just push AVWriter and start using it in my
parts of the code: it is not in the scope of any maintained part, there
is nothing in the actual project rules that forbids me to do it. But it
would be extremely rude. And more than rude, it would lead to more
inconsistency (see https://xkcd.com/927/).

What we need is somebody or somebodies who listen on all sides of the
arguments, weigh the benefits and drawbacks, and decide: no, we'll
continue using basic C strings, don't waste your time working on
AVWriter; or yes, we'll use AVWriter, so all must find fifteen minutes
to learn how to use it; or even, yes we'll use smarter strings, but
rather this other proposal that looks more promising than AVWriter.

I can deal with AVWriter being discussed and rejected. What I have a
hard time dealing with is uncertainty: the code I am currently writing,
will it be wasted?

I took AVWriter as an example because it is something I worked on
recently, and something that affects a significant part of the code, but
there are many similar cases, where we need somebody to be able to
decide, for the whole project, how we will be doing things.

This could fall under the mandate of the tech committee, but I am not
sure it is the best idea: these issue border on the technical, but they
are also a matter of policy and human interaction. It would greatly
increase the power of the tech committee.

But tech committee or other, we need to be able to ask and answer these
questions.

> Also in this example, noone is telling them to fork, just to use the
> API to register their custom protocol.

I have a point for this, but this mail is already very long, I will make
it separately.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200707/a59b5c6e/attachment.sig>