React Summit Remote Edition

React Summit Remote Edition 2020

When developers think about broadcasting live from the browser, the immediate assumption is to use WebRTC. While WebRTC is amazing technology, server-side implementations are...lacking right now. We'll talk about a (totally hacky) way to get video from the browser via technology you're using today. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Going Live from your Browser without WebRTC

And we'll see you in a minute. My name is Matthew McClure. I'm a co-founder of a company called Mux. We provide an API to online video infrastructure. And one of the things that we provide is this live streaming solution. So you can create live streams, we give you back stream key, and then you can just push RTMP feeds to it. So it's great for live broadcast, but a really common question we get is how can I let my users go live directly from a browser? So right now the current recommendations are usually use native software like Open Broadcast Studio or Wirecast or something along those lines. But people want to be able to just keep people in their applications themselves and not ship them off to another solution, make them download and learn a new technology. So it's understandable why they want to, but unfortunately it's not quite that easy. So let's talk about a hack I've been working on that's probably a really terrible idea. So first of all, let's talk about what we mean by live broadcast. We'll get some quick background here. Live broadcast is not live chat. So it's a really common misconception, but these two things are actually quite different. So live chat, you have just two people, two users talking directly back and forth. They can just share video, potentially even peer to peer. So it doesn't need to get routed through a centralized server. It can just go directly from one to the other. This latency needs to be like 300 milliseconds or less. Start getting up to like 500 milliseconds, it gets really hard to actually have that like one-to-one conversation. You can maybe even have a few peers here. So that can get three, five, 10, really depends on how much bandwidth each user can have, because you're kind of constrained by whoever has the least bandwidth to be able to share video back and forth between every person in the chat. Live broadcast, on the other hand, is from one camera feed to hundreds, thousands, tens of thousands, hundreds of thousands of people at once. And so now you're not talking anymore about a communication, one-to-one communication anymore. It's one person kind of broadcasting out to a bunch. So you need to be able to scale it. You need to be able to have affordable costs. But then those viewers don't necessarily need to be talked back in real time. So latency in 10 seconds, 15 seconds is pretty fine. By the time a person's responded in chat, it should be pretty responsive. So the same technology doesn't really work well for both for a few reasons. So live chat is powered by browser technologies like WebRTC. So that's a suite of APIs that can be used for browsers to communicate with each other, peer-to-peer, get the browser's media, all those kind of things. Live broadcasting, on the other hand, is powered by technologies like RTMP. So RTMP is a server protocol, a communication protocol for delivering video. So it used to be used a lot more on delivery, but now it's kind of standard for getting a broadcast feed into a server. Then that server will transcode that to something for delivery to the end users that's a little bit more cheap and scalable, like HLS. And HLS is a format that basically takes video, chunks it up in small chunks, lists those chunks in a manifest, and then players can download the manifest and then keep pulling it for updates. But it can just be hosted on normal CDNs, just delivered like normal files, just HTTP. So it's really, really easy and understandable to scale, and it's cheap, relatively speaking. Okay, so you're probably thinking, if I need to get to RTMP first, let's just go WebRTC RTMP in the browser. The browsers are mostly like, nah, you unfortunately can't get low level enough in the networking level to be able to communicate over RTMP. Okay, so what about the technology we can access? What about the things that we do have in our toolkit? So spoiler alert, a server is going to be involved either way. You're just not going to get from a browser to RTMP without in some way involving a server. So WebRTC to server side implementations of WebRTC, it can be done. It's a little bit complicated. The WebRTC spec is large and daunting. This has gotten a lot better recently. There's projects like Pyon that really make this much easier, but it's still pretty daunting. So you're thinking WebRTC to a server side WebRTC implementation, but now that implementation is just headless Chrome. And this can be done. It's actually done really well. Once you're, you know, you basically can have a chat, the headless Chrome instance can just join that chat and record it. And the nice thing here is you're just using browser technologies, you can do overlays, you can do whatever you would do in the browser there, and then it's just in the stream. It's really, really cool. The problem is now you're having to run Chrome at scale for every single person that wants to do a live stream, which can be complicated. Okay, so what if we just used a piece of that WebRTC spec, get user media, which is the process of getting the browser microphone and camera, and then we'll just send that over WebSockets. WebSockets are understandable, the server side implementations are common, and things that we've all worked with, or a lot of us have worked with in the past. So let's try that. You might be thinking, how would that work? So first we would request the browser's media. So get user media is what I was talking about earlier. You can set different constraints. We'll just set audio and video to true, but you could adjust that if you wanted to. We'll set that stream, we'll add that stream to a video element so we can see it, and then we'll capture that stream, and then we'll pass that stream to the media recorder, to a media recorder instance. Or we'll create a new instance of the media recorder API, which just allows you to basically record content from a browser. And then that recorder will expose this data available event. So every time that event fires, we have a chunk of video, so we'll just fire that chunk of video down a WebSocket connection. I'm ignoring all the process of creating that WebSocket connection, but assuming we have a WebSocket connection, now we can just send that video down that WebSocket connection, which is great. So then the server side of things is also pretty simple and straightforward. We have this WebSocket, every time we get a new connection, we'll spin up a FFmpeg process. Here I'm using a MUX, or RTMP endpoint, but that could be anything. We'll do some cleanup if the FFmpeg process dies, or if the WebSocket closes, but otherwise, every time we get a new message and it's a buffer, we'll just write it to FFmpeg, and then FFmpeg will deliver it via RTMP. So this actually works pretty well. If you want to see a demo of this, you can check out a glitch. It's got everything running. You can see it working in the browser. It's actually pretty cool. It works pretty well. Here you just put a stream key. If you wanted to remix the glitch and use a different RTMP endpoint, totally cool. And I also wrote a blog post on this whole thing. So if you want to check it out, get more details, I go a little bit more into it. So thanks, everybody. Well, that's a lot of knowledge in just 20 or 28 minutes it was. Four great topics. I would like to invite all the Lightning Talk speakers with me on the stage to do the last round of Q&A of the day. Hey, everyone. Hello. Hey, there. Hey. Hello. Good morning, evening, night, whatever it is for you. Yeah, I'm going to go straight into the questions. I'm going to start with the first question from Matt McClure. What market are you targeting? And why would someone use Mux instead of Twitch or YouTube? Yeah, it's a valid question. We're a developer-facing product. So we're purely just APIs for developers to build into their platform as opposed to Twitch and YouTube, which are much more consumer-facing products. So if you're a streamer just looking to go live without writing any code whatsoever, those are great platforms you should probably use them. If you're trying to build a platform, we're probably a better fit there. Okay. So it's more about the target audience, I guess, and that you have more control over what you're doing. Yeah, I would think about it a little bit like a bad analogy that I mentioned in Slack is they're more like the PayPal or Venmo. We're more the Stripe, if you're thinking about it in terms of like payment APIs. Okay. Thank you. Thank you. The next question is for Jen. What are the reasons why someone like the React Native web team would want to use a div as a button? The reason is that putting HTML inside of a button is not actually semantic HTML. So they may want to wrap that content, for instance, a card or a block of like an image and text into a div and make that an accessible button instead of putting a button around it. Yeah. So if you have a completely clickable card with different elements inside it, you can do that semantically within a button. Correct. So in that case, you'll want to make an accessible div. Well, you should want to at least. Perhaps. And can I say, if you don't, Jen is going to come and get you. I will very kindly tap you on the shoulder and make suggestions. How about that? Yeah, but tap doesn't work. Then I might hack it. Yeah. Yeah. Not a question, but just for you a nice tap on the shoulder from Martin van Houten. Not really a question. I just want to say Mesh looks awesome. Well, that's always nice to hear. Thank you very much. I hope that you feel the same and not hate me. Well, actually, at the company I work for, Albert Heijn, we are using it. And I have to say it's been a pleasure. So thanks a lot. Oh, you're my neighbor. I can come visit you. It would be a pleasure. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Mike, does Ionic support native apps similar to React Native or is it like a Cordova standard app where it's a web UI instead of a native app? So it's kind of a mix of both where the majority of the UI is displayed in a web view. But you can integrate with custom native views or activities on Android and kind of mix which one gets displayed, the web view or the native view, or even just overlay the native view on top of the web view. So you get kind of the best of both worlds. That feels powerful. Okay. Thanks. Thanks, guys. And my lady for this great talks. For the people watching, they're also going to be in the Zoom rooms for questions. But the formal part is now over. I'm going to say goodbye to you for a little bit. So thanks for joining. Thank you. Thank you. And have a great day.


