Introduction to WebAssembly and Its Application in Live Streaming Transcoding

WebAssembly (Wasm) has become a hot technology in recent years, offering a new turning point for JavaScript performance. Since its inception, JavaScript suffered from performance limitations, but the introduction of JIT compilers in browsers around 2008 improved speed by more than tenfold, enabling JavaScript to run on the server (Node.js) and desktop (Electron). However, the idea of compiling JavaScript ahead‑of‑time into binary code led to the emergence of WebAssembly.

Before Wasm, JavaScript was the only language that could run in browsers. WebAssembly allows code written in C, C++, Rust, Go, Java, C# and other languages to be compiled into .wasm modules, which are executed in a dedicated virtual machine inside the browser. Because the modules are binary, they run much faster than interpreted JavaScript, making Wasm attractive to front‑end developers as a next‑generation technology.

In the context of iQIYI live streaming, the platform originally used three approaches to play FLV streams: Flash plugins (now deprecated), client‑side FLV decoding with Canvas/audio, and converting FLV to MP4 on the client before handing it to the native video element. The third method is the most widely used, but JavaScript‑based conversion suffers from low performance.

To improve this, iQIYI introduced WebAssembly for the FLV‑to‑MP4 transcoding pipeline. The workflow consists of the following steps:

Write the transcoding logic in C. Define the functions that will be called from JavaScript and mark them with EM_PORT_API so they become exported in the Wasm module.

Compile with emcc. Install the Emscripten SDK, then run emcc main.c -s TOTAL_MEMORY=268435456 -g -o flvToMp4.js . This produces flvToMp4.js (the JavaScript glue) and flvToMp4.wasm (the binary code).

Load and instantiate the Wasm module. The generated JavaScript automatically fetches the .wasm file, calls WebAssembly.instantiate() , and provides retry logic on failure.

Integrate with a Web Worker. Because transcoding is CPU‑intensive, the Wasm module runs inside a worker to keep the UI thread responsive. The worker forwards progress events and buffer addresses to the main thread via the previously defined interfaces.

The complete transcoding pipeline is:

JavaScript receives the live FLV stream and stores it in an FLV buffer.

JavaScript notifies the Wasm module of the buffer’s start address and current progress.

The Wasm module reads data from the buffer, performs the conversion, and writes MP4 fragments into an MP4 buffer.

The Wasm module reports progress back to JavaScript.

JavaScript hands the MP4 buffer to the native video element for playback.

Performance tests conducted by iQIYI show measurable gains:

Average transmission rate increased from ~35 KB/s (JS only) to ~46 KB/s (Wasm), indicating faster transcoding.

CPU usage dropped from ~7 % to ~5 % during stable playback, roughly a 10‑20 % improvement.

Beyond transcoding, iQIYI envisions further Wasm applications such as porting C++ image‑processing projects to the web, protecting proprietary algorithms through binary obfuscation, and enabling H.265 support by converting streams to H.264 on‑the‑fly.

Overall, WebAssembly provides a practical way to boost performance-critical front‑end tasks, and its adoption is expected to grow across many web‑based services.