> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Nicolas George > Sent: Mittwoch, 26. Februar 2025 15:08 > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Cc: Kieran Kunhya <kieran...@googlemail.com> > Subject: Re: [FFmpeg-devel] I've written a filter in Rust > > Soft Works (HE12025-02-21): > > 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? > > I am with Kieran and Tomas on this. This feature would make it > extensible for everybody, but considering that it is already extensible > for everybody who agrees to release their source code, it mostly helps > the people who do not want to release their source code.
Hi Nicolas, I see it somewhat more liberal and I would see the primary purpose in helping people who have code which cannot get into ffmpeg (for whatever reason). But surely it would have that side-effect of making it easier to deliver binaries without source. The tag word seems to be "binary blobs", yet I wonder whether that's even a sustainable approach for such vendors. On Windows it's pretty easy to build a single dll (per architecture) which can have its own set of dependency and C runtime libs. I'm not sure for Linux & Co - is it even feasible for a vendor to create a "binary blob" that would work universally? What I mean is, how many different "binary blobs" might a vendor need to build, then? (not sure if dlmopen() or RTLD_LOCAL would allow something similar like on Windows) Anyway, I'm not intending to fight against open-source ideas, it should be up to the developers to decide in which ways their works are being used; personally, I wouldn't mind this kind of of usage, but I understand that others see it differently. > What we could do is make it easier to build from source with extra > components: [..] > - Build scripts that detect available libraries. Possibly build scripts > that install devel packages for these libraries. Possibly even a build > script that installs a Debian in a VM/container. > > - Tweak the build system to let add a component by just dropping it in a > subdirectory. Yes, that's exactly what I mean. Currently, when adding custom filters (or codecs, muxers etc.), you need to make changes at various places and each time when rebasing or merging things around and managing versions, these things are causing conflicts. Or when you want to provide a filter/component to the community (as source code), you can't provide a patch that could be applied to arbitrary ffmpeg versions. Having a "plugins" directory that is automatically scanned for plugin code, or a command line parameter like ./configure --plugindir=../myplugins would be fine IMO. And obviously much more agreeable for everybody than runtime plugins, even though I would favor having both 😊 Thanks, sw _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
