[FFmpeg-devel] Project orientation

Mon Jul 6 08:42:38 EEST 2020

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Jim
> DeLaHunt
> Sent: Monday, July 6, 2020 6:54 AM
> To: ffmpeg-devel at 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 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".
> 
> 
> 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 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".> 
> 
> 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 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".

+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 ;-)