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

From: "Tomas Härdin" <git@haerdin.se>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] I've written a filter in Rust
Date: Wed, 26 Feb 2025 15:11:13 +0100
Message-ID: <75dfc4639cd6851a60de100d19a8bc4c3bb34a14.camel@haerdin.se> (raw)
In-Reply-To: <20250223215144.GS4991@pb2>

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

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