[FFmpeg-devel] Project orientation

[Paul B Mahol]

On 7/4/20, James Almer <jamrial at gmail.com> wrote:
> 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?
>

Certainly compels me behavior of you and rest of FFmpeg "developers".

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

I said clearly my opinion about Nicolas. From now on consider yourself
in same position.

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