Daniel's been watching AI agents get really good at command line tools and it's made him curious about something most of us never think about. FFmpeg — you know, that thing you type when you need to convert a video — can do almost anything with media. Trim, transcode, overlay, analyze, stream. But it's a terminal command. No splash screen, no marketing, no credit roll. Daniel wants to know its history, how many people built it, and what kind of person contributes to a tool that only exists as a text interface.
This is one of those questions where the answer is so much weirder and more interesting than most people would guess. FFmpeg is arguably the most powerful media tool on the planet, and it's a command you type into a black box. No GUI. No brand recognition outside developer circles. But it powers YouTube, VLC, OBS, Plex — basically every video pipeline in existence runs through FFmpeg at some point.
So today we're going to look at one of the most powerful CLIs ever written, and ask a question we rarely ask about the tools we type into a terminal: who made this, and why?
And the timing on this is perfect, because agentic AI is making CLIs cool again in a way I don't think anyone predicted. LLMs are suddenly expert users of tools like ffmpeg, grep, sed — they're turning cryptic flags into natural language requests. An AI agent can now chain together a dozen ffmpeg commands to do something that used to require a human reading man pages for an afternoon.
Which means the design decisions someone made twenty years ago about how flags should work and how filters should chain together — those decisions are suddenly load-bearing for an entirely new kind of user that didn't exist when the code was written.
So let's start with what FFmpeg actually is, because the name itself tells you something. It stands for Fast Forward MPEG. It started in the year two thousand as a way to handle MPEG video on Linux when basically nothing else could. It's a cross-platform solution to record, convert, and stream audio and video. But that description doesn't capture the scale of what it does now.
What does it do now?
Everything. It handles hundreds of codecs, dozens of container formats. It can transcode between basically any two media formats that exist. It can extract audio from video, burn in subtitles, apply filters, analyze motion vectors, generate waveforms, stream to a server, grab from a live source. The filter system alone — the dash v f and dash a f flags for video and audio filters — is essentially a domain-specific language. You can compose transformations like a pipeline. Overlay this on that, scale it, rotate it, blend it, then pipe the whole thing into an encoder.
And all of this lives behind a command you type. No buttons, no timeline, no preview window.
Right. And that's not a limitation — that was the architectural choice that made FFmpeg programmable. The CLI is the API. You can script it, pipe it, compose it. GUI video editors came and went over the last twenty years, and FFmpeg is still here because a command line interface doesn't age the way a graphical interface does. There's no design language to go out of fashion, no framework to become obsolete.
The terminal is the world's most stable UI framework.
It really is. And the reach of this thing is staggering. If you've ever watched a YouTube video, FFmpeg was involved. VLC uses FFmpeg under the hood. OBS — the tool every streamer uses — depends on FFmpeg. Plex, Handbrake, basically any tool that touches video on a server runs FFmpeg somewhere in the pipeline. It processes more video every day than all commercial video editors combined, and most people have never heard of it.
Which brings us to Daniel's actual question. Who built this thing? And what kind of person looks at the landscape of media tools and decides, I'm going to spend years of my life on something that only speaks in text?
So let's go back to the beginning — to a French programmer who, in his spare time, wrote one of the most important media tools ever created.
Fabrice Bellard.
Fabrice Bellard started FFmpeg in two thousand. And Bellard is one of those figures who makes you question what's possible for a single human being to accomplish. He also wrote QEMU — the hardware emulator that runs most of the cloud. He wrote a tiny C compiler called TCC that can compile the Linux kernel in seconds. He calculated pi to two point seven trillion digits. He wrote a software 4G base station. He wrote a PC emulator in JavaScript that runs Linux in a browser.
So FFmpeg was his side project.
His side project. He was frustrated that Linux didn't have good tools for handling MPEG video, so he wrote one. That's the origin story of a shocking amount of critical infrastructure — someone was annoyed and nobody else was fixing it fast enough.
The "fine, I'll do it myself" school of software engineering.
Which has produced more value than every corporate roadmap combined, I'm convinced. But here's where the story gets more complicated, and more interesting for Daniel's question about who maintains these things. FFmpeg didn't stay Bellard's project. It grew, attracted contributors, developed a community. And in twenty eleven, that community had a schism.
The Libav fork.
The Libav fork. This is a rare window into how open source CLI tools handle conflict, because there's no corporate parent to adjudicate. There's only technical merit and community trust. The dispute was over governance and the release process — how decisions got made, how often releases happened, who had commit access. A group of developers, including several core maintainers, felt the project was stagnating under the existing structure. They forked the code, called it Libav, and initially most of the contributors went with them.
So the FFmpeg project essentially lost its community overnight.
It did. And for a while, Libav was the dominant fork. Debian switched to Libav. Ubuntu shipped Libav. It looked like FFmpeg might become the abandoned parent project. But the FFmpeg project rebuilt. They brought in new maintainers, established clearer governance, and by about twenty fifteen, FFmpeg had re-established itself as the dominant fork. Debian switched back. The Libav project eventually wound down.
What decided it? Why did FFmpeg win?
Partly it was the name recognition — FFmpeg was the brand people knew. Partly it was that the FFmpeg project was more aggressive about merging patches and supporting more formats. And partly it was just... the community that rebuilt around FFmpeg was more open to new contributors. The fork taught both projects something about governance, but FFmpeg seemed to learn the right lessons faster.
So the tool that powers half the internet's video almost didn't survive its own community dynamics.
And that's the thing about CLI tools that have no corporate owner. Their survival depends entirely on whether enough people care to keep them alive. There's no marketing department to spin a comeback, no CEO to reassure the press. Either the code gets maintained or it doesn't.
Which brings us to the people. Daniel asked how many have been involved, and what kind of person contributes to something like this.
According to OpenHub data, FFmpeg has had over two hundred contributors across its lifetime. The core maintenance team is small — maybe a dozen people doing the majority of the ongoing work. But the long tail is fascinating. You've got codec specialists, format hackers, people who contributed a single critical patch for a niche container format and then disappeared.
What's a niche container format look like?
Think about something like the DTS audio codec. Someone out there has a home theater system that plays DTS-encoded audio, and they wanted FFmpeg to handle it properly, so they wrote a decoder. Or someone works with broadcast video and needed MXF container support, so they contributed that. The contributor list is a map of every obscure media format that someone, somewhere, cared enough about to implement.
So the motivation is often just... they needed it to work.
That's the biggest one. For a lot of contributors, FFmpeg is infrastructure — they need it for their day job. A codec engineer at Google or Netflix or Intel needs FFmpeg to support their company's hardware or format, so fixing a bug or adding a codec is faster than waiting for someone else to do it. Intel contributed the QSV hardware acceleration support because they wanted FFmpeg to use Intel Quick Sync Video. Google engineers have contributed VP8 and VP9 codec support. Netflix engineers work on FFmpeg because their entire encoding pipeline depends on it.
So these aren't volunteers in their spare time. They're paid professionals whose employer needs the tool to work.
A lot of them are, yes. And that's one of the misconceptions about open source CLI tools — that they're maintained by hobbyists working nights and weekends. Some of them are. But many FFmpeg contributors are doing it as part of their job. Their company has a business need, and contributing upstream is the most efficient way to meet it.
Which is a pretty good business model for a tool with no business model.
It's the "I need this to exist, so I'll help make it exist" model. But there's also something else going on. Beyond the paid contributors, there's a genuine craft ethos around CLI tools. The command line is clean in a way GUIs aren't. There's no design by committee, no product manager saying "can we make the button blue." The interface is the API, and the API is the logic. For a certain kind of engineer, that's deeply satisfying.
The absence of a GUI isn't a missing feature. It's the feature.
Right. And this connects to something I've been thinking about with agentic AI. The filter chain syntax in FFmpeg — the dash v f flag where you string together operations like "scale this, then overlay that, then draw text here" — that's a domain-specific language. It was designed for humans to type, but it turns out it's even better for machines to generate. An LLM doesn't care that the syntax is cryptic. It just needs it to be composable, predictable, and stateless.
Which is exactly what FFmpeg's CLI is.
No hidden state, no modal dialogs, no undo buffer that might be in an unknown condition. Every command is self-contained. Given the same input and the same flags, you get the same output every time. That's ideal for an AI agent. The design decisions Bellard and the community made twenty years ago — composability, predictability, scriptability — are suddenly more valuable than ever, because the primary user of these tools is shifting from humans to machines.
So the CLI was built for humans but optimized for AI by accident.
By accident, but also by philosophy. The Unix philosophy — do one thing well, compose with pipes, use text as the universal interface — that was always about making tools that could be combined in ways their creators never anticipated. AI agents are just the latest thing doing the combining.
You mentioned the contributor list is a map of obscure formats. What does the career path look like for someone who contributes to FFmpeg?
It's become a de facto training ground for video engineering talent. Companies hire people who have FFmpeg commits because it's a signal they understand media at the bitstream level. You can't fake an FFmpeg contribution — you either know how a video codec works or you don't. Several contributors have built entire careers on the back of their work on the project. Michael Niedermayer, who was one of the core maintainers for years, is a recognized expert in video compression. People who cut their teeth on FFmpeg now work at Netflix, at Google, at Apple, at every company that moves video over the internet.
So the invisible tool creates visible careers.
It does. The CLI is the least flashy surface imaginable — literally just text in a terminal — but it's also a portfolio. Every commit is public. Every patch is a demonstration of competence. In a field where credentials can be hard to verify, an FFmpeg commit is a credential.
That's the history and the people. But the more interesting question Daniel's getting at is what this all means now, as AI agents become fluent in these tools.
We're seeing FFmpeg get a second life. An AI agent can now do what used to require reading man pages for an afternoon. "Transcode this video to H.264 at 1080p, extract the audio as MP3, and burn in these subtitles" — an LLM can generate the correct ffmpeg command for that in seconds. It can chain together filter graphs that would take a human half an hour to debug.
And the agent doesn't get frustrated when the error message is incomprehensible.
It doesn't get frustrated, but it does hit the same walls. Which is where this gets interesting. FFmpeg's error messages are famously... let's say austere. The tool assumes you know what you're doing, and if you don't, it will not help you. An LLM encountering a cryptic FFmpeg error has to do exactly what a human does — search forums, read source code, try variations until something works.
So the AI inherits the same learning curve.
It does, but it can climb it faster. And this raises an open question that I don't think anyone has a good answer to yet. As AI agents become the primary users of CLIs like FFmpeg, will the interface change? Will we see "AI-friendly" flags — more verbose output, structured JSON modes, better error messages?
Or will the agents just adapt to the existing interface and ossify it further?
That's the tension. If LLMs get good enough at reading cryptic error messages, there's zero incentive for maintainers to improve them. The human-unfriendly CLI gets preserved because the machines can handle it, and the humans who still need to use it directly are left with an even steeper climb.
The tool becomes more powerful and less accessible at the same time.
Which is... no, start with the container. The CLI was always supposed to be the power user interface. The GUI wrappers — Handbrake, OBS, whatever — were supposed to be the accessible layer. But if AI agents make the CLI so productive that the GUI layer atrophies, we might end up in a world where the only way to use FFmpeg effectively is through an AI intermediary.
And the people who actually understand what's happening under the hood become even rarer.
Which is a genuine concern. We're already seeing this with programming more broadly — LLMs can generate code, but debugging that code when it fails requires understanding it. If nobody learns FFmpeg's filter syntax because the AI handles it, who fixes the AI's mistakes?
So we're back to the people. The two hundred plus contributors who built this thing — they're not just maintaining code, they're maintaining a body of knowledge about how media works at the bit level. And that knowledge has to live somewhere.
It lives in the source code, in the commit messages, in the mailing list archives. FFmpeg's development history is essentially a twenty-five-year seminar on digital media. Every codec implementation is a practical lesson in signal processing. Every format muxer is a lesson in container design. The CLI is just the surface — underneath it is an extraordinary accumulation of specialized knowledge.
None of it has a splash screen.
None of it has a splash screen.
Speaking of people who have spent way too much time with FFmpeg...
Hilbert: I had a wrapper script. Two thousand seven. Bash, about four hundred lines. Took parameters like "input format DV, output format H.264, target device iPod" and spat out the correct ffmpeg incantation. Worked about eighty percent of the time. The other twenty percent it produced files that would play upside down on a first-generation iPod Touch. I never figured out why.
You were doing agentic AI before it was cool.
Hilbert: I was doing it before it was profitable, which is the same thing.
What was the startup?
Hilbert: Called StreamWell. Raised four million dollars, burned through it in eighteen months, shut down in two thousand eight. My job was transcoding the entire catalog into seven different formats for seven different devices. iPhone, iPod, Zune, PSP, a Flash player that needed FLV, a Silverlight thing that needed WMV, and RealPlayer for some reason. RealPlayer was already dead but the CEO's wife used it.
Of course she did.
Hilbert: I had a rack of four Dell PowerEdge servers running ffmpeg twenty-four hours a day. The wrapper script was supposed to make it so the intern could queue up transcodes without knowing what a codec was. The intern was the CEO's nephew. He queued up a three-hour documentary in reverse once. The whole thing. Credits first, then the movie running backwards. Took me two days to notice because I was debugging why FFmpeg would crash on a specific MP4 file from a specific camera.
What was the error?
Hilbert: "Application provided invalid, non monotonically increasing dts to muxer." That's it. No line number, no hint. I had to read the source code. The CLI is powerful, but it's also merciless. It assumes you know what you're doing, and if you don't, it will not help you.
That's a decoding timestamp error. The frames were arriving out of order and the muxer couldn't reconstruct the proper sequence.
Hilbert: I know what it is now. In two thousand seven I was just a man with a bash script and a dream that was slowly being crushed by a specific JVC camcorder that wrote non-standard MP4 files. I still have one of those camcorders. It's in a box.
The wrapper script is the part that gets me. You essentially built a proto-agentic AI layer — take high-level intent, generate the correct CLI invocation — but in bash, with case statements, fifteen years before LLMs started doing it.
Hilbert: It wasn't smart. It was just a lookup table. "If target is iPod, use these flags. If source is interlaced, add the deinterlace filter." The hard part wasn't generating the commands. The hard part was knowing which commands to generate. That took months of trial and error, reading forum posts, and one very long phone call with a German engineer who had reverse-engineered the iPod video chip.
That's exactly what the FFmpeg contributor community is. All that trial and error, all that reverse engineering, accumulated over decades and compressed into source code and documentation. Your wrapper script was a thin layer on top of an enormous pyramid of specialized knowledge.
Hilbert: The pyramid is held together by about a dozen people who understand the whole thing. Everyone else understands their one brick. I understood the iPod brick. The German engineer understood the video chip brick. Fabrice Bellard understood... all the bricks, apparently.
Do you still have the script?
Hilbert: It's on a hard drive somewhere. It wouldn't run on a modern system anyway. The ffmpeg flag syntax has changed three times since then. That's the other thing about CLI tools — they evolve. Your wrapper breaks. Your knowledge goes stale. The only thing that stays constant is the terminal window.
And the error messages.
Hilbert: The error messages stay constant. I checked recently. "Non monotonically increasing dts" is still there. They haven't improved it. They haven't needed to, because the kind of person who encounters that error is expected to know what it means or figure it out.
Or ask an AI.
Hilbert: Or ask an AI. Which, I have to say, would have saved me about three weeks in two thousand seven. I'm not bitter about it.
You sound a little bitter.
Hilbert: I'm a little bitter. The company went under, I never got my last paycheck, and somewhere in a landfill there's a Dell PowerEdge with my ffmpeg wrapper script still on the hard drive, still trying to transcode a RealPlayer file that nobody will ever watch.
The most common misconception about FFmpeg is that it's a single tool written by one person — some genius in a room who cranked out the whole thing.
The reality is it's a massive collaborative project with over two hundred contributors, a complex governance history, a near-death experience in the form of a fork, and a community that spans hobbyists, academics, and engineers at the biggest tech companies on earth. Fabrice Bellard started it, but FFmpeg is the work of hundreds of hands.
The CLI wasn't a limitation. It was the design choice that made all of that collaboration possible. A GUI would have constrained what the tool could become. The command line let it grow in whatever direction its contributors needed it to grow.
Now we're watching AI agents become fluent in that command line, which raises a question I don't think we've answered yet. As the machines get better at using these tools than we are, does the interface change to serve them, or does it stay frozen in the form that humans built? I suspect we're going to find out in the next few years.
FFmpeg is a reminder that the most important software is often invisible. No GUI, no brand, no press releases. But it processes more video every day than all commercial video editors combined. The people who built it are engineers, hobbyists, and academics who believed a command line was worth getting right.
They were right. Twenty-five years later, their text interface is teaching machines how to see. Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. Find us at my weird prompts dot com, or email the show at show at my weird prompts dot com. We'll be back soon.
