HTTP-FLV & MPEG-TS Playback: Low-Latency Veterans

Open devtools on a Chinese live platform and you will likely see .flv requests; surveillance and broadcast gear mostly emit MPEG-TS. These “old formats” thrive in low-latency live — browsers don’t support them natively, but MSE demuxing (the flv.js/mpegts.js lineage) has served reliably for years. ZWPlayer ships the pipeline built-in: paste a .flv/.ts URL and it plays.

Format Background: Why Live Can’t Quit Them

FLV: the Flash-era container — simple structure, tiny headers, stream-friendly. Flash died, but HTTP-FLV (FLV over chunked HTTP) became the de facto live pull standard — 2–5 second latency, an order below HLS, far simpler than WebRTC;
MPEG-TS: broadcast-grade transport, resilient to loss, built for endless streaming. The native output of surveillance cameras (see the RTSP gateway), satellite feeds, and recording files.

Shared trait: <video> doesn’t recognize either — JavaScript demuxes them into MSE (Media Source Extensions). ZWPlayer runs that pipeline internally.

Playback: Zero Config

// HTTP-FLV live
new ZWPlayer({
  playerElm: 'player',
  url: 'https://live.example.com/live/stream01.flv',
  isLive: true,   // live state: Live badge on the control bar, chase enabled
});

// TS live / TS file
new ZWPlayer({
  playerElm: 'player',
  url: 'https://example.com/live/program.ts',
});

FLV playback Figure 1: an HTTP-FLV stream playing in the browser — the control bar shows live state

FLV film Figure 2: on-demand content in an FLV container plays just as directly

Routing rule: .flv URLs go to the FLV/mpegts engine, .ts to the MPEG-TS engine — no stream-type declaration needed.

Two Engines: mpegts.js and flv.js

ZWPlayer ships both generations:

mpegts.js (flv.js’s successor, community-maintained): the default — FLV and TS, H.265/HEVC support (with a capable browser);
flv.js (the classic): for legacy scenarios; useOldFlv: true opts back in.

The engine is invisible to viewers — paste the URL, the player picks.

H.265 FLV: The Surveillance Case

Cameras increasingly emit H.265 (half the bitrate at equal quality). The old blocker was browser H.265; today the path is Safari natively and hardware-decoding Edge/Chrome on recent machines — h265_aac FLV/TS streams auto-select direct decode or a friendly notice in ZWPlayer. Paired with the RTSP gateway’s rtsp_bypass: true, H.265 cameras reach the browser with zero transcoding.

Latency and Selection: Three Live Protocols

	HTTP-FLV/TS	HLS	WebRTC
Typical latency	2–5 s	5–30 s	Sub-second
Ops complexity	Low	Minimal (static + CDN)	High
Massive distribution	Moderate (CDN features needed)	Excellent	Costly
Fits	Mid/low-latency live, surveillance	Big-audience VOD + slow TV	Co-streaming, auction-grade real time

The common combo: FLV main (low latency) + HLS fallback (resilience and CDN scale), with WebRTC layered on for key events.

FAQ

FLV live drops after a few minutes? Check server GOP caching and HTTP chunk timeouts; long-lived FLV connections often need buffering disabled at the reverse proxy (X-Accel-Buffering: no et al).

Can TS files seek? On-demand TS (complete files) — yes; live TS is a stream, it follows the edge.

Do FLV feeds get VR/watermarks? Yes. FLV/TS, HLS, and MP4 are equals at the capability layer — VR panorama, anti-record watermarks, and multiple audio tracks all apply.