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