This post is kind of a work in progress, but we wanted to publish it now instead of waiting to get it perfect. Please bear with us and let us know if you have any suggested additions/clarifications.
SRT (Secure Rapid Transport) is an open standard streaming protocol which is meant to replace the older, more basic ways of streaming video over the internet, which up to this point has mainly been RTMP.
The basic needs that SRT addresses is to bring in low latency remote video to your production at a level of quality better than Zoom, Teams, Webex, or other desktop teleconferencing applications.
What is SRT?
- SRT is a transport layer that replaces the transport layer that was developed for point-to-point file transer over the internet
- Ultra Low Latency (typically 80 ms to 1 second)
- Firewall Friendly
- More Tolerant of Unpredictable Network Connections
- Its Latency is configurable so it gives you more control when working with unpredictable network connections
- RTMP (the older and most common way of sending video – for example with YouTube or Facebook) just ‘throws at the wall and hope it sticks’ over the internet and just hopes it gets there.
- SRT has a secondary back channel of data with diagnostic and packet recovery information that is coming back to your origin from the destination. It tells the sending source useful information such as:
- round trip time
- packet loss
- and other diagnostic data
- It was designed to replace satellite trucks and leverage the faster network speeds of today.
Here is a Great Video That Explains SRT In-Depth
This video was made by Epiphan, and features:
- Dave Kirk – Marketing VP
- George Herbert – Customer Support
SRT was invented by Haivision, but it then has become an open standard. The SRT Alliance is a group of manufacturers that have adopted SRT technology:
Definition of Low and Ultra-Low Latency
Here is a chart showing common transport schemes and their typical latencies in seconds, and milleseconds (1/1000th of a second).
SRT Application Examples (see video)
NFL Draft – 2020
They needed a very large number of remote sources and wanted to optimize the quality. SRT was their choice
NASA and SpaceX
Used during some of the recent launches to move data between their mission control and launch pads which are in different geographic locations.
Use Cases w/ Epiphan and SRT:
- Streaming Content to a CDN (Probably the most common):
2. Point-to-Point for Live Event Production with One or More Remote Sources:
3. Contribution Encoding – using a variety of other SRT Sources:
How to Configure SRT for Best Results
Haivision Play, Rivet – SRT software decoders
Why Pearl (Epiphan’s Hardware Platform) vs. a Software-Based System?
- Dedicated appliance, purpose built
- Easier to use
- Professional Quality
- Once place to go for support
- None of the username / password issues typically involved with sending out an enterprise computer.
The Epiphan Pearl Line Up:
Pearl-2 – for use as a production hub
- 6 SRT Inputs
- 6 SRT Outputs
- Multiple Video Programs
Peal Nano – for Contribution – streaming and recording
- 1 SRT Input
- 1 SRT Output
- Single Video Program
- Very easy to use by pre-configuring and then just pushing the ‘stream’ button
End-To-End Control When Using Pearl and SRT
How to Configure SRT with an Epiphan Pearl
SRT Connection Modes
- Caller/Listener – this method is somewhat less complex.
- Caller – works hand-in-hand with listener. The Caller initiates the connection
- Listener – works hand-in-hand with caller. The Listener is standing by waiting a caller to initiate a connection.
- Rendezvous – Either endpoints can initiate the connection, but both have to known the others public ip addresses. This can sometimes be more of a challenge. Rendezvous is very good at traversing unknown or problematic firewall.
- Both the source and destination can be set as caller, listener, or rendezvous
Look at the information and use it to tune the settings to optimize the connection.
- Latency is the key parameter that you will dial in. The goal is to set that as low as possible to minimize the overall transmission delay.
- Packet loss % will tell you how reliable the connection is.
SRT Connection Tuning
Being able to measure the actual connection statistics is key to optimizing each connection and also for troubleshooting. Otherwise you are relegated to just guessing, and trial and error.
- The packet loss percentage is .91%. Looking that up in the table, that means your RTT multiplier should be 3.
- Then take the RTT multiplier and multiply it by the measured Round Trip Time to get your recommended minimum latency setting.
For this example:
The RTT is 26.508 ms
So 3 x 26.508 mS = 78.24 ms
- The encoding bit rate still has to be less than your network bandwidth
- Remember, a millisecond (ms) is 1/1000th of a second, to a 78 mS delay is less than a tenth of a second (about 2 frames in a 30p video)
These are meant as a starting point. The idea is to try and figure out the minimum latency that will be needed to have an uninterrupted stream. Let’s use the values from this screen shot as an example:
The RTT mulitplier x the Round Trip Time to dertimine the minimum latency that you need to configure.