SRT Packet Loss in Live Video Contribution

How it works

SRT operates at the transport layer over UDP, preserving the low end-to-end latency characteristics of UDP while adding mechanisms to detect, request, and retransmit missing packets. It also smooths arrival jitter through a configurable receive buffer before handing media to decoders. The protocol’s effectiveness against packet loss depends on the interplay of several subsystems described below.

Packet-loss detection and recovery (ARQ / NAK-driven retransmit)

SRT assigns monotonically increasing sequence numbers to every packet. The receiving endpoint continuously monitors these sequence numbers and detects gaps as soon as an out-of-order or missing packet is identified. Upon detecting a gap, the receiver immediately issues a Negative Acknowledgement (NAK) specifying the missing packet sequence number(s).

On receipt of a NAK, the sender re-sends the requested packet(s). This selective retransmission — known as Automatic Repeat reQuest (ARQ) — continues until either the missing packets are recovered or the receive window (latency buffer) expires. Because only missing packets are retransmitted rather than entire segments, ARQ is bandwidth-efficient under moderate loss conditions.

The critical constraint is temporal: successful recovery requires that the round-trip time (RTT) plus retransmit processing time fits inside the configured receiver latency buffer. If RTT + retransmit time exceeds the buffer window, the packet cannot be recovered before playout, and the loss becomes visible to the decoder as an artefact or concealment event. This relationship makes per-flow RTT tracking and buffer state monitoring necessary for reliable operation.

Forward error correction (FEC) and hybrid protection

SRT implementations support FEC, which sends redundant parity packets alongside media data so that some lost packets can be mathematically reconstructed at the receiver without requiring retransmission.

FEC is particularly useful in scenarios where RTT is too long for timely ARQ recovery — for example, satellite links or high-latency WAN paths — or where packet loss is bursty and the cost of multiple retransmit cycles is unacceptable. In these cases, FEC provides a proactive recovery layer that complements or partially replaces ARQ.

The trade-off is bandwidth. FEC increases outbound bandwidth proportionally to the parity rate: a 10% FEC overhead increases required bandwidth by approximately 10%. For bandwidth-constrained links, this overhead must be weighed against the probability and severity of loss. A hybrid approach — ARQ for isolated random losses, FEC for burst protection — often provides the best balance between bandwidth efficiency and recovery reliability.

Receive buffer (jitter buffer), latency, and packet-rate sizing

The SRT receive buffer corresponds directly to the configured latency window, measured in milliseconds. This buffer holds out-of-order, delayed, and retransmitted packets for reassembly into the correct sequence before playout.

The memory required per stream follows a straightforward formula:

Buffer memory per stream ≈ bitrate (bits/s) × latency (s)

For example, a 50 Mbps stream with a 200 ms receive buffer requires approximately 50,000,000 × 0.2 = 10,000,000 bits, or roughly 1.25 MB of buffer memory. While this is modest for a single stream, large numbers of concurrent streams multiply memory and CPU requirements significantly. Each flow requires its own buffer allocation, RTT tracking state, and socket handling — creating density and scaling constraints on gateways and media nodes that must be accounted for in system design.

Congestion control and adaptive behaviour

SRT includes congestion-aware features that probe available bandwidth, adapt retransmit behaviour, and use pacing to avoid oversubscribing network links. When packet loss is caused by network congestion rather than random link errors, aggressive retransmission can worsen the problem by adding traffic to an already saturated path.

In congestion scenarios, reducing encoding bitrate or increasing FEC overhead can be preferable to repeated retransmits. SRT can operate alongside adaptive-bitrate encoding and encoder-side rate control to maintain stream continuity. This adaptive behaviour is important for contribution links that traverse shared or variable-quality network segments where available bandwidth fluctuates.

Why it matters in broadcast

Broadcasters require predictable low latency and minimal visible artefacts in contribution feeds. Packet-loss recovery that completes within the production latency budget keeps streams visually intact for switching, graphics insertion, and downstream distribution.

