Same analog signal, same encoder, two protocols. The clock burned into the picture is the publisher's (via ffmpeg); the clock under each player is the browser's.
publisher timecodes, as received latency
MoQ—
HLS—
latency vs this device's clock, ± clock sync · Δ is sync-independent
Media over QUIC
--:--:--.---
Low-Latency HLS
--:--:--.---
Known caveats — why this benchmark is also bs
Buffer asymmetry. MoQ runs a 150 ms jitter buffer; HLS "typical"
targets 1.5 s and "ragged" 300 ms — and ~300 ms (3× the origin's 100 ms
parts) is LL-HLS's floor, while MoQ's floor is zero. The matched-buffer comparison is
?moqlatency=300&hlspreset=ragged.
The 150 ms is a handicap, not a gift.<moq-watch>
defaults to real-time (zero buffer); reload with
?moqlatency=real-time to watch MoQ drop lower still — and stutter on any
jitter. Latency is a buffer-policy dial on both protocols; what differs is where each
protocol's floor sits.
Chain vs chain, not protocol vs protocol. The "HLS" number includes
FLV/RTMP ingest + MediaMTX remux + Caddy TLS; the "MoQ" number includes moq-cli
repackaging + relay fanout. Each is a representative single-hop deployment (no CDN on
either leg) — not isolated egress-protocol overhead.
Encoder-to-glass, not glass-to-glass. The clock is burned at encode,
so LaserDisc→capture-card latency is invisible — identically for both legs.
The measured numbers are Chrome numbers. The harness drives Chrome:
WebTransport + hls.js/MSE. Safari would be WSS fallback + native HLS — different
pipelines entirely.
Harness limits. Samples are midpoint-timestamped screenshots
(±shot_spread_ms/2); publisher, browser, and OCR share one machine; ~12
samples per run; OCR misreads are filtered only by plausibility; runs are human-curated
and the results tiles headline the latest run.
Video only. Audio latency, A/V sync, startup time, and rebuffering are
unmeasured.
Local vs WAN. The all-local stack isolates protocol architecture but
hides QUIC's loss-recovery advantages; WAN runs add network + geography. Compare both on
results.