Every producer has lived this moment: the stream has plenty of bandwidth — the
meter says 40 Mbps up, the encoder asks for 10 — and the picture still stutters.
The guest freezes mid-sentence. Chat notices before you do.
Here’s the uncomfortable truth: most live-stream glitches aren’t bandwidth
problems. They’re variance problems. And you can’t fix variance by buying a
bigger pipe.
The three ways a live stream dies
1. The outage. A carrier’s cell site drops, a fiber gets cut, a satellite
terminal reboots. On a single connection, your encoder’s session dies with it.
Even with an auto-reconnecting protocol, you’re dark for 10–60 seconds — an
eternity on air.
2. The brownout. Nothing “fails,” but the path quietly degrades: congestion
at halftime, rain fade, an overloaded hotel circuit. Throughput sags below your
encode rate for eight seconds. Your buffer drains. Frames drop.
3. Jitter. Packets arrive, but erratically — 20 ms apart, then 400, then 15.
Real-time protocols like SRT can absorb some of this with latency buffers, but
every millisecond of buffer you add is delay you feel in two-ways and IFB.
A single connection — any single connection — is exposed to all three. That’s the
actual reason “the internet” got banned from serious broadcast for so long.
Hot failover: surviving the outage
Bonding changes the failure model. With SpeedFusion
running across, say, four 5G carriers and a Starlink terminal, your stream isn’t
on a connection that can fail — it’s spread across five, packet by packet, inside
a single tunnel. When one path dies, the tunnel doesn’t. Packets are simply no
longer scheduled onto the dead path. There is no session to re-establish, so
failover cost is measured in milliseconds of packet re-steering, not tens of
seconds of reconnecting. The encoder never knows. This is what “hot” failover
means, and it’s the difference between an incident and a log entry.
WAN smoothing: killing the brownout and the jitter
Hot failover handles death; WAN smoothing handles sickness. Enable it on your
contribution stream and SpeedFusion duplicates critical packets across two or
more paths simultaneously. Whichever copy arrives first wins; the loser is
discarded. The effect on the stream is dramatic:
- A path browns out → the duplicate on a healthy path already arrived. Zero loss.
- One path jitters → the steadier path sets the pace. The delivered stream’s
timing looks like the best path, not the average.
Yes, duplication spends bandwidth — that’s the trade. A 10 Mbps program feed
smoothed across two paths costs 20 Mbps of aggregate uplink. On a bonded kit
pushing 120–300 Mbps (an HD4 MBX
plus Starlink), that’s a trade you make without thinking. Spend bandwidth, which
is now cheap; buy certainty, which was never for sale before.
The configuration that works
The pattern we deploy for production customers is per-application steering:
- Program/contribution stream: WAN smoothing on, duplicated across the two
healthiest paths, priority queue. - Comms and tally: low-bandwidth, latency-sensitive — smoothed as well.
- File transfer and crew Wi-Fi: plain bonding, no duplication — let it soak
up the leftover capacity.
One box, one policy, and the glitch reel is over.
Want us to build that policy for your kit? Talk to West Networks
or start with the hardware: shop the solution.
(~730 words)
Leave a Reply