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

["Tomas Härdin" <git@haerdin.se>]

mån 2025-02-24 klockan 16:51 +0200 skrev Rémi Denis-Courmont:
> Hi,
> 
> Le 23 février 2025 23:30:03 GMT+02:00, "Tomas Härdin"
> <git@haerdin.se> a écrit :
> > 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.
> 
> Why? The ABI will never be fully stable. Zero-cost abstractions just
> don't lend themselves to an ABI.

The C ABI is very stable. It's why "C for the API/ABI and C++ for the
implementation" is a such powerful combination. Perhaps the same thing
could be done with Rust, or both Rust and C++..

> > > > 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.
> 
> But STL is not worth switching to C++ for.

We already use C++ in the codebase. The cost for using it in more
places is very low

> If the goal is to enable a language with significantly improved
> static safety, without compromising on performance (especially no GC)
> and optimisability, then Rust is pretty much the only option at the
> moment.

I have suggested using formal methods (frama-c) to improve the safety
of the C code. So far the reception has been lukewarm at best, even for
less demanding tools such as value analysis, compared to weakest
precondition calculus (WP). Frama-C is also moving towards C++ support.

> > 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 makes sense if the goal is to publish and forget, but otherwise
> I doubt that NihAV will ever be relevant "in the field".
> 
> That being said, I think Rust would make much more sense for decoders
> and demuxers than for filters and ML stuff.

On this I fully agree. For demuxers it makes perfect sense, and also
for the non-DSP side of codecs. But this is also why, if you're already
willing pay the oxidation cost, contributing to NihAV makes much more
sense, because you're not held back by trying to retain ABI compat.

Far above all this, what is even more important is to do proper
parsing, with say a parser combinator framework, not just implementing
yet another library of shotgun parsers. And of course, using existing
libraries whenever possible. But in this project both of these amount
to tech-heresy.

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