RTMP vs. SRT
COMPARING LATENCY AND MAXIMUM BANDWIDTH
For those looking to stream live video over IP with low end-to-end latency, there’s a limited selection of transport protocols to choose from. This is especially true when using the public internet as a transport medium as it presents a number of challenging obstacles to overcome such as packet loss and jitter. In this white paper, we set out to compare and evaluate the merits of two commonly used protocols, RTMP and SRT.
The Real-Time Messaging Protocol (RTMP) is a mature, well established streaming protocol with a reputation for reliability thanks to its TCP-based packet-retransmit capabilities and adjustable buffers.
Secure Reliable Transport protocol (SRT) is an open source protocol pioneered by Haivision which leverages an intelligent packet retransmit mechanism on top of a UDP data flow, along with AES256 encryption.
In this white paper, we will examine how SRT performs compared to RTMP over public networks. We’ll explore how much buffer is required, what latency looks like and whether there is a limit on the amount of bandwidth you can use. We’ll also answer the question of how far a video stream can travel across the globe before it fails.
COMPARING LATENCY OF RTMP VS. SRT
First, let’s start by examining end-to-end latency. End-to-end latency, sometimes referred to as glass-to-glass latency, is the total amount of time it takes for a single frame of video to transfer from the camera to the display. There are many factors which contribute to latency depending on the delivery chain and the number of video processing steps involved. While individually these delays might be minimal, cumulatively they can really add up. They include the encoding, decoding, transport medium (internet, satellite, radio, fiber, etc.), sources (cameras, video players etc.) and display devices.
The focus of this white paper is to measure the impact of using either RTMP or SRT on end-to-end latency. In order to achieve comparable results, the same devices with exactly the same settings were used during testing and the only variable was switching between RTMP and SRT protocols. In some instances however, configurations had to be changed in order to get a stable RTMP stream, and these will be explained in further detail.