RTMP Alternatives 2022

 

RTMP was once the standard for both media ingest and egress. These days, it continues to be the most popular ingest protocol. However, as the streaming protocol landscape keeps evolving, especially with the recent growth of WebRTC, it’s unclear how much longer developers will lean on it vs one of numerous RTMP alternatives. 

Regardless of whether RTMP is on its last legs, there are alternative ingest protocols that could be better suited to your streaming needs. These RTMP alternatives and some others that may be on the horizon are well worth a look as you optimize your streaming strategy. In this article, we’ll explore current alternatives to RTMP as an ingest protocol, the benefits of a two-protocol workflow, and what might be just around the corner. 

   

What Is RTMP

RTMP stands for Real-Time Messaging Protocol. It operates by maintaining a constant Transmission Control Protocol (TCP) connection between the player client and server. This TCP connection requires a client-server handshake, ensuring a stable connection and reliable stream. 

Brief History

Macromedia first developed this protocol back in 1996, intending it for the entirety of the streaming workflow: from contribution through delivery. Adobe then acquired Macromedia in 2005, putting it to work in their once ubiquitous Flash player. Finally, Adobe opened RTMP up as an open specification in 2012, and that’s when things really took off. 

For a long time after, RTMP was the end-to-end standard for live and on-demand streaming. However, HTTP-based protocols like HLS and MPEG-DASH eventually usurped it on the delivery side of things. Having never supported RTMP for playback, Apple devices essentially forced the issue, pushing people to use HLS in particular. Add to that Adobe’s announcement that they would no longer be supporting Flash, and browsers stopped supporting RTMP, effectively killing it for last-mile delivery. 

Understanding Ingest vs. Egress

Let’s take a step back. We’ve been throwing around a lot of terms like “last-mile” and “ingest,” but what does all of that really mean? To understand where RTMP is still useful and where it isn’t, you need to understand the difference between an ingest (first-mile) protocol and an egress (last-mile) protocol. 

In its simplest form, streaming takes media coming in at one location (like a webcam) and plays it back in another location (like a web browser). However, there are usually stops in between. Media servers and content delivery networks (CDNs) act as intermediaries, helping make streaming data more flexible, more secure, and farther reaching, among other things. 

Sometimes media streams use a certain protocol to get from the source to the media server (ingest) and a different protocol to get from the media server to the playback device(s) (egress). These are referred to as ingest protocols and egress protocols respectively. Sometimes they are the same protocol and sometimes not. 

RTMP is still widely used as an ingest protocol but defunct as an egress protocol, so if it is used at all, it must be part of a combined workflow that transmuxes the data before last-mile delivery. 

Pros and Cons

Given the above, when we talk about the pros and cons of RTMP, we are really talking about the pros and cons of RTMP as an ingest protocol, since the latter is no longer relevant. In considering the strengths and weaknesses of RTMP, remember that comparable streaming protocols face similar challenges. You’ll want to look closely at the comparisons that follow to know which protocol is best for you. 

Pros:

• Reliable – The three-way handshake makes for a more reliable connection.
• Flexible – RTMP works with more than just audio and video media and can effectively blend media types into a cohesive package. This includes embedded timed metadata widely used for ad markers, caption data, or any custom data.
• Fast – RTMP streams with just 3-5 seconds of latency.

Cons:

• Ingest only – Being HTTP incompatible means that RTMP is ingest only and using it at all requires the use of a video software or service to repackage the stream.
• Lack of support – Adobe is no longer updating or supporting RTMP despite its continued use.
• TCP latency and congestion – As a TCP-based protocol, RTMP will build latency over time on a poor connection due to congestion and packet retransmission.
• Limited Codec Support – RTMP is limited to older codecs like H.264 and VP8. It offers no support for new codecs like H.265 or AV1, which offer greatly increased encoding efficiency over H.264.

Why Transition Away

