[FFmpeg-devel] Project orientation

[Michael Niedermayer]

Hi

On Sat, Jul 04, 2020 at 04:43:54PM +0200, Nicolas George wrote:
> 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.

not sure we are thinking of 100% the same thing but i also feel that
theres less design and healthy/friendly discussions about design going on
than what should be and what was really long ago.

Another area as we are already on the subject is stuff falling a little
outside what FFmpeg covers.
Not every filter that anyone wants to write should have to be in FFmpeg
This is a bit like requiring every C program to be in the repository of
the C compiler. You know, that would have issues for C and it does for
FFmpeg too.

Similarly are encoders/decoders. someone can write a rather advanced codec for a
fringe format thats either faster or compresses better and volunteer
to maintain it. But it gets rejected because Its just a fringe format
the majority in FFmpeg doesnt care enough about in relation the the
complex code.
I dont think this sort of thing is good, we loose new blood this way
and what remains is simple but unmaintained code for that codec.


[...]
> 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.

A bit toward this topic, would be a more generally useable utilities
library. something like libavutil but not just for multimedia.


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

i do hope the planned technical committee will help with some of the
problems you discussed here.
But sometimes people are also rather rigid in discussions less interrested
to find a good compromise to move forward with and more interrested in
"winning" a discussion. That is also not helping and i dont think the
technical committee should be seen as the solution to this. Its better
people discuss and agree than to go to some arbitration to decide

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200704/713d4d82/attachment.sig>