swadhin / vidolib public
/ vidolib / docs / NO_FFMPEG_MANIFESTO.md
swadhinbiswas docs: add open-source community contributor guide, architectural specification, roadmap, manifesto, and web examples · 7/23/2026
076cd4d
40 lines · 3.3 KB
Raw Download

📜 The Native Browser Media Engine Manifesto: Why No FFmpeg WASM?

Introduction

For over a decade, web media development has suffered from an engineering anti-pattern: porting heavy desktop C/C++ media software (FFmpeg/GStreamer) directly into WebAssembly (WASM).

While FFmpeg WASM ports are impressive technical demos, using a 20MB–40MB software decoder binary inside a web browser creates severe real-world problems for end users and developers alike.

media-runtime was created to prove that modern web browsers already possess all the native hardware capabilities required to build world-class, zero-copy media players, without dragging along multi-megabyte software decoder blobs.

5 Critical Reasons to Avoid FFmpeg WASM in Production Web Apps

1. Battery Drain & Thermal Throttling

  • FFmpeg WASM: Forces the CPU to perform manual software decoding of high-resolution video streams frame-by-frame. On laptops and mobile phones, this spikes CPU usage to 80%–100%, causing thermal throttling, fan noise, and rapid battery depletion.
  • media-runtime: Delegates decoding directly to the device's dedicated GPU / hardware video decoder ASIC via the WebCodecs API (VideoDecoder) and native <video> hardware pipelines. CPU usage remains under 4%.

2. Startup Latency & Initial Load Time

  • FFmpeg WASM: Requires downloading, instantiating, and initializing a 15MB–40MB .wasm file before a single video frame can be parsed or rendered. On 3G or congested 4G connections, users wait 3 to 10 seconds before video startup.
  • media-runtime: Core runtime weighs only 3.4 KB gzipped. Media begins parsing and rendering in under 110 milliseconds.

3. Out-Of-Memory (OOM) Crashes on Mobile Devices

  • FFmpeg WASM: Allocates hundreds of megabytes of WebAssembly linear memory (emscripten_malloc). On iOS Safari and low-end Android devices, WebAssembly memory pressure frequently triggers forced tab reloads and OOM crashes.
  • media-runtime: Uses zero-copy VideoFrame references and bounded ring buffers. Total resident memory stays under 18 MB RAM.

4. Patent Pool & Royalty Exposure

  • FFmpeg WASM: Compiling software decoders for patented formats (H.264, H.265/HEVC, AC-3, DTS) into WASM binaries and distributing them to end users creates real legal exposure to patent licensing pools (MPEG-LA, Access Advance, Via Licensing).
  • media-runtime: Strictly uses hardware decoding already licensed by the operating system and device manufacturer (Apple iOS/macOS, Google Android/ChromeOS, Microsoft Windows). Software decoders are permitted only for royalty-free codecs (AV1, VP8, VP9, Opus, FLAC, Vorbis).

5. Architectural Ergonomics & Developer Experience

  • FFmpeg WASM: Exposes opaque C pointers, manual memory management (free()), complex build flags (emcc), and thread synchronization hurdles.
  • media-runtime: Pure TypeScript monorepo with 100% type safety, clean ES modules, zero-dependency plugins, and standard web streams (ReadableStream<Uint8Array>).

Join the Native Web Media Movement

If you believe the web should be fast, battery-efficient, accessible, and lightweight, help us build media-runtime! Explore open contributor tasks in ROADMAP.md and check out our CONTRIBUTING.md.