Using WebRTC as an RTMP AlternativeOctober 8, 2021
Last year, Adobe Flash Player finally died. While the cut-off date was years in the making and very much expected, it had impacts on a key technology in many streaming workflows: the Real-Time Messaging Protocol (RTMP).
RTMP was initially designed for the transmission of audio, video, and other data to Adobe Flash Player. And in its heyday, RTMP was the primary technology for transporting video over the internet. It could be used from end to end and ensured quick live delivery. Today, however, fewer devices and browsers support it than ever before.
While RTMP will remain a reliable mechanism for transporting video between encoders and servers, the same cannot be said for RTMP-based playback. And in Adobe’s own words, broadcasters are encouraged “to migrate any existing Flash content to… new open formats.”
In an issue of Streaming Media magazine early last year, Robert Reinhard cautioned, “If you’re using Flash for low-latency real-time streaming, you’ve got about a year or less to try moving over to a WebRTC solution. And what does that mean exactly? Any code you’re using on your Flash-based media server (Adobe Media Systems, Wowza Streaming Engine, and so on) needs to migrate to WebRTC instead of Real-Time Messaging Protocol (RTMP)”
And yet, many content distributors are still struggling to replace RTMP with a real-time format for video playback. Why? Well, both HLS and MPEG-DASH support high-quality streaming to a variety of devices, but 30+ second latency comes standard with these HTTP-based technologies. Low-latency extensions of these protocols exist (Low-Latency HLS and low-latency CMAF for DASH), but neither achieve the sub-second delivery speed that many are after. Plus, support for Low-Latency HLS and low-latency CMAF for DASH in players, content delivery networks (CDNs), and devices is still in the early stages.
For real-time streaming, Web Real-Time Communication (WebRTC) is your only option, which is why it’s attracted a lot of attention in recent years. The HTML5-based technology offers the quickest method for transporting live video across the internet. What’s more, like RTMP in its prime, it can be used end to end.
But WebRTC isn’t without its limitations. The protocol was designed for browser-based encoding and small-scale streaming, both of which don’t jive well with some broadcasting scenarios.
Sure, it’s a popular buzzword among developers — but is WebRTC the best solution for replacing RTMP? As I’ll explain, it all depends on the technologies you’re using to support deployment and what you’re trying to achieve.
RTMP vs. WebRTC: A Comparison
WebRTC delivers several advantages over RTMP. For one, it’s a new and open-source technology that’s also standardized by the IETF and W3C. All major browsers support WebRTC without requiring a plug-in, eliminating the interoperability challenges that come with proprietary streaming technologies. Plus, it benefits from a community of software developers contributing to its ongoing development.
Secondly, at sub-500-millisecond delivery speed, WebRTC is the lowest latency protocol out there. This makes it a go-to solution for creating interactive video experiences ranging from real-time auctions to live commerce, and also an attractive option for live sports broadcasters looking for an edge on their competitors.
Large-scale broadcasting to numerous viewers, however, has always been an issue with WebRTC. The video chat framework simply wasn’t designed to scale. Luckily, we’ve developed a solution to overcome this limitation — which I talk about in detail below.
On the video contribution side, WebRTC enables simple broadcasting using only a web browser — but for broadcasters hoping to control their encoding settings with a hardware or software solution, browser-based encoding isn’t ideal. Likewise, RTMP has a leg up on WebRTC when it comes to using timed metadata for functionality like captions and ad markers.
So, where exactly can RTMP be swapped out for WebRTC when it comes to live video streaming? As an end-to-end technology, it’s possible to use WebRTC for ingest, egress, or both. Here’s a look at the benefits on either end of the workflow, and how it can be used from encoding through delivery — without sacrificing scale.
Replacing RTMP With WebRTC for Ingest
RTMP remains the standard for first-mile video contribution. And there are several reasons for this. For one, it’s widely supported by live encoding software and hardware. It’s also accepted by many social media platforms.
Encoding vendors have begun adding support for open-source protocols like SRT, but WebRTC has previously been restricted to browser-based publishing. For anyone looking to broadcast directly from their browser using only their webcam and microphone, this worked great. But for content distributors wanting to stream produced live content with a professional encoder, WebRTC ingest wasn’t an option.
And so, the team at Milicast designed the WebRTC HTTP Ingest Protocol (WHIP) to overcome this obstacle. WHIP provides encoding software and hardware with a standard signaling protocol when talking to media servers, thus enabling WebRTC ingest across vendors. WHIP enables ingesting WebRTC directly, retaining its latency advantages over RTMP, while removing any connectivity barriers between encoders and media servers.
When used for ingest, WebRTC ensures low latency, mandatory encryption, and offers support for advanced codecs like Opus and VP9. It’s also becoming a viable format for hardware and software encoding thanks to WHIP. For broadcast workflows that require fine-tune control over encoding settings (including bitrate, codecs, and codec parameters), this will allow WebRTC to compete directly with RTMP.
Replacing RTMP With WebRTC for Egress
RTMP is no longer supported by browsers, rendering it dead on the playback side. Most broadcasters today use HLS for last-mile delivery, but 30+ seconds of latency comes standard when using it.
When it comes to low-latency alternatives, WebRTC is the speediest of the bunch. For that reason, if you need true interactivity — and we’re talking sub-one-second video delivery for scenarios like emergency response and remote monitoring — then WebRTC is your best bet. Low-Latency HLS and low-latency CMAF for DASH are also good options, but they can’t achieve the same real-time delivery as WebRTC.
That said, WebRTC wasn’t designed for broadcasting at scale. We used to encourage content distributors to instead leverage tuned HLS or Low-Latency HLS when broadcasting interactive content to large audiences, but we’ve evolved our offering to address this obstacle.
Specifically, we developed a new feature that deploys WebRTC across a custom CDN to provide near-limitless scale. The solution, Real-Time Streaming at Scale for Wowza Streaming Cloud, ensures sub-second delivery to viral audiences across the globe.
As illustrated in the diagram, when delivered in this manner, WebRTC playback can be used in a wide range of workflows, including WebRTC end-to-end or RTMP to WebRTC.
Considerations When Implementing WebRTC
If you’re considering using WebRTC as an RTMP replacement, take the following questions into account:
1. Do you require two-way video or real-time interactivity?
Interactive live streaming solutions and WebRTC go together like peanut butter and jelly. As long as you’re using WebRTC for both publishing and playback, sub-500ms streaming is achievable. What’s more, use cases comfortable with sub-second streaming can leverage a RTMP to WebRTC workflow. Hybrid models also exist, where interactive participants view the WebRTC stream and passive viewers are served a higher-latency stream delivered via HLS.
2. Do you expect to go viral?
All content distributors hope their streaming applications will become a huge success, with thousands or even millions of viewers watching. However, that many users can easily overwhelm your infrastructure. Traditional WebRTC deployments are limited in their ability to scale without leveraging a custom-built CDN like what our Real-Time Streaming at Scale feature offers. So be sure that you have the right infrastructure in place if your goal is to reach large audiences.
Because WebRTC was designed for video chat applications, two major barriers have stood in the way of its adoption in live broadcasting workflows:
- Limitations of browser-based encoding, and the lack of WebRTC capability in encoding software and hardware.
- Challenges with scalability, which made WebRTC difficult to use when broadcasting to thousands of viewers or more.
Luckily, the industry has come up with workarounds for both issues, making WebRTC a powerful alternative to RTMP on both the ingest and playback side.
In our 2021 Video Streaming Latency Report, we found that WebRTC is now the second most popular format for ingest and the third most popular for delivery. I expect that adoption will continue to grow given the work that vendors have put into improving WebRTC usability for live video broadcasting.
To learn more about WebRTC streaming with Wowza, don’t hesitate to contact us today.