Many questions on the discuss-webrtc mailing list nowadays are about specific configuration flags. It’s frequent enough to deserve a blog post to provide the basic and try to reduce the number of stuck people.Continue reading
The work to add RTC AV1 in Chrome, which started in November last year is now well underway. Many people still ask the legitimate question: when will it be available and how good will it be. We had planned to deliver the implementation at IETF in Vancouver at the end of the month and make demos, but the IETF like many other events has been cancelled, so we are switching to weekly updates until the release, still planned for April. This post provides some information about both timing and quality questions.Continue reading
With all of CoSMo businesses growing, especially our Millicast real-time streaming platform doing 10x revenue YoY, and on track for +65% this Quarter (eq. to 7x annual), time has come again to hire.
We are duplicating our operation team, adding a Singapore Center in addition to the Existing US center based in California. As a result, we are opening a mid-level to senior Media DevOps position in Singapore, co-located with our global HQ, most of the C-Level, and the R&D team.
I took the opportunity to create a “Jobs” section in this blog. Do not hesitate to come back and visit, as we are likely to open more position as the year advance.
Within AOMedia things are moving fast with the preparation for AV2 in full speed.
Outside of AOMedia, the adoption of AV1 is like a blazing fire. With the first AV1 adoption by Browser (decoder) two years ago, Netflix switching to AV1 for all content, recently on mobile as well, Hardware acceleration available for more than a year, and Real-Time codec implementations by google and Cisco, all is already on the table for success. Cisco demoed publicly real-time AV1 in webex, on a MacBook Pro in june 2019 !
With NAB around the corner, a lot of big player are positioning themselves, not only to differentiate their offer in production, but also internally to position themselves as the implementation reference for AV2. Netflix/INTEL SVT-AV1, google’s libaom, and xvc from Divideon (non-aom member)
With a very early Chinese new year this time around, the month of January was gone before we could even realise it was around. So many good things happened though, with even more to come toward the end of the quarter, that we thought a post was overdue. Be careful, it is a short post, but on steroid, with many #webrtc news in it!Continue reading
In a recent post on the millicast.com blog, we spoke about the value of Media Streaming and the corresponding business models. We think that question if of interest to a larger audience, and that some points can actually be better addressed. So we’re doubling down with a more focussed post here.Continue reading
WebRTC M80 release notes announced for the first time some support for AV1 in #webrtc. This is the closest one gets from official announcement of support, but it is also difficult from the one-liner in the release note to understand what it is about and how to use it. This blog post will present some details on video codecs support in libwebrtc, position the m80 release in that scope and provide some visibility on the AV1 support in #webrtc timeline.Continue reading
WebRTC has been a magical word for the best part of the 2010 decade, starting, if we had to put a date on it, with 2011 Google IO presentation. From conversations as early as 2018, and many small signs (dropping support for official mobile release in m80 release notes), it was clear that, for Google at least, the WebRTC star itself was already the past. Still, more people depend on webRTC, or want to adopt it, today than ever. What are the options out there? How should one prepare for WebRTC in 2020?Continue reading
W3C TPAC @ fukuoka Japan, October 6 to 20, 2019
Greetings from Fukuoka, Japan – or, your essential update to all things WebRTC…
As ever year, the technical plenary meeting of the World Wide Web consortium took place in the fall. After Lyon, the French “culinary capital”, in 2018, it was hosted this year in Fukuoka, Japan, during the week before the first Rugby World Cup hosted by Japan.
If you only have a few seconds or have an attention deficit 🙂 here’s a very quick wrap of what happened at Fukuoka; however, I DO encourage you to read the the remainder of the blog to get a full perspective of the SIGNIFICANT DECISIONS that were taken, and the background perspective.
As far as the standard and corresponding specifications of WebRTC are concerned, the job is done. I know, we’ve all heard this before. However, with the IETF RTCWEB group closed last year, and the W3C WebRTC group closing in April, 2020, there will be no official space, nor resource, to make any more WebRTC standard work. Thanks God!
With Unified Plan now implemented by almost all browser vendors, Simulcast and the Statistics are the last two big items whose implementation needed more work. We should see the browser vendors work more on these items now on.
It is clear for some time that the focus of the browser vendors has moved from WebRTC proper to the next big thing.
WEBRTC NV, including QUIC, then WASM and AV1 codecs were the big thing last year, and even if NV is now being called WebCodec and WebTransport now, it feels like those four items are still the focus.
Looking at the still active or newly active standard drafts being proposed, one can read between the lines as well, and IETF 106 (November 18-22) should tell us more about what has been, or is, brewing.
I believe that WebTransport is going to be the main group to follow, but some drafts like RIPP are also introducing interesting techs.
Let’s get things in context (short history reminder)
Last year, beside the usual maintenance items, the two main working items of the WebRTC working group were Simulcast, to finish WebRTC 1.0, and WebRTC NV use cases. BUT not a single test from the WebPlatformTest suite was passing on all 4 main browsers, that said, it was not an excessive worry at the time.
WebRTC NV had many small use cases, but the overall idea was open up the WebRTC API even further to allow people to bring their own codec, and bring their own transport. In conjunction with web assembly (WASM), being made available through another group, this could lead to support for a lot of use cases, and give much more flexibility to applications.
The only part of WebRTC that would NOT be opened was the DTLS-(S)RTP part, as it was not only mandatory for WebRTC 1.0, but also needed to be handled by the Browser itself to protect users.
Both Apple and Mozilla were pushing back on WebRTC NV, for different reasons. Apple wanted to focus on finishing WebRTC 1.0 and did not want to see WebRTC NV draining away already limited resource.
Mozilla, heavily involved at IETF with Cisco in the PERC standard, would oppose anything that would allow overlapping features with PERC. That eventually lead to two Mozilla employees, who were Area Directors at IETF, to send a formal liaison letter from the IETF to the W3C claiming that the W3C working group was trying to alter the security foundation of WebRTC by removing DTLS-SRTP.
We, at cosmo, do not remember such removal to have been proposed, but it did not matter, the WebRTC working group had to drop the corresponding item
Meanwhile, at IETF, the PERC standard, chaired by Cisco and Mozilla, was declared “a rough consensus” by the chairs, and accepted as a standard. This was, after multiple problems had been raised both on the mailing list and during the meetings, as well as no less than 12 negative comments raised during Last Call.
Simulcast was generating a unanimous concern. With Unified Plan now out of the way, the Simulcast holy mountain could finally be cleaned, but nobody knew really how much work was left to be done. More worrying maybe, no testing tool existed which would allow the browser vendors to test their implementation. As Bernard Aboba from Microsoft was also pointing out, testing Simulcast meant testing against an SFU, and in this absence of a reference SFU, that meant testing against enough SFUs to make sure it worked. The feature was deemed at risk, and marked as such by the W3C itself.
CoSMo then committed to allocate resources to provide a reference SFU, as a variation of Medooze, and corresponding KITE tests to all browser vendors to help address simulcast. Rendez-Vous was taken to each IETF Hackathon (which most browser vendors attend, and which take place three times a year instead of only one time for the W3C TPAC) and to make sprints and discuss progress.
And now to Fukuoka..
Fast forward to Fukuoka this year. CoSMo had implemented a reference SFU, with a lean-a-and-mean compliance mode that would only accept the latest specs. Apple had, for example, used it during their QA to accelerate their development. The WebRTC working group meeting was more relaxed, at least while it came to Simulcast, which was taken out of the features-in-danger list.
The KITE simulcast tests and infrastructure (Medooze) have been made publicly available. The extension of this test bed to the WebRTC-SVC specification, and/or to the alliance for open-media’s AV1 RTP payload specification is under discussion.
The coverage of the WebRTC specifications has seen a great surge, going from 0 to almost 50% of tests that would pass on all 4 browsers (see below). If we take into account all tests that pass on at least 3 browsers, that goes up to almost 70%, and with 2 browsers, which is the criteria for W3C, that’s 85%.
INTEL who had announced their intention to open-source their full WebRTC implementation at TPAC last year had since came through with their promise in April. They are planning to join the Google / CoSMo lead Hackathon at IETF 106 in Singapore on 16th and 17th November (see here) to integrate better their tests in KITE, to participate in the SFU Compliance testing session, and to collaborate with Apple to bring H.265 Hardware Acceleration to libwebrtc.
The WebRTC working group was chartered only until April 2020.
The questions was now, what to do next? It was pretty clear that the number of active members in the group had reduced, and following the problems arising during the WebRTC NV discussion, a lot of interest to keep working this way, with that group of people, had declined (more below). Once the decision ad been taken that we would NOT reach out to extend the working group life, there remained the question of what to do with pending documents. Dom, as representative of W3C for the group, presented simple conditions: for a draft to be kept alive and get support it needed to have two things:
– One editor that was taking responsibility to finish the document.
– At least one browser vendors which would commit to implement it.
The INTEL device group stood up and took responsibility of the Depth Image support, as they had already provided an implementation in Chrome. Microsoft confirmed support on their side. Same for some other contributions to the Device support (PTZ cameras, ….). One by one, the remaining specifications were distributed, or dismissed.
Following the “PERC Drama”, and because of the little remaining time left in the WebRTC working group charter to do things, most of WebRTC NV items had been rebranded into WebTransport and WebCodec, and dispatched into different working groups.
With the imminent closure of the WebRTC working group, the new Media Group got extra attention. Traditionally, at W3C media meant the Video element, streaming of non-ICE, non-real-time media (Media Source Extension), DRM (Encrypted Media Extension). Just like in the rest of the industry, we can now see the two groups (real-time and VOD) coming together and working together on a set of converging technologies. Logically, the Media Group will be Hosting the WebCodec effort.
Until next time ……