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

[Zhao Zhili]

> On Feb 26, 2025, at 23:32, Rémi Denis-Courmont <remi at remlab.net> wrote:
> 
> Hi,
> 
> Le 26 février 2025 16:18:20 GMT+02:00, Zhao Zhili <quinkblack-at-foxmail.com at ffmpeg.org> a écrit :
>> 
>> 
>>> On Feb 26, 2025, at 21:50, Tomas Härdin <git at haerdin.se> wrote:
>>> 
>>> fre 2025-02-21 klockan 20:10 +0000 skrev Soft Works:
>>>> 
>>>> 
>>>> From: Kieran Kunhya <kieran618 at googlemail.com>
>>>> Sent: Freitag, 21. Februar 2025 20:27
>>>> To: Soft Works <softworkz at hotmail.com>
>>>> Cc: FFmpeg development discussions and patches
>>>> <ffmpeg-devel at ffmpeg.org>
>>>> Subject: Re: [FFmpeg-devel] I've written a filter in Rust
>>>> 
>>>> 
>>>> On Fri, 21 Feb 2025, 15:02 Soft Works,
>>>> <softworkz at hotmail.com<mailto:softworkz at hotmail.com>> wrote:
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: ffmpeg-devel
>>>>> <ffmpeg-devel-bounces at ffmpeg.org<mailto:ffmpeg-devel-bounces at ffmpeg
>>>>> .org>> On Behalf Of
>>>>> Kieran Kunhya via ffmpeg-devel
>>>>> Sent: Freitag, 21. Februar 2025 15:53
>>>>> To: FFmpeg development discussions and patches <ffmpeg-
>>>>> devel at ffmpeg.org<mailto:devel at ffmpeg.org>>
>>>>> Cc: Kieran Kunhya
>>>>> <kieran618 at googlemail.com<mailto:kieran618 at googlemail.com>>
>>>>> Subject: Re: [FFmpeg-devel] I've written a filter in Rust
>>>>> 
>>>>> On Fri, 21 Feb 2025, 14:30 Soft Works, <softworkz-at-
>>>>> hotmail.com at ffmpeg.org<mailto:hotmail.com at ffmpeg.org>>
>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: ffmpeg-devel
>>>>>>> <ffmpeg-devel-bounces at ffmpeg.org<mailto:ffmpeg-devel-bounces at ff
>>>>>>> mpeg.org>> On Behalf Of
>>>>>>> Michael Niedermayer
>>>>>>> Sent: Freitag, 21. Februar 2025 14:22
>>>>>>> To: FFmpeg development discussions and patches <ffmpeg-
>>>>>>> devel at ffmpeg.org<mailto: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".
>>>> 
>>>> Open means it's extensible for everybody, including vendors. I fail
>>>> to see
>>>> what's bad about it. Do we have a fight against everything
>>>> commercial?
>>>> 
>>>> What are you afraid of to happen?
>>> 
>>> I think Kieran already expressed quite well the issue:
>>> 
>>> 1) it encourages proprietary blobs
>>> 2) it creates pressure on us to maintain compatibility with said blobs
>> 
>> The first issue has a solution: use gpl or more strict license for the plugin
>> interface support, like obs-studio.
>> 
>> For the second issue, we can just not give a stable API/ABI guarantee for
>> the plugin interface, for example, reject to load a plugin if the version doesn’t
>> match.
>> 
>> I have some feature in mind which suit for a plugin but not for a builtin implementation.
>> For example, different AI model have different pre- and post-process. Current
>> dnn in libavfilter only support some particular model like yolov4. We can’t write some
>> code for each model, which can be outdated soon.
>> 
>> VLC and obs-studio are both good example of plugin based frameworks.
> 
> Or the Linux kernel.
> 
> Though VLC does not have that "unofficial" plugins, which aren't backports of official plugins from a newer version. So I'm not convinced that that's a good example.

Maybe not much but I have noticed some unofficial plugins,

https://github.com/mfkl/awesome-vlc

And there is a Debian package for vlc-plugin-bittorrent.

Plugin interface can be abused, but at the same time, they can fulfill many legitimate
user needs. Not everyone can write a program based on libavcodec/libavformat/libavfilter,
and get the same function as fftools. They can write a filter plugin, and let ffmpeg cmd to
do the heavy lifting.

> 
> Even then proprietary vendors still managed to screw it up by failing to release new versions of their binary blobs for new versions of (Windows) VLC.
> 
> In my opinion, VLC plugins are more about reducing binary load times and load sizes by breaking the code up, and helping Linux distro break dependencies down, than about enabling external (proprietary or not) plugins.
> _______________________________________________
> 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".