[FFmpeg-devel] Project orientation

[James Almer]

On 7/4/2020 11:51 AM, Paul B Mahol wrote:
> On 7/4/20, Nicolas George <george at nsup.org> 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.
>>
>> 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?
> 
> Certainly one where you are not part of it.

Can you just fuck off already? What compels you to be like this?

If you have nothing worth saying in this thread, then just don't.

> 
>>
>> Sorry for the interruption, you can resume your normal occupation.
>>
>> Regards,
>>
>> --
>>   Nicolas George
>>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>