Matt McClure

JSNation Live

JSNation Live 2020

There are other ways to proxy live video from a browser to an RTMP endpoint, but what if we wanted to interact with that stream first? And not just interact writing obtuse ffmpeg filters, but just some good ol' HTML and CSS? Let's do that! We'll talk about how you can allow your streamers to go live directly from their browser using headless Chrome and ffmpeg. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Going Live from a Browser...with Another Browser

Hey everybody, my name is Matthew McClure. I'm one of the co-founders of Mux and we do online video infrastructure for developers. So one of our features is an API to live broadcast and that's where we get a ton of questions from developers on how to help their customers go live. They're in a world where they want to just build an application in a browser, let the user just log in and immediately go live without needing to download third-party software like OBS or something like that to be able to do it. Totally makes sense. So but today we're not talking about just going live from the browser. We're talking about going live from the browser via another browser. This is also probably a bad idea for most use cases, but when you need this kind of thing, this can be a really great path forward. So we covered something similar or another path to do this at React Summit. So we're going to quickly recap some of these like high-level concepts just to get on the same page, but if you want more information, you might want to check out that talk as well. You can just find it on YouTube. So common misconception is that live broadcast is the same as live chat. So live chat, you have two browsers that can communicate or a few browsers that can communicate directly to each other, sub-500 milliseconds of latency so they can talk synchronously. Live broadcast, on the other hand, is one-to-many. So you have one input stream out to many viewers, and that can be 50 to a million viewers. Latency can be 10 seconds plus. It's fine because there's not really an expectation to be able to communicate back to that streamer. So because of those constraints, the same technology really doesn't work very well for both of them. For live chat, it's typically powered by browser technologies like WebRTC or proprietary implementations that can allow you to communicate directly between the streamers so that you have as low of latency as possible. Live broadcast, on the other hand, is powered by technologies like RTMP and HLS. RTMP is kind of an old Flash implementation that has become the de facto standard for being able to ingest live content directly into a server, which then will transcode that content and then broadcast out via HLS. We won't get into the specifics of HLS, but for our purposes, it allows you to download video via Git requests on the browser, and you can just scale it as you would any other file transfer. It's really nice. Okay, so let's just take WebRTC and then turn that into RTMP in the browser is probably what you're thinking. Unfortunately, no.
We can't get quite low enough in the network stack in a browser to be able to do it. So even in our current modern world of WASM and all this other goodies, we just can't quite get there. 
But let's talk about what technologies we can access. So whatever we're talking about here, it's all involving a server in some way. But the first way is we can take WebRTC and then use a server-side WebRTC implementation. So if you'd asked me a year ago, I just said, this is crazy. This has gotten a lot better. Projects like Pyon have come a really long way. It's a per year ago implementation. So this actually isn't that crazy anymore, but it's still not... It's certainly not the easiest way that you can get this done. And if you want to be able to do anything interesting with the video on the server side via client-side technologies, this would kind of leave you in the cold a little bit. 
So to fix that last thing, what if we just took WebRTC, ran it on a server via Chrome? It can be done, but the problem is now you're running Chrome. Or we can take GitUserMedia, which is just a few of the WebRTC APIs that allow you to get the microphone and camera. We'll broadcast that to a server via WebSockets and then encode into RTMP. So you might be thinking, how does that work? Let's go back to this headless Chrome thing. If you want more information on that one, you can talk about the other talk I mentioned. Or you can go watch the other talk I mentioned. So WebRTC to a server-side WebRTC via headless Chrome. Kind of cool. You can just have a chat, one-to-one, few-to-few, have headless Chrome join that chat, broadcast that via RTMP. Really interesting. Like, you want to hide that Chrome in the client of the other chatters, but that Chrome can then lay out the chat interface how it wants, add overlays, anything like that right there. So what about these downsides? You have to run one Chrome per input stream or per output stream. And so you have all the orchestration that comes with that. 
So if you use Chrome as your normal browser, you might notice it's 
resource-intensive. That also applies on the server. The bigger issue, 
though, is it's not the most beaten path. Like, a lot of people are doing 
this. They're just not talking about it.

