SRT vs RTMP vs RIST: which streaming protocol do you need?

The short answer: use RTMP to send a stream to a platform such as YouTube, and use SRT, or RIST if the receiving end asks for it, to send a feed between two sites over the internet. All three carry a video stream from one place to another, but they are not interchangeable, and picking the wrong one is a common cause of dropped or stuttering streams. Two questions get you to the right one.

RTMP is the oldest of the three and still the usual way to push a stream to a platform. YouTube, Facebook and Twitch all take RTMP or its encrypted form, RTMPS. It is simple and very widely supported. It runs over TCP, so when a connection is poor the stream falls behind and can stutter or drop. It is a push to a server, and it was not designed for sending a contribution feed between two sites over a difficult link.

SRT (Secure Reliable Transport) was built for that job. It adds encryption and resends lost packets within a time limit you set, so it can hold a clean stream over a variable internet connection, such as a mobile uplink or venue Wi-Fi, where an RTMP stream would break up. It is open source and widely supported by encoders and decoders. This is what our Ultra Encode encoders use to get a feed from a remote site back to base.

RIST (Reliable Internet Stream Transport) is the newest of the three. It is an open specification published by the Video Services Forum, and it recovers lost packets in a similar way to SRT. Choose it when the receiving end, for example a broadcaster, specifies RIST.

Rule of thumb: use RTMP if you are pushing straight to a public platform. Use SRT, or RIST if your receiving end requires it, if you are sending a contribution feed over an unpredictable internet link and need the picture to arrive intact. Both ends must use the same protocol, so ask the receiving end what it accepts before you choose.