Optimizing Live Stream Latency for Interactive Content

Trying to minimize latency for a live, interactive game show segment on a recent broadcast was a real push. Our primary goal was near real-time audience participation, so even a few seconds of delay felt like an eternity. We initially tried a standard RTMP ingest followed by HLS distribution through a major CDN, which gave us around 8-12 seconds of end-to-end latency, better than some, but still too high for responsive trivia.

What worked surprisingly well was switching to WebRTC for the ingest path from the studio to our custom backend and then using a fragmented MP4 (fMP4) chunking strategy with very small segment durations (1-2 seconds) for the HLS distribution. We even experimented with Apple's Low-Latency HLS (LL-HLS) which, while promising, still had some compatibility quirks across all target devices that made it less reliable than our fMP4 approach for broad reach. The biggest win was moving computation for audience responses closer to the ingest point, almost pre-processing before the full stream hit distribution, cutting down server-side overhead. This combination brought us consistently under 3 seconds, making the interactive elements feel genuinely live.

What didn't work was relying solely on CDN optimization features; while helpful for scale, they often introduce their own buffering and latency. Also, trying to force a single, ultra-low latency format like WebRTC all the way to every end-user proved unsustainable due to browser and device compatibility variations. We found a hybrid approach was key. I'm curious, for those pushing the boundaries of live interactivity, what are your experiences with sub-second latency solutions that scale reliably across diverse user environments without massive infrastructure costs?