Why FFmpeg and VLC Developers Are Skeptical of Rust Rewrites

Lex Fridman asks two veteran multimedia developers what they think about Rust, and the answers land far from the hype cycle. The clip features Kieran Kunhya (FFmpeg developer, wearing a trademark orange VLC traffic cone hat) and Jean-Baptiste Kempf (VLC president and co-founder), both speaking from years of shipping performance-critical C and assembly code in projects used by hundreds of millions of people.

Rust Has an Esperanto Problem

Kieran fires first. He acknowledges that memory safety as a concept is valuable, but calls Rust's community energy misplaced. His comparison is pointed: Rust reminds him of Esperanto, the constructed language designed to be perfect but never widely adopted because it prioritized ideological purity over meeting people where they already were.

He extends the analogy to Sir Clive Sinclair's C5, an electric vehicle from the 1980s that was technically forward-thinking but practically unusable. Sinclair believed everyone would adopt it. Almost nobody did. The lesson: to displace an entrenched technology, the replacement has to be at least as good across every dimension that matters, not just the dimensions the new thing cares about.

For FFmpeg specifically, Kieran says nobody would object to Rust code in the project. But it would need to pass the same unit tests, maintain ABI stability, and match the existing tooling. Offering memory safety while falling short on those practical requirements is not a trade anyone in the project is willing to make.

Rewriting Is Almost Always the Wrong Move

Jean-Baptiste Kempf picks up the thread from his experience building VLC and his new startup Kyber (an open-source project written primarily in Rust). He is not anti-Rust. He calls it "a better C++ that cares about memory" and praises its ownership model as genuinely novel. He has written Rust modules for VLC and uses the language daily.

But his position on rewrites is firm: in all his years as an engineer, manager, and CTO, the answer is almost always "don't rewrite." He explains why through a principle that anyone who has inherited a codebase will recognize. It is an order of magnitude easier to write code than to read code. When a developer arrives at a complex, unfamiliar codebase, they do not understand it. They lack the original author's thought process, the undocumented business logic, the reasons behind decisions that look arbitrary from the outside.

So they say "let's rewrite it." And the rewrite gets to 80% fast, then 90% with more effort, and then the last 10% becomes a grind that may never finish. He points to the Rust coreutils rewrite as a real-world example of this pattern, echoing Kieran's earlier point about the last 1% taking 99% of the time.

The Assembly Problem Nobody Talks About

The most technically interesting argument comes at the end. Kempf points out a gap in the Rust security narrative that rarely gets discussed. Take a video codec like dav1d or x264. A large portion of the runtime lives in handwritten assembly, carefully optimized for specific CPU instruction sets. You could rewrite the C scaffolding in Rust and gain memory safety there. But the moment execution drops into handwritten assembly, all safety guarantees vanish. Assembly can jump anywhere in memory. It does not respect Rust's ownership model or borrow checker.

His proposed solution is not "rewrite assembly in Rust" (which would sacrifice the performance that justified handwriting it in the first place). Instead, he advocates for compile-time instrumentation of assembly code itself, verifying at build time that assembly routines are not making unsafe memory jumps. He references work already underway on the dav1d and x264 projects with Videoland to do exactly this. In his view, "secure assembly" tooling is the real frontier, not Rust rewrites that leave the most dangerous code untouched.

Key Takeaways

• Rust's memory safety model is a real contribution, but evangelism without full practical parity drives skepticism among maintainers of large C codebases.
• To displace entrenched technology, the replacement must match or exceed it on every axis that matters to existing users, not just the axes the new tool optimizes for.
• Rewriting existing software is almost always a mistake because reading code is an order of magnitude harder than writing it, and the hidden logic in mature codebases is what makes the last 10% of a rewrite so brutal.
• For performance-critical multimedia code, the real security gap is handwritten assembly, which breaks any safety model the moment it executes. Compile-time assembly instrumentation may be more valuable than language-level rewrites.
• Rust shines on greenfield projects and in domains like parsing and networking where its memory and bounds checking provide immediate, measurable safety gains.