Why flv.js Is the Future of Browser Live Streaming (No Flash Needed)

With major browsers disabling Flash by default, exploring flv.js for live streaming is crucial because traditional Flash‑based solutions require user permission and deliver poor user experience.

Before introducing flv.js, common live streaming protocols are reviewed along with latency and performance test results.

Common Live Streaming Protocols

RTMP : built on TCP, relies on Flash in browsers.

HTTP‑FLV : uses HTTP for streaming FLV, requires browser support for FLV playback.

WebSocket‑FLV : transports FLV over WebSocket, which itself is established over HTTP.

HLS : Apple’s HTTP Live Streaming, based on HTTP; playable directly in HTML5.

RTP : built on UDP, ~1 s latency, not supported by browsers.

Latency and Performance Comparison (reference data)

RTMP (Flash): latency 1 s, memory 430 MB, CPU 11 %.

HTTP‑FLV (Video): latency 1 s, memory 310 MB, CPU 4.4 %.

HLS (Video): latency 20 s, memory 205 MB, CPU 3 %.

Among supported browser protocols, latency ranking is RTMP = HTTP‑FLV = WebSocket‑FLV < HLS , while performance ranking is RTMP > HTTP‑FLV = WebSocket‑FLV > HLS , meaning lower latency often comes with higher resource usage.

Therefore, using HTTP‑FLV in browsers offers a good balance: better performance than RTMP + Flash and comparable or lower latency.

flv.js Overview

flv.js is an open‑source project from Bilibili that parses FLV files and feeds the decoded audio/video data to the native HTML5 Video element, enabling FLV playback without Flash.

Advantages of flv.js

Hardware‑accelerated video rendering via the native Video tag, supporting high‑definition playback.

Supports both on‑demand (recorded) and live streaming.

Eliminates the need for Flash.

Limitations of flv.js

Video codec must be H.264; audio codec must be AAC or MP3. IE11 and Edge do not support MP3, so H.264+AAC is recommended.

On‑demand playback depends on the native HTML5 Video element and the Media Source Extensions (MSE) API.

Live streaming requires either HTTP‑FLV or WebSocket to transport FLV data. HTTP‑FLV needs a streaming‑capable fetch/stream implementation.

The minified script flv.min.js is 164 KB (≈35.5 KB gzipped), similar to a Flash player.

Because it relies on MSE, browsers on iOS and Android ≤ 4.4.4 do not support flv.js, limiting mobile usage.

Browser Feature Compatibility

HTML5 Video

Media Source Extensions

WebSocket

HTTP‑FLV (fetch or stream)

How flv.js Works

flv.js fetches FLV‑encapsulated audio/video data, decodes it with JavaScript, and feeds the raw streams to the native Video element via the MSE API (HTML5 natively supports only MP4/WebM, not FLV).

The extra conversion step is necessary because most live streaming services still deliver media in FLV containers.

Compatibility Strategies

PC

Prefer HTTP‑FLV for low latency and good performance (1080p smooth).

If flv.js is unavailable, fall back to Flash + RTMP (widely compatible but slower).

As a last resort, use HLS (only Safari on PC supports it).

Mobile

Prefer HTTP‑FLV if the device supports flv.js.

If not, fall back to HLS (high latency).

If HLS is also unsupported, live streaming is not possible because mobile browsers do not support Flash.

Practical flv.js Implementation

Below is a guide to building a complete live streaming system.

Set Up Audio/Video Service

Use the Go‑based livego server, which runs on any OS. Steps:

Download the appropriate livego binary for your platform.

Extract and run livego. It starts an RTMP service on port 1935 for publishing and an HTTP‑FLV service on port 7001 for playback.

Create the Playback Page

In a React project, install the reflv component and add the following code:

npm i reflv

After loading the page, you won’t see a stream until a broadcaster pushes one.

Push Stream with OBS

Configure OBS to publish to the RTMP endpoint (e.g., rtmp://your_server/live/stream_key).

Or Push with FFmpeg

Run the following command:

ffmpeg -f avfoundation -i "0" -vcodec h264 -acodec aac -f flv rtmp://localhost/live/test

flv.js Latency Optimization

The default setup yields about 3 seconds of latency; with optimizations it can reach 1 second. Understanding the streaming pipeline helps identify optimization points:

Shorten the GOP (group of pictures) length on the broadcaster side to reduce buffering, at the cost of compression efficiency.

Disable I‑frame caching on the media server to lower latency, which may increase initial playback delay.

Reduce server‑side buffering, trading off processing throughput.

Reduce client‑side flv.js buffering, which may affect decoding performance.

Enable flv.js Worker (multi‑threaded parsing) to speed up decoding. The configuration code is illustrated below.