When a live match stutters, everyone blames ‘buffering’. The real culprit is usually not bandwidth at all — it’s packet timing. Here’s why 50 milliseconds of jitter matters more than a fat pipe.
Every operator has lived through it: the second innings starts, concurrency spikes, and suddenly the picture stutters for thousands of homes at once. The instinct is to add bandwidth. Often that fixes nothing, because the problem was never throughput — it was jitter, the variation in when packets arrive.
A jitter buffer smooths out uneven packet arrival by holding a little bit of stream before it plays. The catch: a bigger buffer means more latency. Live TV — especially sport, where a neighbour’s cheer must not precede your screen — runs the buffer small. A small buffer tolerates less jitter. So the very thing that makes live feel live is what makes it fragile.
50 ms of jitter is nothing to a movie download and everything to a live match. The tighter you run latency, the less timing variance you can absorb — which is exactly why live sport is the hardest thing an IPTV platform delivers.
Two properties stack up. First, synchrony: everyone watches the same live moment, so a network hiccup doesn’t average out across time — it hits the whole audience together. Second, concurrency spikes: a wicket or an innings break drives a wall of simultaneous joins and channel changes that stress every hop, from origin to the last-mile switch.
On UDP/multicast (the STB path), there is no retransmission by default — a lost packet is a visible artifact unless you add recovery. That’s what FEC (forward error correction) and RET (RTP retransmission) are for. On HTTP/DASH (the app path), TCP hides loss by resending — but at the cost of latency, so low-latency DASH tightens buffers and brings jitter sensitivity right back.
| Path | Loss behaviour | Recovery |
|---|---|---|
| Multicast / RTP (STB) | Loss = visible artifact | FEC + RET (retransmission) |
| HTTP / DASH (apps) | TCP resends, adds latency | Low-latency DASH + tight edge |
‘Buffering %’ is a lagging, useless metric on its own. What actually predicts a bad match are rebuffer events, join time, and packet-timing variance per hop. If you only watch bandwidth graphs, you will miss the jitter that’s about to ruin the final over.
Three things: FEC/RET on the multicast path so loss is repaired before it’s seen; carefully tuned origin timeouts (an HLS-origin refresh must not be mistaken for a stream drop); and an edge that sits close to the viewer so there are fewer hops for jitter to accumulate across. Live is delivered from the nearest PoP, not hair-pinned across the country.
Talk to a team that runs a live operator, not just sells software.