The exception is open-source projects like Jitsi, which if you're not 
familiar, is like an open-source Zoom competitor. That's how they do 
one-to-many broadcast or a few-to-many broadcast. So there are a few paths 
to get this done, which come with a few tradeoffs. One is to do this 
getUserMedia style approach and then broadcast that to a server via 
WebSockets. You might be thinking, like, wait, why are we talking about 
this again? It's not actually getUserMedia. Now we're going to use the 
Chrome.tabCapture, but it uses a very similar API under the hood. It uses 
the same internals as the MediaRecorder API, which is what we would use in 
that implementation. So here we take WebRTC, same process where we have it 
in the browser that joins, call the tab capture API, broadcast that via 
WebSocket to a server that encodes it in RTP and goes to the rest of the 
workflow. Those can be on the same server, but that's kind of the high level. 

The pros are that you can actually run Chrome in headless mode, which 
means you get much more multi-tenant, much easier multi-tenant access. You 
get all these browser features. We can use the fancy WebSocket workflow. 
The downside is it still uses the MediaRecorder API, which is kind of a 
disaster. If there's no changes in the tab, it won't send any frames, which 
can make encoders barf. And it's the MediaRecorder API, that process for 
encoding video is really inefficient, so it can use a lot of resources, 
even more than Chrome itself. So this is probably the most common way you 
see this done in the wild, surprisingly. However, we think there's a better 
way. Like what if we just took WebRTC, had a whole Chrome instance that's 
actually there, captured that, and then broadcast that via RTMP. So here's 
a really high level script. You can scan over this, but the workflow looks 
something like this.

