> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Jim > DeLaHunt > Sent: Monday, July 6, 2020 6:54 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] Project orientation > > On 2020-07-04 07:43, 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. > > > > 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? > > > > Sorry for the interruption, you can resume your normal occupation. > > > > Regards, > > > > -- > > Nicolas George > > I am really happy to see this discussion starting up. It is good timing; > some new governance committees are forming. They might be able to take > it on. From my perspective as an outside observer, I think the project > will benefit from you — the people who are at the heart of the project — > having this discussion. > > For what purpose do all of you contribute to FFmpeg? What is the good > you see FFmpeg doing? What is FFmpeg's purpose? What stands in the way > of FFmpeg achieving its purpose, and of you achieving your own > individual purpose? > > For me, several comments in the thread resonated. They have a theme: > bringing in new participants: > > > On 2020-07-04 08:37, James Almer wrote: > > > > Just a few quick Saturday morning thoughts that don't cover your entire > > email and may be just me rambling, but some of this could be linked to > > the completely different world we're living in today than in say 2010, > > regarding what is expected of multimedia projects. Nowadays almost > > everything is streaming, and almost everything is mobile focused. > > Getting a 1% speed up in one hot loop in h264dec that could mean the > > difference between realtime or dropped frames in some ARM chip is > > immensely more important and demanded than a smoother experience > > running > > a filter chain, or a decoder for a 20 years old console game that would > > aid with emulation efforts. And yes, even if those chips have a hw decoder. > > > > Similarly, the HEVC patent pool disaster completely ruined any chance > > for ffhevc to ever see any kind of real development, and the situation > > indirectly (or not) resulted in what would have been the internal AV1 > > decoder becoming a standalone library: It required a extremely > > permissive license for the sake of fast and widespread adoption that > > ffmpeg could not provide with LGPL. > > It's the first time a very important codec is not present internally in > > our codebase, and that itself is proof things are definitely not the > > same as they used to. I can't imagine ffmpeg without an internal h264 > > decoder ever making it anywhere a decade ago. > > Of course anyone could port it today, but does anyone capable want to? > > So far it doesn't look like. > > > > Another thing worth mentioning is a lack of new blood. Despite > > participating in GSoC for a long while, i can't name a student that > > stuck around after the fact. Mind, there are new devs that started > > contributing for other reasons, but perhaps not enough? > > _______________________________________________ > > 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". > > > On 2020-07-04 11:20, Soft Works wrote: > > My time as a student is long gone. Over the years, I have seen a lot and > > done > > a lot of things as a developer. From my perspective, ffmpeg is one of the > > least attractive software projects for contributing, that I know. There are > > so > > many reasons, I don't even know where to start. > > > > Let's take this one: While writing this e-mail, I have to insert manual line > > breaks in order to adapt to how mails were written until the 1980ies. I > > cannot > > use bullet points or font formatting (e.g. to indicate code snippets). > > > > Communication via a mailing list is anachronistic. The world has changed > > and > > much better ways exist to communicate. The fact alone, that this mailing- > > list > > approach forces me to continuously read everything - including that > > sociopathic talk that is happening here as well, would be reason enough for > > me to walk away. > > With something like a forum or GitHub issues, I could not only step out of > > those conversations, but also better choose topics where I'm interested in > > and where not. > > > > And using patch files with plus and minus signs for collaborating on code > > changes? Really? It's not just that it would be a matter of taste - there > > are > > obvious shortcomings when comparing with modern ways, like that it's > > impossible to connect code and discussion about that code. > > > > Another problem is, that there is almost no connection to users of ffmpeg. > > The user mailing list is strictly separated and developers seem to be living > > inside some kind of bubble with little contact to those who are actually > > using > > ffmpeg. That's my impression at least. I'm sure there is one or the other > > who > > does differently. > > > > As a developer (without a well-known name) who wants to contribute a > > patch, things can be quite frustrating here. When that patch accidentally > > hits > > an area of one the very few who are caring and friendly - you're lucky. > > But otherwise, a patch will either be ignored or talked into infinity. > > > > I have a number of things to contribute, but after it didn’t work well with > > small things, I decided not to bother with the bigger ones. > > As an example, I gave my QuickSync/DX11 code to Intel, in order to let them > > deal with getting it merged, but even that didn't work out so far. > > AMD AMF hardware decoders are still missing. They had submitted > > something 1 or 2 years ago, but they didn't get any feedback and were > > discouraged to proceed. > > Windows Media Foundation HW acceleration has recently been merged, but > > the actual patch existed for several(!) years. > > Things running not really smooth here, a lot more progress could be made in > > some areas. > > > > I know, the project is community driven, but sometimes I think there is > > missing someone who is "in charge" of things and connects the many loose > > ends that exist. > > > > ----------------------------- > > > > I don't really have a problem with how things are. I accommodate, we got our > > own fork and platform builds and just do our changes there. > > > > This is my very personal view. People have different opinions (luckily), > > and I > > didn't write this to discuss all those points in detail or to initiate some > > change > > to the project. > > > > But when somebody starts wondering, why there aren't any new developers > > joining the project, one should maybe think about whether one or two of > > the things I listed above could be the reason... > > > > Kind regards, > > softworkz > > > > _______________________________________________ > > 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".> > > To the extent you decide that you want new participants to join you on > FFmpeg, I'm sorry to say, I think you have a problem. My own experience > is that this project is more hostile to newcomers than many other free > culture projects I know (e.g. Python, Thunderbird, Gnucash, Drupal, > MusicBrainz, Wikipedia). It's not just your rudeness to each other on > the email lists. It's not just the inattention to patches from new > developers. It's also a simple lack of telling newcomers: welcome, we > are glad you are here, we want your help, we will help you learn. > > Even more deeply, the culture of this project is focussed on checking in > compileable code to the exclusion of other kinds of contribution: > testing, documentation, support. Those contributions seem not welcome > simply because they are not code, and code is all that matters. > > I suspect that you may find that some of the things that frustrate you > are linked to work the project does not value. Repetitive questions on > the ffmpeg-users list may in part result from the inadequate > documentation, which doesn't tell users what they need to know. Feeling > stretched thin over too much code without enough tooling might result > from the too little of the right unit tests. And so on. > > I wish you success as you ask yourself these big questions. I hope it > helps you have a more pleasant time in this project. I am confident it > will result in a better FFmpeg. > > —Jim DeLaHunt, software engineer, Vancouver, Canada > > > _______________________________________________ > 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".
+1 ! (now you had to scroll all the way down just to see my '+1'... While the technical achievements of ffmpeg are outstanding, this appears to me a bit like designing a rocket using a typewriter ;-) _______________________________________________ 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".
