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

["Rémi Denis-Courmont" <remi@remlab.net>]

Hi,

Le 26 février 2025 16:18:20 GMT+02:00, Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org> a écrit :
>
>
>> On Feb 26, 2025, at 21:50, Tomas Härdin <git@haerdin.se> wrote:
>> 
>> fre 2025-02-21 klockan 20:10 +0000 skrev Soft Works:
>>> 
>>> 
>>> From: Kieran Kunhya <kieran618@googlemail.com>
>>> Sent: Freitag, 21. Februar 2025 20:27
>>> To: Soft Works <softworkz@hotmail.com>
>>> Cc: FFmpeg development discussions and patches
>>> <ffmpeg-devel@ffmpeg.org>
>>> Subject: Re: [FFmpeg-devel] I've written a filter in Rust
>>> 
>>> 
>>> On Fri, 21 Feb 2025, 15:02 Soft Works,
>>> <softworkz@hotmail.com<mailto:softworkz@hotmail.com>> wrote:
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: ffmpeg-devel
>>>> <ffmpeg-devel-bounces@ffmpeg.org<mailto:ffmpeg-devel-bounces@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@ffmpeg.org<mailto:devel@ffmpeg.org>>
>>>> Cc: Kieran Kunhya
>>>> <kieran618@googlemail.com<mailto:kieran618@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@ffmpeg.org<mailto:hotmail.com@ffmpeg.org>>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: ffmpeg-devel
>>>>>> <ffmpeg-devel-bounces@ffmpeg.org<mailto:ffmpeg-devel-bounces@ff
>>>>>> mpeg.org>> On Behalf Of
>>>>>> Michael Niedermayer
>>>>>> Sent: Freitag, 21. Februar 2025 14:22
>>>>>> To: FFmpeg development discussions and patches <ffmpeg-
>>>>>> devel@ffmpeg.org<mailto:devel@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.

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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".