You could have a Chrome that is in a headless mode, and a headless mode is 
a feature that was added to Chrome that allows you to run Chrome without 
good UI. So you can run Chrome and be able to interact with it without 
having to actually see it. And it's run here in a headless mode. So you can 
have your Chrome instance. And then you can have a WebSocket server that 
listens to that Chrome instance. So you can have the WebSocket server 
listen to the Chrome instance. And then you can have your WebSocket client 
and your WebSocket server, which is an RTMP server, which is your WebRTC 
server. And then you can have an RTMP client, and that could be, for example, 
OBS. And you can send frames from there, from OBS, to your WebRTC server, 
and then from your WebRTC server to wherever you want to send it, for 
example, YouTube.

You start your server. This will give you the static files that you want to serve. Give yourself a screen to work with, actually on the server via XBFB. Capture that screen with FFmpeg, and then start streaming it somewhere. And then open Chrome to a page with your stream in it. And then whatever you do from there is up to your imagination. You want to open Chrome in full screen mode, but that's kind of it. So the pros are that no MediaRecorder API. It's more reliable to stream because you're using FFmpeg, which is designed and built for this. It's a much better tool for this use case. The con is that you need a full Docker container, a full instance for each stream. But once you have this working, you can do whatever you want with the stream before you send it out, which is amazing. Also it's compositing and everything. So if you want more information on the process of doing this, check out Nick's talk from All Things RTC. muxing.com and broadcast him if you want to see the source. Otherwise, thank you so much, everybody. I really appreciate your time. Ask me if you have any questions.

JSNation Live 2021

Synchronizing multiple streams, particularly multiple live streams, and especially when the audio is critical too, can be incredibly difficult. How, then, could you build an experience where you have a few camera angles and you want a viewer to be able to seamlessly pick one? We'll walk through a hack technique that allows you to do just that without ever having to worry about synchronization. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Remember CSS Sprites? Let's do that with video!

