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

[Tomas Härdin]

sön 2025-02-23 klockan 22:51 +0100 skrev Michael Niedermayer:
> Hi
> 
> On Sun, Feb 23, 2025 at 10:30:03PM +0100, Tomas Härdin wrote:
> > lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> > > Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a écrit :
> > > > The above said, I'm not against Rust. It has some nice properties. But
> > > > it does not seem very "stable" so far. Perhaps this has changed in
> > > > recent years..
> > > 
> > > IME, it's become very usable for user-space code. Bare metal still pretty much 
> > > requires unstable features, but that's not a problem for FFmpeg.
> > 
> > I mean more in terms of ABI, and having to have cargo install specific
> > versions of the Rust compiler and so on.
> > 
> > > > If we're in the habit of allowing other languages I'd be in favor of
> > > > allowing C++, so that we can make use of the STL containers rather than
> > > > rolling our own.
> > > 
> > > Yikes. Rust is actually way saner for type-generic programming than C++.
> > 
> > No doubt, but STL is still miles better than rolling our own
> > containers.
> > 
> 
> > Anyway, rather than shoehorning Rust into this codebase it might make
> > more sense to contribute to NihAV instead. But only if it has a sane
> > parsing framework
> 
> That misses the point. FFmpeg should support a "safer" language than C
> because for some modules its the better choice.

Maybe. We can do a lot by just improving the build system. But if we're
going that route I think we should first try and see how working C++
into more parts of the code works, because we already have support for
C++ for torch and decklink. Doing so would allow us to toss out lots of
code, especially in lavu, which is always nice. Code is a liability.

/Tomas