 Thank you. Thanks for the kind introduction. So it's my real pleasure being here. Not only do I like traveling to Brazil a lot I think it's a great country But I think Brazil has also come a long way from a technology perspective. I just looked into some numbers yesterday on where Brazil stands and I found that there are about 300,000 startups that are being created every year in Brazil now and from an internet perspective 64% of all internet users connect from mobile and from those 64 86% actually have access to 3G networks, 2G and 3G networks So I think this is a really great time to get started with real-time communication and thinking about how to enable those users on a real-time basis with WebRTC And that's why I'm here to talk with you and to you about WebRTC and give you a status update where we are and how we got there So I'm starting off with a status update just giving you some numbers What we see of WebRTC usage in Chrome from those users who opt-in into providing this data to us in Chrome But also how the ecosystem has developed I'm Gonna do a quick one-on-one on on the WebRTC overall pictures And I think we've seen already and heard really great presentations today I also learned quite a bit about WebRTC actually and I will look into Give you an overview of features that we have developed and and launched this year And what's our roadmap basically towards end of the year and beginning of Q1 So about five years ago On June 1st 2011 my colleague Harald who works with Varun on on the get stats specification Posted to a W3C mailing list that we are open sourcing WebRTC and working on standardizing platform web APIs for for real-time communication platform So five years fast forward On June 1st 2016 we celebrated the fifth year's anniversary by updating the logo on the end of this year And what what did this five year basically? bring into launching a Toolkit basically for real-time communication An enabling users to make use of RTC in the browser So just two weeks ago on the Chrome Dev Summit It was published that there are two billion Chrome browsers across the desktop platform and also mobile Which are active every month These are monthly active users and all those are WebRTC enabled all those are WebRTC built-in and you can basically Directly enable all Chrome users by making use of the of the web API is that we have But it's not only Chrome right Since we launched WebRTC WebRTC has been adopted across Various browsers. So this is an overview Basically of which APIs are enabled by which browsers and you see there are quite a few now and not every user Obviously is a Chrome user People make use of different browsers, but many of them are WebRTC enabled Microsoft on the Edge Web Summit Provided this update on on WebRTC development status, and I'm super happy basically to see really Microsoft joining basically the bandwagon of WebRTC and I think there's actually one update to this slide that VP8 for real-time communication is now also in development in Edge So you will have basically various options from a codec perspective to connect users across different platforms There wasn't question about WebKit earlier ago. So There are some folks who have brought open WebRTC an alternative implementation of WebRTC Into WebKit just a few weeks ago and here you see a WebRTC video call between a WebKit enabled WebKit GTA GTK plus browser and Chrome So WebRTC is actually already somehow there in WebKit But if you look on the WebKit side, you see all to the official status of under development So eventually also WebKit and other browsers that build on top of WebKit. Hopefully will also be WebRTC enabled And these WebRTC browsers are being used. It's not only they all enabled You know and sitting there around on some desktops and and mobiles So what we see in Chrome that we have an aggregated usage of audio and video minutes per month of one billion Well, that is 2,000 years of audio and video communication per week What is being used only in Chrome? By various service providers But it's not only audio and video communication that we think of of WebRTC, right? It's all of the data channel that has been mentioned today and what we see on the in Chrome again For the data channel is per week is one petabyte of data transferred over the data channel And that is for various use cases, right? There are services that provide Content delivery networks CDNs and WebRTC But this is also any kind of content sharing basically for peer-to-peer. So this is massive and The end is only 0.1 percent of all Chrome traffic, but this number has been rapidly growing So just beginning of this year. This was at 0.05 percent and now basically we doubled this or Users you all and all WebRTC users have doubled this with the services provided over the data channel And it's spread across different Projects and companies that make use of WebRTC. So by launching this toolkit as open source and providing the codex Which are the which we have talked about already today and whichever dig into a little bit later on. We've really unlocked basically The previously closed ecosystem of real-time communications. So 1200 WebRTC based companies and projects that are tracked by Saribe on his on his blog And this is great because it's not just a few players that basically own all the services on users It's it's tons of projects and services that that make use of it now It's not only a phenomenon of the web So some estimations that we have done just by knowing what kind of services build of WebRTC shows that there are probably Around more or more than five billion Apps that have been downloaded which include WebRTC on iOS and Android So what are those services on mobile? We have just launched our own reference service or communication service on top of WebRTC, which is dual This August it's been used a lot actually here in Brazil But there are quite a lot of other mobile apps that make use of WebRTC It's Viber for example that makes use of part of it hangouts obviously builds on top of the WebRTC stack Facebook Messenger builds on top of WebRTC So if you want to make a voice call or video call inside of Messenger, it's WebRTC that is being shipped with it Snapchat as being managed by Sahi earlier today the video calling service in Snapchat is based on WebRTC And Slack has just some month ago launched basically all your calling In Slack and this is all the based on WebRTC These are numbers that we don't see but if you think about it the 1 billion minutes per week only in Chrome and now you basically Multiply this across all those apps. It's probably much much more usage is being made in top of WebRTC And the phenomenon is global So Brazil makes it under the top 20 But these are the Google trends for WebRTC search queries in Google and you see this has been growing continuously over the last five years And it's been spread around the world So it's China who's making basically most of the queries, which is very interesting But then also South Korea and Taiwan so this is first of all like an Asian form a phenomenon But it's also Sweden India and US. I think doesn't even make it under the top seven Well, it's nice to see that It's it's not really like the the Western tech countries who adopt this but you can see it all over the world That users and servers are investigating how to bring real-time communications to all internet users But let's dig a little bit into into WebRTC for those of you who might be new to it So this is the overall Architecture picture that we are living with in a couple years and WebRTC and I just want to quickly walk you through basically top to bottom so we have seen the the web APIs already and those were covered extensively basically today already But there are also mobile APIs which are provided by the by the mobile native libraries for iOS and And Android that we are providing those. These are either an objective C or Java bindings that you have there and below those application-level APIs you have the C++ Peer connection, which is like the main interface basically to the WebRTC library and Be those those you have you have three big components one is the voice engine as we call it Which includes all the the audio codecs and this is opus isek and and g7 11 that is enabled in WebRTC and Which is a a jitter buffer, which we call net EQ is a net equalizer So this jitter buffer basically takes care of all the the incoming packets and trying to Packet concealment if their packets lost or trying to manage basically the the variability that we see in in the delivery of the packages and Then we try to address Certain very hard to solve signal processing problems in software Well, this is echo cancellation noise suppression and gain control and this in the end basically what what helps to make Audio great and tries to fix many problems with different hardware that we see There's a video engine basically which enables WebRTC with video communication Though the codecs that are being provided are VP8 VP9 and H264 and similar to net EQ on the voice side There's basically a video jitter buffer that manages the incoming packets and outgoing the incoming packets for for video communication and the the underlying algorithms that enable a Best quality video communications and WebRTC is bandwidth estimation. So WebRTC is mainly used by in the Internet, right? It's not provide not usually or the tacos are what they are not the usual use of WebRTC So we know we are not have we are not operating on a medium with a dedicated quality of service We don't actually know what kind of bitrate and quality we have for each individual sessions You can do tests in advance But actually the next time your network quality might be completely different because the Internet and especially Wi-Fi is a shared medium So bandwidth estimation is a key component To understand and to deliver video and then obviously it's like error correction if you lose packets How do you deal with those? Can you apply even forward error correction in and providing more bits and fixing those areas that might occur? And then there's a transport component. So each communication and WebRTC is always encrypted There's never unencrypted communication as RGP and I think Stunt or an ice has been extensively covered already today here But this is basically the mechanism that we have built into WebRTC that helps you to to cross the network translation that is applied in many IP version for networks nowadays and Then we have those platform specific connectors So every operating system every hardware is having its own audio capturing and rendering video capturing rendering a network IO system basically to which we need to Adopt or connect to from a from a WebRTC software perspective So bandwidth estimation beginning of this year We had about two seconds medium ramp up time to one megabit Video that means bandwidth estimation the algorithm is algorithm use two seconds To understand what is the capacity of the network and to be able to ramp up to one megabit Which provides an almost HD stream since then we have made great changes to bandwidth estimation We switched the algorithm from a send receive site split algorithm Moved all the logic of bandwidth estimation into the send side and worked on a feedback format Which is provided from the receiver side back to the send side And this allows us to basically decrease the time of That we need for ramping up to one megabits to six hundred fifty milliseconds. So this below one second And this is for example, why do works so great and why we can do something like Knock knock with a good video quality from the very beginning because we get instantly very good video quality The codex as I mentioned in WebRTC our Own codex from the from the web end project vp8 and vp9 They're both provided with lip vpx inside of chrome They're open source and royalty free so everybody can use them and the work that has been started There is now being continued in the Alliance for Open Media Which not only All big internet players more or less have joined But also and this is very important the chips that manufacturers have joined or many chips Have joined the Alliance for Open Media and this really provides basically assurance that the next generation codec will also be hardware enabled The other codec that we committed to support is h.264 The legacy video codec basically so we make use of open h.264 here for encoding video in WebRTC and Chrome always had lip ffm pack for decoding h.264, which is also used for WebRTC But even basically beyond this and thought okay if you want to make it efficient if you want to address the capabilities of the devices We also implemented the hardware encoders on desktop where it is available. So that is on Mac OS, Chrome OS and on Windows Select as machines and if you have basically h.264 hardware encoding in there Chrome automatically makes use of it and this saves you battery This reduces the heat of the machine and and the time basically on turn the fan turns on Well, I want to give you here an idea what what is the advantage actually of VP8 versus VP9 and why we call VP9 the successor of VP8 The great the great thing is that it requires 30% less bits so I will jump out of this presentation Go in here and this is an example video that I'm starting now and the left side Shows VP8 at 800 kilobits per second there as the right side of this red line Makes use of VP9 at 650 kilobits per second and both are on HD resolution So usually if you see here, I'm sliding on the white background There's like hardly any difference looks boring is actually exciting because this is these white backgrounds It's usually where you can very good where I see when when there's a lot of compression happening in the codex And then those look very different, but also if you look basically on Arco shirt Like hardly any any difference or all to the skin color or I show you here basically to two sides of this video and there's no difference and This is actually the great thing that I want to outline here Going back Into some numbers That we have from YouTube which has enabled VP9 already in large scale so in 2015 there were 25 billion hours of YouTube video shown making use of VP9 So think about 30% less bits on such a scale that is huge for for network providers On traffic that needs to be delivered that is huge for YouTube on capacity for play out But this is also huge for content creators and connecting their users with them Excuse me Oh, this another graph provided by by YouTube and you see here Brazil is here on on number four Basically, and this is the amount of users that will be that VP9 enabled to upgrade to an SD resolution And SD is actually actually something on mobile where we say like this an acceptable video quality So over 10% of users in Brazil Where due to VP9 upgraded to an SD resolution where they had before very low resolution So now think about the potential of real-time communication, right? You provide better video quality to your video communication service even as the network capacity is not that great That might be on your on your 3g network for example on your bad Wi-Fi The VP9 is a more complex codec than VP8 Some of you may say it's difficult to run this basically in software on the devices But our tests have shown that at these rather small resolutions It's feasible so you can actually make use of VP9 also on mobile if you run at those small resolutions The audio codec has been ancient before is opus, which is our codec of choice It's also an open-source project. We continue to invest into opus massively mainly for reasons of improving quality Improving quality at the ultra low bitrate range so somewhere between 12 kilobits and below This is if you have a if you have a rather good edge connections or or a pretty bad 3g connection You should still be able to have without if you don't have huge packet loss or delay spikes You should still be able to run a voice call at those bit rates But we also try to increase the complexity so increasing and complexity Provides in general higher quality of the opus end coding and for be able to doing this we basically work a lot on performance So let's look into some of those features that we have launched this year And I'll continue to launch towards end of this year So one of the most start Features in and vibrati the this year Was media recorder there were actually over 2,500 stars It was the highest stars start back in the chromium bug tracker And what it does? It supports the recording of local and remote media streams So this is not necessarily an API that you want to make use of a neighbor real-time communications But you can basically capture your screen or capture any incoming Stream with this API You can capture it in VP 9 VP 8 or h264 and the default code like I said to opus audio So we see that this API is being picked up We don't really know what what's happening and and why people are using it and we would literally love to hear basically back What are your use cases? What are the kind of services that you from a developer's perspectives are working on to record? media on a host We worked a lot on bringing more performance to to iOS so mobile is a focus for us obviously and Performance on mobile is always critical so on iOS we worked a lot on the texture pipeline and that helped us to Decrease the power consumption by 18 percent by being able to to capture directly to textures by Reducing or removing copies of frames that we have done before and especially if you think of the of the iPhone 4 for s or 5 5 s devices This is where it becomes critical that you that these performance improvements really make your your service smooth But Android obviously has been also in the focus so app RTC mobile RTC has been mentioned before it's a free service that you can that we offer Just for trying our web RTC. There's also a mobile app, which is called app RTC mobile and by making use of capture texture for example and reducing frame and removing frame copies in the capture process We reduce the power consumption. So don't be fooled by these graphs. They look kind of equal But if you look on the on the y-axis here, you see that the scale is different Well, this is just a battery power that has been removed This is basically CPU improvements that we have done and we have also enabled offloading to the GPU and This is how how the GPU load looks after all these improvements So these are massive improvements that we have done in this deck inside of web RTC to help you from a developer's perspective To to create better services on mobile From an enterprise perspective or not only that from what mainly from an enterprise perspective Screen sharing is an important topic So what we have done is to enable Screen sharing on Android. So it captures everything that is on the main screen. It's just being launched now in m55 Which is coming out soon, but it's already used. It's used in the pixel phone That we have launched if you have issues with your pixel phone and don't know how to use it you can call a help hotline and The help hotline asks you if you want to share the screen with the back end or the hotline agent and the hotline agent is then able to annotate the screen and then provide Drawings to the user on what buttons to touch on on where to go on the screen for doing things And this is where party see enabled inside of every pixel phone if also Enhanced and improved screen sharing on the browser So in Chrome 54 We enabled tap sharing before that it was always Share your entire screen or share an application window So now in Chrome you can also just share a specific tap With with with other users being connected and I call And you can see that we have organized the screen picker UI differently It makes use of material design now as a as a UX And we have organized it differently and hopefully more intuitive so you can share your entire screen the application window Or the chrome tap and additionally you can share your system audio So we received many requests actually that users want to share also audio in in screen sharing sessions and For tap sharing this can be done across all diff all different platforms. This can be done a macOS window and and Linux Whereas the system audio sharing is not always available So we will share these slides later on with you, but there's also a URL on here where you can where you can try this out by also installing a an extension for this Where party sees also used a lot in in corporate networks and enterprise scenarios and often These corporate networks are managed and blocked or protected by firewalls And that means that UDP is limited to a often to a specific port range and not across all the All the range above 1024 usually port 1024 So what we have done we have enabled a Chrome user policy That the administrators can specify the port range for which it allows web RTC traffic and Then web RTC is forced so all UDP traffic and web RTC is forced to go through this specific port range This has been a much wanted feature From all big service providers that make use of web RTC So what's the upcoming work that we are focusing on end of this year and beginning of next year? It's making web RTC better even when When the proxies that require authentication there are still a few Bigger bucks I would say that prevent web RTC for being like having really the five nines of reliability High FPS frame per second screen sharing and what we call slim web RTC. So I want to briefly walk you through these features so Yeah, web RTC works best with direct UDP. It can fall back to TCP But in many corporate networks, there's a proxy which requires All traffic that goes in and out to be authenticated. So there are two different stacks basically in Chrome one for the HTTP signaling side and then one for for for the media side from a network perspective and Whereas proxy authentication works well since a long time for the HTTP signaling. It does not yet for any for any media traffic So what we will be working on until the end of this year together with the Chrome team is to enable basically the media side also with proxy authentication and That will enable the media traffic to path through these proxies in such a managed environment And you see that this this feature request is having over a hundred stars So in just in general if you want basically features to be prioritized in our work Starring a buck is always a good idea because then this is a feedback mechanism to us where we understand What is really wanted by the community? Improving media reliability, so there are still three main issues that we see Where where chrome and web RTC fails from time to time One feature is there is no audio from microphone coming in we actually see the microphone But we all get zeros all the time So and you need to restart chrome to make this happen or to to fix this a Similar issue is there is no webcam detected and you need to restart chrome to get the webcam back enabled and then There are from time to time glitches on the audio and video Render and capture side. So these are Fundamental problems that we have with web RTC inside of the chrome architecture It's due to how processes are being managed inside of chrome and how different process competing on threats and What this means to us is we need to switch basically the process man handling for for media in web RTC And there's a new process framework and chrome which is called mojo It's it's a simplified Process model and it addresses basically a data ownership and process sharing so we will adopt mojo for audio and video capture They will get their own processes They will not compete against other processes anymore inside of chrome So if you have very heavy and expensive java script in your application This will not block the audio or video capturing or ending anymore and video will come first Until end of this year and audio is a little bit of a bigger project And this will land basically next year then and this will be a big milestone for us because then we believe that really web RTC will become very stable inside of chrome Another feature that we are working on is high frame per second screen sharing in chrome. So the idea is to enable Users with sharing video or multimedia content sharing gaming via chrome. This is the feedback that we have received so we are adopting a new direct X feature for desktop capture it allows us to go up to 30 frames per second depending on the power of the mobile of the desktop hardware and This will bring almost real-time screen sharing into chrome Last but not least slim web RTC Is a project with which we address? The request from from many users who want to customize web RTC not always do you want to ship? all codecs with web RTC or you want to Deploy web RTC to constraint devices because you are building a camera or a speaker or a microphone Which is all network connected from an internet of things perspective? Though web RTC might be too too big basically the footprint might be too large of the binaries So we are coming up with a way of allowing you to configure the web RTC libraries on a modular basis Removing specific features and customizing it to your needs So to sum up What we are doing with web RTC the web RTC platform on the web is moving Towards a very stable state We see tons of services being built on top of it. There's a lot of usage is massive usage We ourself have at the moment an increased focus on mobile to bring up the mobile platform on an equal state from a performance perspective and We invest tons of time and efforts to make web RTC better When the when the networks are not so good, and I think this is especially something in markets like Brazil On mobile networks where we hope to make web RTC to work much better I thank you for your for your time and being here for listening to me and yeah Are there any questions that you would like to ask me?