📊 Measured latency

Encoder-to-glass: the burned-in publisher clock, OCR'd out of each player, minus the local clock — measured on the publisher machine, so both clocks are one clock. (The clock is burned at encode, so capture-chain latency is excluded — identically for both legs.) ← receipts · back to the live streams

How to read this page: each run is one invocation of scripts/measure-latency.sh on the publisher machine, reviewed and committed by a human. The tiles summarize the latest run only; the chart and table show every committed run; the map shows the single run named in its title.

Caveats

Both streams come from one ffmpeg encode (same bitrate, GOP, encoder), so the comparison is apples to apples. Measurements run on the publisher machine: the burned-in clock and the local clock are the same clock, so there is no NTP skew. Each sample is timestamped at the midpoint of its screenshot; shot_spread_ms records the window, so the residual timing uncertainty is ±spread/2. hlsjs-api rows are the latency hls.js itself reports, not encoder-to-glass, shown for cross-checking only. Since Task 6, the harness records each run's HLS tuning receipt (client preset, part target, sync target) straight off window.__hls — shown as a hover tooltip on hls table rows and appended to the HLS tile's subtitle; runs from before then have no tuning receipt and render as before. The viewer page's Mode A "typical" and Mode B "ragged" presets are the two tuning stories this compares.