The escape hatch that turned out to be french doors
I wanted an FFmpeg that couldn't touch my disk. Building the interface to get one accidentally produced something considerably more useful.

I wanted an FFmpeg that couldn't touch my disk. Building the interface to get one accidentally produced something considerably more useful.

Every FFmpeg progress bar I've seen scrapes the CLI's stderr. afmpeg has no CLI to scrape, so progress had to become part of the API instead.

A security review read "safely process untrusted media" and asked the harder question. A sandbox stops escape; it does not stop exhaustion.

The last US AVC patent expires in November 2027. Until then ffmpeg-wasi's H.264 encoder ships on sufferance, on Cisco's binaries taught to run under WASI.

FFmpeg assumes a disk it can seek around in. Giving it a convincing in-memory filesystem, and testing the behaviour that would hurt most first.

afmpeg shipped single input to single output. Adding multi-pad filter graphs and multi-output muxing: one decode, two files, one pass.

Adding stream-copy remux to a WebAssembly FFmpeg build, where writing Matroska hung forever and the identical MP4 path did not.
