4K AV1 in the browser, over plain HTTPS LIVE
No plugin, no WebRTC, no SFU. Just HTTPS, and the whole stream decodes in the browser via WebAssembly.
Position: lower latency than HLS/DASH (1–2 s vs 2–10 s), and far simpler on the broadcaster side than WebRTC (no signaling server, no STUN/TURN, no SFU). Built for surveillance / VMS / educational live workloads where 4K AV1 needs to land in any modern browser without infrastructure upgrades.
Where this slots in
The shortest comparison against the alternatives a live-video engineer would normally reach for:
| This demo | WebRTC | HLS Low-Latency | Legacy RTMP/HLS | |
|---|---|---|---|---|
| Wire protocol | TCP / HTTPS only | UDP + STUN/TURN | HTTPS | HTTPS |
| Server side | Static HTTPS + tiny range/range-poll endpoint | Signaling + SFU/MCU | Origin + CDN | RTMP server + transcoder + CDN |
| Glass-to-glass latency | ~1–2 s | < 0.5 s | 2–4 s | 6–30 s |
| Plugin / native? | None | None | None | None |
| 4K AV1 live, all browsers | Works (dav1d-WASM mt) | Implementation-dependent | Implementation-dependent | No (codec ID gap) |
| Firewall friendliness | Same as any HTTPS site | UDP often blocked at corp/edu | Same as any HTTPS site | Same as any HTTPS site |
The trade-off is the latency band. If you need < 500 ms and own the network, WebRTC still wins. Anywhere else — especially in environments where UDP is blocked or where standing up an SFU is overkill — this HTTPS-only path is the simpler answer for 4K AV1.
Architecture
[Encoder host (AI-01Server)] [Browser]
Capture (AV.io 4K HDMI)
|
v
slimenormenc.exe (av1_nvenc, NVENC)
|
v
live_stream.ivf (growing IVF on disk)
|
v
Node serve_live.js
- HTTP Range (206)
- HTTPS (TLS, COOP / COEP / CORP) | dav1d.js (single-thread, ~544 KB)
- /__reset_live (truncate + restart) | or dav1d_4t.js (multi-thread, ~567 KB)
| | ^ requires SAB + crossOriginIsolated
+------- HTTP Range polling ------->+ |
| v
| Presentation queue (1–2 s)
| |
| v
| 30 Hz steady render
| + NormMap block-skip (spatial gate)
| |
| v
| <canvas>Recommended viewer spec
| Viewer device | Resolution / fps | WASM mode | HTTPS required? |
|---|---|---|---|
| 2-core mobile / older PC | 720p / 30 fps | single-thread | not required |
| 4-core mobile (Intel 11th gen, etc.) | 1440p / 30 fps | single-thread | recommended (LAN) |
| 4-core mobile + multi-thread WASM | 4K / 30 fps | multi-thread (mt) | required (cross-origin isolated) |
| 8-core+ desktop | 4K / 30 fps comfortable | multi-thread (mt) | required (LAN/WAN) |
The multi-thread build uses SharedArrayBuffer, which requires cross-origin-isolated=true — HTTPS plus the COOP / COEP / CORP header set on the encoder host.
Live preview & latency check
The encoder draws a millisecond-precision wall-clock overlay into every frame it sends. Read the live picture's timestamp, then read the clock below (your local terminal time). The difference is the glass-to-glass latency, measured by eye.
Integration evaluation available on request — contact us.
What runs in the browser (technical breakdown)
- HTTP Range polling: the client fetches only the new tail of
live_stream.ivfevery few tens of ms. - IVF frame extraction: 4-byte size + 8-byte pts header per frame, fed straight to dav1d as AV1 OBUs.
- WASM decode: single-thread
dav1d.wasm(~544 KB) or pthread-multi-threaddav1d_4t.wasm(~567 KB). - Presentation queue: up to ~60 decoded frames (~2 s) buffered to absorb OS-level filesystem-flush bursts on the encoder host.
- 30 Hz render:
setInterval(33 ms)drains the queue at a steady cadence; no pulsation regardless of how the IVF arrives. - NormMap spatial gate: 16x16 block diff against the previous frame, ~99 % of blocks skipped on a static scene.