Measured end to end, reported with the conditions.
We don't publish a number without the run behind it. Every figure below comes from a run whose raw output we keep, and each is labelled with the rig it ran on.
Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testingMeasured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing (Oct 2026). These are results from controlled lab runs on August 2026 builds. They are not production SLAs and don't guarantee performance on your network. A load test is pending (October 2026), and this page will be updated with its results.
56–57 ms median, 70 ms p95
Glass to glass is the time from light hitting the sender's camera to the frame appearing on the receiver's screen. It covers capture, encode, packetising, the network both ways through the relay, the jitter buffer, decode and display. That is everything a person on a call experiences, not just the network.
About 22 ms of the median is the network round trip to the relay. Most of the rest happens on the phones.
Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testingRig
| Devices | iPhone 15 Pro and iPhone Air |
|---|---|
| Relay | Google Cloud Compute Engine, Los Angeles (us-west2) |
| Network | Ordinary home Wi-Fi in Venice Beach, California (about 108 Mbps down, 8 Mbps up), shared with TVs and other devices streaming movies during the runs. Mean round trip to the relay: 21.8 ms |
| Media | One 720p HEVC rung from the camera, hardware encode |
| Direction | Both phones publishing and subscribing at once, 90 s, every frame delivered |
| Clocks | Both synchronised to NTP. The clock-agreement error is reported next to every reading |
* Built to scale: a Rust media plane and a Go control plane, each scaling out horizontally. Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing.
Latency by resolution, led by 4K
What is measured, and what is scheduled. How MOQOM compares →
| Resolution | Typical use | Median glass-to-glass | Status |
|---|---|---|---|
| 4K (2160p30) | Solo host, broadcast | Measuring Oct 9, 2026 | 4K rung added to the Swift SDK camera ladder (opt-in); end-to-end run scheduled |
| 1080p30 | Host / spotlight | Measuring Oct 9, 2026 | Supported (top rung of default camera ladder) |
| 720p30 | Two-person call | 56–57 ms (p95 70 ms)* | Measured: two iPhones, home Wi-Fi, relay in Los Angeles, both directions at once, 90 s, every frame delivered |
| 540p60, 600 kbps | Co-host tiles | 69 ms* | Measured, same relay |
| 360p30 | Co-host tiles in shared calls | Measuring Oct 9, 2026 | Supported (600 kbps rung) |
| Shared video calls (360p–540p per tile) | Group calls, co-host grids | Measuring Oct 9, 2026 | Closest references: 540p60 at 69 ms; 720p30 with the layout changing every 8 s at 61 ms |
Shared video calls. In a shared call, each person sends video at the size of their tile on screen (360p–540p) rather than a full frame, so each person's stream is smaller. The median for shared calls will be measured on Oct 9, 2026. Until then, the closest measured references are the 540p60 run (69 ms median) and a 720p30 run with the layout changing every 8 seconds (61 ms median).
* Built to scale: a Rust media plane and a Go control plane, each scaling out horizontally. Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing.
6,000 viewers at 5.46 Gbit/s from one 4-vCPU relay
One publisher, one track and N subscribers. A size counts as clean only if every subscriber received every object and the kernel dropped no packets. Subscriber reports and the relay's own counters are read together, so a relay that quietly gave up on some viewers can't look clean.
6,000 is the largest size we have run, not the ceiling. The relay used 3.88 of its 4 cores, and the machine's 10 Gbit/s egress cap was not reached. That works out to roughly ~1.3–1.4 Gbit/s of egress per vCPU, and the figure held across synthetic and real-video runs.
Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testingSynthetic traffic: 30 fps of 4,096-byte frames
| Subscribers | Sockets | Clean | Relay cores | Gbit/s | Kernel drops |
|---|---|---|---|---|---|
| 3,500 | 1 | yes | 2.97 | 3.12 | 0 |
| 4,000 | 1 | yes | 3.44 | 3.55 | 0 |
| 4,500 | 1 | no | 3.61 | 2.90 | 340,498 |
| 5,000 | 1 | no | 3.68 | 3.61 | 297,551 |
| 4,000 | 4 | yes | 3.50 | 3.57 | 0 |
| 4,500 | 4 | yes | 3.76 | 4.11 | 0 |
| 5,000 | 4 | yes | 3.82 | 4.59 | 0 |
| 5,500 | 4 | yes | 3.82 | 5.04 | 0 |
| 6,000 | 4 | yes | 3.88 | 5.46 | 0 |
Relay: Google Cloud n2-standard-4 (4 vCPU), us-east1-b. Subscribers: two n2-standard-8 load generators. Publisher: n2-standard-2. One zone, gVNIC, MTU 1460. The same relay binary for every run, restarted between sizes.
* Built to scale: a Rust media plane and a Go control plane, each scaling out horizontally. Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing.
54 µs to encrypt a 1080p keyframe
SFrame with AES-256-GCM, on the device, against a 33 ms frame budget. Encrypting media payloads costs a small fraction of a frame.
Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing* Built to scale: a Rust media plane and a Go control plane, each scaling out horizontally. Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing.
How we measure
- Latency is timestamped in software at capture and read at render, against a shared clock
- A run is marked untrustworthy if the clock error exceeds the median it reports
- Phone-side numbers are checked against the relay's counters. A smooth run that only looked smooth because frames were dropped doesn't count
- Fan-out uses MOQOM's own load generator, which can drive any relay that speaks draft-19
- The relay restarts between sizes, so each size starts from cold state
A physical photodiode rig is planned, and its numbers are the ones we will quote in a contract. Cellular, cross-city, Web, Android and desktop numbers will be published with each release.
We make no latency comparison with other MoQ stacks yet, because none publishes a glass-to-glass figure measured comparably. The fair test is the same two phones through each relay, and it is on our list.
Full methodology on moqom.dev ↗Test coverage
- Swift SDK
- ~864 tests
- Media engine
- ~944 tests
Plus coverage-guided fuzzing of every decoder on every change, and cross-language interop: a Swift publisher and subscriber through the Rust relay, and both backend SDKs against the real control plane.