Many modern contribution and REMI (Remote Integration Model) links traverse unmanaged or semi-managed networks — public internet, cellular backhaul, or shared WAN paths — where packet loss and jitter are routine. SRT’s recovery mechanisms make these links viable for broadcast-quality contribution without requiring dedicated leased circuits.

The cost implications are significant. Replacing fixed leased circuits with SRT-over-Internet paths can substantially reduce operational expenditure, but only if packet-loss recovery and stream density are engineered to meet quality requirements at scale. An under-provisioned gateway that cannot service retransmit requests promptly under load negates the protocol’s benefits.

Operational predictability depends on understanding the relationships among RTT, configured latency, FEC overhead, and retransmit behaviour. These parameters directly affect capacity planning, service-level agreements, and timing accuracy for switcher and graphics integration in remote production environments.

Technical specifications and trade-offs

SRT’s core packet-loss recovery mechanisms include selective retransmission (NAK/ARQ), optional FEC, a configurable receive buffer (latency window), and AES payload encryption. The key variables that determine whether packet-loss recovery succeeds for a given link are:

• RTT (ms): determines how quickly a retransmit cycle can complete

• Configured receive latency (ms): the time window available for recovery

• Stream bitrate (Mbps): affects buffer memory and packet rate

• FEC overhead (%): additional bandwidth consumed by parity packets

• Packet-loss characteristics: random loss is easier to recover than burst loss

• Number of concurrent streams: multiplies per-flow resource requirements

Comparison of packet-loss approaches

Approach	Typical latency impact	Bandwidth overhead	Recovery reliability vs. RTT	Density / CPU implications
SRT ARQ (NAK/retransmit)	Low if RTT ≪ receiver buffer; fails otherwise	Minimal (retransmits only as needed)	High when RTT + retransmit ≤ receiver latency	Per-flow state (buffers, RTT tracking); scales linearly with stream count
SRT with FEC	Buffer latency can be reduced (design-dependent)	Moderate to high (e.g., 10–20% parity)	Good for high RTT or bursty loss	Additional encode/decode CPU; predictable bandwidth increase
RTP/UDP + application-level FEC	Similar to FEC trade-offs above	Moderate to high	Good where link is stable and pre-planned	Increased FEC processing; simpler per-flow state without ARQ
Proprietary managed WAN (e.g., Zixi)	Tunable; often low	Varies; may use bandwidth-efficient techniques	High under vendor-managed conditions	Vendor-optimised datapaths and kernel bypass; high-density offerings exist
Native reliable IP (managed circuit/fibre)	Minimal	No overhead	Near-zero packet loss expected	High cost; limited geographic flexibility

The “Recovery reliability vs. RTT” column summarises whether retransmit-based recovery is practical given the network delay on a particular path. The “Density / CPU implications” column highlights that per-connection state — including buffers, AES cryptographic processing, and socket management — increases aggregate resource demands and may require specialised hardware or kernel-bypass networking at scale.

Related approaches and standards

Several alternative and complementary technologies address packet loss in live media transport:

• RIST (Reliable Internet Stream Transport): An open, interoperable specification emphasising low-latency retransmission and multi-vendor compatibility. RIST is often preferred in environments where interoperability across equipment from different manufacturers is a priority.

• RTP with IP-FEC / SMPTE ST 2022-1/2: Packet-based professional transport profiles with established FEC schemes designed for contribution over IP networks. These standards provide well-defined FEC configurations for predictable recovery characteristics.

• SMPTE ST 2110: The professional standard for real-time media over IP with sample-accurate timing, typically deployed on managed LANs and MANs. SRT is often used at the WAN edge to contribute streams into ST 2110 facility domains.

• Bonded paths and rendezvous modes: Stream-bonding techniques aggregate multiple network paths — cellular, public internet, satellite — to reduce effective packet loss and increase aggregate bandwidth. SRT’s connection modes (caller, listener, rendezvous) facilitate NAT traversal in bonded configurations.

• Transport security: SRT supports AES payload encryption (128-bit and 256-bit variants) alongside standard network security practices including NAT traversal, firewall configuration, and access control for secure contribution.

