[FFmpeg-devel] I've written a filter in Rust

[Stephen Hutchinson]

On 2/21/25 9:53 AM, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, 21 Feb 2025, 14:30 Soft Works, <softworkz-at-hotmail.com at ffmpeg.org>
> wrote:
> 
>>
>>
>>> -----Original Message-----
>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>>> Michael Niedermayer
>>> Sent: Freitag, 21. Februar 2025 14:22
>>> To: FFmpeg development discussions and patches <ffmpeg-
>>> devel at ffmpeg.org>
>>> Subject: Re: [FFmpeg-devel] I've written a filter in Rust
>>>
>>> Hi
>>>
>>> On Fri, Feb 21, 2025 at 10:01:56AM +0100, Tomas Härdin wrote:
>>>> tor 2025-02-20 klockan 23:49 +0100 skrev Michael Niedermayer:
>>>>> Hi
>>>>>
>>>>> On Thu, Feb 20, 2025 at 02:06:47PM +0100, Leandro Santiago wrote:
>>>>>> [insert meme here]
>>>>> [...]
>>>>>> I also recorded a video showing the filter in action [7].
>>>>> [...
>>>>>> [7] https://youtu.be/U_y4-NnaINg
>>>>>
>>>>> cool, it doesnt detect everyone though
>>>>>
>>>>> also i think this shows how useful a plugin framework would be for
>>>>> ffmpeg
>>>>>
>>>>> with plugins everyone could use,test and contribute to this today.
>>>>> without plugins, this needs to be merged in ffmpeg git master. (which
>>>>> will take some time i suspect)
>>>>
>>>> Have we not gone over and rejected plugins many times? I recall points
>>>
>>> no
>>> there was no formal and no public informal vote that i remember.
>>>
>>> ive raised the issue with plugins many times. Because it would
>>> allow people and myself to contribute more complex features and
>>> end the stagnation of FFmpeg.
>>
>> Yup, that's exactly one of the reasons why other projects like GStreamer
>> have gained that much popularity. It might not have happened when
>> ffmpeg would have been more open and extensible in the first place.
>>
> 
> It's quite the opposite. Gstreamer is successful in its vertical because it
> allows easy inclusion of vendor binary blobs. This is not "open and
> extensible".
> 
> Don't confuse the history of avisynth in the 2000s with today's reality.
> 

And for that matter, AviSynth got bit **hard** when supporting more than
just 32-bit x86 became necessary, so any early success in attracting
plugin authors by having a Classpath-style exemption was quickly offset
by getting stuck with those decisions to maintain compatibility, and
suffering a lack of established plugins on new architectures/platforms
due to how many authors in the early days kept their plugins closed 
(thankfully most(?) of the regularly used and useful plugins now are
under FOSS licenses, but I don't even know how many plugins exist that
simply can't be ported because they're essentially closed-source
abandonware tied to an ancient version of AviSynth).

So it's just as much of a cautionary tale about how not to set up plugin
licensing and how the upstream handles compatibility in regard to it.