Don’t take this the wrong way; while we are thrilled about WebRTC and its potential to open up live streaming and communication within browsers, we want to pose the following question: do you actually need WebRTC for your use case? After much analysis, what we’ve found based on talking to our customers is that the answer nine times out of ten is no.
I know what you are thinking. Flash is dead: it’s a memory hog, it has terrible security flaws, and it’s an antiquated relic that should be banished from every browser on the planet. Yes, yes, much of this is undoubtedly true. Regardless of its obvious weaknesses, Flash is still a strong solution, and it can do the job that WebRTC does pretty much universally on desktops and laptops today. We originally built Red5 to integrate with Flash, and one of the most logical reasons we didn’t just start from scratch with Red5 Pro is that it still works great in this scenario. There’s a reason that solutions like video.js have a Flash fallback feature. Flash exists on these older browsers, it’s consistent, and it still works remarkably well considering its age.
Mobile publishing (meaning accessing the camera, encoding to a video format, and live streaming out) typically has to be done via native apps. This is especially true on iOS, as the Safari browser doesn’t support WebRTC today. The latest versions of Chrome on Android support WebRTC, and in a lot of cases it’s a viable way to implement live streaming. However, the most successful apps out there today are all native, such as Skype, Periscope and WhatsApp. In this regard, most of our customers feel it’s important to make a native app, and WebRTC doesn’t buy you anything if you have to implement it natively.
If you have the time and patience you can get the WebRTC project to compile and integrate on your mobile app, but most developers don’t want to be bothered with the complexities of integrating protocols at this level–they prefer a nice layer of abstraction using an easy-to -implement SDK. While there are excellent WebRTC based SDKs like TokBox, most developers don’t actually care what the underlying protocol is. In the end, they just want it to work.
We chose RTSP/RTP for our protocol within the Red5 Pro mobile SDKs as it’s both extremely fast and efficient. In addition, even after we’ve finished our current WebRTC implementation, which will be released in the Spring of 2016, we won’t be switching the protocol for the mobile endpoints. As an aside, if you study the WebRTC standard you will see that they actually use RTP as the base level protocol for the transport anyway.
What do you think? Do you really care what protocol your preferred streaming SDK is using under the covers, or do you just want it to work flawlessly? We would love to hear your feedback on this.
It also turns out that if you want to build an app that simply views live streams in a browser, then there are other ways to to do it. HLS, or HTTP Live Streaming has already become the standard streaming protocol on iOS devices, and there’s support for it on newer Android devices. I mentioned the video.js player, and there’s commercial ones like JWPlayer which support HLS as well.
On many Android devices, RTSP is a standard that can be relied upon as a way to consume live streams. With Red5 Pro we support both HLS and RTSP.
Not to Discount WebRTC
Clearly there’s a future in WebRTC, and as more browsers begin to support the standard and the protocols begin to be unified, we will see it become the go-to strategy for live streaming and live communication apps. We strongly believe in the future of WebRTC, and this is why we are working diligently on implementing WebRTC support in Red5 Pro. In the meantime though, there are many alternatives which work well, and for the foreseeable future we will still need these other protocols and platforms to work as fallbacks. Red5 Pro supports what you need today to get live streaming apps up and running for 90% of the use cases.
Let us know what you think. Are you currently using alternatives to WebRTC in your apps today? How much longer do you think solutions like Flash will stay relevant?