It’s very possible that RTMP could be around for quite a while longer. However, it’s a fact right now that it is not viable for last-mile delivery. Therefore, any stream that includes RTMP must utilize additional technology to repackage the stream. In other words, a media server must transmit or repackage the RTMP stream to a protocol suitable for delivery. This may complicate the streaming workflow and take longer, leading to greater latency. 

If that weren’t enough, it’s also a fact that new streaming protocols and related technologies are being developed all the time. They may not have the strong history of reliability that RTMP does, but unlike RTMP, they are actively being supported and improved on. Of course, RTMP has its strengths as well as weaknesses. Knowing if it’s the right fit for you comes down to asking the right questions.

   

Considerations When Choosing a Protocol

So how do you choose an ingest protocol for your stream? Note the following common considerations for live and on-demand streaming.

• Scalability – How many people are you streaming to? 
• Latency – How important is speed to your audience? 
• Quality – How important is quality to your goals? 
• Proprietary vs. Open Standards – How much freedom do you need to tailor your streaming solution? How much are you willing to invest? 
• Codec Requirements – Do you have any specific audio or video codec requirements that might limit the protocols available to you?

That said, the biggest indicator for which protocol(s) would best suit your needs comes down to your unique use case. As you read through the following RTMP alternatives, ask yourself: 

• Do I need real-time interactivity? 
• Do I need a high level of content protection? 
• Who is my audience? How large are they? 
• What platforms am I streaming to? 

 

Replacing RTMP With RTSP

Like RTMP, Real-Time Streaming Protocol (RTSP) is an older protocol that is used today for ingest only (if it’s used at all). RTSP is specifically used to facilitate highly secure low-latency streaming for IP cameras and similar systems. In other words, if surveillance is your goal, then RTSP may be a better ingest option for you. 

RTSP Pros and Cons 

Pros: 

• Highly secure
• Built into a great number of IP cameras
• Commonly supported for its specific use case

Cons: 

• Legacy protocol on its way out
• Not supported by Android or iOS, so typically used for ingest only 
• Not widely supported by encoders outside of its niche use

Best Use Cases for RTSP

Put simply, RTSP is at its best where IP cameras are involved. It is ubiquitous among IP cameras and therefore widely supported. If you are looking to stream within a security system utilizing IP cameras, there is really no better ingest protocol for you. 

Conclusion: How It Compares to RTMP

It’s quite honestly difficult to compare these two. RTSP and RTMP are best considered side by side rather than one over the other. They are both older protocols that have come to be used for ingest only, meaning that whichever you use for ingest, you’re in need of transmuxing to get your media the rest of the way. RTMP is more widely supported by encoders, making it a more generally applicable option, while RTSP is a more niche protocol.

 

Replacing RTMP With SRT

Secure Reliable Transport (SRT) is an open-source protocol designed to stream content quickly and reliably on often unpredictable public networks. At present, it too is typically used for ingest only. However, it is a newer protocol, and encoders and media servers have been expanding their support. In time, for certain use cases, SRT could be an effective end-to-end option. 

SRT Pros and Cons 

Pros: 

• Open source
• High quality / Low latency
• Codec agnostic
• Reliable in that it accounts for packet loss while maintaining low latency
• Provides end-to-end security with AES 128/256 encryption

Cons: 

• Not as widely supported by many playback devices
• Not well suited for playback to large audiences

Best Use Cases for SRT

SRT is designed for live streaming across unpredictable public networks. Therefore, it’s best streaming use cases take advantage of that. Interactive and large-scale broadcasts, like the 2020 virtual NFL draft, uniquely benefit from this sort of technology.

Conclusion: How It Compares to RTMP

Both streaming protocols are notably fast, reliable, and secure. That said, SRT is faster than RTMP and more effectively addresses packet loss as a protocol that’s specifically designed for delivering on less reliable networks while maintaining low latency. SRT is a newer technology that is still being developed and for which support is growing on both the ingest and egress sides. In other words, it’s not as widely supported as RTMP by encoders but that could easily change.

 

