Small Talk

A couple days ago I was chatting with a friend about converting video formats. Everyone’s first reaction was basically: “Just use FFmpeg.” Fair. FFmpeg is like the Swiss Army knife of video—does everything, and almost everyone has used it at least once.

But do you know what it’s written in? C. And it’s old. Massive codebase, complex architecture—like the tangled wires in an old neighborhood: messy, but it works.

ffmpReg project cover, hinting at a Rust-first multimedia future

Recently, a 21-year-old developer named Ajay Kumar did something pretty wild: he decided to rewrite FFmpeg from scratch in Rust. The project is called ffmpReg (it kind of sounds like “FFmpeg registry,” which is funny on its own).

My first reaction was: is this kid just… bored?

Why Rewrite the Wheel

Honestly, when I first saw the project I had a bunch of question marks in my head. FFmpeg works, right? Why not just patch it up and keep going?

But after reading the motivation, I kind of get it.

Multimedia work is basically a “perfect storm”: low-latency I/O, bit-twiddling dirty work, parsers that must be safe and correct, and brutal performance requirements. Put all of that together and you get a programmer’s nightmare.

Rust happens to be good at exactly this: memory safety without a GC, concurrency without fear, and components that compose like LEGO blocks. That’s a pretty good match.

Rust multimedia pipeline architecture diagram

What Exactly Is ffmpReg

Let’s be clear: ffmpReg isn’t a thin wrapper around FFmpeg. It’s a real, from-the-ground-up implementation in Rust—a pure Rust rewrite approach.

Imagine the whole processing pipeline as a chain of LEGO pieces: demux → decode → convert → encode → mux. Each stage is an independent “block” you can swap and compose. Compared to FFmpeg’s classic “god function” vibe, this is way cleaner.

What It Can Do Today

The project is only about five weeks old, but it already looks promising:

  • End-to-end WAV conversion works (pcm_s16le, pcm_s24le, pcm_f32le… convert freely).
  • MKV parsing is half done: container info, codec IDs, and timebase metadata can be read.
  • Next up is broad container support: MKV, MP4, WAV, AIFF.

What the Code Looks Like

Here’s a small example: converting WAV sample formats.

# s16 → f32
ffmpreg convert input.wav --to pcm_f32le -o out.wav

And the lower-level API looks like this:

use ffmpreg::audio::{Frame, SampleFormat, convert};

fn s16_to_f32(frame: Frame<i16>) -> Frame<f32> {
    convert::pcm_s16_to_f32(&frame)
}

Pretty clean, right?

Here’s another example: inspecting MKV file info.

ffmpreg inspect video.mkv

Output looks roughly like:

Container: Matroska (EBML v1)
Duration: 00:04:12.345
Streams:
[0] Video  av1  timebase=1/1000  size=1920x1080
[1] Audio  opus timebase=1/48000  ch=2  layout=stereo

ffmpReg CLI tool screenshot

The Design Philosophy Is Interesting

Some of the goals are genuinely compelling:

Memory safety first: no undefined-behavior gremlins hiding in parsers. Rust’s borrow checker and pattern matching eliminate whole classes of bugs.

Zero-copy: save copies where it matters; slice I/O via &[u8] / Bytes, manage packet lifetimes with arenas.

Predictable performance: no surprise allocations in hot loops; you know exactly when you allocate and free.

Composable graph structure: each stage is a trait object or generic component, supports backpressure, and stays type-explicit.

Opt-in features: codecs and containers are feature-gated—enable what you need, keep the binary lean.

A Small Detail: Timestamps

Timestamps are where multimedia code loves to break. ffmpReg treats them as first-class types:

#[derive(Copy, Clone)]
pub struct Timebase {
    pub num: u32,
    pub den: u32,
}

#[derive(Copy, Clone)]
pub struct Timestamp {
    pub pts: i64,
    pub tb: Timebase,
}

impl Timestamp {
    pub fn to(&self, dst: Timebase) -> Timestamp {
        // Exact rational conversion with overflow checks
        let num = (self.pts as i128) * (self.tb.num as i128) * (dst.den as i128);
        let den = (self.tb.den as i128) * (dst.num as i128);
        Timestamp { pts: (num / den) as i64, tb: dst }
    }
}

Which prevents the classic “wait… is this milliseconds or something else?” moment.

How It Differs from FFmpeg

To be honest, FFmpeg is a battle-tested veteran. If ffmpReg wants to replace it, that’s a long road.

But ffmpReg is chasing a different philosophy: Rust-first ergonomics, small auditable components, and a predictable build pipeline. That’s very different from the “C API + global state + unsafe corners” worldview.

My Take

Rewriting something on FFmpeg’s scale does sound a bit insane. But sometimes it’s exactly these “unreasonable” projects that create new possibilities.

For the Rust community, whether ffmpReg “wins” in the end isn’t even the point. It’s a valuable experiment: it shows Rust is viable in the audio/video processing world, and it clears a path for the next person.

And come on—the author is 21. After five weeks, there’s already a working pipeline. Who knows what this looks like a year from now?

What’s Next

Based on the roadmap, the next steps include:

  • MKV completeness: blocks, lacing, cues, seeking, metadata.
  • Audio essentials: resampling, channel mapping, dithering, perfect PCM/float conversions.
  • Containers: MP4/ISOBMFF demux/mux, better WAV/AIFF.
  • Codecs: FLAC decoding, Vorbis decoding, Opus, AV1 encoding.
  • CLI UX: convert, inspect, probe, transcode, JSON output, progress bars.
  • Test suite: fuzzing, golden vectors, cross-validation against reference tools.

Closing Thoughts

Is ffmpReg “just another wheel rewrite”? It’s too early to call. But one thing is clear: in multimedia, Rust is quietly proving its value.

If you’re into audio/video processing, or you just want to see what a 21-year-old can pull off, keep an eye on this project. Even if it doesn’t fully land, the journey itself is worth watching.

Did this help? Like and share it with friends learning Rust or getting into multimedia dev. Follow the WeChat account “梦兽编程” for more practical tech content. See you in the next one.