What is an RTMP Stream and Why Use It?

History

RTMP (Real-Time Messaging Protocol) is an application-level video streaming protocol originally developed by Macromedia and now owned by Adobe. With a long history in the media streaming market, RTMP was originally designed for delivering on-demand media and live media (i.e live audio, video, and data) over the Internet between a Flash player and a Media Server. Without Flash, we more than likely wouldn’t have low-latency video communication through WebRTC, nor would Internet video protocols like HLS and MPEG-DASH be so prevalent.

Flash Player was the dominant usage of RTMP for a long time. At one point, Flash was arguably the most downloaded and widely distributed piece of software in the world, and its impact has been felt everywhere we look. Back in its heyday, the Flash coalition was an informal group of tinkerers, hackers, artists, and extremely collaborative people who saw the possibilities in a tool originally designed for simple animations on the Web.

In 2005, an expert team of developers from across the world (including the founders of our company) created the Open Source Red5 software by reverse engineering RTMP as an alternative to Adobe’s expensive Flash Communication Server. Many of those same developers still work for us today.

Current Use

Despite the earlier dominance of Flash streaming, it has been steadily declining in usefulness for years. Browsers continue to disable plugins altogether and in fact, 2020 marks the last year that Adobe will officially support Flash.

However, that does not mean that RTMP has completely gone away.  Due in part to its widespread use in the past, the fact you can still get, and the flexibility of the protocol, RTMP is still used as an ingest protocol by Facebook Live, YouTube and, most noticeably, Twitch.

However, these platforms including Wowza still have a higher amount of latency (1-2 seconds at the very lowest) due to how they have implemented the RTMP protocol. Red5 has always been able to achieve sub-second round trip latency using RTMP due to our more efficient implementation of the protocol.

Future

Despite the current use by large companies, RTMP has disadvantages as well. It has trouble dealing with poor network conditions and low bandwidth may cause interruptions in media streaming. It does not have the adaptability of other UDP based protocols such as SRT and WebRTC.

Most importantly, RTMP depended upon Flash for display in browsers. Now that Flash is quickly approaching its end of life, this is a big problem for trying to stream to browsers. Flash also had the ability to access camera and microphones to publish an RTMP stream to a media server.

So without Flash, what are the alternatives? Let’s break this down into two categories: ingest and egress.

Ingest

As mentioned earlier, SRT (Secure Reliable Transport) is an option for ingesting live streams. According to the SRT Alliance, “SRT is an open source video transport protocol and technology stack that optimizes streaming performance across unpredictable networks with secure streams and easy firewall traversal, bringing the best quality live video over the worst networks.” In other words, it sends best-quality videos over bad networks by accounting for jitter, packet loss, and fluctuating bandwidth.

However, browsers do not support SRT. SRT was originally designed for hardware encoders and is quickly being adopted by manufacturers led by Haivision, the original creator of the protocol. In the future,  it will be interesting to see what happens to SRT and whether the Web Standards groups want to adopt it. For now, there’s another alternative.

WebRTC, which does work in the browser, and its tech stack allows for accessing cameras and microphones on devices. It uses an efficient UDP based transport known as SRTP, and as we’ve mentioned many times before, is also a good transport protocol to ingest live video with the lowest latency currently possible. It can also still maintain a high-quality video, even in less than ideal network conditions.

In short, there are two replacements for RTMP; SRT for hardware encoders, and WebRTC for browsers.

Egress

Not only does WebRTC work for publishing streams, but it works for receiving video (egress) as well. Part of its low latency capabilities comes from the fact that WebRTC works natively in the browsers. This capability also means you can connect to an egress WebRTC server and consume a video stream over SRTP where it’s rendered in the browser. All the decoding is performed directly in native code as opposed to other protocols such as MSE which rely on Javascript to translate and display the data on the stream, which means even faster performance and better latency.

Furthermore, as covered in other blog posts, WebRTC works much better as compared to other HTTP based streaming protocols such as HLS or MPEG DASH.

On a final note, it might not be completely over for RTMP. Sarah Allen (no relation to our CEO Chris Allen) is currently working on RTMP 2.0. Here is a video where she discusses the history of RTMP, where we are now and where it may be going.

By using WebRTC, Red5 Pro supports streams with under 500 milliseconds of latency. Through our autoscaling solution, it is also fully scalable to millions of concurrent connections. Take a look for yourself, or contact us by sending an email to info@red5.net or scheduling a call. We’d love to show you what Red5 can do!