 Hello. Hello, everyone. How's everyone doing today? I am very excited. This is my first time in LA and my first time ever speaking at a conference. So we're going to help for the best. Let's deal with my name is Rachel Sheik. I use she her pronouns. I'm a software engineer at Twitter where I work on all Twitter's live audio and video services. Most notably our product Twitter Spaces, which is sort of a conversational approach to social media where you can as a host invite some speakers in and have a bunch of listeners as your audience and just talk about whatever you want. You can find me on Twitter at Rachel Sheik. And without further ado, let's jump into how today's talk is going to work. I'm going to keep things fairly high level and accessible to all audiences. So we're going to cover what Movie Night is, what WebRTC is, how I used WebRTC, how I used Kubernetes, and some core learnings and takeaways that I learned throughout this project that you guys can take forward. If you ever want to follow in my footsteps, so let's kick it off. So what is Movie Night? Let me grab a drink of water real quick. So I really like movies and TV shows, as do most people, and I really enjoy watching them with friends and family. However, when we were quarantining at the beginning of the pandemic, it became really difficult to sync things up and get a watch party together. And it's always a hassle trying to sync things up over the phone where you're trying to like start in the middle of a show and everyone is trying to get to the right time stamp. And then it's just off by a millisecond so you're hearing it echo the entire time. So I wanted to create something to solve this problem. If you've ever used Disney Plus, they have their new group watch feature, or if you use the Chrome extension Netflix Party, it's very similar to this where it's a distributed approach to concurrently streaming video across multiple peers. So yeah, so it's just something you can start up as a host, start up stream and then kick back and watch with your friends and they can join in whenever they want. So let's go over the core technology is to build this web RTC web, being that it can go across web clients. For the most part, you have your Chrome Firefox opera pretty seamless RTC stands for real time communication. And this is an open source framework developed by Google to enable peer to peer connections across different browsers. There are a few key terms we want to go over before we jump into really explaining how I use this technology, but something similar that I want to break off first is that a lot of you might be familiar with WebSocket. It's where you have client A, client B and a server in the middle and to be able to sync up client A and client B, client A has a WebSocket connection to the server and client B has a WebSocket connection to the server and client A is streaming to the server and the server is syncing up all the rest of the clients to it, which is great and it works a lot of the time. But between the latency of client A speaking to the server and the server having to push that data everyone else, you're looking at about at most a second of latency, which isn't great if you want to have a real time watch party. WebRTC however cuts out that server in the middle and just does a direct peer to peer connection, which has its limitations and we'll be going over them. So we want to have client A and client B talk to each other. So what do we want to do to get started? First, we're having these succession description protocols, which are just packets of metadata like your audio codec, your video codec and any other browser specific metadata points that client A needs to send to the server so that client B can also read it and sync into it. So client A will send an SDP offer and that will go live in a signaling server somewhere and client B will see that offer and send back its own SDP answer. So both of these clients have sent forward their metadata, they're syncing up together, everything's seamless. If you're on the same server or you're on the same device, group it up. This is all you need to establish that connection from client A to client B. However, if you want to move past that into the real world, we have firewalls and all these networking things to get through. So this is where interactive connectivity established from candidates come into play or ICE candidates. What ICE candidates are are a list of public-facing IP addresses and ports that each client generates so that other clients can connect to those public-facing ports and make the connection happen. What we do to programmatically figure out what's the best connection between point A and point B is we use a stunt server. Stunt servers, there's a bunch of free resources. Google has a bunch of stunt servers that you can utilize in your projects where basically it'll take a look at candidates, figure out the best path in between, and then as soon as that path is established, you have a great way to just send data packets through. For the most part, this works. For Movie Night, this was it. But about 14% of the time, which is like your very large scale things like spaces, it doesn't always work. And so you'll have to go dive back a little bit into the web socket world where you'll have these things called turn servers. Turn servers are just publicly hosted servers that allow for the facilitation of passing data through it. So say you'll have a few clients in a restricted network that can't connect publicly to a stunt server with their ICE candidates. So they'll connect with web sockets directly to the turn server and send their data through, and then everyone else can publicly connect to that turn server using its own public ports and IP addresses to get the data via TCP or UDP, whichever is better. So it streamlines things a lot. So let's go over to how I use WebRTC. First, I used a generic example. WebRTC.org has a lot of great code samples. If you ever want to just get up and running, they had an example where you had two different clients on your same device. Start a webcam connection to each other. I took that. I created a singling server on Firebase, let both the clients sort of send their SDPs over to that and sort of start things off by connecting and then starting an RTC pure connection to send the video data through. This sort of removed any need for me setting up my own video server and just let me use the host as the server. Then I separated in two different laptops. So now I had to deal with the network. So now I just use one of those free Google Stun resources to go through the ICE candidates from each laptop and connect them over the network. And then so now we have essentially Zoom. And so to turn Zoom into a movie night session, I sort of cut off all of the peers, video streams, and I only had it running from the host. And so I've used OBS in the past to stream Twitch. A lot of people just use it to capture video on their device, whether it's from a screen, a window, or just like the whole display. So you hook up that OBS stream, you use videos that you legally have access to, and you sort of stream that from the host to all the peers and a peer-to-peer network. It's fairly simple. So this is how we create one single sort of watch party and movie night. Now here's where the Kubernetes partner comes in, because if you have one instance of the movie night session and you want to scale up, Kubernetes is a great way to do that. You're all at Kubernetes conference and you've heard a lot of Kubernetes talk, so I'll stay fairly high level and stick to how I used it. And one example of something I would have wanted to explore in the future. So I put all the single session logic into a Docker image back when Docker and Kubernetes played well together and put that into a pod. And thanks to the Kubernetes config, I was able to take advantage of horizontal load balancing with an auto scaler so that each time a new person wanted to join in and start their own movie night session, they were starting in a new pod. So one instance, one session. Something I wanted to explore if I had gone a little further is using instance recovery. So you have all these pods, all these people watching their shows, one person watching Squid Game crashes. But because we have all these STP metadata, so we have the timestamp where they died off and we have all the code information. We should be able to spin up a recovery pod, stick them back in there and start them at the exact same point. Something I didn't fully flush out, but I want to get to exploring if I ever touch back on this project. So let's recap it real quick and tie it all together. So first, you're going to build out a single WebRTC instance to stream a single movie night session and add it to a Docker image and add it to your pod. Then you're going to build out the Kubernetes info around that pod to be able to scale it out, do whatever you need to do, deploy it, scale. And then after that, you're good to kick back, watch away, start your session, keep on rolling. So now the core learnings and takeaways. First thing I would have wanted to do was explore a different video streaming protocol slash approach to WebRTC. WebRTC is great if you want low latency for all of your video streaming. However, you do sacrifice things along the way to get low latency. If you've ever used a Zoom call or a Google Meet's call, you'll notice that video buffer sometimes or it's really low quality and the audio might chop some time. You're losing a lot of packets along the way just to make sure things are synced up in real time. However, when you're watching a 4K movie with people on your laptops with like all your nice retina displays and everything, you kind of want that quality back. So something I would have wanted to explore was instead of having the peers manage the video streaming, tie it into something like a turn server where I manage it and basically have only the primary host connect to that turn server and be communicating playback controls while the video playback is all taking place on the server and just streams out to all of the listeners or viewers via low latency HLS. Another thing I would have wanted to explore if I stuck with the WebRTC part was exploring bundled PDP P2P slash video streaming. This is something that Apple just sort of explored with their new FaceTime features where you can jump on a FaceTime call, be seeing people face to face, having a conversation and someone can start a video and everyone can tune into that video at the exact same point. This could have led into that with just a little few more tweaks, more so like capturing that video webcam instance that I had in my initial POC and then bundling out with the video. So that would be really cool to explore. The last point is playing around with different approaches to initial scaling. The way I architected it out, you had one instance or one session per instance. Something that would have been really cool to explore is exploring the aspect of like cable television to sort of streamline how video was played on the platform. So say you have 100 channels of all these different shows and TV shows so that if you had 50 people using 50 instances of moving night on the Kubernetes cluster and they're all watching Squid Game, you're cutting down on the duplication of data flowing through your platform. So just having a bunch of channels and having people tune into those channels whenever they wanted and if they're the only ones in there have access to playback controls. We really need to explore. But without further ado, that's it. Are there any questions? This is my dog, Hera. So we're going to do Q&A now and the way we're going to do this to make this easy for us is you yell out your question and I'll repeat it so the folks online can also see, can also hear. So yeah, let's go. Oh, in the back. So in the back, one of the attendees asked, what was your experience like debugging your WebRTC? Yeah, totally. So the reason that I started out building up a single session first instead of just lumping everything into Kubernetes and going full send was that along the way I was actually learning about things where you have to orchestrate the ordering of answers to your offers. And so I bottlenecked that at the client side and just sent out metrics so that whenever things went wrong, I had a local registry on my device that I could go and look at what was happening in the server. And that was super cool. And also the WebRTC community is just really amazing. They're almost as good as the communities community where they have a lot of resources for you to sort of ask around, learn how to do things. And so basically just setting up those metrics helped me orchestrate things and sort of bottlenecked them depending on who was connecting from which client. And that's how I solved it. Thank you. Oh, another question out in the back. So were you able to, you can read out the question kind of my brain. Sure. Yeah, so the question was, did I ever explore around with people sort of streaming in their own WebRTC connections to the video call and watching the movie along. Is that correct? Yep. Yeah. So that was something that I like lightly played with back when it was still the webcam sort of zoom feature thing back and forth. And it's something I wanted to explore further. That was sort of my point on the sort of Apple FaceTime stuff where you could see the people you're watching with and still see the video. And that would just involve bundling that sort of webcam stream alongside the video stream and just putting it in your client further up in the corner. So the question was, did I use the turn server to sort of manage all of that and would all of this people sort of stream into the turn server. Yes. So the way the turn server work, it's not just client a and then everyone else pulls out. Actually, everyone has a bidirectional connection to that turn server so they can all send in data at the same time. And you just work straight in the turn server and just spit it back out to everyone. Thank you. Any more questions. Alrighty. Thank you everyone for attending. Thank you so much.