Thanks for sharing David!

Awesome! Yes, here’s my response on the Red5 Pro blog.

https://blog.red5pro.com/webrtc-the-delivery-protocol-for-live-streams-of-the-future/

Thanks Chris

While I am following the Red5 Pro blog, please comment here back again with a link to that piece once written 🙂

However regarding HLS, what we’ve been seeing with our customers is a move away from it as a delivery protocol simply because the high amount of latency it introduces. This ends up meaning that WebRTC is the preferred protocol for one to many delivery when you want to have interactive features that require low latency. Some examples of this are a live text chat along with the stream and multiparty conference style broadcasts (like Blab).

Our approach with the upcoming release of Red5 Pro (http://red5pro.com) is to provide a JavaScript SDK which has a series of fallbacks depending on the capabilities of the browser: first WebRTC, then RTMP/Flash, and finally if all others aren’t there, HLS. I will write up a blog post today on this, as I think it’s relevant to the conversation.

Thanks as always for your insights Tsahi!

https://twitter.com/HCornflower/status/736456618758574080 — even though I suspect that was a CPU issue.

I’ve seen bad quality in Chrome-Chrome/Firefox H264 calls while performing some of the https://github.com/fippo/testbed tests.
It will be very interesting to do some large-scale A/B testing obviousy 🙂

Fippo, as always – thanks for your insights – and you are of course correct 🙂

I disagree slightly. Mostly on the impact this has. Yes, this allows video calls between Edge and Firefox/Chrome. That turned out to be a no-brainer, took me less than a day between the announcement and actually running this. The impact will be a lot less than you’d expect.

First, there is a lot of calls using 1-1. For these and ignoring things like recording, codecs are negotiated. H264 will be the interop baseline. I do expect the majority of calls to continue to be using VP8, with VP9 ramping up slowly. How fast Edge interop is going to ramp here is a question, this also depends on Chrome unflagging H264 support.

Then there is multiparty. Just because H264 is the baseline all participants will support that does not mean the majority of your calls will be H264 either. Switching dynamically based on the best possible codec supported by everyone has been something at least I have worked on for quite a while now. Given the bugs i’ve reported in that area I seem to be the only person doing this however.

Advanced multiparty (read: simulcast) is a different beast. Despite the theory of SFUs being codec-agnostic, in reality you need to know _something_ about the codec. Like for example whether a packet contains a keyframe. Or the temporal layer. That requires some effort but then this is mostly about teaching your SFU those tricks and then doing them regardless of codec.