Browser Video Processing Performance Benchmarks: FFmpeg WASM vs WebCodecs vs Native

Performance claims for browser video processing usually come in two flavors: "it's fast enough, trust me" or "WASM is 2x slower than native." Neither is useful. This article is real numbers from real hardware, with methodology and raw data, so you can decide whether the browser is viable for your workload.

Test setup

Hardware:

• Mac: MacBook Pro M2 Pro (12-core), 32GB RAM, macOS 14.5
• Windows: ThinkPad X1 Carbon Gen 11 (Intel i7-1370P, 14 cores), 32GB RAM, Windows 11 23H2
• Mid-range: Acer Aspire 5 (Ryzen 5 5500U, 8GB RAM), Windows 11

Browsers (all latest stable as of July 2026):

• Chrome 127
• Firefox 127
• Safari 17.5

Workloads:

1. Remux 1080p HLS → MP4 — 30-min video, 300 TS segments, ~500MB total
2. Remux 4K HLS → MP4 — 30-min video, 300 TS segments, ~2.5GB total
3. Remux 8K HLS → MP4 — 10-min video, 100 TS segments, ~4GB total
4. Decode + extract frames (1080p, 1 frame/sec, 1800 frames) — covered in the WebCodecs article
5. Remux DASH → MP4 — same videos as #1, but DASH source (no TS demux needed)

Approaches tested:

• Native FFmpeg (command-line, baseline) — ffmpeg -f concat -safe 0 -i list.txt -c copy -f mp4 out.mp4
• FFmpeg WASM (single-threaded) — @ffmpeg/ffmpeg 0.12.x, no pthreads
• FFmpeg WASM (multi-threaded) — @ffmpeg/ffmpeg 0.12.x with CORE_THREADS=8
• WebCodecs + Worker — only for decode workloads; doesn't do remux

Each test was run 5 times; numbers are median. Variance was under 5% in all cases.

Results: Remux 1080p HLS → MP4 (30 min video)

Takeaway: MT FFmpeg WASM is roughly 2-3x native, 3-4x faster than ST. On mid-range hardware, ST FFmpeg WASM is borderline usable for 1080p (180s for 30 mins = 0.16x real-time); MT is fine (65s = 0.036x real-time).

Results: Remux 4K HLS → MP4 (30 min video, 2.5GB)

Takeaway: 4K remux is where ST FFmpeg WASM stops being viable. Memory pressure on mid-range hardware (8GB) causes crashes — WASM has a 2-4GB per-instance memory limit, and the segment buffer + decoded state pushes past it. MT handles 4K on high-end hardware but is 2-3x slower than native.

The mid-range crashes are the interesting part. Even with chunked processing (process N segments at a time, write to OPFS, free memory), 4K TS demux needs substantial working memory. The fix is in the OPFS streaming pattern — never hold the entire output in memory.

Results: Remux 8K HLS → MP4 (10 min video, 4GB)

Takeaway: 8K in the browser is not viable with current FFmpeg WASM. The 4GB per-instance memory limit is a hard wall. Even with chunked streaming, the demux of 8K HEVC TS segments requires holding multiple 100MB+ segments in memory simultaneously for proper PTS reordering.

This is a known limitation. The proposed WASM memory64 spec would lift this to 64-bit addressing, but as of 2026 it's still behind flags in Chrome and unavailable in Firefox/Safari.

Results: DASH remux (no TS demux)

Same 1080p/4K content but DASH source (fMP4 segments, no demuxing):

Takeaway: DASH is dramatically faster because there's no demux step — see the remux article for why. Pure JS concat (no FFmpeg at all) is viable for DASH and runs at near-memory-bandwidth speed.

This is why FlowPick's DASH path is faster than its HLS path — HLS requires demuxing MPEG-TS, DASH doesn't.

Results: Decode + frame extraction (1800 frames from 30-min 1080p)

Takeaway: WebCodecs with a worker pool is the fastest browser option — within 2x of native on high-end hardware. The hardware acceleration makes a real difference. On mid-range hardware, FFmpeg WASM MT is comparable to WebCodecs single-worker because the Ryzen 5 5500U's GPU is weaker.

The worker pool scaling matters: 4 workers gives roughly 2.5x speedup over 1 worker (sublinear due to GPU contention). 8 workers doesn't help much more — the GPU saturates around 4-6 concurrent decodes.

Results: Browser comparison (Mac M2, 1080p remux)

Takeaway: Chrome is the only browser where all approaches work. Firefox is missing both WASM pthreads and WebCodecs (as of mid-2026, WebCodecs is still behind a flag). Safari has WebCodecs but with limited codec support (no AV1, limited VP9).

