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

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

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@ffmpeg.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?

Just wanna understand the position, thanks.
sw


Hi Kieran,

What will happen is all the binary blob vendors who have to currently ship a custom ffmpeg and tell their users to compile from source can just ship their blob as a plugin.

We currently have 200 reasons (commits) for needing to ship a custom ffmpeg and a plugin model would not change that.
It’s hard for everybody to get even good changes in ffmpeg and there are other changes for which there’s clearly no place in the ffmpeg codebase. There should be an equalization for this situation.
Also, I think it’s a bit unfair and oversimplifying to blame all vendors’ main interest being to ship binaries as extension just for the sake of keeping them closed source – even though those cases might occur.


FFmpeg will get all the bug reports from crashes (this is why the kernel had to add the "tainted") flag.

Is this really a big problem? It seems to me that such cases can be easily identified (the presence of loaded plugins could also be indicated in the version header).

I have a deep dislike for binary blobs.

That I can understand. But on one side rejecting a lot of source code and also not allowing compiled code for extending is a pretty fencing policy es well.

What do you think about a compile-time plugin model?

PS:I don’t know the avisynth back story...

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".