ffmpeg-wasi¶

ffmpeg-wasi builds FFmpeg's libav* libraries and drives them with a small purpose-built engine, shipping the result as two runtime targets: a sandboxed wasm32-wasi module that runs media pipelines anywhere a WASI runtime does — designed for wazero, the pure-Go runtime, so Go programs can transcode/filter/mux embedded, CGO-free, and sandboxed — and a native driver (real threads + SIMD) that runs the same jobs at 48–58× the software-encode speed.

It is the reference server-side FFmpeg for WebAssembly: current (not the EOL build), WASI-native (not the browser one), and pure-Go-runnable (no CGO) — by linking the libraries directly and going under the FFmpeg-7.0 CLI threading wall that stops everyone else. The native driver (spec 0028) is the same engine and the same job-spec, built for the host instead of the sandbox — a drop-in speed tier, driven out-of-process by afmpeg's native backend.

Before you start, check it does what you need. Limits & what is not supported is the short list of things ffmpeg-wasi deliberately will not do — no ffmpeg command lines, no network inputs, no hardware acceleration, no HEVC or AV1 encode from the .wasm module, and a native driver for linux/amd64 only.

Status: released. Releases ship current FFmpeg (n8.1.2) as lgpl and gpl builds, in a lean and an intermediate profile — both as portable WASI modules and as native drivers (spec 0028, threads + SIMD, driven by afmpeg's native backend for 48–58× faster software encode). The native driver adds a third full profile with HEVC (x265) and AV1 (SVT-AV1) encode. The engine transcodes (decode → filter → encode → mux) over a virtual filesystem: the probe, process (full filter_complex), frames, and version ops all work today. Design: afmpeg spec 0007.

Further reading¶

Everything written about the estate, including the curated guides, is on the blog.