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.
signature.asc
Description: PGP signature
_______________________________________________ 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".
