Using WebRTC as a Replacement for RTMP (Video Series: Part 2)May 30, 2018
While RTMP is still a reliable way to provide low-latency delivery for voice chat and other use cases, its long-term phase-out has begun—and businesses are seeking alternatives. WebRTC has become one of the more popular options in recent years. As an HTML5-based solution, it doesn’t require browser plug-ins for playback support, and can leverage peering techniques for data transfer between connected sessions.
However, WebRTC isn’t without implementation difficulties. Sure, it’s a popular buzzword among developers—but is it the best solution for your use case?
In part one of our four-part video series on low-latency streaming, we covered what low latency means, and what types of streaming use cases require it. In part two, we talk about the available options for replacing RTMP delivery:
Four Questions to Ask Before Implementing WebRTC
If you’re considering using WebRTC as an RTMP replacement, ask yourself these questions first:
1. Do you require two-way video or real-time interactivity?
Interactive and chat use cases should be very possible with WebRTC. As long as you are using WebRTC for your publish and playback, latency should be < .5 seconds in good network conditions, facilitating real-time interactions. If you would like to delay the playback time, or try to synchronize playback across multiple devices, you may want to capture with WebRTC, but use HTTP Live Streaming (HLS) for playback, using metadata and timecode to control the time you want referenced from playback.
2. Do you expect to go viral?
All developers hope their streaming applications will become a huge success, with thousands or even millions of viewers watching. However, with that many users comes a big scalability question. Currently, WebRTC is very limited in its ability to scale past a few thousand instances without a vast (and expensive) network of live-repeating servers that can handle the load. Because WebRTC utilizes peering networks, there still has to be a nearby node to help distribute the stream to other local hosts—and peering across a global network can be incredibly difficult.
3. Do you need broadcast-quality streams?
Today, you can’t reliably stream broadcast-quality video through a WebRTC infrastructure. The WebRTC protocol is currently limited to supporting VP8 and .H264 video—which means larger file sizes will bog down the network, not to mention burn up processors when ingesting and attempting to send a large file in its entirety. To support 4K or broadcast-quality 1080p60 resolutions, you’ll need to be able to transcode for playback on a variety of devices, while sending the highest-quality source to your transcoder.
4. Do you need an app today, or one that will last long term?
Maybe you’re considering using WebRTC because it’s trendy, or because you think you can develop an app on it faster. If that’s the case, first investigate whether it’s really the best solution for you in the long run, versus just being the fastest to develop upon.
If scale is a concern, then you should definitely look at alternative protocols. RTMP is still a viable option that now requires custom players with the death of Adobe Flash. SRT is great for traversing the public internet and degraded or congested networks. And Wowza also provides several alternatives for low-latency workflows that can support broadcast-quality streaming.
Wowza continues to support WebRTC, and has built a number of features within Wowza Streaming Engine to help mitigate some of the concerns. To see it’s the right fit for you, request access today and learn how it can power your low-latency project.