On a live-cam platform, latency is not a comfort metric — it is the product. A tip that appears three seconds after the performer reacts to it breaks the illusion of presence, and viewers describe that as “broken” even when video and audio are perfectly smooth. The fix is a latency budget owned end to end, not a single low-latency setting.
The mechanism: interaction desync
The felt problem is the gap between the viewer’s view and the performer’s world. That gap is the sum of capture, encode, contribution, distribution, player buffering, decode, and display. Add the return path — viewer action, payment, chat, performer display — and you get the round-trip that determines whether interaction feels live. A stream can have excellent video quality and still feel broken because the presentation delay exceeds the interaction tolerance, usually a few hundred milliseconds for reactions and haptics.
Topology: SFU versus CDN
| Topology | Latency | Cost model | Fits |
|---|---|---|---|
| Direct peer / SFU | Very low (sub-second) | Scales with concurrent sessions and egress per peer | 1:1 private shows, small rooms, interactive |
| CDN distribution | Seconds | Scales with viewers, cheap per viewer | Large public rooms, one-to-many |
| Hybrid | Low for interactors, seconds for the crowd | SFU for a subset, CDN for the mass | Freemium rooms with a paying core |
The economic trap is running every viewer through an SFU. SFU egress scales with viewers, not streams, so a popular room becomes linear cost with no cache to absorb it. A CDN scales with streams and is nearly flat per viewer, but adds seconds of latency. The right answer is usually hybrid: low-latency path for the paying, interacting core; CDN path for the passive audience. See Live-cam CDN.
WHIP constraints
WebRTC-HTTP ingestion (WHIP, RFC 9725) gives you a simple HTTP-based contribution handshake and low latency, but it is a contribution protocol, not a distribution one. It constrains you to the codecs and pacing the encoder negotiates, it does not solve scale-out to many viewers, and it assumes a WebRTC-capable distribution path downstream. WHIP removes contribution complexity; it does not remove the SFU-versus-CDN decision.
TURN is not free
When direct paths fail — symmetric NAT, restrictive corporate networks, mobile carriers — WebRTC falls back to a relay (TURN). Every relayed session is a server egress you pay for, and a meaningful fraction of real-world sessions relay. That cost is invisible in a lab and dominant at scale. Budget for it explicitly: measure relay ratio, keep relays close to viewers, and prefer topologies that terminate near the viewer rather than hairpinning traffic across regions.
LL-HLS and LL-DASH tradeoffs
Low-latency segment-based delivery (LL-HLS, LL-DASH, described in RFC 9317) gets you to roughly two to five seconds without WebRTC. It reuses the CDN path, caches normally, and scales cheaply — at the cost of partial segments, more frequent manifest updates, and more origin/edge chatter. It is the pragmatic choice for large rooms where a few seconds is acceptable, and a poor choice for 1:1 interaction.
Presentation-delay modelling
Measure the actual end-to-end delay, not the protocol’s theoretical minimum. Instrument each stage:
- Capture-to-ingest: encoder buffering and keyframe interval.
- Ingest-to-edge: contribution transport and any transcode hop.
- Edge-to-player: segment duration, player target buffer, and catch-up policy.
- Return path: chat, payment, and performer-display latency.
Then set a target for interaction and prove the sum against it. A player that buffers to smooth jitter will silently add the very latency you are trying to remove; configure it to a target delay and accept a small rebuffer risk, and let the CDN absorb variance rather than the buffer.
What good looks like
- Interaction round-trip measured and budgeted, per room type.
- SFU for the interacting core, CDN for the passive crowd.
- Relay ratio measured, and relay egress costed.
- LL-HLS/LL-DASH where seconds are acceptable, WebRTC where they are not.
How to prove it
Run one room type through a low-latency path and compare interaction round-trip, relay ratio, rebuffer ratio, and cost per viewer against the incumbent. This is a controlled test on a slice of traffic, and it tells you which topology pays for itself.
Related reading
- Video CDN overview for segment and range behaviour.
- Live-cam site for the product context.
- Why tube-site video buffers for the VOD-side analogue.