[EN] SRT: The Engineering of Low Latency and Packet Recovery

The SRT (Secure Reliable Transport) protocol transformed the public internet into a viable medium for professional video contribution by replacing the paradigm of unpredictable transport with deterministic latency and intelligent recovery. While TCP-based protocols suffer from Head-of-Line Blocking and pure UDP ignores data integrity, SRT utilizes a selective retransmission mechanism that guarantees the delivery of every frame without interrupting the continuous streaming flow, even under adverse network conditions.

Knowledge Architecture: Study First

To master the fine-tuning and engineering of SRT, it is imperative to understand the pillars that support its technology stack:

• UDP: The low-overhead, high-speed transport base.
• ARQ: The automatic repeat request logic that SRT optimizes.
• RTT (Round Trip Time): The fundamental metric of physical network response time between endpoints.

Concept: NAK Recovery and Fixed Latency

Unlike TCP, which confirms every received packet (ACK), SRT operates primarily via NAK (Negative Acknowledgement). The receiver monitors packet number sequences in real-time; upon detecting a gap, it immediately sends a "packet not received" signal. The secret of its resilience lies in the configurable latency buffer: the receiver holds packets for a precisely defined time, creating a window of opportunity for retransmissions requested via NAK to arrive and be reordered before playout.

Operation and Internal Structure: SRT

SRT's internal mechanics overlay UDP with a layer of congestion control and high-precision timestamping.

• TSBPD (Time-Stamped-Based Packet Delivery): Each packet carries a timestamp from the encoder. The receiver uses this data to deliver packets to the application at exactly the same rhythm they were generated, eliminating network jitter.
• Selective Retransmission: The transmitter keeps a copy of recently sent packets in memory (send buffer). When it receives a NAK, it resends only the missing packets, avoiding the overhead of retransmitting data that has already reached the destination.

Calculating and Adjusting Minimum Latency

Adjusting latency is a video engineer's most critical decision. The value must be calculated based on the network's RTT. The gold standard formula is: Latency = RTT * Multiplier. For stable professional networks, a multiplier of 3 to 4 is used. On unstable or long-distance networks (packet loss above 5%), 5 to 8 is recommended. Why this calculation? A complete retransmission cycle (Detect loss -> Send NAK -> Transmitter receives NAK -> Retransmitted packet arrives) consumes exactly 1 RTT. Setting latency to 4x RTT ensures the protocol has at least four attempts to recover the same packet before playout time expires. If your RTT is 100ms, your safe latency should be at least 400ms. Adjusting below this on jittery networks will result in dropped frames and image artifacts.

To learn more about the subject:

• 1. How does SRT's TSBPD algorithm mitigate jitter variations on long-distance connections?
  Click here to investigate
• 2. What is the mathematical relationship between overhead bandwidth and ARQ effectiveness in SRT?
  Click here to investigate
• 3. Why is SRT preferred over RTMP for transmissions over 4G and 5G networks?
  Click here to investigate

---

Technical Disclaimer and Intellectual Property Notice

This blog presents analyses and facts based exclusively on technical documentation, RFCs, and publicly available materials on the global computer network. The information contained herein is compiled for strictly educational and technical reference purposes.

Lack of Affiliation: This project is independent and has no official affiliation, endorsement, or link with the developers, companies, or rights holders of the mentioned technologies. All trademarks and logos cited belong to their respective owners.

Liability: The implementation of any protocol or configuration based on these notes is the sole responsibility of the user. The author disclaims any liability arising from the misuse of this information.

Rights and Corrections: We fully respect intellectual property. If you are the rights holder of any material or technology cited here and identify the need for corrections, adjustments, or wish to make official comments, please send a private message directly to the author for immediate resolution.