MP4 → WEBM fails: "didn't complete this time"

[ogfrench]

What happens

Converting an MP4 to WEBM runs for ~90 seconds and then fails with the generic conversion-failed popup:

Conversion not available yet
MP4 to WEBM didn't complete this time. Try a different target format or another file.

WEBM is offered in the format picker, so this reads as a supported route that quietly doesn't work.

Reproduction

1. Converter surface
2. Drop an H.264 MP4 (reproduced with an 18 MB, 20-second, 1080p phone recording)
3. Target WEBM, Convert
4. ~91s later: the failure popup

What was ruled out

Found while verifying unrelated progress-reporting work, so a few things are already eliminated:

• Not the progress change. That work only reads the assembled argv and emits events; it cannot affect encoding. The same file compresses MP4 → MP4 successfully (316s, 17.3 MB → 5.8 MB, −66%) and converts MP4 → MP3 successfully on the same build.
• Not the file. It is valid — mvhd reports 19.968s, and both the MP4 and MP3 routes handle it.
• Not a timeout. It failed at ~91s, well inside the 10-minute worker ceiling.

Where to look first

Most likely the WEBM encoder is unavailable or misconfigured in the bundled ffmpeg-core build. WEBM needs libvpx (VP8/VP9) plus libopus/libvorbis for audio, and the wasm core is often compiled without them. Worth checking:

• Whether libvpx/libvpx-vp9 appear in the core's -encoders output
• Whether doConvert is passing an explicit codec for WEBM or relying on the muxer default
• The captured stdout from the failed run — FFmpegHandler keeps it, and the real error is likely Unknown encoder or Automatic encoder selection failed

Either way, the copy is wrong

If WEBM genuinely cannot be encoded in this build, it should not be selectable — an offered format that always fails is worse than an absent one. If it can, the failure needs the actual reason rather than "didn't complete this time", which gives the user nothing to act on.

[ogfrench]

Root cause is narrower than "WEBM is broken", and partly fixed in 702eda4 — but not closed.

Both of the muxer's default encoders crash this core

libvpx-vp9 and libopus die with RuntimeError: memory access out of bounds on a two-second clip. ffmpeg picks exactly that pair for a .webm output, so every attempt failed regardless of input size.

Isolated on fresh engine instances, which matters: a bounds error leaves the WASM instance unusable, so anything run afterwards on the same engine also fails. VP8 first looked broken for exactly that reason and is fine.

case	result
vp8 video-only	✅ 258 KB / 26 s
vp8 + opus	❌ memory access out of bounds
vp8 + vorbis	✅ 284 KB / 26 s
vp8 + crf (no -b:v)	✅ 163 KB / 19 s
vp8 + crf + -b:v 0	✅ 163 KB / 20 s
concat demuxer + vp8	✅ 258 KB / 26 s
default codec (vp9)	❌ memory access out of bounds

The encoders are all present — -encoders lists libvpx, libvpx-vp9, libopus, libvorbis. They are compiled in and two of them do not work.

What changed

FFmpeg.ts now pins both sides explicitly rather than accepting the muxer defaults:

const WEBM_VIDEO_CODEC = "libvpx";     // VP8
const WEBM_AUDIO_CODEC = "libvorbis";

Also applied to the audio-to-video placeholder path, which hardcoded libopus for WebM. Guarded by FFmpeg.invariants.test.ts so neither crashing encoder can be reintroduced silently — ffmpeg.wasm has no Node build, so nothing else in CI can catch it.

Why this stays open

The reported 20-second / 18 MB file still fails, now after ~12 minutes. Short clips convert; that one does not. Remaining suspects, in order:

1. Memory. 2 s of 1080p VP8 succeeds, 20 s does not, and the error class is an allocation failure. 32-bit WASM heap.
2. Something in the assembled command that the isolation matrix did not reproduce — the concat demuxer and -crf were both tested clean individually.

I stopped short of isolating (1) rather than keep burning time on it. The pinning is a strict improvement either way: the previous pair failed at every length, including two seconds.

Still true regardless

Whatever the resolution, a target that cannot complete should not sit in the picker offering itself, and "didn't complete this time" after twelve minutes tells the user nothing they can act on.

---

Generated by Claude Code

[ogfrench]

Correcting what I recorded here earlier: I said the remaining cause was most likely memory, and stopped isolating. That was wrong.

It is speed against the worker timeout

Peak wasm heap is flat across every duration, against a 2 GiB ceiling decoded from the core's memory section. Nothing scales with duration:

Clip (1080p30)	Wall time	Peak heap
2s	17.4s	100 MB
5s	49.1s	100 MB
10s	96.1s	100 MB
20s	205s	115 MB

Time is dead linear at ~10x realtime. runInWorker gives up at ten minutes (workerClient.ts:21), so the ceiling lands near a minute of 1080p on the machine I measured on, and proportionally less on a slower one.

That also explains why the symptom changed after the codec pinning. Before, it crashed at ~91s with "memory access out of bounds". After, it ran for ~12 minutes and then failed — the pinning stopped the crash and exposed the timeout underneath. Same generic popup, different cause, which is what made it look like a memory wall.

Your 20-second file takes 3.4 minutes here, so your machine is roughly 3.5x slower — which puts a 20-second 1080p clip right at the ceiling and anything longer past it.

Fix

-cpu-used 5 instead of libvpx's default of 0: 4.6x faster on the same source, 205s → 45s. That brings your file to around 2.5 minutes with room to spare on slower hardware. It costs efficiency rather than quality target — the same content came back 1.54 MB instead of 0.75 MB.

Pinned in FFmpeg.ts with an invariant test, so a refactor cannot quietly drop it.

One thing this does not fix

While measuring I found that -crf is inert for libvpx in this core — -crf 23, -crf 32, and both again with -b:v 0, all byte-identical. So the compression level does nothing on this route and output sits at libvpx's default bitrate. Filed separately as #25, because it changes output for every WebM user and does not belong at the end of a release branch.

Please reopen if a long clip still fails on your hardware — the next lever is resolution, not memory.

---

Generated by Claude Code