> On Feb 26, 2025, at 23:32, Rémi Denis-Courmont <[email protected]> wrote: > > Hi, > > Le 26 février 2025 16:18:20 GMT+02:00, Zhao Zhili > <[email protected]> a écrit : >> >> >>> On Feb 26, 2025, at 21:50, Tomas Härdin <[email protected]> wrote: >>> >>> fre 2025-02-21 klockan 20:10 +0000 skrev Soft Works: >>>> >>>> >>>> From: Kieran Kunhya <[email protected]> >>>> Sent: Freitag, 21. Februar 2025 20:27 >>>> To: Soft Works <[email protected]> >>>> Cc: FFmpeg development discussions and patches >>>> <[email protected]> >>>> Subject: Re: [FFmpeg-devel] I've written a filter in Rust >>>> >>>> >>>> On Fri, 21 Feb 2025, 15:02 Soft Works, >>>> <[email protected]<mailto:[email protected]>> wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: ffmpeg-devel >>>>> <[email protected]<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- >>>>> [email protected]<mailto:[email protected]>> >>>>> Cc: Kieran Kunhya >>>>> <[email protected]<mailto:[email protected]>> >>>>> Subject: Re: [FFmpeg-devel] I've written a filter in Rust >>>>> >>>>> On Fri, 21 Feb 2025, 14:30 Soft Works, <softworkz-at- >>>>> [email protected]<mailto:[email protected]>> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ffmpeg-devel >>>>>>> <[email protected]<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- >>>>>>> [email protected]<mailto:[email protected]>> >>>>>>> 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 > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
