VP8 and H.264 codecs are mandatory to implement to be webrtc compliant. Simulcast is a way to use multiple encoders at a time to provide different resolutions of the same media to chose from as a way to adapt to bandwidth fluctuations (and other good things). Unfortunately, while some patches were proposed some two years ago by some including HighFive, libwebrtc did not implement support for simulcast with the H.264 codec. H.264 was then a de-facto secondary codec, and Safari which only supported H.264, could not achieve the same level of adaptation (or quality) than VP8 and some other browsers could. This blog gives more details about the epic journey to get that done, the design of the implementation, and the impact for WebRTC products.
Such is the title of one of the latest blog post by wowza. While it is a very interesting question, I believe the blog post is conveying the cliche the streaming ecosystem as been carrying about WebRTC and that are not longer true. I do not believe wowza to be knowingly deceiving people, i see their point, I just believe that recent advances in the webrtc protocols make most of their statements inaccurate. This post is an attempt to document the statements that can be proven wrong today. Fact-checking in some way.
Since our “Real-time communication testing evolution with WebRTC 1.0” article was accepted for publication by IEEE, not many new scientific papers have been published on WebRTC testing apart from  and  ( is also available, but without indication wether it has been peer-reviewed and accepted for publication or not), but a lot has happen with KITE.
Beyond being the official testing tool for webrtc.org, and adding tests for multistream and simulcast to better cover the last pieces of the WebRTC 1.0 spec, support for mobile browsers and mobile app testing, as well as for Electron apps testing have been added. KITE can now support up to 20 clients configurations, making it the most complete and most versatile #webrtc testing tool known to date.
Beyond the Interoperability Mode, a Load Testing mode has been added to KITE, specifically to stress test webrtc servers and infrastructures, with a capacity of 1 millions users. It has been tested in production by several customers in a one-to-many streaming environment.
Of course, you can have CoSMo run KITE for you (hosted and managed), or you can run it yourself, on premises. More details in this Post.
In their latest blog post, Wowza is doing a great job at explaining in simple words latency, and the use cases that could benefit for having under 500ms, a.k.a. “real-time”, latency. However, the section about streaming protocol is somehow confusing me. This blog post is an attempt to put those protocols back into perspective to have a fair comparison.
Which codec, and which flavours of codecs are supported by which browsers. This is a tricky question for every product manager that wants to define product expectations and roadmap. Should I support only VP8 / H264 ? Should I wait for VP9? What is multi-stream, simulcast, and SVC versions of those codecs? Beyond all those questions really is: when can I tell my customers I support Desktops browsers, Android, iOS? If I can’t should I have a native app instead. This blog post aims at putting everything back in perspective.
I used to be very entertained by stories given by different webrtc consultants. The “Cat roulette” example by L. Barr last year during a conference in Miami was exhilarating. I was thinking: those guys have all the fun!
What people don’t tell you when you go into that business is the wide variety of clients you end-up facing. Now that I am on the other side of the fence, the grass is not exactly greener. In an effort to give people a glance of how hard it can be sometimes, and to keep my mental sanity by letting it out, I’m writing a post about the horror stories we’ve faced so far, or, to put it in amore diplomatic way: about the inherent bias clients can have about our perceived value, or WebRTC perceived value.
CoSMo and Meetecho have been working together for some time as the #webrtc A-Team. So far the contributions described in different blog posts have mainly been on the server-side, with Double-Encryption, VP9 SVC, or more recently better bandwidth management support. This time, we are going to speak about several client software options to connect to Janus Instances that have been just been made available.
Security in Real-Time Comms.
Security is important for communication, and in the wake of XXXX (pick your favorite) revelations, the IETF RTCWEB working group and other standard committees alike had decided to up their game. With respect to webrtc, that’s for example when the decision was made to mandate the more secure DTLS-SRTP over SDES-SRTP. The entire Security architecture is documented within a corresponding documents and some dependencies:
Encryption is only really useful if it is end-to-end and if you are sure who you are talking to.
Main Coders and Architects: Sergio Murillo, Lorenzo Miniero,
Facilitator, Motivator, and Secretary: Dr Alex Gouaillard.
Janus Bandwidth management has been incrementally updated to support the latest technologies available in a joint effort between CoSMo and Meetecho, a.k.a. The WebRTC A-Team. This article describes the original design of Janus and its VideoRoom plugin with respect to bandwidth management, and the incremental changes that were needed to bring it to automatic bandwidth estimation and adaptation on the sender side, and availability of simulcast for bandwidth management on the receiver side. A concrete example about how to leverage simulcast with the Janus VideoRoom Plugin is provided for illustration and testing purposes.
One week ago, KITE daily runs results were made available on webrtc.org. This signs the end of a first phase, and shows that webrtc automated testing in desktop and mobile browsers is doable today. This blog post reflects on the path taken to get here, the ongoing maturation of webrtc implementations, and KITE as tool for the RTC industry to achieve End-to-End testing, as well as load testing, and benchmarking.