[FFmpeg-devel] Project orientation

Nicolas George george at nsup.org
Sat Jul 4 17:43:54 EEST 2020


Hi.

When I first started progressively to contribute do FFmpeg, the project
was far from mature, but it was very much alive.

There was attempts at implementing new and better codecs, directly in
lavc's code base. There were attempts at designing new formats with
useful features.

Even outside the specialized work on specific codecs and formats, there
was creativity. At the API and framework level, there was work being
done to do things in a smarter way, either more convenient or more
efficient or both.

For example, the format negotiation in liabvfilter (which was mostly
designed before I got involved: I am not singing my own praise here),
with its pointers to pointers to pointers, is not run-of-the-mill code.
Even if parts of it are made of common algorithms, the whole is very
specific to FFmpeg, and its design was creative. Creativity was
necessary later to extend it to support audio.

Nowadays, not so much. There is work in making highly-optimized
decoders, this work is impressive and creative, there is no doubt about
it. But as far as I can see, that is mostly all there is going on. The
rest seems to be rather basic: fixing bugs (and things that are not
bugs, like harmless integer overflows), implementing support for
features that were decided and designed elsewhere.

And it is not just that it is not happening: there is genuine opposition
to creativity: things that are not already justified externally, things
that do not look like well-known patterns, are met with scepticism and
eventually rejected.

At this point, we should ask ourselves:

Is it what we want the project to be, or is it just what we have let it
become?

I do not think this evolution is the result of a deliberate choice. I
think it is more the result of the stress of success and the stress of a
fork. Success can stifle creativity, because creativity implies the risk
of failure: the project has become advert to risk.

It has evolved that way, but are we fine with it?

I personally am not.

I find the new ambiance boring.

Creativity is the reason I practice development, and the reason I do not
practice it professionally: my creativity cannot be put on a schedule.

My skills are not for micro-optimizing codec code: I cannot help on
these tasks. If I am allowed to analyze this myself, I would say that my
skills lie in general organization: making sure that the right code gets
called at the right time, finding more convenient ways of doing tasks,
etc.

I have several ideas for the project. Some are not directly related to
multimedia at all; rather, the are invented for FFmpeg precisely, for
FFmpeg's exact needs and ways of doing things. They relate to options
and introspection, to inter-thread scheduling and asynchronous
operation, to error reporting to the application, to handling of strings
and serialization, to partial configurations of filters, to avoiding
global state and allowing multiple instances, etc.

I have shown the first steps of some of my ideas (AVWriter a few months
ago, avrefcount_template.h more recently), and the outcome was rather
disheartening and discouraging: "it's too complex" (of course: I am
putting all the complexity in one place so that the rest of the code can
be simple, if you look at just that part it looks complex!), "why don't
you just" do thing the usual way? (because I am trying to find a better
way than the usual way.) It seems my fellow developers do not look beyond
the immediate strangeness of the proposal to see the promised benefits,
but remember: strangeness is just lack of familiarity, it goes away fast
all by itself, and all that remains are the benefits.

These proposals would probably be better met if they were complete: if I
proposed a patch series that eliminates escaping hell or gets
non-blocking operation working all at once, it would be easier to get it
accepted. But it is too big a task, especially with the rest of the code
moving under my feet, with conflicts at each rebase.

Lacking that, they require a little trust: trust enough to look, beyond
the immediate strangeness, where I am going and to try to see what I
want to achieve, and see that it is achievable. But for now, I have seen
more doubt and dismissal than trust and enthusiasm. And the projects are
too big, I am not prepared to fight an uphill battle to get accepted
every small step.

If I cannot express my creativity by developing for FFmpeg, I will find
other projects, mine or existing, to express it. I suspect others have
orbited away from the projects for similar reasons.

So, I ask one last time: What kind of project do you want FFmpeg to be?

Sorry for the interruption, you can resume your normal occupation.

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/20200704/111b300b/attachment.sig>


More information about the ffmpeg-devel mailing list