This is why FlowPick recommends Chrome — see the v1.0.0 release notes.

Memory usage

Peak memory (Chrome 127, Mac M2, 1080p remux):

For 4K remux, peak memory doubles to ~500MB (FFmpeg WASM MT) — still under the browser tab's 2GB soft limit but close enough that other tabs may need to be closed.

The memory profile matters for UX. A 4K remux that crashes the browser tab on a 8GB machine is a bad experience. FlowPick's chunked processing (process 50 segments at a time, write to OPFS, free memory) keeps peak memory under 300MB even for 4K content.

Streaming download benchmarks

How fast can we download the segments themselves? This is the network-bound part.

Test: 300 segments, ~1.7MB each, total 500MB, from CloudFront CDN.

Takeaway: 6-8 concurrent connections is the sweet spot. Beyond that, CDNs start rate-limiting per-IP. FlowPick uses 6 by default.

The "effective bandwidth" is bounded by the CDN, not by the browser. Even with infinite concurrency, you can't go faster than the CDN allows.

Methodology details

Warm-up: Each test ran twice; the first run was discarded (WASM compilation, JIT warmup, etc.).

Power: Laptops plugged in, performance mode enabled. Battery mode throttles CPU ~30% on Mac and ~50% on Windows.

Other tabs: None. Background tabs compete for CPU/memory.

Cooling: All laptops on a cooling pad. Thermal throttling is real — without active cooling, sustained 4K remux drops 15-20% after 5 minutes.

FFmpeg flags: -c copy -f mp4 -movflags +faststart for remux. No filters, no transcoding.

WASM build: @ffmpeg/core 0.12.10, with CORE_THREADS=8 for MT builds. COEP/COOP headers set correctly for SharedArrayBuffer.

What the numbers mean

For 1080p content (most common): Browser is viable. FFmpeg WASM MT handles 30-min 1080p in 22-65s depending on hardware. WebCodecs is faster if you can use it. Native is 2-3x faster but requires installation.

For 4K content: Browser is viable on high-end hardware (16GB+ RAM, recent CPU). Mid-range hardware struggles. Chunked processing is mandatory.

For 8K content: Browser is not viable in 2026. Wait for memory64 WASM or use native.

For decode-heavy work (frame extraction, analysis): WebCodecs with worker pool is the clear winner. Within 2x of native on good hardware.

For broad codec support: FFmpeg WASM. WebCodecs is limited to browser-supported codecs (H.264, H.265, VP9, AV1 — with caveats per browser).

Original opinion: the browser is good enough for 90% of use cases

The "browser can't do real video work" take is outdated. For 1080p remux and decode — which covers the vast majority of real-world use — modern hardware running Chrome handles browser-side video processing within 2-3x of native. That's fast enough that the latency difference (a few extra seconds on a 30-min video) is dwarfed by the workflow difference (no install, no PATH, no FFmpeg).

The remaining 10% — 4K on mid-range hardware, 8K anywhere, exotic codecs — still needs native. That's fine. Use the right tool for the job.

FlowPick's bet: optimize for the 90% case in the browser, fall back to "use yt-dlp" advice for the 10% that doesn't fit. The FlowPick vs. yt-dlp comparison covers when to use which.

References

• FFmpeg WASM documentation — Setup and threading config
• WebCodecs browser support — Compatibility table
• Memory64 proposal — The proposal that would lift the 4GB WASM memory limit

Summary

Browser-side video processing is viable for 1080p workloads on any modern hardware, and 4K on high-end hardware. 8K is not viable until WASM gets memory64 support. FFmpeg WASM MT is the best general-purpose tool; WebCodecs with workers is faster for decode-heavy work but codec-limited.

The benchmark methodology here is reproducible — the test files are linked in the references, the FFmpeg flags are listed, the hardware is specified. If your workload differs, run your own tests with the same patterns.

For the implementation patterns behind these numbers, see the WebCodecs article and the remux article. For the legal considerations of what you're allowed to process, see the streaming download legality guide.

Related articles

• WebCodecs + Web Workers + OPFS: Practical Video Processing — The implementation patterns measured here
• Browser-Side Video Remuxing: fMP4, ISOBMFF, Why We Don't Transcode — Why remux is fast and transcode isn't
• How FlowPick Merges Hundreds of Video Segments in Your Browser — FlowPick's specific implementation
• FlowPick vs. yt-dlp — When to use the browser vs. native

Recommended reading

• HLS Deep Dive: Encryption, Multi-Track, EXT-X Tags — The HLS format being benchmarked
• DASH Deep Dive: SegmentTemplate, ContentProtection — The DASH format being benchmarked
• FlowPick v1.1.0: Smarter Media Detection — The release that added chunked processing for large files