128.4 fpsmedian · direct · 16:04
11.31 MbpsAV1 1440p · median
11 msmedian RTT · AV1 session
20.2 msRG557 median decode
Representative sessions
Median and P95 are shown together when available. Very short or incomplete sessions are labelled.
| Date and path | Setup | Measured result | Honest reading |
|---|---|---|---|
| 08 Jul · AV1 direct | 2560×1440 · AMD → Chrome | 11.31 Mbps median · P95 14.74 · 60.1 fps · RTT 11/18 ms · decode 0.9 ms | Good AV1 path for this pair only; not proof for every browser. |
| 11 Aug · HEVC direct | 1920×804 · 16:04 | 6.59 Mbps median · P95 7.84 · 128.4 fps median · P95 140 · RTT 25/32 ms | Over 120 fps proven on this run; locked 144 fps not proven. |
| 11 Aug · HEVC direct 8M target | 1920×804 · 12:54 | 7.46 Mbps median · 60 fps · RTT 25/35 ms · 5 freezes / 4.539 s | Long usable run, with measured loss and freezes. |
| 28 Jul · Android RG557 | 1920×1080 · HEVC | 5.10 Mbps median · 31.5 fps · RTT 39.5/48 ms · decode 20.2 ms | This small device’s decoder and buffer are the limiting factors. |
| 12 Aug · Windows native local | H.264 then HEVC · 5 s each | 14.18 then 11.46 Mbps · 50.9 then 61.9 fps · decode P95 0.05/0.34 ms | Very short local proof; WAN and signed distribution not validated. |
| 12 Aug · HEVC direct | 1920×1080 · 26 min | 3.17 Mbps median · 59.9 fps · RTT 12/20 ms · decode 1.5/2.1 ms · 27 freezes / 6.975 s | Stable bitrate and decode, but measured freezes and discontinuous audio. |
| 11 Aug · relay / background | 92 min | 1.37 Mbps median · RTT 25.5 ms · buffer P95 478 · 471 freezes / 403.576 s | Long incident: this scenario is not acceptable quality. |
| 05 Aug · Apple TV 4K | 4K60 · tvOS · ~60 s | 49 freezes / 15.741 s · decode 11–15 ms · audio and ICE active | Host capture/encode incident; proof that resolution alone is not enough. |
How results are read
- Identify the runDate, duration, client, resolution, codec and direct or relay path stay attached to the result.
- Read the distributionMedian describes the center of a session; P95 reveals spikes hidden by a simple average.
- Separate stagesFrame rate, RTT, decode time, buffer, loss and freezes measure different things.
- Publish the caveatA short, local, audio-less or disrupted run keeps that limit explicit.
What these counters do not prove
- WebRTC RTT is not glass-to-glass latency.
- NAL-to-display or client decode does not cover the full capture, encode and physical display path.
- A frame-rate peak is not the same as a locked cadence throughout a session.
- One GPU, phone or network does not represent the whole range.
Glass-to-glass measurement still to be produced
A proper proof requires a high-frame-rate external camera filming the host action and client display together. Until that protocol is run, Lume does not publish a glass-to-glass figure.
Follow new validations
The changelog and roadmap publish fixes, experiments and remaining work.