Microsoft Acquires Beam, Showing the Value of WebRTC to Interactive Live Streaming

Low latency is critical for interactive live streaming.

Microsoft acquired last week Beam, a company focused on a gamer interactive live streaming service.

According to CrunchBase, Beam has been around for almost 2 years before getting plucked by Microsoft. The investment in them has been smaller than 0.5M USD.

For some reason unknown to me, there are people who love watching other people play games. I guess it is similar to some extent to people sitting down to watch a soccer game. Another thing I can’t really understand. It is the reason why Twitch was acquire by Amazon for almost a billion dollar – a month prior to Beam’s founding.

What Beam worked on was a way to enable viewers to be a part of the game and up their engagement. You do this by allowing viewers to push feedback to the gamers – add challenges to them, buy virtual goods for them, etc. From Beam’s website:

We make it possible for streamers to involve viewers in their gameplay, no matter what game they’re playing.

Want to let your viewers choose your weapon, make quests for you, or even fly a drone around your room? You can do that, all in realtime. Our SDK allows developers to create interactive experiences for existing games with as few as 25 lines of code.

In the console world, there are two major players – Microsoft Xbox and Sony PlayStation. With the acquisition of Beam, Microsoft is trying to build an ecosystem of viewers around the gamers and games offered in Xbox. Will they share the SDK and platform with Sony? It is too soon to tell, especially now that Microsoft is opening up and trying to build large ecosystem around its services as opposed to its operating systems. It might just be that Microsoft is trying to become a big player in gaming in general – not just console ones but also mobile.

Back to Beam and video streaming.

To enable higher and richer interactions between viewers and gamers, and offer the kind of  that, latency higher than a second are detrimental. This makes HLS and MPEG-DASH protocols irrelevant. Flash is on its way out the window. The only other technology that can get to a sub-second latency for real time video streaming then is WebRTC.

WebRTC is exactly what Beam has been using in their “protocol” dubbed FTL. It used WebRTC to stream video to the viewers instead of the more traditional mechanism of Flash.

I have been a believer in WebRTC for live streaming and broadcast for over a year now. It is just another place where WebRTC makes a lot of sense, but it will take time for us to get there. The main reason for that is that current implementations are too focused on video chat scenarios – trying to leverage the WebRTC implementation found in Chrome and hooking it up to backend media servers that are again geared towards video chat use cases.

There are 4 different techniques that WebRTC can be leveraged in interactive live streaming (or streaming at all):

1. Use WebRTC’s data channel as a replacement for HTTP(S) to send video packets
   • Theoretically, this should be faster than HTTP and enables optimization to buffering
   • No one has taken that route yet as far as I can tell
2. Build a kind of P2P CDN on top of WebRTC’s data channel
   • Think BitTorrent inside the browser
   • Peer5 and a view other vendors are doing just that
3. Use WebRTC in its full glory – voice and video channels opened and streamed
   • Acquire the original live stream using WebRTC or some other mechanism, and then use WebRTC to connect the viewers via a VOD like architecture to the broadcast
   • Probably the most wasteful of all approached
   • And the one I am guessing Beam is currently employing
4. Optimize on (3) to offer something akin to a Flash/HLS streamer
   • Handle multiple bitrates and resolutions
   • Be able to get high density of streams in a single machine

Options (1) and (2) require knowledge of networking.

Option (2) requires knowledge of P2P networks.

Option (3) requires WebRTC knowledge at its basic level.

Option (4) means you practically implement a WebRTC stack of your own with a focus on live streaming.

My guess is that with time, we will see vendors implementing options (2) and (4) which will be the winning architectures for live streaming.

Option (2) will be deployed to support today’s use cases, while option (4) will be deployed to support future use cases, where interactivity between viewer and broadcaster are important.

Beam took the right challenge on itself. It got it acquired in a short timespan and in a way redefine live streaming and low latency.

For Microsoft, this is yet another acquisition in the WebRTC space, and another area in which it now relies on this technology – even without supporting it on IE.