Hey everyone, today I want to talk about something a little hacky I've been thinking about lately, but the idea here is that we want to use video sprites in the same way that a lot of you might have used CSS sprites back in the day. So we'll talk about what I mean by a lot of this. But hello, I'm Matt McClure, I'm one of the co-founders of a company called Mux, and I run the developer experience org there. And in a nutshell, we build awesome video infrastructure for developers. So if you're looking for a video API, we're there. So check us out. So okay, taking a step back, what is a sprite? So in a nutshell, this is an image with a bunch of images in it. So the client gets this big combined image and then can just pick and choose which parts of it to show. So if you're relatively new, then you might not have seen this as widely used, but this is a really common optimization technique from the early aughts. So if you had a button with hover states and depressed states and active states, then you would just send one button image and then use your CSS background to decide which one of that image to show. So a little bit more common if you're kind of started there. You might remember this from back then. But to show this a little bit more concretely, a lot of people know about this from video game sprites. So all of Mario's states are in one image and then the client viewport just shows the state of Mario at once. So you might be wondering what in the world does this have to do with video? The gist here is the same technique works. You can send a few videos combined into one and then just show the one you care about in the player. 
So you might be wondering, like, why? Why in the world would we be doing this? And I would say, you know, use your imagination. There could be a bunch of examples of this. Like I think sports, sporting events, concerts. But the biggest example that comes to mind and what we see the most from customers wanting to do stuff like this is around feed synchronization. Particularly around, like, being able to pick between these different feeds in a synchronized way. So let's say you're streaming live concerts, live music. So you've got a bunch of different cameras streaming a bunch of different angles. So one's on the drummer, one's on the singer, one's on the audience. And a producer on site is typically deciding which one of those feeds to show at any given time.
So they might do a nice little transition, go from the drummer to the audience, et cetera. That producer then sends a feed to an encoder service or whatever else that looks like.
I'm using Mux as an example here for obvious reasons. But then that service then broadcasts that to all of your end viewers. So then those viewers start saying, like, actually, I just want to watch the drummer all the time and I hate the transitions that this producer is doing. So they want the power to be able to pick which feed they watch. So you decide, okay, how can we go about building this out?
So you start thinking, okay, I'll send every camera directly to that encoder or broadcast service. And then every viewer can get all the feeds. In this example, three feeds. And this is where things really get hairy if you start going down this path.
So now you've got three different live streams that people can watch. But how do you switch between them? So do people just click another feed and then you might be a few seconds off in terms of audio for all of them? So it can be tough to synchronize that in the client or honestly next to impossible to do that well.
So one solution would just be to send one video again. So like you were doing before, but instead of that video being produced, you just combine all the feeds at that level and then send them along. So in this example, all the cameras go into that one encoder box locally. It just lays them out in four quadrants, sends those to the encoder broadcaster service, and that goes out to all the viewers. And then from there, the viewers can then pick which one they want. So now you're guaranteed that your feeds are synced. You only have to worry about one audio stream that's shared between all of them for obvious reasons. And then you only show the quadrant of the video that the viewer selects in any given time.
So how might this work detail-wise? So all this code's on GitHub. I would just say just checking it out there. But at a high level, you want to grab the coordinates of the feed that you want to show. So I have the feeds just named like zero through three. And you want to lay those coordinates out.
So it's in this example, this array is the source X, source Y position, source width, and source height. So what you want to chop. So zero, zero, top left. Zero, half the video width is the top right quadrant, and so on and so forth. And since these are quadrants, you just each one is half the video height and half the video width. And then you use these when you're updating the canvas. So when you draw that image to the canvas, you draw the video image or you pass the video image in and then you pass these coordinates that we just grabbed, which will then say like okay, only draw the top right quadrant of the video into canvas. And then, you know, call request animation frame over and over and over again. So if you want to go have a play, it's just video-sprites.mux.dev. And then the source is all on GitHub.com. But real quick, I wanted to just show you what this looks like. This is just video-sprites.mux.dev. I just have a bot asset in here, but this could also work with live, whatever else. Here's some smooth stream music. So it works surprisingly well. The gotchas here that I would call out are that you should keep in mind that you're only going to be able to broadcast a subset of whatever your top level is. So if your streaming service is limited to 1080, for example, then each one can only be a quarter of that, which is fine for most examples. Once we get up to 4K for really a lot of services supporting, then you could do 1080 for each quadrant. But that's the one thing to keep in mind and all the other gotchas with canvas. But thanks so much for listening. If you decide to use this at all, please let me know. Shoot me a note at Matt McClure on Twitter. And otherwise, if you want any video stuff, check out mux.com. All right. Thanks, everybody.

React Summit Remote Edition 2021

Remember CSS Sprites? Let's Do That with Video!

