Client-Side Architectures and WebRTC
Learn more about WebRTC at Streaming Media East.
See complete videos and other highlights from Streaming Media West Connect on Streaming Media's YouTube channel.
Read the complete transcript of this video:
Robert Reinhardt: Let's talk about client-side architecture issues that you might experience with WebRTC, that you didn't with other architectures. Like most of the legacy apps that I talked about, those cattle auctions, and wine auctions, they were all RTMP, which was TCP only. That was the only option we had. TCP can start to lag over time. It wasn't that RTMP didn't have its issues, but when it came to ports and access to firewalls, it was a simpler equation. I remember all those. How many of you remember those issues when RTMP first came out? When I was working at Schematic down in L.A., A big agency that did projects for Disney, ABC, and NBC, invariably, if anything was RTMP-based, some big-wig higher-up was behind some corporate firewall where RTMP wasn't coming through.
So, when they started to make the shift to HTTP streaming away from RTMP, that made a huge difference, because HTTP would pass through most firewalls. Unless they were doing packet introspection and looking at exactly what was coming over that port and that protocol, but WebRTC is a blend of TCP and UDP. UDP is going to give you the lowest latency. And if you don't have the proper TURN implementation, UDP can be problematic. If I'm on my cell phone and I'm behind some asymmetric net, then that could be problematic to be part of a WebRTC session that's in progress. But TURN servers help mitigate that. Some vendors don't have TURN support, though. And that's the problem. So you want to make sure that you do your due diligence.
Vendor lock-in: WebRTC is a specification that has no single correct implementation. And I'll talk about this in a moment. I'm actually going to be highlighting some work that Dr. Alex Gouailliard haseen doing with some traction to move to a more consistent implementation, at least from a client side point of view.
Adaptive bit rates--some browsers support simulcasts. And like I mentioned, already, VP8 SPC could be a future option. SVC in general, as a concept, could be an option. If we start to see that come out ... You have to remember that WebRTC stems from original P2P concepts. And so servers, if they were involved at all, were just the stunned servers to negotiate the IP and clients could talk over P2P directly with each other.
Serverless infrastructures--if that's a requirement, then you're only going to have so many options when it comes to trying to get quality out to someone that can't receive that high quality, what are you going to do? Uh, you know, If your P2P's only one on one, you've got more options there. But if you're having P2P sessions that involve more than one person, more than two parties, it can start to get complicated.
Camera and microphone access--this is just really more of a UX thing, but again, something you have to play, it's just like you would for a flash app. A lot of examples that you see out there that ship with WebRTC examples, you have to go into browser settings to change the camera and microphone. Of course you can expose it in JavaScript, but it's just something that you're going to need to give attention to. Selecting the camera, selecting the microphone, adjusting their properties.
Flash had its own learning curve. I'm not going to say WebRTC is any more difficult, but it is one of my complaints. I'm often working with my clients, web devs and--don't take this the wrong way if you're one of those--that expect there to always be an SDK. But I had to do plenty of dev where there weren't real SDKs where things were made easy. You had to build things from the ground up and ActionScript. You had to work with native classes and build out your own thing.
And I'll talk a little bit about that in the future. I find that's probably one of the biggest pain points whenever I'm working with web devs and WebRTC, is that capturing getting the media capture, getting all the parameters right with bitrate, frame rate. Getting those controls into place can be a big problem, only because it takes time. And if you're used to always having an SDK that makes things simple. And you're used to just, "Hey, I'm going to a web app developer. I know how to do this X, Y, and Z." And you started talking about media capture APIs with them. Then that's where special specialties will evolve, but if you need to hit the ground running and you don't have time to go through those learning curves, then that might influence your decision about how you're going to build your next WebRTC app.
Related Articles
Millicast Chief Revenue Officer Ryan Jespersen discusses how WebRTC reduces streaming latency in this clip from Streaming Media Connect 2022.
16 Mar 2022
Wowza's new ultra-low latency offering can deliver either an RTMP stream or a WebRTC stream, with WebRTC outperforming the legacy protocol
21 Oct 2021
Where and how does "real time" fit into your workflows in this "COVID and beyond" era? Similar to global wars accelerating advances in medicine such as plastic surgery, COVID has pushed all of us working in streaming media to rethink, innovate, optimise, and rebuild many components of our day-to-day responsibilities.
14 Oct 2021
VideoRx CTO Robert Reinhardt discusses how using various server-side architectures with WebRTC is like to play out, whether it's open course, commercial/licensed server, or cloud services, in this clip from Streaming Media West Connect.
23 Nov 2020
VideoRx CTO Robert Reinhardt discusses WebRTC's emergence as a low-latency option for one-to-many streaming, and the challenges of scaling it in this clip from his presentation at Streaming Media West Connect.
18 Nov 2020