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

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Mittwoch, 26. Februar 2025 15:08
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Cc: Kieran Kunhya <kieran618@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-request@ffmpeg.org with subject "unsubscribe".