Going Live from your Browser without WebRTC

Rate this content
Bookmark

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.

This talk has been presented at React Summit Remote Edition 2020, check out the latest edition of this React Conference.

FAQ

Mux provides an API for online video infrastructure, including live streaming solutions that allow the creation of live streams. They offer a stream key for users to push RTMP feeds, suitable for live broadcasts.

Currently, Mux recommends using native software like Open Broadcast Studio or Wirecast for live streaming. Direct browser-based solutions involve more complex setups involving servers due to limitations with RTMP communication through browsers.

Live chat involves direct, real-time video communication between two or a few users, often peer-to-peer, requiring low latency. Live broadcast refers to streaming from one source to many viewers, where real-time interaction isn't necessary, allowing for higher latency.

Live chat is typically powered by WebRTC, which supports peer-to-peer browser communications. Live broadcasting often uses RTMP for sending broadcasts to a server, which then uses formats like HLS for scalable, cost-effective delivery to viewers.

Direct live broadcasting from browsers using WebRTC to RTMP is not feasible due to browser restrictions. However, server-side implementations of WebRTC can process the data for broadcasting, though they require more complex setups.

HLS (HTTP Live Streaming) is used in live broadcasting to deliver video efficiently. It chunks video into small segments listed in a manifest, allowing for scalable distribution over CDNs using simple HTTP transactions.

Mux targets developers needing APIs to build live streaming into their platforms, offering more control over the streaming technology. In contrast, Twitch and YouTube cater more to individual streamers and consumers with user-friendly interfaces but less customization.

Matt McClure
Matt McClure
13 min
02 Aug, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The video discusses how to enable users to go live from a browser without relying on WebRTC. It explains that while WebRTC is suitable for live chat, it does not work directly with RTMP, which is used for live broadcasting. To achieve live streaming from a browser, the video suggests capturing the browser's microphone and camera using the getUserMedia API and sending the data over WebSockets. On the server side, FFmpeg can then process this data and deliver it via RTMP. The video also touches on the differences between live chat and live broadcast, noting that live chat is for direct communication between users, while live broadcast is for one-to-many streaming. For those looking to integrate live streaming into their platforms, Mux provides APIs that offer more control compared to consumer-focused platforms like Twitch or YouTube. The video also mentions that running headless Chrome at scale can be complex but allows for incorporating browser technologies and overlays into the live stream.

1. Introduction to Live Streaming and User Experience

Short description:

I'm Matthew McClure, co-founder of Mux. We provide an API for live streaming. Users often ask how to let their users go live from a browser. Current recommendations involve using native software, but people want to keep users in their own applications.

So, let's get started. 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 broadcasts, 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 and make them download and learn a new technology. So, it's understandable why they want to, but unfortunately it's not quite that easy.

2. Difference between Live Broadcast and Live Chat

Short description:

Live broadcast and live chat are often confused, but they are different. Live chat is for direct communication between two users, while live broadcast is for one person broadcasting to many. Live chat uses WebRTC, while live broadcast uses RTMP and HLS. WebRTC cannot directly communicate with RTMP, so a server is needed for the conversion.

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. 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, in 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. You start getting up to like 500 milliseconds, it gets really hard to actually have that one-to-one conversation. You can maybe even have a few peers here. So, that can get 3, 5, 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. So now, you're not talking any more 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, you know, 10 seconds, 15 seconds, is pretty fine. By the time a person's responded in chat, it should be pretty responsive. 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 browsers' 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 into 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, it's just delivered like normal files, it's just HTTP, so it's really really easy and understandable to scale, and it's cheap, relatively speaking. Ok, so you're probably thinking, if I need to get to RTMP first, let's just go WebRTC to 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. Ok, so what about the technology we can't access? What about the things that we do have in our toolkit? So spoiler alert, a server is going to be involved either way.

QnA