SRT and RIST: What IP Contribution Protocols Need From Your Connection

The speed test at the venue returns 40 Mbps up. The feed is set to 12 Mbps. The engineer has four times the bandwidth the encoder asks for, and the picture still breaks up in bursts that nobody can pin to anything.

That gap between a healthy speed test and an unhealthy feed is where most IP contribution problems live. A speed test measures how much data a link can move over a few seconds. A contribution protocol cares about when each packet arrives, whether a lost one can be replaced before it is needed, and how much the timing wanders while that is happening. Those are different questions, and bandwidth answers only the first.

This article covers what SRT and RIST actually do, the latency budget that governs both, why jitter is more expensive than packet loss, and what to specify in a connection so the protocol has something to work with.

Why the two obvious approaches both fail

TCP recovers everything. It detects a missing packet, retransmits it and refuses to deliver anything behind it until the gap is filled. For a file that behaviour is correct, because a file is wrong if any part is missing. For live video it produces the failure everyone recognises: the stream stalls while the protocol insists on repairing something that stopped mattering two seconds ago. TCP also backs off aggressively when it sees loss, so a congested link makes it slow down exactly when the production needs it to keep going.

Plain UDP has the opposite problem. It sends and forgets, which suits live timing and offers no recovery at all. On a clean managed circuit that is workable. On a cellular link at a full venue, or on a public internet path with a congested hop somewhere in the middle, packets go missing routinely and the picture carries every one of them.

SRT and RIST occupy the space between. Both run over UDP and add selective retransmission on top: the receiver notices a specific missing packet, asks for that one again, and the sender resends it while everything else keeps flowing. Nothing waits in line behind the repair. The recovery is bounded by a deadline, which is the design decision that makes the whole thing work.

The latency budget is the design

A retransmitted packet is only useful if it arrives before the moment it has to be played out. That gives the protocol a fixed window in which to detect a loss, request a replacement and receive it, and that window is configured as a latency buffer at setup.

The size of the window is set against round trip time, since detection and repair each cost one traverse of the path. A buffer of roughly three to four times RTT is the common working figure, and it rises when loss is heavier because a request may itself go missing and need repeating. SRT ships with a modest default that suits short, clean paths and is frequently too small for the paths productions actually use.

This produces the trade that defines IP contribution. A larger buffer recovers more and puts the picture further behind live. A smaller buffer sits closer to live and discards repairs that arrive too late, which appear as the same artefacts the protocol was installed to prevent. There is no setting that is correct in general, only one that is correct for a given path, a given loss profile and a given tolerance for delay.

The practical consequence is that RTT belongs in the connection specification. A path with 30 ms round trip and one with 300 ms need very different buffers to achieve the same protection, and the second one cannot be configured into behaving like the first.

Jitter costs more than packet loss

Loss is the problem engineers plan for. Jitter is the one that consumes the plan.

A stable path with two percent loss is straightforward: the buffer is sized against a known RTT and the repairs land inside the window. A path whose round trip swings between 40 ms and 250 ms is harder even at lower loss, because the buffer has to be sized against the worst case rather than the average. Every millisecond of variation is either budget spent in advance or a repair that arrives too late.

Cellular paths jitter for structural reasons: scheduling on the radio, contention when the cell fills, handovers between cells, and queueing at congested points along the way. That is why a connection sold on peak throughput can behave worse in contribution than a slower link with disciplined timing, and why measuring a path means watching RTT variation over time rather than reading a single figure.

It is also why the same encoder produces different results at the same venue at different hours. The bandwidth may hold up as the crowd arrives while the timing does not.

Retransmission is not free bandwidth

Every repair is additional traffic on a link that is already carrying the feed, and repairs cluster precisely when the path is under stress. A link sized exactly to the video bitrate has no room to recover, so the first burst of loss produces repairs that cannot be sent, which produces more loss.

Around a quarter more capacity than the encoded bitrate is the conventional allowance, and difficult paths justify more. That headroom has to exist in the upload direction, which is where contribution runs and where consumer-oriented connections are weakest by design. The distinction between symmetric and asymmetric upload matters more here than in almost any other application.

The arithmetic is worth doing explicitly before the event: encoded bitrate, plus retransmission headroom, plus anything else sharing the link, against sustained rather than peak uplink at the worst hour of the day.

SRT and RIST compared

Both solve the same problem and arrived by different routes. SRT came out of a vendor implementation and spread quickly through an industry alliance, which gave it very broad support in encoders, decoders, cloud services and software. RIST was developed through a standards body process with interoperability between manufacturers as the explicit goal, and it is structured in profiles so a deployment can take only the complexity it needs.

For most productions the choice is settled by what the receiving end supports rather than by protocol merit. Both are sound. Neither compensates for a connection that cannot hold sustained uplink with stable timing.

Where these sit relative to bonded cellular

This distinction causes regular confusion, and it is worth stating plainly.

