On the June 18, 2024 episode of WebRTC Live, Arin welcomed Pion founder Sean DuBois to talk about about broadcasting with WebRTC and OBS.
Sean is very active in the WebRTC community. He is the creator of Pion (a WebRTC implementation 100% in Go), a developer at Twitch, Field CTO for LiveKit, and author of WebRTC for the Curious.
Bonus Content
- Updates from CommCon
- Our regular monthly industry chat with Tsahi Levent-Levi.
Key Insights and Episode Highlights below.
Watch Episode 92!
Key Insights
⚡ The pros and cons of using WebRTC in a broadcasting environment. WebRTC offers several unrivaled benefits for interactive broadcasting, such as low latency. But it also has some important drawbacks that need to be considered. Sean explains, “For me, WebRTC, the pro is that if you use other protocols that have higher latencies, you’re going to have to have two systems where if I want to use a protocol with higher latency, then I have users that come to me and say, ‘Hey, I really want low latency’ you’re going to have to have WebRTC and your other protocol infrastructure. But with WebRTC, the problem is, okay, it can do low latency, but the challenge is growing it up to do higher latency, which is a solvable problem. It’s a solvable problem. It will take work, and we’ll have to figure it out, but it’s an intractable problem to grow a slow protocol down.”
⚡ Simulcast holds great potential for broadcasting. Simulcast enables more efficient and higher-quality streaming because broadcasters can directly control video quality by encoding from their own devices. This means they can ensure better broadcast quality without relying on potentially lower-quality server-side transcoding solutions.
Sean explains, “What really is really cool is since I’m encoding it in the client, I can choose exactly what I want to send. If I’ve got a bunch of really nice hardware, I can send 10 ADP and do it the best quality possible. My experience with talking to all these companies that do server side transcode, they’re always trying to push costs down. Even if you depend on someone doing the transcodes for you, they’re always going to be lower quality because these companies are trying to save money. So Simulcast is kind of, the way I see it is, it’s like putting the control back into the broadcaster that you can have the best experience possible that you care about.”
⚡ Can WebRTC broadcasting consistently provide HD quality? One of the key uses of WebRTC is broadcasting, which allows the streaming of live videos to online audiences. But an important question arises which is whether WebRTC can reliably deliver HD-quality video. Sean says, “There’s a misconception that WebRTC is tuned to be something for low latency or it’s tuned to be for low bitrates. WebRTC is just a road and you decide what kind of car you put on it. With WebRTC, I can set the RTP play out header to be three seconds, and I can push 4k, and nothing says that I even have to use the browser. So yeah, that’s what I hope to solve with things like WebRTC for the Curious. It’s like someone can go read that and kind of like pick the pieces together. […] These things are always changing and what we would perceive as high quality now will be table stakes in the future.”
Episode Highlights
Simplifying broadcasting with WebRTC
Sean’s main focus right now is to simplify broadcasting and the tools used for it. He aims to do this by reducing technical barriers and making broadcasting more accessible for everyone. He explains,
“The thing that I’m most interested in right now is making broadcasting easier and also making the things that people build with broadcasting easier. So, about two years ago, I added WebRTC to OBS. Another developer had already started it where he had created a PR to add WHIP support to OBS. He had written it in Rust, and I got involved, and kind of took it over. So now you can do this WHIP output. And then what also was really important to me is I wanted to make broadcasting as easy as possible. Setting up RTMP and HLS and all the bridging and transcoding is very hard. So, I made an easy self-hosted server called Broadcast Box where you can just ‘docker run,’ and you can run it on your AWS instance or Digital Ocean instance, and you can broadcast out to your friends very easily. So I wanted to solve these two problems of low latency with WHIP, but also just make it easier to build these things.”
Is QUIC the future of media transmission?
QUIC holds great promise for the future of media transmission due to its advantages in speed, security, and simplicity. However, Sean is torn between continuing with the challenges of WebRTC or making the leap to QUIC. He explains,
“I see all of these multiple efforts to bring media over QUIC into the space. And some of the things I’ve heard about that are exciting is that media over QUIC, it talks about this idea that we will only have to have one server o, instead of having your WebRTC media servers and then your HTTP servers, you just have one server, and it covers everything. It just sounds interesting to me. That would be great if we had that. The other thing I hear is switching to QUIC is like… We all want to get to one place where we have like really easy video infrastructure. And right now we’re on the WebRTC road, but it has potholes and all these problems. And I don’t want to start over because I feel like we’re getting to a destination. But someone told me, ‘Let’s start over on this QUIC road, and because QUIC is a better road, we’ll get to our destination faster, even if we have to start the trip over.’ So, this is kind of an existential problem I have. I’m like, should I start over because I’ve worked so hard to get it in clients and make it in compliance testing, all these things?’”
Scaling WHIP and WHEP is straightforward because it reuses HTTP
According to Sean, scaling WHIP and WHEP is remarkably straightforward due to their reliance on HTTP. He explains, “As far as scaling WHIP and WHEP, I find it really, really easy because it reuses HTTP where if you’re defining a new protocol, there’s all these things you don’t anticipate, or you don’t realize, and because WHIP and WHEP is using HTTP, I can reuse all of these nice things that already exist. I think that’s kind of the superpower here that I can add arbitrary HTTP headers. I can do redirects. We’ve had like 30 years now of prior art on how we scale HTTP services, that makes it super easy. It’s not a new protocol. So that’s the superpower here.”
Up Next! WebRTC Live Episode 93
Tools for WebRTC Hacks with Chad Hart of webrtcHacks.com
Wednesday, July 10 at 12:30 pm Eastern