How Appear addresses this

Appear’s X Platform family implements hardware-accelerated SRT processing in purpose-built chassis designed for high-density contribution and distribution workflows. The hardware acceleration targets the specific CPU, memory, and packet-rate constraints that arise when handling large numbers of concurrent SRT connections — each requiring its own ARQ buffers, AES cryptographic processing, and socket/packet handling.

Published product-level capacities include support for up to 22 simultaneous UHD camera feeds in a single unit, with multi-gigabit aggregate SRT throughput figures documented for systems such as the X Platform. Offloading per-stream SRT processing to dedicated hardware reduces per-stream overhead compared with general-purpose servers, improving achievable concurrent stream density within the latency and recovery constraints that broadcast contribution demands.

FAQ

What causes packet loss on SRT links?
Packet loss commonly results from transient network congestion (queue drops at routers or switches), link errors on wireless or last-mile segments, router or buffer overflow under load, or deliberate packet drops due to bandwidth oversubscription or QoS policies.

If packets are lost, will SRT always recover them?
No. SRT recovers lost packets using ARQ only if the retransmit cycle can complete within the configured receiver latency window. If RTT plus retransmit processing time exceeds the receive buffer duration, recovery fails and the decoder must conceal the error.

How does receive latency affect packet-loss recovery?
A larger receive latency increases the time window available for retransmit attempts, improving recovery probability on higher-RTT links. However, it also increases end-to-end latency and receive-buffer memory consumption per stream.

When should I use FEC instead of ARQ?
FEC is preferable where RTT is too high for timely retransmission (e.g., satellite links with hundreds of milliseconds of RTT), or where loss is bursty and multiple retransmit cycles would be unreliable. FEC trades additional bandwidth for reduced dependence on retransmit round-trips.

How does concurrent stream count affect packet-loss handling?
Each stream requires its own receive buffer memory, RTT state, and cryptographic processing. Scaling to many concurrent streams increases aggregate memory, CPU, and packets-per-second processing demands, which can affect the platform’s ability to service retransmit requests promptly.

Can SRT tolerate out-of-order packets?
Yes. SRT uses sequence numbers and the receive buffer to reorder packets. Reordering is resolved inside the jitter buffer before playout, so moderate reordering does not trigger unnecessary retransmit requests.

Does encryption affect recovery performance?
AES payload encryption adds CPU cost per packet. Modern CPUs with hardware AES acceleration (AES-NI) mitigate this for moderate stream counts, but at high density the cumulative cryptographic load can become significant without purpose-built hardware or accelerated datapaths.

How do I size a gateway for expected packet loss?
Determine the expected RTT, target maximum end-to-end latency, stream bitrates, and stream count. Compute receive-buffer memory as bitrate × latency per stream, plan CPU and crypto capacity for AES processing at the aggregate packet rate, and add FEC bandwidth margin if the link characteristics warrant it.

Are there SRT protocol versions that add FEC or bonding?
The SRT open-source library and broader ecosystem have introduced FEC capabilities and bonding/multipath features in successive releases. Implementation maturity and feature availability vary between versions, so compatibility should be verified between endpoints.

What monitoring metrics indicate packet-loss problems?
Key metrics include packet-loss rate, retransmit (NAK) rate, RTT distribution, receive-buffer occupancy, packet reordering counts, and decoder error or concealment events. Monitoring these in combination provides early warning of recovery degradation.

Can I use SRT across firewalls and NAT?
Yes. SRT supports caller, listener, and rendezvous connection modes that accommodate common NAT traversal patterns. However, network firewall and NAT rules must allow the relevant UDP ports, or tunnelling and relay strategies must be employed.

Should I prefer SRT or RIST for contribution?
The choice depends on interoperability requirements and ecosystem support. SRT has wide adoption and strong open-source tooling. RIST focuses on standardised interoperability profiles and is preferred by some broadcasters in multi-vendor environments. Evaluate encoder/decoder support, feature parity (FEC, bonding), and operational requirements for your specific deployment.