On 7/4/20, James Almer <jamr...@gmail.com> wrote: > On 7/4/2020 11:51 AM, Paul B Mahol wrote: >> On 7/4/20, Nicolas George <geo...@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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
