What is SRT?
SRT is a transport protocol that enables the secure, reliable transport of data across unpredictable networks, such as the Internet.
While any data type can be transferred via SRT, it is particularly optimized for audio/video streaming.
open source transport protocol, https://github.com/Haivision/srt.
https://www.srtalliance.org/, currently more than 500 members to date.
- Data agnostic transport protocol built on top of UDP.
- Bidirectional data transfer / Connection bonding
- ARQ (ACK + NAK)
- Stream multiplexing
- Secure (AES 128/192/256 Encryption)
- Statistics support
since SRT is a protocol, which enables us to see the transmission via too such as wireshark.
Transmission Modes
| Message | Live | Buffer | |
|---|---|---|---|
| Realtime | No | Yes | No |
| Transfer | File/Msg | Live Streaming | Single file |
| Note | Latency management |
How come it can be reliable?
i ask this question to myself from technical aspect, how it can be so different?
1st of all, SRT has its roots in the UDP-based Data Transfer (UDT) protocol. While UDT was designed for high throughput file transmission over public networks, it does not do well with live video.
SRT includes a mechanism that recreates the signal characteristics on the receiver side, dramatically reducing the need for buffering.
Latency Window
As the latency window slides, that packet is supposed to be ready to give to the application, but is not available.
That leads to a skipped packet. It cannot be recovered, so it will be removed from the loss list and never asked for again.
this means that let's drop / skip packet to keep the latency.
based on latency window, SRT provides the following 2 ways.
Timestamp Based Packet Delivery (TSBPD)
If packet #4 arrives in the receiver‘s buffer, but not packet #3, a NAK is sent to the sender.
This NAK is added to a compressed list (the periodic NAK report) that is sent at intervals to mitigate the possibility that individual NAKs may themselves be delayed or lost in transmission.
If packet number #2 arrives, but packet #3 does not, then when packet #4 arrives, the NAK is sent right away to address the reordering.
Too-Late Packet Drop (TL Packet Drop)
allows the sender to drop packets that have no chance to be delivered in time. In the SRT sender, when Too-Late Packet Drop is enabled, and a packet timestamp is older than 125% of the SRT latency, it is considered too late to be delivered and may be dropped by the encoder.
Packets of an IFrame tail can then be dropped before being delivered.
Fast Retransmit
this addresses the issue by retransmitting unacknowledged packets before the congestion window is full.
The sender adds to the loss list any packets that have not been ACKed within a reasonable time, based on the RTT and the original timestamp of the dropped packet.
Periodic NAK Reports
SRT Periodic NAK reports are sent with a period of RTT/2, with a 20 msec floor (the UDT4 setting was 300 msec).
A NAK control packet contains a compressed list of the lost packets.
Therefore, only lost packets are retransmitted.
By using RTT/2 for the NAK reports period, it may happen that lost packets are retransmitted more than once, but it helps maintain low latency in the case where NAK packets are lost.
Bidirectional Transmission Queues
It’s useful to think of this as a standard point-to-point SRT session between Sender and Receiver, where each peer has a transmit/send (Tx) buffer as well as a receive (Rx) buffer.
The Sender’s Tx communicates with the Receiver’s Rx, while the Receiver’s Tx communicates with the Sender’s Rx. Just as in a regular one-way session, the Tx/Rx latency values must match.
In the handshake packet, the sender will provide both its preferred Tx latency and a suggested “peer latency” (the value for the Receiver’s Tx).
The Receiver responds with corresponding values.
The proposed latency values are evaluated on both sides (and the larger values chosen) within a single RTT period.
Statistics
supports statistics APIs https://github.com/Haivision/srt/blob/master/docs/API/statistics.md for each endpoint socket.
- link RTT
- bandwidth
- packets sent/received
- packets lost / dropped
...
Access Control
see https://github.com/Haivision/srt/blob/master/docs/features/access-control.md
Stream ID which is a string of maximum 512 characters set on the caller side.
a callback can be registered on the listener socket for an application to make decisions on incoming caller connections.
This callback, among others, is provided with the value of Stream ID from the incoming connection.
Based on this information, the application can accept or reject the connection, select the desired data stream, or set an appropriate passphrase for the connection.
Bonding Mode
- Broadcast: transmits all packets on each socket.
- Backup: secondary backup socket will take over if 1st one goes down.
- Balance: equally consumes bonding sockets.