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.

Fifteen minutes, no API keys, nothing to pay for, and a real mp4 at the end of it. The cheapest way to find out whether keryx does what you think.

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.

FFmpeg in pure Go with no install, no CGO and no disk: a WebAssembly build running over an in-memory filesystem, and why it exists.
