RTMP vs. RTSP: Which Protocol Should You Choose? (Update)

The wide world of video streaming is complicated enough without needing to consider which ingest protocol best suits your goals. And if the term “ingest protocol” already has your head spinning, then strap in. It only gets more complicated when you acknowledge ongoing updates and technology (like Adobe’s Flash Player) that have long since been relegated to the scrap heap. 

Scared? Don’t be. We’ve got you covered with a thorough breakdown of two of the most widely used ingest protocols: Real-Time Messaging Protocol (RTMP) and Real-Time Streaming Protocol (RTSP). In this article, we talk about what makes them unique, how they work, and most importantly, how they measure up to your needs.

   

Streaming Protocols: A Brief Overview

Put simply: if your data is a passenger, then your codec is a car, and the streaming protocol is the highway and set of “road rules” that makes it possible for content to get from one place to another.

When it comes to streaming video or audio, your codec is the compressed version of those files, and the protocol is the set of rules that govern how those files are broken down and sent to their destination. After all, different playback devices require different data packages. And your media needs to be compatible with a variety of playback devices to reach end users. For example, Apple devices work with the popularly used HTTP Live Streaming (HLS) protocol, but not with Dynamic Adaptive Streaming over HTTP (MPEG-DASH). 

Finally, to understand how protocols like RTMP and RTSP work (and in some cases no longer do), you need to understand that protocols can layer on top of one another. Transmission Control Protocol (TCP) acts as a foundation for RTMP. Conversely, Hypertext Transfer Protocol (HTTP) acts as the foundation for newer protocols. This will come up again when discussing pros and cons of RTMP vs. RTSP.

 

RTMP vs. RTSP: How They Work

That’s all well and good, but what is an “ingest” protocol and how does it fit into your streaming workflow?

Also known as a contribution protocol, ingest protocols are used for the first part of data delivery during the streaming process. Note the below graphic, which breaks streaming down into four key parts: 

• Contribution – Raw video or audio data is sent to an encoder, which encodes it using an ingest protocol. This is sometimes referred to as the first mile. 
• Processing – The encoded data is sent to a streaming media server. Here data may be transcoded to alter the resolution and bitrate of the original raw data. It may also be transmuxed to adjust the streaming protocol. 
• Scaling and Delivery – Using edge servers or a content delivery network (CDN), your data is prepared for a larger audience. This may or may not come into play for your stream. 
• Delivery – This is the last mile. The data is sent to various playback devices for viewing. Which playback devices you can reach depends on your chosen protocol(s). 

Note the protocols in fine print on the right and left edges of the graphic. These are protocols that can be used at contribution and delivery. Web Real-Time Communications (WebRTC) can be used for both. However, in most case, protocols will need to adjust during the workflow. 

 

What Is RTMP?

Remember when you tried playing videos back in the day, and your computer would tell you to update your Flash plugin? That was RTMP knocking at your door.

Real-Time Messaging Protocol (RTMP) was once the standard for streaming across the entire workflow — from contribution right through to delivery. It was developed by Macromedia (later purchased by Adobe) for streaming to Flash players. 

After it was no longer proprietary, RTMP became even more widely used. For more than two decades, RTMP was the standard for live and on-demand streaming from end to end. However, it lost its luster as Flash started being phased out and HTTP-based protocols became the new standard for streaming to playback devices. 

All that said, RTMP is still alive and kicking. It is the most popular ingest protocol for live and on-demand streaming. It just needs to partner with an HTTP-based protocol (like HLS or MPEG-DASH) for last-mile delivery. 

 

RTMP Pros 

The four key benefits of RTMP as an ingest protocol are: reliability, adaptability, flexibility, and low latency. Let’s break those down a little further. 

Reliability 

RTMP operates on a three-way handshake between the client and server. Basically, the client (where the data is coming from) pings the server (the media server that manages and transmuxes the data), asking for a connection. The server responds, starting the connection. The client then responds to that response, maintaining the session. This results in a continuous connection between where the data is coming from and where it is being transmuxed for delivery to playback devices. 

The result is a very steady, reliable connection that is not subject to the whims of the server’s bandwidth. This is particularly handy where live streaming is concerned as raw data is being recorded, encoded, fed to the streaming server, and transmuxed for playback in a continuous stream. 

Adaptability

With RTMP, it’s possible to set up a stream where viewers aren’t locked into one particular “direction.” In other words, they can pause, skip, and rewind. It also allows viewers to join live streams after they’ve already begun. 

Flexibility 

RTMP works with a wide range of media types, not just audio and visual data. RTMP supports text and graphic data. It also makes it easy to blend data types (audio, visual, and text) into one cohesive package.

Low Latency 

RTMP operates with three-to-five seconds of latency. That is to say, your live stream will feature on playback devices with only a three-to-five second delay. Certainly, this is no longer the fastest available, with WebRTC coming in at sub-second ultra-low latency, but it is considered a good and reliable target. 

 

RTMP Cons

Now for the bad news. RTMP is not perfect, and its shortcomings can best be summarized as follows: HTTP incompatible, lack of support, and susceptibility to bandwidth issues (wait, what?). 

HTTP Incompatible 

Let’s address the elephant in the room. RTMP is no longer viable for last-mile delivery. Of course, we already knew that; that’s why we are talking about it only for ingest purposes. It does not work with HTTP, nor can it be played on HTML5 players (the new industry standard).

Lack of Support

Adobe officially announced that Flash was no longer being supported in December of 2020. With Flash gone, there was apparently little need to keep up with RTMP. While it is still in wide use, the protocol itself is no longer being updated or support. Perhaps Adobe will be announcing its death sometime soon. 

