StreamHelpers / SRTLA bonding

SRTLA cellular bonding for IRL streaming

A moving stream cannot rely on one speed test. Coverage changes, venue Wi-Fi gets congested and a cellular link can stall. SRTLA lets a live stream use several network paths instead of depending on a single uplink.

How SRTLA bonding works

SRTLA transports an SRT stream across multiple internet connections. The sender runs on the router; an off-site receiver reassembles the stream for delivery. StreamHelpers uses SRTLA from the BELABOX project, credited with the bundled software, and adds link management, camera controls, overlays and diagnostics around that transport.

The practical route is camera or director → Mudi 7 bonding sender → internet uplinks → SRTLA receiver → Restreamer or another configured publishing workflow → viewers. SRT and SRTLA are not interchangeable destination addresses: configure each stage with its expected protocol.

Which connections can join the bond?

The dashboard manages supported active uplinks, including router cellular, compatible connected modems, shared-phone cellular and available Wi-Fi. Nearby Android phones can contribute their own data through Companion connection sharing or Moblink over the rig's network. A phone sharing data is not necessarily a camera or director; those are separate roles.

Use per-link throughput and health to see what each connection contributes. More SIMs do not automatically mean more independent coverage. Different brands can use the same underlying carrier, and different connections can share a congested tower or Wi-Fi radio.

Bonding versus internet failover

Bonding uses multiple usable paths for the video transport. Failover changes which connection ordinary internet traffic uses when its preferred path is unavailable. Router failover helps traffic such as chat, weather and publishing controls; it is not a substitute for the SRTLA video bond.

A connection can show signal bars and still have poor upload capacity. Likewise, a Wi-Fi association does not prove internet access: captive portals and congested venue networks need separate checks.

Bandwidth and latency still matter

Bonding can improve resilience when enough capacity remains on other links. It cannot create coverage where every connection is gone or make arbitrary video bitrates reliable. Leave room for protocol overhead and retransmissions. Raising output resolution without checking the encoder, radio conditions and receiver can make a stream less stable.

SRT's latency budget allows recovery of some late or lost packets, but a larger buffer also delays the broadcast. Packets that miss their delivery deadline can still cause decoder errors or damaged frames. Test under realistic movement rather than selecting a latency setting purely for the lowest number.

The receiver and backup video

A bonded setup needs a reachable receiver, commonly a Docker container on an always-on server with a public address. Configure its ports, publishing outputs and available capacity. The router dashboard and receiver have different jobs; the router alone does not publish a reassembled SRTLA stream.

Receiver backup video is separate from bonding. When enabled and ready, it can switch to your uploaded holding clip if live video disappears or crosses your configured threshold, then return when the feed recovers. It must be tested off-air. A backup switch can interrupt delivery and is not a promise of seamless playback.

Diagnose both ends

Check camera arrival, director encoding, sender link throughput, receiver SRT loss and late drops, and delivered frame rate. A healthy upload number does not prove that viewers receive clean video. StreamHelpers brings sender and receiver health into the workflow so the failing stage can be identified rather than guessed.

Continue with the router and bonding guide, receiver setup and IRL hardware checklist.