Hey everyone, today I want to talk about something a little hacky I've been thinking about lately, but the idea here is that we want to use video sprites in the same way that a lot of you might have used CSS sprites back in the day. So we'll talk about what I mean by a lot of this. But hello, I'm Matt McClure, I'm one of the co-founders of a company called Mux, and I run the developer experience org there. And in a nutshell, we build awesome video infrastructure for developers. So if you're looking for a video API, we're there. So check us out. So okay, taking a step back, what is a sprite? So in a nutshell, this is an image with a bunch of images in it. So the client gets this big combined image, and then can just pick and choose which parts of it to show. So if you're relatively new, then you might not have seen this as widely used, but this is a really common optimization technique from the early aughts. So if you had a button with hover states and depressed states and active states, then you would just send one button image and then use your CSS background to decide which one of that image to show. So a little bit more common if you're kind of started there. You might remember this from back then. But to show this a little bit more concretely, a lot of people know about this from video game sprites. All of Mario's states are in one image, and then the client viewport just shows the state of Mario at once. So you might be wondering what in the world does this have to do with video? The gist here is that the same technique works. You can send a few videos combined into one, and then just show the one you care about in the player. So you might be wondering why in the world would we be doing this? And I would say, you know, use your imagination. There could be a bunch of examples of this, like I think sports, sporting events, concerts. But the biggest example that comes to mind and what we see the most from customers wanting to do stuff like this is around feed synchronization, particularly around being able to pick between these different feeds in a synchronized way. So let's say you're streaming live concerts, live music. So you've got a bunch of different cameras streaming a bunch of different angles. So one's on the drummer, one's on the singer, one's on the audience. And a producer on site is typically deciding which one of those feeds to show at any given time. So they might do a nice little transition, go from the drummer to the audience, et cetera. That producer then sends a feed to an encoder service or whatever else that looks like.
I'm using Mux's example here for obvious reasons. But then that service then broadcasts that to all of your end viewers. So then those viewers start saying, like, actually, I just want to watch the drummer all the time, and I hate the transitions that this producer is doing. So they want the power to be able to pick which feed they watch. So you decide, okay, how can we go about building this out? So you start thinking, okay, I'll send every camera directly to that encoder or broadcast service. And then every viewer can get all the feeds, in this example, three feeds. And this is where things really get hairy if you start going down this path. So now you've got three different live streams that people can watch, but how do you switch between them? So do people just click another feed, and then, you know, you might be a few seconds off in terms of audio for all of them. So it can be tough to synchronize that in the client, or honestly, next to impossible to do that well.

So one solution would just be to send one video again. So like you were doing before, but instead of that video being produced, you just combine all the feeds at that level and then send them along. So in this example, all the cameras go into that one encoder box locally. It just lays them out in four quadrants, sends those to the encoder or broadcaster service, and that goes out to all the viewers. And then from there, the viewers can then pick which one they want. So now you're guaranteed that your feeds are synced. You only have to worry about one audio stream that's shared between all of them for obvious reasons, and then you only show the quadrant of the video that the viewer selects at any given time. So how might this work detail-wise? So all this code's on GitHub. I would suggest checking it out there. But at a high level, you want to grab the coordinates of the feed that you want to show. So I have the feeds just named like zero through three. And you want to lay those coordinates out. So it's in this example, this array is the source X, source Y position, source width, and source height. So what you want to chop. So zero, zero, top left. Zero, half the video width is the top right quadrant, and so on and so forth.
And since these are quadrants, you just each one is half the video height and half the video width.
And then you use these when you're updating the canvas.
So when you draw that image to the canvas, you draw the video image or you pass the video image in and then you pass these coordinates that we just grabbed, which will then say like, okay, only draw the top right quadrant of the video into canvas.
And then, you know, call request animation frame over and over and over again.
So if you want to go have a play, it's just video-sprites.mux.dev.
And then the source is all on GitHub.com slash muxlab slash video sprites.
But real quick, I wanted to just show you what this looks like.
This is just video-sprites.mux.dev.
I just have a bod asset in here, but this could also work with live, whatever else.
Here's some smooth stream music.
So it works surprisingly well.
The gotchas here that I would call out are that you should keep in mind that you're only going to be able to broadcast a subset of whatever your top level is.
So if your streaming service is limited to 1080, for example, then each one can only be a quarter of that, which is fine for most examples.
Once we get up to 4K for like really a lot of services supporting, then you could do 1080 for each quadrant.
But that's the one thing to keep in mind and all the other gotchas with canvas.
But thanks so much for listening.
If you decide to use this at all, please let me know, shoot me a note at Matt McClure on Twitter.
And otherwise, if you want any video stuff, check out mux.com.
All right.
Thanks, everybody.