Skip to main content

SRT (Secure Reliable Transport)

Quick look-up table​

SRT
Type of streamingReal time streaming
Development StateIn active development
Expected LatencyVariable
Connection typeUDP
Container typeMPEG2-TS*
WhereCustom players, to servers
Default PortNone
Modern codecsAll*
Difficulty of readBeginner
Notes*Actually media agnostic, but in the industry everyone uses it in combination with MPEG-TS

What do I need to know about SRT?​

SRT stands for Secure Reliable Transport, it was made to be a propriatary transport for Haivision, they later open sourced it April 2017. SRT is made to be an combination of UDP and TCP. The goal was to get the low latency of UDP, but with the reliability of TCP. To a certain extend they are succesful in this, just keep in mind that low latency and reliability are generally two sides you need to balance. You can't have both. The reason why it's often referred to as Haivison SRT and not just SRT is because the subtitle format SubRip uses .srt as file format and has been around since 2000.

When would you use SRT?​

Live streaming to servers or between server transport in unreliable network conditions

SRT is a good method of getting your media to a server without too much hassle. It doesn't have to be a live stream, but there's no true benefit to using SRT if you're transporting VOD content. Over the years SRT has gotten quite a feature list and is something you can adapt to most network conditons, which definitely works in favor for its popularity. One thing of note would be that the defaults have been pivoting towards low latency rather than reliability. This does mean that one needs to read up on the usage of SRT when the defaults do not fit your use-case, which can become quite complex.

The scheme for SRT looks like this:

srt://(address):port?parameter1&parameter2&parameter3&etc..

While the address is optional the port is required and will need a unique port per input or output unless the ?streamid=stream_name parameter is used. Together with the ?latency=time_in_ms, ?mode=caller/listener and ?passphrase=passphrase parameters these will most likely be the ones you'd use the most.

There's 5 important things to know about SRT:

  • Every connection has a caller (the side to connect to the other side) and a listener (the side that waits for a connection to be made). Connections will only work if a caller and listener are combined. You can specificly set these with ?mode=caller or ?mode=listener
  • address is optional, leaving it out implies listener mode, while setting it implies caller mode.
  • ?latency=time_in_ms has a default of 120ms, this is the amount of time the SRT process will allow for packets to be retransmited/recovered. Anything not "whole" by the end of this time is considered lost. Another important thing to note that this is the latency the SRT process adds, any latency applications need to generate the SRT stream can still be added!
  • ?streamid=stream_name is a parameter that will allow a single SRT port to stream towards multiple stream sources. This way you can use a single SRT port instead of one per stream.
  • ?passphrase=passphrase requires at least 10 characters and will mean a connection fails if one side has a non-matching or non-set passphrase. This is set per port, so setting this in combination with ?streamid makes everyone use the same passphrase.

Advantages of SRT​

  • UDP: low latency transport
  • Media agnostic, potentially everything can be supported
  • Latency and quality is adjustable

Disadvantages of SRT​

  • No browser support, needs a custom player
  • Every implementation only uses MPEG-TS, which holds it back from ultra-low latency
  • Can be harder to understand what to fine-tune to get the results you want. Defaults actually won't help you for unreliable networks

How do you get started with SRT?​

Want to know how to set up SRT and use it as your transport for your media server? Look at our How to use SRT post and learn more or download MistServer yourself and try it out. Since SRT is more of a transport towards a server we would recommend using another protocol to reach your viewers. Need to make a decision on which protocol? Visit our Introduction to streaming protocols