Earlier this week Tsahi Levent-Levi wrote up a great post on how he thinks h.264 is the protocol of choice for WebRTC apps moving forward. There’s so much that’s true about what he wrote, and I tend to agree on almost every point he makes. h.264 is supported in hardware encoders for just about every mobile device out there, and with Microsoft supporting it and not VP9/VP8, it seems like an obvious choice. That, and I don’t think anyone in the world believes that Apple will pick anything other than h.264/AAC for WebRTC support.
HLS isn't the Answer
Tsahi also pointed out that h.264 was important for live streams because the best mode of delivery for a broadcast is over HLS which basically requires the use of h.264. This is true as it stands today, but what we are seeing is a trend away from HLS as a delivery protocol simply because of the high amount of latency it introduces. Our customers are looking for more interactive experiences, and we strongly believe that low latency will play an important part of future live streaming apps. For a write up on why HLS is so slow, read this post - (https://blog.red5pro.com/what-you-need-to-know-about-hls-pros-and-cons/).
So why is low latency important in a live streaming app? It all boils down to one word: Interactivity. See, people aren’t just using these new apps like watching TV where it’s a completely passive experience; instead, they are doing things like live text chat along with the stream and multiparty conference style broadcasts (like Blab). In order to have any of these interactions make sense, you can’t have the stream be delayed by 30 seconds. It just doesn’t work. There are also other unique apps people are making, like streaming apps for live auctions. You certainly can’t have people bidding on items which are 30 seconds behind because your live auction app is using HLS. “Sorry sir, you bought the replica Civil War era coin. But I bid on the Jackson Pollock painting!”
The Future is WebRTC
The new SDK won’t be limited to a player either. We will have a publisher component which prefers HLS first, but then falls back gracefully to Flash for realtime encoding from the browser’s camera on the device.