WebRTC vs. RTMP: Which Protocol Is Best for Your Video Deployment?
There are numerous streaming protocols out there that can help get your video assets from your source to your audience and all the stops in between. However, some are better suited to particular tasks than others, and it’s fortunately possible to use more than one thanks to the wonders of transcoding.
Two popular protocols you might be comparing include WebRTC vs. RTMP. You can think of Web Real-Time Communications (WebRTC) as the jack-of-all-trades up-and-comer whose name is gradually becoming ubiquitous, while the Real-Time Messaging Protocol (RTMP) is the former celebrity who was once everywhere but has since started approaching retirement — though is still widely recognized in certain circles. They both have their advantages and disadvantages, so when it comes to putting your content in front of viewers, what are the differences and similarities between them?
Table of Contents
What Is RTMP?
RTMP was once the industry’s go-to protocol for transporting video and audio data because it came hand-in-hand with Adobe Flash Player (Flash powered almost 98% of internet browsers back in the day, so RTMP was a big deal). Since Flash’s death, this once proprietary protocol has become an open specification that boasts low latency, minimal buffering, and high reliability.
But wait — wouldn’t Flash’s death have pulled RTMP down with it? Not necessarily, though it’s true RTMP has fallen out of favor for last-mile delivery because not many browsers, applications, or devices support it anymore. RTMP is also less popular because it struggles getting past firewalls and isn’t ideal for adaptive bitrate streaming.
What made RTMP great was its performance: It maintains a constant connection between servers and client players, creating a continuous pipeline that lets data flow from one end to the other. Plus, even though RTMP isn’t the best for delivering data to viewers’ screens anymore, many encoders still support it for ingest. Countless content creators and broadcasters now use RTMP for first-mile contribution and then repackage it to something else for the final stretch, including WebRTC or Apple HTTP Live Streaming (HLS).
You can dive deeper into RTMP with this blog post.
What Is WebRTC?
WebRTC isn’t just a protocol; it’s a combination of protocols, standards, and JavaScript APIs that enable real-time communication it’s named for. It takes advantage of browser peer-to-peer connections to deliver data with a latency as low as 500 milliseconds or less. Plus, WebRTC is open source, meaning a large community of developers have and continue to contribute to it.
WebRTC began as a Google project intended to support real-time video and audio communication without third-party plugins (like Flash). Even though it was originally a Google endeavor, WebRTC is not a proprietary framework but an open specification the IETF and W3C have since standardized. That’s where much of WebRTC’s appeal lies: you don’t need additional software or equipment because the framework leverages three HTML5 APIs that enable browsers to capture, encode, and transmit streams all on their own.
However, as we’ve stated, WebRTC was designed to support peer-to-peer connections. It’s excellent for click-to-start video chats (you’re likely familiar with several applications that use WebRTC whenever you have a meeting or virtual happy hour), but it’s not made to handle streaming to large audiences.
This blog takes an in-depth look into all things WebRTC.
WebRTC vs. RTMP
Now, let’s address the question of WebRTC vs. RTMP and why it’s important to consider them both.
Based on their above descriptions, you might be leaning toward WebRTC because it can be used for both first and last-mile delivery whereas RTMP is only useful for the first. It’s important not to discount RTMP right away, though; 76.8% of respondents to Wowza’s 2021 Video Streaming Latency Report indicated they still use RTMP for ingest, while 24.74% said they use WebRTC.
What Protocols Do You Use for First-Mile Contribution?
RTMP vs. WebRTC Latency
One of the reasons why we’re having the conversation of WebRTC vs. RTMP is because they’re comparable in terms of latency. WebRTC takes the cake at sub-500 milliseconds while RTMP is around five seconds (it competes more directly with protocols like Secure Reliable Transport (SRT) and Real-Time Streaming Protocol (RTSP), but other protocols such as Apple HLS and MPEG-DASH have much higher latency (as much as 30 seconds) without their respective low-latency extensions, Low-Latency HLS and low-latency CMAF for DASH.
Compatibility
You’ll likely face few issues with WebRTC compatibility. Most browsers, including the more popular ones like Firefox, Chrome, and Safari, support WebRTC. This makes it an excellent fit for applications like video chat (not to mention the fact that you don’t need any additional plugins the way you did with Flash). As such, it’s possible to use WebRTC for encoding and delivery, whereas not many viewer-side technologies support RTMP anymore. If you’re a content producer using a more powerful encoder, though, RTMP is still likely to work.
Scalability
As amazing as WebRTC is, scalability is the area where it struggles most. WebRTC leverages peer-to-peer browser connections and consumes a lot of bandwidth in the process. It’s fast, but you may start to experience problems with more than 50 people. Similarly, RTMP isn’t ideal for scale because it’s typically used for first-mile contribution but you can transcode it to something like HLS that can scale to millions of viewers.
There is a way to overcome WebRTC’s lack of scalability, though: with Wowza’s Real-Time Streaming at Scale feature, you can deploy WebRTC across Wowza Video’s custom CDN that enables you to stream to millions of viewers without sacrificing the protocol’s famous speed.
Security
Next, how secure are RTMP and WebRTC? In the former’s case, there are different variations called RTMPS (the “S” referring to an added security layer) and ERTMP (the “E” referring to additional encryption, which is actually a simpler version than RTMPS). RTMPS provides additional protection against unauthorized interception with SSL or TSL encryption.
WebRTC is secure because it mandates SRTP (Secure Real Time Protocol) encryption and a group of other standards (it is more than just a mere protocol, after all). The Internet Engineering Task Force, one of the organizations that helped standardize it, outright prohibits WebRTC connections without necessary encryption.
Besides being encrypted at the protocol level, WebRTC also leverages browser and community-supported security. Major browsers like Firefox, Chrome, Safari, and Edge all take WebRTC security seriously, so they require HTTPS to access the framework, users to grant permissions to individual sites before allowing camera and microphone access, IP leakage protections, and other privacy controls. As an open-source project, WebRTC’s community of developers also work together to ensure its security is of the highest caliber.
Ingestion vs. Delivery
Another key difference between WebRTC vs. RTMP is the portion of a streaming workflow you use it for. WebRTC is convenient for both: because it’s HTML5-based, all major browsers support it, so you can use it for initial encoding after video production all the way to delivery on the viewer’s side. RTMP was once useful for both but is now primarily for the first stretch: getting your video data from your encoder to a media server or streaming platform. Now, it’s best to use RTMP for first-mile contribution before transcoding it into another protocol that’s more widely supported and supports adaptive bitrate streaming.
It’s also important to note another of RTMP’s advantages: It’s better for functionality like ad markers, captions, and timed metadata. WebRTC is excellent if a browser is all you need, but if you want more control over your encoding settings, then RTMP might be the way to go.
For TL;DR’s sake, here’s a table to summarize things for you:
| WebRTC | RTMP | |
| UDP or TCP? | UDP | TCP |
| Compatibility and Support | Supported by most devices and browsers including Firefox, Chrome, and Safari without an additional plugin. | Primarily software and hardware encoders (and some social media platforms); no longer supported by Android, iOS, and most browsers or embeddable players. |
| Latency | 500 milliseconds or less | 5 seconds or less |
| Scalability | Not intended to reach large audiences without the help of a custom CDN, primarily for <50 viewers or participants. | Scalable to reach large audiences. |
| Security | Encryption is mandatory when using WebRTC. Security can also be enhanced with a streaming service or platform. | RTMP doesn’t automatically encrypt data, but it’s possible to add TSL or SSL security layers with RTMPE or RTMPS. |
| Use as Ingest Protocol | Desirable as an ingest protocol because it doesn’t require extra hardware or equipment. | Almost always used as an ingest protocol. |
| Use as Delivery Protocol | Excellent for last-mile delivery, ensuring glass-to-glass streaming. | No longer widely supported as a delivery protocol. |
WebRTC vs. RTMP With Wowza Video
If you’ve decided to use RTMP to encode your video, you can use the Wowza Video platform or Wowza Streaming Engine software to transcode it into another protocol before delivering it to your audience (such as HLS). Check out these tutorials to learn more:
If you’ve chosen WebRTC, you face a significant scalability problem if you want to stream to an audience greater than a few dozen people. Not to worry, though — Wowza’s Real-Time Streaming at Scale feature utilizes a custom CDN that allows you to scale WebRTC streams to audiences of up to a million viewers. WebRTC already includes a package of APIs and protocols, so Real-Time Streaming at Scale provides even more APIs and developer tools you can use to expand on WebRTC’s essential functions.
With Wowza Video or Wowza Streaming Engine, you can build whatever workflow you want to stream your videos to your audience as swiftly and reliably (and maybe even interactively) as possible.