Replacing RTMP With WebRTC

Web Real-Time Communications (WebRTC) is a collection of protocols, standards, and JavaScript APIs that work together to provide ultra-low latency streaming. That said, it is frequently referred to as a “streaming protocol” and compared to others like RTMP. WebRTC works for both ingest and egress, but is most often used for the latter. For the purposes of this comparison, we’ll be focusing on WebRTC as an ingest protocol. 

WebRTC Pros and Cons 

Pros:

• Ultra-low latency (sub-second)
• Open source
• Continually evolving its capabilities and support
• Highly flexible 
• Allows for simple browser-based publishing without requiring an encoder
• WebRTC simulcasting promotes stream quality

Cons:

• Not very scalable at its core
• Less secure 
• Not capable of adaptive bitrate streaming (ABR)
• Not compatible with digital rights management (DRM) providers

Best Use Cases for WebRTC

WebRTC’s number one selling point is its sub-second latency, making it an ideal choice for interactive streaming that relies on near real-time experience. That said, its limited scalability gets in the way of many such cases, so a more complex workflow may be required to adapt it to larger audiences. 

Conclusion: How It Compares to RTMP

For a while, WebRTC was really lacking on the ingest side of things, and a RTMP to WebRTC workflow is still much more effective than an end-to-end WebRTC workflow. However, its viability as an ingest protocol has been changing in recent years thanks to increasingly better browser support, making it a more competitive alternative to RTMP. Like SRT, it’s continuing to be developed, meaning it may continue to replace legacy protocols like RTMP and RTSP in various workflows.

Highlight on WHIP

Milicast developed WebRTC HTTP Ingest Protocol (WHIP) in response to challenges with WebRTC ingest. For a while, WebRTC only worked with browser-based publishing, making WebRTC ingest via a professional encoder impossible. Although more professional encoders are now supporting WebRTC, WHIP is still a popular method for implementing WebRTC ingest. It provides encoding software and hardware with a standard signaling protocol when talking to media servers, thus enabling WebRTC ingest across vendors. Additionally, WHIP enables ingesting WebRTC directly, retaining its latency advantages over RTMP, while removing any connectivity barriers between encoders and media servers.

 

Replacing RTMP With RIST

Reliable Internet Stream Transport (RIST) is an open-source and open standard protocol specifically designed for transporting data across unpredictable public networks. Sound familiar? That’s because RIST promises essentially the same thing as SRT and was, in fact, intended as its successor. Although both RIST and SRT are still evolving and offer very similar functionality, RIST seems to have a slight edge on SRT in terms of compatibility with older devices and a bit higher tolerance for packet loss. 

RIST Pros and Cons 

Pros

• Open source and open standard
• Low latency / High quality 
• Highly reliable on lossy networks
• Supports end-to-end encryption including DTLS

Cons

• Less encoder and media server support than SRT
• Not widely supported by many playback devices
• Not well suited for playback to large audiences

Best Use Cases for RIST

As an answer to SRT, RIST’s use cases are similar. It helps your media navigate unpredictable networks, most notably the internet. Its speed and quality make it a viable option for live streaming to multiple platforms (simulcasting).

Conclusion: How It Compares to RTMP

Honestly, it makes more sense to compare RIST to SRT given they have compatible aims. The bigger question is whether either of these protocols is a better fit for you than RTMP and, if so, then you can worry about which. As with SRT, the questions really come down to “are you streaming across a lossy network?” and “are you worried about packet loss?”

Highlight on Zixi

Zixi’s RIST implementation lacks the benefits afforded by being open source, namely the flexibility that comes with not being beholden to a specific vendor. Zixi is, in fact, one of many commercial vendors that support RIST, including VideoFlow and QVidium. That said, there’s a place for commercial protocols with those looking for something more functional right out of the gate as opposed to building a ground-up solution.

 

