Video & Audio Converters

How FFmpeg WebAssembly Powers Offline Media Conversion

Historically, digital media conversion was incredibly taxing, requiring specialized command-line binaries compiled specifically for individual operating systems (Linux, macOS, Windows). Executing these processes inside a sandboxed web browser was deemed impossible.

With the emergence of WebAssembly (WASM), developer toolchains can compile raw C and C++ source repositories directly into platform-independent instruction sets. Under the hood, DuckConvert utilizes the official @ffmpeg/ffmpeg package:

What each output format is actually encoded with

There are no quality sliders here, so it is worth publishing what the presets are. These are the exact settings the worker passes to ffmpeg.

• MP4 — H.264 via libx264 at CRF 23 with the veryfast preset, pixel format forced to yuv420p, audio AAC at 128 kbps. CRF 23 is x264’s own default and is visually close to the source for most material. Forcing the pixel format is what makes the result play everywhere: some phone captures use a format many players show as a green or blank rectangle.
• WebM — libvpx targeting 1 Mbps, audio Vorbis. That is VP8 rather than the newer VP9, which encodes far more slowly in WebAssembly than most people are willing to wait.
• AVI — libxvid at quality scale 3, audio MP3. AVI exists here for old software that will not accept anything else; it is not a format to choose on merit.
• Animated GIF — 10 frames per second, scaled to 480 pixels wide with Lanczos resampling, through a two-pass palettegen/paletteuse filter. The two passes matter: GIF allows only 256 colours, so the first pass reads the whole clip and builds a palette fitted to it. Without that step ffmpeg falls back to a generic palette and gradients band badly.
• Audio — MP3 via LAME at -q:a 2 (variable bitrate, averaging roughly 190 kbps); M4A and AAC at 192 kbps; WAV as uncompressed 16-bit PCM; FLAC and Vorbis at their own defaults.

Two consequences worth knowing

Every conversion re-encodes. There is no stream-copy path, so a file that only needed its container changed — an MOV already holding H.264, say — is decoded and compressed again anyway. That costs time and one generation of quality on a file that needed neither.

Opus output is deliberately missing. The encoder is compiled into the build and handles mono correctly, but crashes the entire WebAssembly module the moment it is handed a stereo stream, at any sample rate and in any container. Since nearly all real audio is stereo, offering it would fail for nearly every file. Downmixing to mono to dodge the crash would silently throw away a channel, so it is not offered at all. Reading .opus files is unaffected — that uses a different decoder, which is fine.