WebRTC shouldn't be this hard!
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
DuBois, Sean
WebRTC was the technology everyone wanted to learn in 2020. With COVID and WFH new developers and companies came pouring into the scene. They had lots of problems making their vision happen. Many of them didn't even know what WebRTC was. When they figured that out they still had to make the long journey of figuring out how to build. This talk is my reflection of helping developerswith Pion WebRTC. WebRTC has so much potential. We just need to solve some technical, educational and cultural problems. Out of those experiences we started WebRTC for the Curious and tried to make Pion easier to use. I also have some future ideas that I would love help from the RTC community.
 Hi, my name is Sean Dubois and I'm here to ask the question, can we make WebRTC easier? Before we get into that, this is my background in the RTC space. First off, I started the Pion project, which is a collection of GoRTC libraries. They're designed to be building blocks to build your vision. The idea is that Pion fits into your existing system. We want it to be flexible and it's a community-owned and non-commercial. The first project was Pion WebRTC, which is a peer-connection API in peer Go. It's the API as you expect in the browser. You call create offer, you call add track, you create answer, but instead of having a tightly coupled media pipeline, instead you control it. We provide Pion media devices so you can call get-users and media like you expect, but we also provide other ways like you can read from a file or you can bridge with RTMP or RTSP. We also provide a setting engine, which allows you to set proprietary Pion-specific options. You can control MD&S and other things like that. The last concept that is specific to Pion is interceptors. You can actually set your own congestion controller, you can set your own NACs. It's basically a pluggable RTP and RTCP pipelines. If you're familiar with Gstreamer, the design is heavily influenced by that. To other major libraries, we wrote a turn as an API in peer Go. It's both a turn server and a turn client that you can embed in existing applications. It's a library, so you get callbacks for authentication. You can plug into your existing auth systems. It's not tightly coupled with Redis or an existing SQL server. You can bring your own logger. You can run turn and HTTPS on the same port by reading the first couple bytes and then demuxing and deciding which way to go. You can embed turn in an existing application. Then, one of our biggest projects is Ion, which is a cluster-based system for building real-time communication. The idea is that you have a Docker container for each one of your processes. You can have an SFU instance, you can have an AVP instance, which processes real-time media or a live instance, which does the protocol bridging. You can set RTMP, HLS. Then the more recent project I've been working on is WebRTC for the curious. It's an open-source book on how WebRTC really works. It's not just about calling the JavaScript APIs, but it's a deep dive on the protocols and how WebRTC actually works. I'm also working on getting interviews with the RFC authors. I was lucky enough to talk with Ron Frederick, one of the co-authors of RTP. I've been able to talk to anyone else yet, but if you do know them, I appreciate a shout-out and convince them to give a little email exchange. It's super important to get that history. Then WebRTC in practice, we want to teach people how to debug. It's a shame that people have to re-learn this stuff. The first half of this talk is informed by questions that I've been asked while working on WebRTC projects. We run a Pion Slack where we have people come and they'll say, this doesn't work. I don't understand. A lot of the questions aren't even really related to Pion. They're more general WebRTC questions. First, people don't understand what WebRTC even is. First off, you go off and most of the docs are for the JavaScript, the API defined in W3C. If you search how to do this with WebRTC, it doesn't talk at all about the actual protocol, how do you get WebRTC working on the outside the browser? Then if you dig a little further, the definition of WebRTC isn't even consistent. If you go to the ITF, they define WebRTC as a protocol. They'll have these collection of docs and it'll say it's a bundling of ICE and DTLS and SRTP. If you go to the W3C and a lot of the public internet, it'll say it's the JavaScript API. If you go to WebRTC.org, it'll say that Google's implementation is what WebRTC is. The definition is all over the place. To get a good sense of this, just compare the definition on Wikipedia, WebRTC.org and the MDN and WebDocs. No one agrees what WebRTC is. The next is, WebRTC is when you're building stuff, it's hard because you have to anticipate the problems that are going to happen down the line. I have a lot of people that will build things and then when they go to deploy, things go wrong and it's very frustrating for them. They'll hit into network topologies and I can't tell you how many times I've asked, are you running a turn server? People don't anticipate this because they build it in a lab and it works perfectly, but then they go to deploy it to the production and everything blows up. Very frustrating for everyone. Then you have that not all clients support H.264. They build this wonderful RTSP bridging system and it works great. Then they go out to the production and you find out that these Android devices, they only support VPX. One customer reports bad video and you say, what is your plan around congestion control and error correction? It blows their mind. They're like, I didn't consider any of this. I just want to send a video over the internet. Why do I have to worry about this? It's frustrating. I don't know what the solution here is because I want to teach people these things and help them not have them hit these roadblocks in production. The next people say, where do I ask for help even? I think the vendor specific communities are really great. I'm on the Gstreamer mailing list and very helpful. If you ask things that are related specifically to Gstreamer with WebRTC, you'll get help right away. Another great one is all the specific SFUs. MediaSoup, Janice, Jitsi, their mailing lists are very healthy. There's a good chance that you'll get good help from them. The vendor agnostic communities aren't so great right now. Discuss WebRTC. You'll get a lot of questions but not a lot of answers. If you do get answers, they're usually pushing people towards a commercial product. There's FreeNode. There's the IRC channel. I think there's two or three people in there. The technical depth is really great if you have a question, but not much beyond that. One that I think is showing a lot of promise is Videodev. They have a channel dedicated just to WebRTC. It's been getting more and more activity. The Red 5 Pro people are in there. There's a lot of people that are interested in spec work and stuff like that. I do enjoy being in that channel. The best thing I've seen is Twitter. You have pretty much all of the people that are involved in WebRTC on there, but that's not friendly to someone that's getting into the community. There's no way they have to go follow all these people and figure it out. It's not tenable. The next thing people say is they want WebRTC in their language. Since the most popular implementation, Google is in C and C++. That doesn't really work for everyone. C and C++ is super powerful, but at a cost. You have to worry about the memory and you have to worry about security. Then it doesn't fit into existing code-based or build systems. A lot of times people are using a different, entirely different language. Even if they are using C and C++, they just want to use CMake. I tell them, you got to do G Client Sync and all these things. It's very frustrating. It's challenging to build. The other thing is some people just want to read code. Google's implementation really isn't too large for anyone to read and understand. You've got over, I think the last time I heard, it's definitely over a million lines of code. That's not someone, and it's something people are going to navigate and understand. I also have people come who are targeting other platforms. If you tell somebody to use a WebRTC implementation that uses OpenSSL, it's out of the question. They have to use MbedTLS or they have to use the primitives that are available with that hardware. Lots of these corner cases that we just forget about. The other one is, I see a lot of non-standard use cases. A lot of people will join the Pion Slack and they'll want to talk about Teleop. They'll want to talk about file sharing. They'll want to talk about natural for data channels. They want to do some server to server thing. There's not really home for them to talk about these things. Discuss WebRTC and other video dev. Very very focused on the SFUs and the video side of things. Another one is because people don't understand WebRTC, there's a lot of them not invented here. The two that I've seen in the last year, I interacted with someone who was working on a proprietary IceClone. They thought, Ice is too complicated. I can do so much better. They learned a lot along the way and they made a lot of mistakes. I guess there's nothing wrong with learning, but it's a shame that WebRTC is perceived as too complicated and so no one wants to use it. We've seen a lot of protocols coming up that are basically just a more simple version of WebRTC. It's RTP without SRTP or RTP but without the sender feedback and MAC and forward error correction. These are all just responses to WebRTC's complexity. On top of that, you have these other protocols that exploit the lack of information about WebRTC. They say, WebRTC is browser only. They'll say, WebRTC can't send HD using all of these things that yes are true if you're using it from Chrome or Firefox, but WebRTC is a protocol. None of these things are enforced by that protocol. What can we do about that? How can we make WebRTC easier to use? How can we dispel some of the disinformation and in general just make a better community and help people build things? I think a big part would be embracing the other WebRTC implementations out there. At this time, these are all the implementations we have out there. We've got a Python implementation. We have a pure TypeScript implementation. It's not using any C or C++ libraries. It's pure TypeScript, which I think is fantastic for safety. We've got an Erlang implementation that isn't public. We've got Pypes Java implementation. We've got a Rust implementation coming up. AWS has an embedded implementation that uses embed TLS and it's really targeted at small devices. There's a lot going on in this space right now. I think that if we embrace these, it will help bring out a lot of the variety in the space. The one thing I'd really like to see this year is interop testing tools. I'd like to see a test suite that I can run to WebRTC agents against each other and assert things like protocol features and compliance. It would be great also for people to learn WebRTC. If I can spin up this test suite and run it, I can say, oh, wow, these are all the interesting things that WebRTC supports and learn from that. It also makes it so much easier for new implementations. WeRift and WebRTC RS, they've both been reading the PyOn code base to learn from it. I think that's great, but it would be even better if they didn't have to do that at all. If all they had to do was run this test suite, assert that things worked and then move on. We need more teaching resources. I started WebRTC for the curious and it didn't really have the uptake that I would hope it would have. It was designed to be this like vendor agnostic book that I'd hope to build a community around, but didn't seem to spark much interest. I'd love to hear, especially from the RTC community, what will it take you think for it to be a useful resource to give people in your community? I don't think that each SFU should have to explain how WebRTC works to all their users. I would love that we could come together and work on this book and have something that could save us all our time. Another thing I'm excited about is the PyOn Interceptors project. We talked before, it's like this RTCP pipeline outside the peer connection. You don't even have to use WebRTC to use them. Go has an RTSP server that's also using these interceptors. I think that'll go a long way to education and just making these things more accessible. Another one is better video debugging. This one, I don't see what the path forward on this is. It sounds more like a browser specific issue, but especially protocol bridging. So many people come to me with questions about debugging H.264 in the browser. It's a frustrating thing and it's always the same. You know, I'm an SPS, PPS with an IDR, things like that. We need more supportive communities. I want to start the non-commercial meetup that maybe meets once a quarter. We can do a deep dive on one WebRTC topic. Someone can get up and just talk about congestion control or just talk about ice-free starts, things that interest them. A roadmap of a WebRTC library. So one month we can have Janus get up and just talk about what's interesting that's going on in the Janus space. And then a demo of one downstream project. There's so many interesting things happening right now with VR and Teleop. I'd love people to hear it back. And of course, the vendor agnostic community. It would be great if this was video dev that people could talk with. How do we encourage people to give back? Like WebRTC and video in generalizes problem where people drop in and ask for things but don't want to give anything back. And then individual ownership. This is something that's important to me. Like a robust community for WebRTC needs to have many owners. I would hate to see WebRTC to have a CentOS moment. A game that CentOS was just sunset by IBM. And the same thing can happen to WebRTC if we put too much faith into one commercial entity and they're not interested anymore. Like that could cause a lot of damage. And then last I want to just showcase what I believe are some of the most interesting open source projects in the space right now. In S remote, someone wired up a WebRTC agent and made it so you can actually stream the video from your Nintendo switch to a VR headset and you can play your games in VR. And so they're sending these video frames over their local network and they're dropped right into the game. I think it's super interesting that the more portable that we make WebRTC implementations, the more we can allow people to do things like this. Macarabra is a protocol bridge. So you have these RTSP cameras and the project that did this, I think it took maybe one, two weeks at most. And I think it's really great that we can bring the security, the natural and all these improvements to the IoT camera space. A lot of these cameras like right now are just running over the public internet unencrypted and by making WebRTC more accessible, we're making the keeping people's data safe. WebRTC let you play games over the internet, especially during COVID. I think a lot of people, they spent their time connecting with people with this. So a later version of this actually allowed people to play multiplayer. So you'd run an NES and we later out on a remote server and it would ship your video frames in and people could play multiplayer games. Niko gives the ability for people to watch videos together perfectly synced. So you're running a browser on a remote digital ocean or AWS VM and everyone's watching can use the browser together. So me and a friend can pull this up and watch a YouTube video together or maybe we can play a game online. The possibilities are endless and it has a chat with it. Tools like this are great. The tele-operations stuff I love as well. So one individual was able to make a thing where they can actually control a tele-drone remotely and put the web at just over a web interface because they're able to do a protocol bridging. ASCII is a really fun tech demo that shows like WebRTC isn't just a browser technology. Right here we have a command line program that's just driven via your terminal and the other side is sitting on a web browser and we're talking to each other just over through our terminals. Cloud Morph. The same developer that made Cloud Game then came out with another project where you can run Windows applications in a remote VM and then stream the video frames over the internet. I think this is great for portability especially for running these old games. So you've got to deal with either running the DOS box or you've got to set up all the infrastructure and get things working. And I have a lot of hope that this will make software that's old that doesn't run in modern environments more accessible. SSH peer-to-peer gives the ability for two hosts to communicate directly and doing the natural versal. So instead let's say you want to run things in two data centers instead you can just connect them directly to each other. And it's also super exciting on the protocol side because you could have one server running Rust, one server running Go, another server running Java and they're all talking directly to each other without having to go through Redis or some kind of other Pub sub. You'll put there's less points of failure. You'll see greater throughput. I think there's a lot of interesting things I think that and also brings like cloud independence instead of instead of having to stick your servers in one place. Snowflake is doing natural versal via data channels. So they have the browser talk to an instance via WebRTC like a Go process that's sitting in the cloud. And that's super exciting because that means that it's something that ISPs or your government can't block because you can't block data channels in WebRTC because it's used by so many other things and it's right in the browser. So you can't block them from downloading binaries either. The ubiquity of WebRTC is bringing information to people that don't have it and Web wormhole. So now instead of having to use a proprietary service to share files with each other, you can download this. You can share files with each other directly from the browser or you can download the command line client that's written in Go and you can just run this file right in your browser. And I think that's super awesome. And then you have representation in the VR space. So everyone is connected here via WebRTC and they're sending their video friends up. And you can see all these other people are in this space as well and talking to each other during COVID. I think that was great that people can still get that in-person time and it does the spatial audio and it tries to create these virtual spaces when we don't have them. Project Lightspeed is a OBS to WebRTC bridge. So you can cast your OBS in sub-second time on a self-hosted instance. It uses the FTL protocol and then bridges with WebRTC. And I think that's super powerful because instead of having to spin up the burden of setting up RTMP servers and other stuff like that, you can just have this single-click deploy docker container and get everything up and running and it runs in sub-second time. Having this self-hosted infrastructure is super important. So I hope you learned something. I hope that this would encourage people to think about how can we make things easier for those coming after us. I don't want to see people reinvent, conchess, control because what we have today isn't accessible. And then also if any of the projects that I just demoed were interesting to you, just go ahead and look up Awesome Pion. All the projects were written using the Pion Go library. And thank you very much and please, we have a Slack that is almost up to like 1500 members. We'd love for you to join and talk. The conversations just aren't about Go, but they're also about lots of other things. And always feel free to reach out to me personally. I love talking about this stuff and I'm very passionate about making it more accessible for other people. And it's great that we can open source, let's us build these things that make other people's lives better. And it's not really difficult for us. We are.
 Hi, my name is Sean Dubois and I'm here to ask the question, can we make WebRTC easier?  Before we get into that, this is my background in the RTC space.  First off, I started the Pion project, which is a collection of GoRTC libraries.  They're designed to be building blocks to build your vision.  The idea is that Pion fits into your existing system.  We want it to be flexible and it's a community-owned and non-commercial.  The first project was Pion WebRTC, which is a peer-connection API in peer Go.  It's the API as you expect in the browser.  You call create offer, you call add track, you create answer, but instead of having a  tightly coupled media pipeline, instead you control it.  We provide Pion media devices so you can call get-users and media like you expect, but we  also provide other ways like you can read from a file or you can bridge with RTMP or  RTSP.  We also provide a setting engine, which allows you to set proprietary Pion-specific options.  You can control MD&S and other things like that.  The last concept that is specific to Pion is interceptors.  You can actually set your own congestion controller, you can set your own NACs.  It's basically a pluggable RTP and RTCP pipelines.  If you're familiar with Gstreamer, the design is heavily influenced by that.  To other major libraries, we wrote a turn as an API in peer Go.  It's both a turn server and a turn client that you can embed in existing applications.  It's a library, so you get callbacks for authentication.  You can plug into your existing auth systems.  It's not tightly coupled with Redis or an existing SQL server.  You can bring your own logger.  You can run turn and HTTPS on the same port by reading the first couple bytes and then  demuxing and deciding which way to go.  You can embed turn in an existing application.  Then, one of our biggest projects is Ion, which is a cluster-based system for building  real-time communication.  The idea is that you have a Docker container for each one of your processes.  You can have an SFU instance, you can have an AVP instance, which processes real-time  media or a live instance, which does the protocol bridging.  You can set RTMP, HLS.  Then the more recent project I've been working on is WebRTC for the curious.  It's an open-source book on how WebRTC really works.  It's not just about calling the JavaScript APIs, but it's a deep dive on the protocols  and how WebRTC actually works.  I'm also working on getting interviews with the RFC authors.  I was lucky enough to talk with Ron Frederick, one of the co-authors of RTP.  I've been able to talk to anyone else yet, but if you do know them, I appreciate a shout-out  and convince them to give a little email exchange.  It's super important to get that history.  Then WebRTC in practice, we want to teach people how to debug.  It's a shame that people have to re-learn this stuff.  The first half of this talk is informed by questions that I've been asked while working  on WebRTC projects.  We run a Pion Slack where we have people come and they'll say, this doesn't work.  I don't understand.  A lot of the questions aren't even really related to Pion.  They're more general WebRTC questions.  First, people don't understand what WebRTC even is.  First off, you go off and most of the docs are for the JavaScript, the API defined in  W3C.  If you search how to do this with WebRTC, it doesn't talk at all about the actual protocol,  how do you get WebRTC working on the outside the browser?  Then if you dig a little further, the definition of WebRTC isn't even consistent.  If you go to the ITF, they define WebRTC as a protocol.  They'll have these collection of docs and it'll say it's a bundling of ICE and DTLS and  SRTP.  If you go to the W3C and a lot of the public internet, it'll say it's the JavaScript API.  If you go to WebRTC.org, it'll say that Google's implementation is what WebRTC is.  The definition is all over the place.  To get a good sense of this, just compare the definition on Wikipedia, WebRTC.org and  the MDN and WebDocs.  No one agrees what WebRTC is.  The next is, WebRTC is when you're building stuff, it's hard because you have to anticipate  the problems that are going to happen down the line.  I have a lot of people that will build things and then when they go to deploy, things go  wrong and it's very frustrating for them.  They'll hit into network topologies and I can't tell you how many times I've asked,  are you running a turn server?  People don't anticipate this because they build it in a lab and it works perfectly,  but then they go to deploy it to the production and everything blows up.  Very frustrating for everyone.  Then you have that not all clients support H.264.  They build this wonderful RTSP bridging system and it works great.  Then they go out to the production and you find out that these Android devices, they  only support VPX.  One customer reports bad video and you say, what is your plan around congestion control  and error correction?  It blows their mind.  They're like, I didn't consider any of this.  I just want to send a video over the internet.  Why do I have to worry about this?  It's frustrating.  I don't know what the solution here is because I want to teach people these things and help  them not have them hit these roadblocks in production.  The next people say, where do I ask for help even?  I think the vendor specific communities are really great.  I'm on the Gstreamer mailing list and very helpful.  If you ask things that are related specifically to Gstreamer with WebRTC, you'll get help  right away.  Another great one is all the specific SFUs.  MediaSoup, Janice, Jitsi, their mailing lists are very healthy.  There's a good chance that you'll get good help from them.  The vendor agnostic communities aren't so great right now.  Discuss WebRTC.  You'll get a lot of questions but not a lot of answers.  If you do get answers, they're usually pushing people towards a commercial product.  There's FreeNode.  There's the IRC channel.  I think there's two or three people in there.  The technical depth is really great if you have a question, but not much beyond that.  One that I think is showing a lot of promise is Videodev.  They have a channel dedicated just to WebRTC.  It's been getting more and more activity.  The Red 5 Pro people are in there.  There's a lot of people that are interested in spec work and stuff like that.  I do enjoy being in that channel.  The best thing I've seen is Twitter.  You have pretty much all of the people that are involved in WebRTC on there, but that's  not friendly to someone that's getting into the community.  There's no way they have to go follow all these people and figure it out.  It's not tenable.  The next thing people say is they want WebRTC in their language.  Since the most popular implementation, Google is in C and C++.  That doesn't really work for everyone.  C and C++ is super powerful, but at a cost.  You have to worry about the memory and you have to worry about security.  Then it doesn't fit into existing code-based or build systems.  A lot of times people are using a different, entirely different language.  Even if they are using C and C++, they just want to use CMake.  I tell them, you got to do G Client Sync and all these things.  It's very frustrating.  It's challenging to build.  The other thing is some people just want to read code.  Google's implementation really isn't too large for anyone to read and understand.  You've got over, I think the last time I heard, it's definitely over a million lines of code.  That's not someone, and it's something people are going to navigate and understand.  I also have people come who are targeting other platforms.  If you tell somebody to use a WebRTC implementation that uses OpenSSL, it's out of the question.  They have to use MbedTLS or they have to use the primitives that are available with that  hardware.  Lots of these corner cases that we just forget about.  The other one is, I see a lot of non-standard use cases.  A lot of people will join the Pion Slack and they'll want to talk about Teleop.  They'll want to talk about file sharing.  They'll want to talk about natural for data channels.  They want to do some server to server thing.  There's not really home for them to talk about these things.  Discuss WebRTC and other video dev.  Very very focused on the SFUs and the video side of things.  Another one is because people don't understand WebRTC, there's a lot of them not invented  here.  The two that I've seen in the last year, I interacted with someone who was working on  a proprietary IceClone.  They thought, Ice is too complicated.  I can do so much better.  They learned a lot along the way and they made a lot of mistakes.  I guess there's nothing wrong with learning, but it's a shame that WebRTC is perceived  as too complicated and so no one wants to use it.  We've seen a lot of protocols coming up that are basically just a more simple version of  WebRTC.  It's RTP without SRTP or RTP but without the sender feedback and MAC and forward error  correction.  These are all just responses to WebRTC's complexity.  On top of that, you have these other protocols that exploit the lack of information about  WebRTC.  They say, WebRTC is browser only.  They'll say, WebRTC can't send HD using all of these things that yes are true if you're  using it from Chrome or Firefox, but WebRTC is a protocol.  None of these things are enforced by that protocol.  What can we do about that?  How can we make WebRTC easier to use?  How can we dispel some of the disinformation and in general just make a better community  and help people build things?  I think a big part would be embracing the other WebRTC implementations out there.  At this time, these are all the implementations we have out there.  We've got a Python implementation.  We have a pure TypeScript implementation.  It's not using any C or C++ libraries.  It's pure TypeScript, which I think is fantastic for safety.  We've got an Erlang implementation that isn't public.  We've got Pypes Java implementation.  We've got a Rust implementation coming up.  AWS has an embedded implementation that uses embed TLS and it's really targeted at small  devices.  There's a lot going on in this space right now.  I think that if we embrace these, it will help bring out a lot of the variety in the  space.  The one thing I'd really like to see this year is interop testing tools.  I'd like to see a test suite that I can run to WebRTC agents against each other and assert  things like protocol features and compliance.  It would be great also for people to learn WebRTC.  If I can spin up this test suite and run it, I can say, oh, wow, these are all the interesting  things that WebRTC supports and learn from that.  It also makes it so much easier for new implementations.  WeRift and WebRTC RS, they've both been reading the PyOn code base to learn from it.  I think that's great, but it would be even better if they didn't have to do that at all.  If all they had to do was run this test suite, assert that things worked and then move on.  We need more teaching resources.  I started WebRTC for the curious and it didn't really have the uptake that I would hope it  would have.  It was designed to be this like vendor agnostic book that I'd hope to build a community around,  but didn't seem to spark much interest.  I'd love to hear, especially from the RTC community, what will it take you think for  it to be a useful resource to give people in your community?  I don't think that each SFU should have to explain how WebRTC works to all their users.  I would love that we could come together and work on this book and have something that  could save us all our time.  Another thing I'm excited about is the PyOn Interceptors project.  We talked before, it's like this RTCP pipeline outside the peer connection.  You don't even have to use WebRTC to use them.  Go has an RTSP server that's also using these interceptors.  I think that'll go a long way to education and just making these things more accessible.  Another one is better video debugging.  This one, I don't see what the path forward on this is.  It sounds more like a browser specific issue, but especially protocol bridging.  So many people come to me with questions about debugging H.264 in the browser.  It's a frustrating thing and it's always the same.  You know, I'm an SPS, PPS with an IDR, things like that.  We need more supportive communities.  I want to start the non-commercial meetup that maybe meets once a quarter.  We can do a deep dive on one WebRTC topic.  Someone can get up and just talk about congestion control or just talk about ice-free starts,  things that interest them.  A roadmap of a WebRTC library.  So one month we can have Janus get up and just talk about what's interesting that's  going on in the Janus space.  And then a demo of one downstream project.  There's so many interesting things happening right now with VR and Teleop.  I'd love people to hear it back.  And of course, the vendor agnostic community.  It would be great if this was video dev that people could talk with.  How do we encourage people to give back?  Like WebRTC and video in generalizes problem where people drop in and ask for things but  don't want to give anything back.  And then individual ownership.  This is something that's important to me.  Like a robust community for WebRTC needs to have many owners.  I would hate to see WebRTC to have a CentOS moment.  A game that CentOS was just sunset by IBM.  And the same thing can happen to WebRTC if we put too much faith into one commercial  entity and they're not interested anymore.  Like that could cause a lot of damage.  And then last I want to just showcase what I believe are some of the most interesting  open source projects in the space right now.  In S remote, someone wired up a WebRTC agent and made it so you can actually stream the  video from your Nintendo switch to a VR headset and you can play your games in VR.  And so they're sending these video frames over their local network and they're dropped  right into the game.  I think it's super interesting that the more portable that we make WebRTC implementations,  the more we can allow people to do things like this.  Macarabra is a protocol bridge.  So you have these RTSP cameras and the project that did this, I think it took maybe one,  two weeks at most.  And I think it's really great that we can bring the security, the natural and all these  improvements to the IoT camera space.  A lot of these cameras like right now are just running over the public internet unencrypted  and by making WebRTC more accessible, we're making the keeping people's data safe.  WebRTC let you play games over the internet, especially during COVID.  I think a lot of people, they spent their time connecting with people with this.  So a later version of this actually allowed people to play multiplayer.  So you'd run an NES and we later out on a remote server and it would ship your video  frames in and people could play multiplayer games.  Niko gives the ability for people to watch videos together perfectly synced.  So you're running a browser on a remote digital ocean or AWS VM and everyone's watching  can use the browser together.  So me and a friend can pull this up and watch a YouTube video together or maybe we can play  a game online.  The possibilities are endless and it has a chat with it.  Tools like this are great.  The tele-operations stuff I love as well.  So one individual was able to make a thing where they can actually control a tele-drone  remotely and put the web at just over a web interface because they're able to do a protocol  bridging.  ASCII is a really fun tech demo that shows like WebRTC isn't just a browser technology.  Right here we have a command line program that's just driven via your terminal and the other  side is sitting on a web browser and we're talking to each other just over through our  terminals.  Cloud Morph.  The same developer that made Cloud Game then came out with another project where you can  run Windows applications in a remote VM and then stream the video frames over the internet.  I think this is great for portability especially for running these old games.  So you've got to deal with either running the DOS box or you've got to set up all the  infrastructure and get things working.  And I have a lot of hope that this will make software that's old that doesn't run in modern  environments more accessible.  SSH peer-to-peer gives the ability for two hosts to communicate directly and doing the  natural versal.  So instead let's say you want to run things in two data centers instead you can just connect  them directly to each other.  And it's also super exciting on the protocol side because you could have one server running  Rust, one server running Go, another server running Java and they're all talking directly  to each other without having to go through Redis or some kind of other Pub sub.  You'll put there's less points of failure.  You'll see greater throughput.  I think there's a lot of interesting things I think that and also brings like cloud independence  instead of instead of having to stick your servers in one place.  Snowflake is doing natural versal via data channels.  So they have the browser talk to an instance via WebRTC like a Go process that's sitting  in the cloud.  And that's super exciting because that means that it's something that ISPs or your government  can't block because you can't block data channels in WebRTC because it's used by so many other  things and it's right in the browser.  So you can't block them from downloading binaries either.  The ubiquity of WebRTC is bringing information to people that don't have it and Web wormhole.  So now instead of having to use a proprietary service to share files with each other, you  can download this.  You can share files with each other directly from the browser or you can download the command  line client that's written in Go and you can just run this file right in your browser.  And I think that's super awesome.  And then you have representation in the VR space.  So everyone is connected here via WebRTC and they're sending their video friends up.  And you can see all these other people are in this space as well and talking to each  other during COVID.  I think that was great that people can still get that in-person time and it does the spatial  audio and it tries to create these virtual spaces when we don't have them.  Project Lightspeed is a OBS to WebRTC bridge.  So you can cast your OBS in sub-second time on a self-hosted instance.  It uses the FTL protocol and then bridges with WebRTC.  And I think that's super powerful because instead of having to spin up the burden of  setting up RTMP servers and other stuff like that, you can just have this single-click  deploy docker container and get everything up and running and it runs in sub-second time.  Having this self-hosted infrastructure is super important.  So I hope you learned something.  I hope that this would encourage people to think about how can we make things easier  for those coming after us.  I don't want to see people reinvent, conchess, control because what we have today isn't  accessible.  And then also if any of the projects that I just demoed were interesting to you, just  go ahead and look up Awesome Pion.  All the projects were written using the Pion Go library.  And thank you very much and please, we have a Slack that is almost up to like 1500 members.  We'd love for you to join and talk.  The conversations just aren't about Go, but they're also about lots of other things.  And always feel free to reach out to me personally.  I love talking about this stuff and I'm very passionate about making it more accessible  for other people.  And it's great that we can open source, let's us build these things that make other people's  lives better.  And it's not really difficult for us.  We are.
webrtc_development_0_383.png webrtc_development_384_2111.png webrtc_development_2112_19331.png webrtc_development_19332_21503.png webrtc_development_21504_21635.png webrtc_development_21636_21695.png webrtc_development_21696_21767.png webrtc_development_21768_21923.png webrtc_development_21924_22019.png webrtc_development_22020_22895.png webrtc_development_22896_24575.png webrtc_development_24576_25835.png webrtc_development_25836_26027.png webrtc_development_26028_26255.png webrtc_development_26256_26303.png webrtc_development_26304_26387.png webrtc_development_26388_27467.png webrtc_development_27468_28259.png webrtc_development_28260_29279.png webrtc_development_29280_29543.png webrtc_development_29544_29591.png webrtc_development_29592_30215.png webrtc_development_30216_31543.png