Starting with version 1.7.15.10276, our video SDK supports SRT streaming.
What is SRT?
Secure Reliable Transport (SRT) is an open source software protocol and technology stack designed for live video streaming over the public internet. If you want to learn more about its history, read our interview with the architect and evangelist of SRT.
SRT provides connection and control, reliable transmission similar to TCP, however, it does so at the application layer, using UDP protocol as an underlying transport layer. It supports packet recovery while maintaining low latency (default: 120 ms). SRT also supports encryption using AES.
Source
https://en.wikipedia.org/wiki/Secure_Reliable_Transport
Git
https://github.com/Haivision/srt
Medialooks SRT
There are two classic modes in the case of SRT streaming:
- caller - requester side
srt://ip_address:port?mode=caller
- listener - listener side
srt://ip_address:port?mode=listener
Also, there is Rendezvous mode, it's described at the very bottom of this article.
Above modes specify the network connection type - who is sending the request for connection and who is waiting for a request. It is not relative to the encoding or decoding processes, so your encoder can act as a listener and your decoder can act as a caller and vice versa.
Pay attention, listener should be run before the caller and wait for a caller request.
In most cases, the decision about how is going to be a requester and who is going to be the listener should be based on your network NAT firewall rules i.e caller in most cases does not need any additional rules. Meanwhile, with listener mode, you should be sure that you have a specific port forward rule.
In our next examples, we are going to use the encoder (Writer Sample) as a caller and the decoder (Network Playback Sample) as a listener.
You can use SRT with Medialooks SDKs in the same way as commonly known UDP/DVB protocols. On the streamer side:
- Run Writer Sample / Sample File Writing
- Choose the SRT as the video format
- Set desirable encoder (MPEG-2 in the current sample)
- Set URL value by the following pattern - srt://ip_address:port?mode=caller
There are a lot of settings available for the SRT (e.g., latency, passphrase) - you should set them directly in the target URL, and not in _bsProps parameter of the WriterNameSet (or WriterSet) method, for example:
srt://127.0.0.1:1234?mode=listener&latency=600000
On the receiver side:
- Run the Network Playback Sample
- URL should be the following - srt://ip_address:port?mode=listener
SRT statistics
MWriter/MFWriter object instances able to provide encoder statistics via "encoder::muxer::stat"
m_objMFWriter.PropsGet("encoder::muxer::stat", out strValue)
MFReader object instances could provide the SRT decoder statistics via "splitter::current::stat"
m_objMFreader.PropsGet("splitter::current::stat", out strValue)
For MFileClass object instances could provide the SRT decoder statistics via "file::splitter::current::stat"
m_objMFileClass.PropsGet("file::splitter::current::stat", out strValue)
In both cases, for encoder and decoder statistics, Video SDK will return default SRT stats. You can find statistics description on HaivisionGitHub: https://github.com/Haivision/srt/blob/master/docs/API/statistics.md#summary-table
Rendezvous mode
How Rendezvous Mode Works:
1. Dynamic Connection Establishment: Instead of requiring a fixed IP address or port number, Rendezvous mode allows SRT endpoints to dynamically discover each other. This is particularly useful in scenarios where network configurations may change frequently.
2. Using a Rendezvous Server:
- One endpoint acts as a Rendezvous server, which listens for connection requests.
- Other endpoints can register with this server to announce their availability and listen for incoming connections.
3. Connection Negotiation: When an endpoint wants to connect, it can send a request to the Rendezvous server. The server then facilitates the connection by informing the target endpoint about the incoming request.
4. Simplified NAT Traversal: Rendezvous mode can help with Network Address Translation (NAT) issues, making it easier for devices behind firewalls or routers to establish direct connections.
5. Resilience: By allowing dynamic connections, Randevoze mode can adapt to changing network conditions, improving the overall reliability of the streaming experience.
Usage:
Writer (Encoder) side - srt://dest_external_IP:12345?mode=rendezvous&localip=local_IP
Reader (Decoder) side - srt://source_external_IP:12345?mode=rendezvous&localip=local_IP
where:local_IP- the local IP address for the current workstation.dest_external_IP - public IP of the destination host (decoder's IP)source_external_IP - public IP of the source host (encoder's IP)
For example, in the above figure, the connection tracking table in Firewall A records the internal network IP and port number of the source device, the public network IP and port number after NAT conversion, and the target device’s public IP and port of the firewall as follows:
At this time, when a data packet is sent from the opposite end, the connection tracking table of Firewall B also records another piece of reverse inbound information, as shown in the following table:
When the reverse data packet arrives at Firewall A, the port number sending and receiving the same data will have a "spoof" effect on Firewall B, making it think that the received inbound data is a reply message to the outbound data, thus allowing the data packet passes to go through the firewall until the transmission session is disconnected, by which the SRT connection is thus established.
But in most scenarios, the network devices we use (firewalls and routers) transfer from LAN IP to public IP with PAT (NAT reload) for address, in which the network devices change the source port number when converting the address. So most of the time the Rendezvous mode cannot be used. It is better to use a router as a static port forward rule - at one end it can be connected with the Listener mode to monitor the forwarded port; at the other end, the Caller mode is used to establish the connection.