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

SRT recovers lost packets only inside the receive-buffer window. Resilience therefore depends on three things: whether the gateway can service retransmissions under load, whether traffic survives the loss of a whole path, and whether the latency setting fits the network the stream crosses. Appear’s X Platform and VX address each.

Retransmission at density

Appear’s hardware-accelerated SRT separates the control layer (CPU) from media transport (FPGA). Retransmission handling then does not compete with encryption and packet processing for CPU as stream count grows. One IP gateway module supports up to 128 services and 6 Gb/s of SRT traffic, with retransmission bandwidth controlled at service level. Capacity figures for larger configurations are in the SRT stream density guide.

Path protection with ST 2022-7 and bonding

Retransmission cannot recover a path that has failed. ST 2022-7 carries the same stream over two independent paths and reconstructs one clean stream at the receiver. X Platform and VX reconstruct dual RTP paths. X Platform also provides seamless protection over SRT and plain IP, using one seamless buffer across both paths. X10 and X20 provide this at density, and X5 supports the venue end. VX provides seamless merge plus A/B failover on commodity Linux hardware, private cloud VMs or public cloud instances. Appear’s SRT implementation also supports bonding and rendezvous mode. For active-active and active-standby design, see the path diversity guide.

Measured results: X5 over bonded wireless

In September 2026, Appear field-tested an X5 sending standards-based SRT over an independent, third-party bonding layer. The layer combined two 5G carriers and a LEO satellite link, with an X20 at the studio end. Field-end video was HD Low Latency HEVC at 6 Mbps. This was exploratory testing, not a certified deployment configuration. Results vary by venue, carrier and weather.

The test also showed where recovery needs tuning:

• At 800ms SRT latency, some retransmission requests arrived too late during LEO RTT spikes. Raising latency to 1,000ms restored stability.
• The bonding device’s smoothing feature duplicated SRT’s own retransmission and roughly doubled bandwidth to around 90 Mbps. Disabling smoothing brought it to roughly 46 Mbps with no loss of stream stability.
• Excluding the LEO link from the bond when its RTT exceeded 150ms (2,000ms hold-off) kept the remaining streams stable.

In production

• Corus: SRT is the primary transport across Canadian affiliates, news bureaux and operational hubs, replacing reliance on leased circuits. Legacy interfaces stay where the transition requires them. Read more
• World Archery: SRT feeds from venues worldwide reach the production centre in Lausanne, which distributes coverage to more than 15 media partners. Read more

Where recovery runs out

SRT recovery has physical limits, and Appear’s implementation works within them. Loss becomes visible when RTT plus retransmit time exceeds the configured latency, or when available bandwidth falls below the stream bitrate plus recovery overhead. SRT can add up to 25% to a stream’s bandwidth. In practice:

• Measure RTT on each path.
• Set latency at 4 to 5 times the RTT of the slowest active link.
• Check that only one layer is handling retransmission.