The Problem with WebRTC
Anyone who’s had to move a media catalog from one vendor’s platform to another's knows the frustration and time involved with repeating an entire process of content aggregation all over again. It’s a little like moving all of your stuff from one house to another—some pieces move right over, but sometimes the entire layout is different and things sit in boxes for a long time.
For those of us in the real-time audio/video space, building WebRTC solutions can be just as frustrating, particularly as your business and technical requirements grow. My business has helped more than a few clients move from one WebRTC offering to another, and each process has had different struggles despite the core constructs being fairly identical:
- Camera/microphone capture
- Intelligent connection logic (P2P, SFU, MCU)
- Efficient transcoding handling (VPx to H.264, Opus to AAC, etc)
- Archiving/replay
- Muxing to other non-WebRTC formats (HLS, SRT, etc)
While this list is by no means exhaustive, they’re likely requirements you’ll have any WebRTC or real-time, low-latency streaming needs. And for the frustrating part: You won’t likely find all of these requirements fulfilled by any WebRTC server or cloud product, and if you do, you’ll very likely be using a very specific client-side software development kit (SDK) for each client target (e.g. Web/JavaScript, iOS, and Android). Particularly on the web/JavaScript side, due to differences in how Chrome, Firefox, Safari, and Edge have implemented WebRTC, these client SDKs are critical to reducing overall development time on a WebRTC project. So, regardless of which WebRTC road you go down, you’ll have to backtrack and go down another vendor’s WebRTC road whenever you need to move from one WebRTC vendor to another. You might get lucky and find a bridge to the new road during the backtracking. But one thing is for certain: The client-side SDK for the next WebRTC vendor you choose won’t match the SDK from your prior vendor, even among open source offerings.
Now, of course, I’ll need to bring a Flash anecdote into this subject, in an effort to find a comparable situation that presented itself in prior periods of streaming history. Flash didn’t have a built-in video player; you couldn’t just pass a video URL to a Flash SWF and have it start playing directly from the Flash Player plugin. Specific code had to be written and compiled into the Flash SWF file to play and manage the video stream. There was no built-in play/pause button—all of that had to be built. Enter JWPlayer, FlowPlayer, and any other business that launched from that space. Adobe acknowledged the growing frustration that there was no easy way to add a video player to a Flash project. So, they started the Open Source Media Framework (OSMF) project and made code freely available to anyone wanting to add video into their Flash project. That simplified things, especially for software devs that weren’t video experts as well. You could use OSMF to play video from a wide range of streaming providers, and those providers could write custom add-ons or plugins to OSMF to extend its capabilities. Akamai, for example, wrote plug-ins for OSMF to enable features available on their CDN.
So how does this relate to WebRTC? As I mentioned earlier, each WebRTC vendor will have different client-side SDKs that will require you (or your software development team) to refactor a lot of code to work with the new SDK. Updates across your target destinations (web, Android, iOS) will need to happen. Wouldn’t it be nice if those updates were fairly minimal, and not expensive from a resource management perspective? As Lemony Snicket might have said, I wish this was the part of the story where I was about to now tell you about the Open Source WebRTC Framework, but I’m sad to say that the Baudelaire ophans will have no such gift awaiting them.
My call right now and right here is for the WebRTC titans of industry to formulate an open source WebRTC framework, library, whatever you want to call it, and adopt it with their server-side counterparts. It could even be a marketing sales point: “Our product is compatible with the version 1.0 of the WebRTC Open Framework” (my made up name of course). Now, there are already community-driven open source code repositories available designed specifically to make WebRTC implementation easier for client-side developers. But they’re all relatively new and have a long way to go to be compatible with different vendor offerings. We need faster progress with viable WebRTC SDKs that don’t tightly tie products to a particular WebRTC server offering.
I’ll end on a happier note. The good news is that we have finally gotten to a point where desktop and mobile web browsers have aligned in their capabilities to consistently use WebRTC as a core technology for real-time web apps or progressive web apps (PWAs). This means that you won’t need to use a specific browser to enable your tech—or at least you shouldn’t have to if your client-side SDKs support all of them.
Related Articles
Look beyond the hype and the monkeys. NFTs, blockchain, and other elements of the new decentralized web—Web3—have serious implications for video creators and publishers.
17 Jun 2022
Teltoo's real-time analytics and WebRTC-enabled P2P gives Haivision an end-to-end low latency ecosystem
09 Jul 2020
CosMo Software Consulting Founder & CEO Dr. Alex Gouaillard rolls out predictions for WebRTC technology in 2020 in this clip from his Video Engineering Summit presentation at Streaming Media East 2019.
04 Nov 2019
CosMo Software Consulting Founder & CEO Dr. Alex Gouaillard discusses the non-realtimeness of WebRTC encoders and how Netflix and others compensate on the decoding end in this clip from his Video Engineering Summit presentation at Streaming Media East 2019.
28 Oct 2019