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

[Leandro Santiago <leandrosansilva@gmail.com>]

(I am replying to the messages in general, not inline, as I got lost with all the subthreads).

My opinion on C++ vs Rust:

I've been using mostly C++ during my career (~15 years) and I confess I kind of lost hope on its future. I no longer see any advantages of writing new code in C++ just because of the language merits.

Unless of course it's "the right/only tool for the job", due to the amount of high quality C++ libraries and large C++ codebases out there, as well as wider compiler/platforms support, to make my position clear.

The main selling point I see C++ has over Rust here is being mostly a superset of C, able to simply include C files.

The good parts of the STL, the containers and algorithms, make it easy to accidentally allocate memory, as well as one never knows really if something will throw an exception, making it harder to work from the C side.

Rust, IMO, prevents most of those issues, due to its explicit nature, especially regarding sharing and allocating/releasing memory.

I also feel that the algorithms and interfaces in the Rust standard library are better designed and provide better ergonomics and performance than the C++ counterparts. C++ has tried hard to improve it with ranges, but the syntax is weird and it seems to have gained little traction.

C++ ranges also do not prevent one of making simple mistakes with object lifetimes.

In my experience on Linux, it's also quite difficult to statically link to lib[std]c++.

Rust, on the other rand, has mature tooling and defaults to static link everything by default. This means no more need to depend on specific versions of GCC, for instance. (in practice, though, ffmpeg will likely link to libstdc++ due to its dependencies).

With Rust (and cargo), 3rd party code vendoring seems to be more mature, so one does not need to depend on an internet connection to build code with cargo.

One of the biggest disadvantages of Rust regarding C compatibility is not being able to simply #include C code. One has to rely on tools such as bindgen for bridging the two ecosystems. In my little experience, it does quite a good job, though, with few bits left to be fixed (things such as complex macros, etc.).

Extra manual work is usually needed, though, to write proper safe and "rusty" wrappers around the unsafe C API.

There is also the question about how to ship and dynamically link Rust libraries. I've played only with static linking and can already foresee challenges linking it dynamically in my application.

While I have no doubts that Rust could benefit core libraries such as avcodec/avformat (which I have very little knowledge of), I imagine that other non core code would benefit as well.

I started playing around with avfilter, but I really think that the fftools would be good candidates for a "RiiR", as they are complex codebases that have no dependents, besides being how most ffmpeg users interact with the project.

In any case, I don't plan to propose mainlining my work on the Rust filters, but I'll continue working on it, and be open to contributions and suggestions. I am not forking ffmpeg as a project, to make it clear. My code is right now very ugly and needs lots of refactoring and cleanup, bugfixing and maturing, being far from being "production ready".

Cheers,

Leandro

On 2/24/25 15:51, Rémi Denis-Courmont wrote:
> 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.
>
> But what is stable is not going to just break in a future version. We could settle for Rust edition 2024 and not depend on any specific compiler version, AFAICT.
>
>>>> 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.
>
> 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.
>
> If the goal were to provide a nicer language to work with rather than improving safety, then maybe Zig would be better than Rust. But I don't see a scenario where C++ can be justified/worthwhile.
>
>> 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.
> _______________________________________________
> 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".
_______________________________________________
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".