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-requ...@ffmpeg.org with subject "unsubscribe".