Bandwidth Issues 

I know what you’re thinking. We just covered how reliable the connection between the client and server are. It’s true, but with a caveat. TCP, upon which RTMP sits, has a window in which it can store data when bandwidth is low, and the data can’t be transmitted. Once the bandwidth picks back up and streaming resumes, it can pull from that data reservoir without missing a beat. So, what’s the problem? The TCP window for saving this data is limited and there is no process in place for recovering lost data outside of this window. So, RTMP can deal with bandwidth issues, but only to a limited extent. 

 

What Is RTSP?

Real-Time Streaming Protocol (RTSP) is a protocol developed by RealNetworks in conjunction with Netscape and Columbia University back in 1996. It’s sometimes used as an umbrella term for RTP, RTCP, and RTSPS (aka Secure RTSP). 

RTSP was designed to establish and maintain a connection between the raw data source (client) and the streaming server. Additionally, it was designed to allow control of the entertainment and communication systems within a streaming server. This real-time media control allows for pause and play functionality.

This combination of reliability and control has long made it a popular choice for closed-circuit television (CCTV) and similar surveillance systems. As such, it’s the protocol of choice for many IP cameras, which has served to further its hold on this corner of the streaming market. 

 

RTSP Pros

What are the key benefits of the RTSP protocol? It has real-time media control, has very low latency, is customizable, and allows for segmented streaming. Let’s start at the top. 

Real Time Media Control 

It’s worth noting that RTSP doesn’t transport the data from the client to the server itself. It works as part of a larger system of protocols. RTSP’s job is to facilitate multimedia playback by defining specific control sequences. The actual data transport is usually left up to Real-Time Transport Protocol (RTP). 

The media control involved in this is nuanced and can come from either the client or the server end. Think of it as the remote control for streaming servers. The streamer themselves can manipulate the stream with play, pause, etc. even as they are recording. 

Very Low Latency

How low is very low? Think less than two seconds. It’s no WebRTC, but it gets the job done fast. For this reason, RTSP is commonly used for real-time security systems. 

Customizable 

RTSP offers greater flexibility in terms of the protocol it uses as its foundation. We mentioned earlier that RTMP sits on top of TCP. RTSP can use TCP as well, but it also works with User Datagram Protocol (UDP), which allows for additional functionality options.

Segmented Streaming

When paired with UDP, RTSP allows you to chunk your streams so viewers can start viewing them before the content is fully downloaded. This allows for very low-latency streaming, albeit the quality of video and audio can sometimes suffer. 

 

RTSP Cons

Like RTMP, RTSP is not HTTP-compatible. Other downsides to this ingest protocol include lack of support for broadcast over the internet and lack of optimization options.

Lack of Support

RTSP is very highly used and regarded in its specific corner of the streaming world: namely, closed and in-house private networks, especially through the use of IP cameras. However, it is not typically used for larger scale broadcasts or streams over the internet and is, therefore, not widely supported by encoders.

Lack of Optimization Options

RTSP is not really intended for your next live broadcast to thousands of viewers. It is not optimized for quality or scalability and requires additional workflow elements to achieve what other protocols might achieve more naturally. Like RTMP, RTSP requires a dedicated server, which limits scaling options.

 

RTMP vs. RTSP: FAQ

Which is Faster? RTMP or RTSP?

RTMP is reported to have a latency of around 2-5 seconds, which is considered very low. RTSP is comparable, with a latency of around 2 seconds flat. In this way, you could consider RTSP the “faster” protocol, but they are similar enough in that arena and different enough in other areas, that this shouldn’t be your deciding factor.

Which is More Secure? RTMP or RTSP?

The answer to this question is also somewhat debated as it really depends on what you are using the protocols for. RTSP, for example, does not support content encryption. However, if you are using it as part of a closed-network real-time security system, then you likely don’t content encryption in any case. RTMP is likely more secure from a general use perspective, like live streaming over the internet.

Can I Convert RTMP to RTSP and Vice Versa?

RTMP can be converted to RTSP using transcoding software like FFmpeg or VLC. As RTMP is no longer suitable for last-mile delivery, it’s not advisable to do the reverse. You can also convert RTMP to other types of egress protocols, like HLS. Which protocol you convert it to should be informed by your use case.

Can I Use Adaptive Bitrate Streaming with RTMP or RTSP?

Adaptive bitrate streaming (ABR) is possible with RTMP and RTSP if you transmux the files to an ABR friendly protocol like HLS for last-mile delivery. RTMP on its own is not suitable for ABR on as an ingest-only protocol. RTSP can be used for last-mile delivery but it not as part of an ABR-enabled workflow.

 

RTMP vs. RTSP: Which Is Right for You?

We tried to cover a lot of ground in this post, but the long of the short of it is this: RTMP and RTSP are both legacy protocols that are likely headed for obsolescence. That said, they’re integrated into so many existing workflows and architectures that it could be another 30 years before they completely disappear. 

They share many of the same limitations, including lack of compatibility with HTTP and HTML5 playback devices, a need for a dedicated server, and the general sense that we aren’t developing these technologies anymore – we are simply finding ways to work around them.

That said, there is still a time and place for each and which you choose depends on what you’re hoping to accomplish. After all, these protocols were designed for low latency and reliability. Ask yourself who you are trying to reach, if your stream is live or pre-recorded, if it is closed circuit or over the internet, and so on. Realistically, it shouldn’t be hard to determine which of these will best suit your workflow.

Once you’ve nailed that down, find a streaming solution that can help take your ingest protocol and make it work to your advantage.