The growth of Web real-time communications (WebRTC) has a lot of people wondering about other things that can be done with the software. Sure, the idea of being able to launch video chats right from a Web browser without the need for additional plug-ins makes a lot of sense, but surely it doesn't stop there.
Surely this isn't just a browser-based Skype clone!
That's got some looking at this in a whole new way, and for some more, the idea of using WebRTC as a medium for broadcasting multipoint video is one of the many new features WebRTC can offer.
Broadcasting multipoint video with WebRTC is a multistep process, but once it's set up, it allows for the ability to treat a browser like a broadcaster – a potentially useful tool.
First, start with a basic analysis of tools and components. Consider the camera, the video encoder, and what will be used to send packets over the network. While the first two points will take pretty much the same effort as P2P video, the packet-sending function will be increased based on how many endpoints are in mind for the intended broadcast. It's not likely to work well on home broadband, and mobile broadband is pretty much right out due to considerations of battery life and data plan life.
Thus, those broadcasting are going to need to focus on the server side of the solution, using the broadcast system to run through a transcoder, and then through a media server for standard solutions to pick up (Flash, iOS and HTML5, for examples) as well as a WebRTC “proxy” for the WebRTC recipients.
The server side operation allows for the creation of multiple separate media streams from the original media stream for each of the individual participants, though the execution on this point can be a problem if not addressed correctly. It also allows for extra versatility in reconciling the fact that different devices with different capabilities will be used to view the broadcast.
It's worthwhile to make the consideration for those users not using WebRTC clients, which will mean a second gateway function is necessary.
The key takeaway here is that broadcasting is going to be resource-intensive. Getting that kind of bandwidth together, backed up by the kind of hardware that would be required to perform this kind of task will be fairly difficult and fairly expensive. But it's still quite possible to do so, and the potential rewards are certainly worth considering.
The rise of WebRTC users likely to occur in the next few months – some are already calling 2013 the year of WebRTC – makes for an audience that's likely to be interested in content. That's hard to pass up, even with the intense barriers to entry represented by the resource and technical challenges involved.
Edited by
Braden Becker