Bonded cellular encoders generally use their own proprietary transport across the modems, because aggregating several paths with different and constantly changing characteristics is a harder problem than protecting one path, and each manufacturer solved it their own way. SRT and RIST protect a single IP path. They are the transport for a link that already exists, whether that is a venue circuit, a fixed line at a facility, a satellite service delivering IP, or a single cellular connection. Which of those bearers a production runs on is a separate decision, set out where bonded cellular and satellite are compared.

In practice the two layers combine. A bonded encoder aggregates its modems with proprietary transport and outputs SRT to the receiving end, so the open protocol carries the last part of the chain into a decoder or cloud service. What the bonding is doing across the modems is a separate mechanism, covered in the batch 1 article on multiple carrier SIMs in one encoder.

The reason it matters commercially: choosing SRT or RIST does not decide the connectivity, and specifying the connectivity does not decide the protocol. They are separate decisions that both have to be right.

Multi-path, and repairing what retransmission cannot

Retransmission fixes packets. It cannot fix an outage, because a path that has stopped cannot deliver a repair for itself.

That gap is closed by sending the same stream over two independent paths and reconstructing at the receiver, taking whichever copy of each packet arrives first and discarding the duplicate. The technique is long established in professional video, and RIST supports it within the specification while SRT deployments generally handle it at a layer above. The result is protection against a whole path disappearing, provided the two paths are genuinely independent.

That proviso carries the weight. Two paths through the same operator, the same mast or the same backhaul route share a failure and duplicate the outage rather than covering it. The reasoning behind independent paths at a live event is set out in the article on redundancy and backup connectivity. Across a full season of sports broadcasting connectivity, verifying that independence at every new ground is the recurring work.

What to specify in the connection

A broadcast connectivity specification for contribution rests on five properties, and bandwidth is one of them rather than the headline.

Sustained uplink at the worst hour, with retransmission headroom above the encoded bitrate. Round trip time, since it sets the latency budget the protocol has to work inside. RTT variation over time, measured rather than assumed, because jitter is what actually consumes the budget. Loss characteristics, and specifically whether loss arrives in bursts, since a burst can exceed what a buffer sized for steady low loss can absorb. And path independence where a second path exists, verified down to the operator and the site rather than taken on trust.

On cellular, the mechanism that improves most of these at once is network diversity. Weconnect provides non-steered access across 700+ carrier partnerships in 195+ countries, so an encoder attaches to whichever networks are performing at that location rather than a set fixed in advance. A path chosen for current conditions delivers better timing than a path chosen months earlier in a procurement round, and timing is what the protocol spends its budget on.

Frequently Asked Questions

What is SRT and how does it work?

SRT is an open protocol for carrying live video over unmanaged IP networks. It runs over UDP and adds selective retransmission: the receiver identifies a specific missing packet and requests it again, and the sender resends it while the rest of the stream keeps flowing. A configured latency buffer sets the deadline, so repairs that arrive too late are discarded rather than stalling the stream the way TCP would.

What is the difference between SRT and RIST?

Both recover lost packets by selective retransmission against a latency buffer, and they differ in origin and structure. SRT came from a vendor implementation opened through an industry alliance and has very broad support across hardware, software and cloud services. RIST was specified through a standards body for cross-vendor interoperability and is arranged in profiles, with seamless multi-link protection included in the specification. In most deployments the receiving end decides which is used.

What latency should SRT be set to?

The buffer is sized against the round trip time of the path, with roughly three to four times RTT as a common working figure and more where loss is heavy or bursty. The default shipped in most implementations suits short, clean paths and is often too small for real contribution routes. A larger buffer recovers more and sits further behind live, so the correct value is a property of the specific path rather than a universal setting.

How much bandwidth do SRT and RIST need?

More than the encoded bitrate, because retransmissions are extra traffic and they cluster when the path is already struggling. Around a quarter above the video bitrate is the conventional allowance, with more on difficult paths, and it has to be available in the upload direction sustained at the worst hour rather than as a peak figure. A link sized exactly to the bitrate has no capacity left to repair itself.

Do SRT and RIST replace bonded cellular?

No, they operate at a different layer. Bonded encoders use proprietary transport to aggregate several modems into one link, while SRT and RIST protect a single IP path. The two are routinely combined, with a bonded encoder aggregating its modems and outputting SRT to the receiving end. Choosing a protocol does not decide the connectivity, and specifying the connectivity does not decide the protocol.

Next steps

Weconnect provides the connectivity these protocols run on: non-steered multi-network SIMs across 700+ carrier partnerships in 195+ countries, upload-focused performance with headroom for retransmission, consumption-based data that follows the fixture list, and every SIM visible from one platform. Tell us what your encoders output, where the productions are and which venues have caused problems, and we will map coverage per location and design the connectivity around it. Challenge us with your connectivity requirements. Direct response within 4 business hours.