Secure Reliable Transport (SRT) is a relatively new streaming protocol from Haivision, a leader in the online streaming industry. This open-source protocol is known for its remarkable security, reliability, compatibility, and capability of low latency streaming.

There are currently some limitations on streaming with SRT because other streaming hardware and software have yet to develop to support this protocol. [1]

Figure 1. The secure reliable transport (SRT)

Figure 1 shows the Secure Reliable Transport (SRT) is a royalty-free, open-source video transport protocol that supports low-latency, high-performance streaming, over noisy or unpredictable networks such as the public internet. Matrox is a member of the SRT Alliance that manages and promotes the use of the SRT protocol.

As a fierce advocate of interoperability and standards, Matrox was among the early supporters of SRT. Matrox has implemented support for the SRT protocol in its current and upcoming encoding and decoding solutions. At InfoComm, Matrox also hosted a multi-vendor SRT open source interoperability showcase to demonstrate SRT-ready products working together.[2]

The benefits of using the SRT protocol:

• Pristine quality video – SRT is designed to protect against jitter, packet loss, and bandwidth fluctuations due to congestion over noisy networks for the best viewing experience possible. This is done through advanced low latency retransmission techniques that compensate for and manage the packet loss. SRT can withstand up to 10% packet loss with no visual degradation to the stream.
• Low latency – – In spite of dealing with network challenges, video and audio is delivered with low latency. It has the combined advantages of the reliability of TCP/IP delivery and the speed of UDP.
• Secure end-to-end transmission – Industry-standard AES 128/256-bit encryption ensures protection of content over the internet. SRT provides simplified firewall traversal.
• Leveraging the internet – Because SRT ensures security and reliability, the public internet is now viable for an expanded range of streaming applications—like streaming to socialcast cloud sites (for example, LiveScale omnicast multi-cloud platform's concurrent distribution to multiple social media such as Facebook Live, YouTube, Twitch and Periscope from one live video feed), streaming or remoting an entire video wall content, or regions of interest of a video wall, and more.
• Interoperability – Users can confidently deploy SRT through their entire video and audio streaming workflows knowing that multi-vendor products will work together seamlessly.
• Open source – Royalty-free, next-generation open source protocol leads to cost-effective, interoperable, and future-proofed solutions.[2]

The Technology Behind SRT

“SRT takes some of the best aspects of User Datagram Protocol (UDP), such as low latency, but adds error-checking to match the reliability of Transmission Control Protocol/Internet Protocol (TCP/IP). While TCP/IP handles all data profiles and is optimal for its job, SRT can address high-performance video specifically.” UDP and TCP are both core components of the internet protocol suite, residing in the transport layer. Streaming protocols like SRT sit on top of these.

TCP is quite reliable and can solve for packet loss and ordering. UDP, on the other hand, starts without requiring any handshake. It transports data regardless of any bandwidth constraints, making it speedier and riskier.

Specifically, the UDP-based protocol leverages an error-correction mechanism for packet recovery called Automatic Repeat ReQuest (ARQ). If the receiver (server) recognizes a gap in the stream, it re-requests those packets from the sender (encoder) via a negative acknowledgment (NAK) packet.[3]

References:

1. https://www.dacast.com/blog/video-streaming-protocol/
2. https://www.matrox.com/en/video/media/guides-articles/srt-protocol
3. https://www.wowza.com/blog/srt-the-secure-reliable-transport-protocol-explained

Cite this article:

Thanusri swetha J (2021), Secure Reliable Transport (SRT) Protocol, AnaTechmaz, pp. 26