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.

If you’ve ever wired a progress bar to FFmpeg you know the trick, and it’s a good one: run the CLI, watch stderr, and pull the numbers out of the frame=... fps=... time=... speed=... line it rewrites every half second. …

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.