Common RTMP Workflows

Despite lack of support, RTMP is still a viable (and widely used) ingest protocol for a wide range of streaming use cases. That said, an ingest-only protocol must be paired with an egress protocol for delivery to end users. Here are some popular workflows using RTMP at ingest and what sets them apart. 

Which streaming formats are you currently using for delivery?

RTMP to WebRTC

RTMP to WebRTC is a popular workflow for those who want to take advantage of WebRTC’s ultra-low latency but lacking an encoder that supports WebRTC ingest. With this workflow, you can easily capture a raw media stream, encode them with RTMP, and send them to a media server to be transcoded and transmuxed (changed to WebRTC). In short, it’s a straightforward way to get the best of both worlds: easy capture and real-time delivery. Wowza’s own Real-Time Streaming at Scale supports this workflow, providing ultra-low latency to a wide audience.

RTMP to HLS/DASH

The RTMP to Apple HLS workflow maximizes compatibility across the board while still supporting quality and (more or less) speed. After all, HLS is the most widely compatible egress protocol, making it ideal for anyone wanting to reach viewers across a range of playback devices. HTTP-based protocols are also more easily scaled to a larger audience via a CDN. Finally, HLS and DASH both support DRM, captions, and ad insertion.

Highlight on HESP

High Efficiency Streaming Protocol (HESP) was developed by THEO technologies for ultra-low latency streaming over an HTTP-based protocol that is compatible with most CDNs. This is worth an honorable mention here as it is considered a hybrid option between HLS and DASH but is still being developed. THEO has created an open recommendation for it and is working to get it standardized. It’s possible another HTTP-based contender is right around the corner. 

   

The Future of RTMP and Emerging Technologies

Speaking of technology that’s right around the corner, we want to wrap up this discussion of the future of RTMP with an exploration of some of the most recently announced streaming protocols. In some ways, the presence of these emerging protocols reaffirms our trust in RTMP as a technology that has stood the test of time. On the other hand, new innovations invite new opportunities. Let’s take a brief peek. 

Introducing RUSH

Reliable (unreliable) streaming protocol (RUSH) is an application-level ingest-only protocol for live streaming video. This newer protocol is most notably being implemented by Facebook as a (sort of) replacement for RTMP. Although realistically, it doesn’t replace RTMP. It’s rather something that would be implemented on the media encoder. Rush runs on top of Quick UDP Internet Connections (QUIC). It’s notable that this is contrast to RTMP, which utilizes a TCP connection.  

Introducing Warp

Just as Facebook is turning to RUSH, Twitch is turning to Warp. Warp transports segmented live video data over QUIC, making it similar to RUSH. However, unlike RUSH, it works for both ingest and egress. In this way, it’s not only seeking to replace RTMP but also HLS/DASH. Warp seeks to prioritize essential media segments when necessary to minimize latency. This technology is still being developed with open-standard specifications likely a few years away. 

Introducing Media over QUIC

While both RUSH and Warp use QUIC when delivering data, they are not to be confused with Media over QUIC (moq). This specifically refers to a IETF proposal to develop a simple low-latency media delivery solution for ingest and distribution of media using QUIC and potentially WebTransport. Some combination of Media over QUIC, WebTransport and WebCodecs may be a viable way to replace WebRTC or potentially even become the next generation of HLS or DASH but it still has a ways to go. 

 

Conclusion: Ask the Right Questions

The streaming protocol landscape is, in a word, vast. By the time you get caught up with one set of options a whole new set is ready to take its place. It’s possible this makes RTMP a comfortable solution. After all, we know it works. However, if you really want to get the most out of your streaming solution, then you’d be better served to seek some guidance on what’s current, what’s being phased out, and what’s just around the corner. This starts with defining your goals, asking the right questions as you determine your needs, and finding a streaming partner you trust to help you along the way.