[FFmpeg-devel] [RFC] 5 year plan & Inovation

[epirat07 at gmail.com]

On 19 Apr 2024, at 16:50, Niklas Haas wrote:

> On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer <michael at niedermayer.cc> wrote:
>> A plugin system moves this patch-management to people who actually
>> care, that is the authors of the codecs and (de)muxers.
>
> A plugin system will only solve this insomuch as plugin authors will
> just host their plugin code on GitHub instead of bothering with the
> mailing list.
>
> I think it runs a good risk of basically killing the project.
>
>> Our productivity as is, is not good, many patches are ignored.
>> The people caring about these patches are their Authors and yet they
>> are powerless as they must sometimes wait many months for reviews
>
> So, rather than all of the above, what I think we should do is contract
> somebody to set up, manage, host and maintain a GitLab instance for us.
>
> This would probably be the single most cost effective boost to both
> community growth and innovation I can think of, as it will remove
> several of the major grievances and barriers to entry with the
> ML+pingspam model.

I agree with that.

IMO extending patchwork while possible is just a stopgap measure and
requires quite a bit of effort too that is probably better spent elsewhere.

Using Trac to manage patches additionally just adds even more inconsistent places
to have patch info that go out of sync with reality like patchwork already does…

I am by no means a die hard GitLab fan, quite the contrary, but I still believe
it is a vast improvement over the Mailing List workflow and if there are shortcomings
in the tooling so that some peoples workflows can continue to work, efforts are probably
better spent overcoming these, rather than „beating a dead horse“ (patching Patchwork).

>
> We can use a system like VLC's auto-merge bot, where any MR that has at
> least one developer approval, no unresolved issues, and no activity for
> N days gets *automatically* merged.

Just to clarify, it does not automatically merge but rather tags them
and a maintainer still does the actual merge.

>
> I'm sure that if we try, we can find an interested party willing to fund
> this. (Maybe SPI?)
>
>> Besides that, developers are leaving for various reasons and they
>> are forced to setup full forks not being able to maintain their
>> code in any other way.
>> IMO A plugin system would improve productivity as everyone could work
>> on their own terms.
>> No week or month long delays and weekly pinging patches
>> No risk about patches being rejected or ignored
>> No need to read every other discussion on the ML. One can just
>> simply work on their own plugin looking just at the API documentation
>> ...
>>
>>
>>
>>>
>>>> * ffchat
>>>>     (expand into realtime chat / zoom) this would
>>>>     bring in more users and developers, and we basically have almost
>>>>     all parts for it already but some people where against it
>>>
>>> This seems like a user application on top of FFmpeg, not something that
>>> should be part of FFmpeg core. Can you explain what modifications in
>>> FFmpeg would be necessary for something like this?
>>
>> ffmpeg, ffplay, ffprobe are also user applications.
>>
>>
>>>
>>>> * client side / in browser support
>>>>     (expand towards webapps, webpages using ffmpeg client side in the browser)
>>>>     bring in more users and developers, and it will be costly for us
>>>>     if we let others take this area as its important and significant
>>>
>>> I don't understand this point - don't all major browsers already vendor
>>> FFmpeg for decoding?
>>
>> FFmpeg does more than decoding.
>>
>>
>>>
>>>> * AI / neural network filters and codecs
>>>>     The future seems to be AI based. Future Filters and Codecs will use
>>>>     neural networks. FFmpeg can be at the forefront, developing these
>>>
>>> We already have TensorFlow support, no? (vf_sr etc.) What more is
>>> needed?
>>
>> more of that AND more convenience
>>
>> lets pick a comparission
>> to run fate
>> you write "make fate"
>> if you want to do it with the samples its
>> make fate-rsync ; make fate
>>
>> if you want to use vf_sr, its reading the docs, looking at some scripts reading their docs
>> and i presume selecting a training set ? creating a model ? ....
>>
>> how many people do that ?
>>
>> thx
>>
>> [...]
>>
>> -- 
>> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I have often repented speaking, but never of holding my tongue.
>> -- Xenocrates
>> _______________________________________________
>> 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".