Performance
What has been measured, how, and under which conditions, and what has not been measured yet.
Every figure on this page comes from a recorded run in the SDK's repository, with its setup beside it. A figure is only as good as its conditions, so read them with it: none of these runs is glass to glass, and none was on a phone or a cellular network.
How we measure
- Path delay is the time from the moment the encoder finishes a frame to the moment the last byte of that frame reaches the viewer. It leaves out the camera, the encoder's own time, decoding and the display. Where the sender and the viewers are on different machines, the clocks' measured offset is taken off.
- Delivery is the share of the published frames each viewer received. "Minimum" is the worst viewer's share, "median" the middle one's.
- Software viewers are programs that subscribe and read every frame without decoding it, so that one machine can stand in for hundreds of viewers. Browser figures are marked as such.
- p50 and p95: half of the frames arrived within the first figure, 95 in 100 within the second.
- Runs are written down before they start (the setup, the steps and the bar to pass), and a result that misses its bar is reported as missed.
1,000 viewers on one stream
Measured twice, on 2026-10-29 and again on 2026-10-30, with the same shape:
- Setup: nine cloud VMs in one region, each with 4 vCPUs: one origin relay, four edge relays, and four machines running 250 software viewers each, one machine per edge. The stream was a 1080p60 H.264 test picture at 4 Mbit/s nominal (3.4 Mbit/s measured), sent to the origin; the edges pulled it from the origin; each step ran for 5 minutes.
- Result:
| 2026-10-29 | 2026-10-30 | |
|---|---|---|
| Viewers | 1,000 (4 edges x 250) | 1,000 (4 edges x 250) |
| Delivery | 100 % median on every viewer machine | 100 % minimum and median on every viewer machine |
| Path delay p95, per viewer machine | 32 to 65 ms | 8 to 58 ms (14 to 20 ms with the clock offset taken off) |
| Each edge's output | 913 Mbit/s | 911 Mbit/s |
| Each edge's CPU | 1.00 to 1.32 cores per Gbit/s | 1.13 to 1.31 cores per Gbit/s, 27 to 31 % busy |
Each edge was about a third busy at 250 viewers, so this is not the edge's limit for this stream. On 2026-10-30 one edge also sent an 8 Mbit/s stream (5.9 Mbit/s measured) to 250 viewers: 100 % delivery, 1.58 Gbit/s out, 0.96 cores per Gbit/s.
Sources, in the SDK repository: bench/results/2026-10-30/b7-rerun, with
every row in its results.md; the 2026-10-29 run is summarised there and
in the scale plan (docs/SCALE-ECONOMICS-PLAN.md).
Player and protocol overhead, against LL-HLS
One machine, with no network between the player and the server. These figures measure what the player and the protocol add, not a real path from a source to a viewer: a real viewer's delay adds the network, the camera, the encoder and the screen.
100 viewers on one machine, the same 1080p30 2 Mbit/s source for both paths, played in headless Chrome with software decoding, from the frame leaving the encoder to the frame drawn on the page. The LL-HLS row is a reference LL-HLS server played with hls.js, not our fallback, to show what the protocol itself costs under the same conditions.
| Path | Viewers | p50 / p95 | Frames shown | Stalls in 20 s |
|---|---|---|---|---|
| MoQ | 100 | 5.1 to 10.7 / 8.2 to 17.5 ms (6 runs) | 99.5 to 100 % | 0 |
| LL-HLS (hls.js) | 100 | 515 to 549 / 531 to 551 ms | 99.5 % | 4 to 7 |
Source: the "Baselines" table in RESULTS.md.
Joining
From a browser asking for the stream to its first picture, on one machine:
a median of 75 ms to the first picture with a 2 s keyframe interval (the
relay hands over the group it holds), and 360 ms median (548 ms the worst
of 12 joins) to the first picture at the live edge. With a 1 s keyframe
interval: 186 ms and 244 ms (584 ms the worst). Source:
the "Join time" table in RESULTS.md.
Losing a relay
On one machine, a software viewer on one of two edge relays: when its edge
was killed, 1.01 s without frames before it played from the other edge.
When the relay the publisher and the viewer were both on was killed and
came back after 1 s: 2.51 s without frames. Source:
the "SDK fan-out and robustness" table in RESULTS.md.
Not measured yet
- Glass to glass through the service (camera to screen).
- More than 1,000 viewers on one stream: 5,000 and 10,000 have not been run, and neither has the limit of one edge for a plain stream.
- Real browsers at scale. The 1,000 viewers were software viewers; the browser figures are for 1 to 100 viewers on one machine.
- Phones: any figure on a real iPhone or Android phone, and the LL-HLS fallback's delay there (Phones and Safari).
- Cellular and long-distance networks, and viewers in a region other than the source's.
- The native Windows player, which has not been run on Windows.
What each feature has been tested on is in Feature status.