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

["Rémi Denis-Courmont" <remi@remlab.net>]

Le perjantaina 21. helmikuuta 2025, 15.18.06 UTC+2 Lynne a écrit :
> > - 1: get a working and efficient implementation of the SORT algorithm.
> > - 2: start learning Rust again (it's been ~5 years since I used it)
> > - 3: learn more about the libavfilter codebase
> > - 4: evaluate whether Rust could work as a second language for hacking
> > FFMpeg.
> 
> None of us know Rust confidently enough to maintain and work on such code.

A project should of course limit the number of distinct programminglanguages 
involved for a number of reasons, but there are people who know Rust quite 
well here as well as in adjacent projects from the OSS multimedia community.

The sustainability problem is really not specific to the programming language. 
The majority of FFmpeg code requires domain-specific knowledge that even most 
FFmpeg maintainers don't have. By that same logic we should not have any 
assembler optimisation for any instruction set other than, maybe, 386 and 
support only the most well-known codecs and containers.

(...)
> Regardless of the language, I disagree with using crates in the context 
> of FFmpeg

I assume that you mean *external* crates because if FFmpeg starts 
incorporating Rust, I would certainly expect it to consist of a workspace with 
multiple crates.

With that said, external crates are just the Rust equivalent of external C 
libraries. I agree that, ideally, FFmpeg should not depend on external 
libraries and carry native implementations of anything other than the 
languages runtimes and hardware abstraction layers...but in actuality, FFmpeg 
has tons of libraries as optional dependencies.

> and any use of cargo.

I fail to see the problem, TBH. You can use rustc directly, but it's really 
inconvenient with little to no benefits. I don't see why we couldn't use Cargo 
to produce static libraries, then have the Makefile import those static 
libraries into the existing linking process.

We can (and most definitely should) restrict adding external crates in the 
Cargo manifests but that does not mean we should ban Cargo altogether.

> We used to link to OpenCV. The only reason why we dropped it was because 
> we used the C interface, which was removed, and no one wanted to or was 
> interested in rewriting it.

I agree that we should not depend on external *frameworks*.

-- 
Rémi Denis-Courmont
Tapio's place new town, former Finnish Republic of Uusimaa



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