Browsers and Processing Power: What Runs Local Transcoding Well
Same tool, same file, triple the speed difference across machines — the performance ceiling of local transcoding is set by browser and hardware together. Knowing the boundary tells you how to schedule big jobs.
Two engine layers: wasm baseline, WebCodecs fast path
The site’s transcoding engine has two layers. The WebAssembly layer (ffmpeg.wasm) is the baseline — any device running a modern browser can use it, with the best compatibility but CPU-bound speed. The WebCodecs layer is the fast lane — it drives the browser’s built-in hardware encoders, and tools like compression, resizing, and trimming take this path on supported browsers, often several times faster.
WebCodecs availability: recent Chromium-based browsers (Chrome/Edge) with H.264 hardware encoding support. Where unsupported, tools fall back to the wasm layer automatically — same result, slower pace. No configuration needed; tools detect it themselves.
Multithread vs single thread: what COOP/COEP do
The wasm engine itself has two gears: a multithreaded core (using multiple cores) and a single-threaded core. Multithreading requires cross-origin isolation (COOP/COEP response headers), which modern desktop browsers support by default; environments without isolation fall back to single thread — slower, identical results. This is one common reason "the same file compresses faster on my colleague’s machine".
Memory is the other invisible boundary: browsers cap per-tab memory, and tens of minutes of 4K footage are memory-hungry. Large files failing is not a performance issue but a memory one — the fix is processing in segments and merging.
Self-check and job scheduling
Three quick checks: browser up to date (old kernels lack WebCodecs and cross-origin isolation); hardware acceleration working (confirm graphics drivers are healthy in system settings); tab not frozen by browser sleep (long-backgrounded tabs get suspended — return to the tab and processing resumes, progress intact).
Scheduling guidance: small jobs (tens of MB) run smoothly anywhere modern; medium jobs (hundreds of MB) are best on desktop Chrome/Edge; large jobs (GB-scale long video) should be segmented or split across sessions. Mobile browsers suit lightweight image and short-audio work — long-video transcoding belongs on desktop.