On the April 10, 2024 episode of WebRTC Live, Arin welcomed industry guest, Dan Jenkins for a discussion on a wide range of real-time and broadcast technologies and where WebRTC stands amidst these advancements. Dan shared the latest updates on the WHIP/WHEP protocols, discussed unbundling with WebTransport and WebCodecs, and delved into other cutting-edge technologies including Media over QUIC and SRT.
Dan Jenkins is the founder and CEO of Nimble Ape and Everycast Labs and the organizer of CommCon, the only residential RTC and Open Media event in Europe (this year in the US, too!) He’s also built Broadcast Bridge, a tool designed to easily incorporate remote presenters and participants into livestreams and broadcasts.
Read Key Insights and Episode Highlights below the video.
Watch Episode 90!
Episode Highlights
WHIP is similar to WHEP, but in reverse
WHEP makes getting low-latency media easier. It’s like WHIP, but in reverse: you ask for media instead of starting a session. This makes real-time communication smoother and more accessible for everyone. It also opens the doors for a lot of flexibility and a lot of scalability.
Dan explains, “What happens if you want to receive that low-latency media? Well, today, before WHEP, you would have to write this custom stuff and to be able to talk to a custom media server somewhere, whether or not that was hosted by Twilio Video or whoever, right? So, WHEP is exactly the same as WHIP, but it’s the other way. It’s: I want to receive this media, and I want to do a HTTP request with an offer. There’s a bit of debate here. I’d love server offers here, but part of the spec today is you do an offer from the client to say: I can accept audio and video. Then the server says: ah, I’ve got some video for you, and it’s in this format. So, WHIP is almost at the end of its journey through the IETF, and it’s almost a proper spec. WHEP is still quite far away from that and of being a proper spec. It’s a draft but it means you can write really nice things that publish from A, and then you receive in B with essentially doing two HTTP calls, and that’s it.”
WHEP’s delay is mainly because of congestion, not technical problems
WHEP is behind WHIP, but it’s not because of technical issues. Dan explains the key reasons, “We all love WebRTC, but there’s a whole load of other people from broadcast think WebRTC is horrible because it degrades and it gets rid of media when it needs to, and it drops packets, right? And this is all bad when it comes to broadcast. And so I think it was: A, they [WHIP and WHEP] were started at different times. B: they wanted to get WHIP right and done almost before starting WHIP and then and then C: probably the most important one was can we even get things like OBS and GStreamer and FFmpeg and like being able to get behind WHIP because if no one else got behind it, then it was kind of a useless journey.”
The rise of WebRTC, WebTransport, and WebCodec has made media sharing easier and more customizable
This is an exciting time for media delivery, as users can now share content smoothly from any device with better control. Dan explains, “Across every single mobile device, you can go to a URL, and it will load up. And then you can share your media wherever, whether or not that’s with WebRTC, or whether or not that’s with something new, like WebTransport and WebCodec, and being able to send media in a more controlled way. That’s a good way of talking about it, right? WebRTC is very much a black box, in the browser, it’s very much a black box. You put your media into it, and it sends it because, ultimately, all the browsers are using libwebrtc underneath. With WebTransport and WebCodec, you’ve now got control over how much delay do we put in? How much other stuff do we put in? And so, we’ve now, in the past three years or so, suddenly got this extra superpower that’s kind of making its way into web browsers. It’s really an exciting time when it comes to delivering media from any device in the world.”
What is the future of WebRTC?
As new communication technologies like QUIC gain traction, big companies might lose interest in supporting WebRTC. It’s a reminder of how quickly technology can change and how important it is for companies to keep up with those changes to stay relevant.Dan shares his thoughts on the future of WebRTC, “My biggest fear is… WebRTC is not going to die, but when media over QUIC, when WebTransport, when WebCodec kind of becomes more of a thing, will the likes of Google and Microsoft and Cisco and all of these big players that kind of came together to make WebRTC what it is today, well, they’ve all kind of got annoyed with being constrained by WebRTC at the same time, they all had to make compromises. Whereas now with media over QUIC, they’ve got the potential to not be constrained anymore, and they can go and do their own thing. And so are we about to see a shift in WebRTC where there’s less interest in it from those big players and that that interest properly shifts over to media over QUIC, to QUIC, in general?”
Key Insights
⚡WHIP enables quick and low-latency media sharing. WHIP makes setting up WebRTC sessions easy. You send a request, get a response, and you’re connected. It’s like using a simple web interface for real-time communication, making media transmission fast and hassle-free.
Dan explains, “WHIP is being able to form a WebRTC session with another peer, whether or not that’s a server. It could even be another peer behind another firewall if you do it properly. But ultimately, it’s a signaling protocol that’s based off of HTTP. You do a post with an offer and then you get an answer back from that post. […] It makes it really, really easy to get going, sending your media from A to B in really low latency. Remember, we’re sending media from a browser or another WebRTC device in 40 milliseconds or even less in some cases. So it’s meant to be really simple to be able to send low latency media.”
⚡The integration of WebRTC into broadcasting presents both opportunities and challenges.
Dan says, “There’s pros and cons on lots of different levels, right? It’s important to remember why WebTransport and WebCodecsbecame more of a thing. It was because of Zoom. So Zoom in the browser didn’t like having to use the stuff built within libwebrtc. They wanted more control. And so they would get their video and audio and do stuff to it, and then they’d send it over a WebRTC data channel because it was the only way the replacing WebRTC blog post that you were just talking about talks about it. It used to be the only way to get UDP out of a browser: the WebRTC data channel. So it gives us a lot of flexibility to be able to do loads of great things, and this is really exciting for the whole industry. But we’re actually still in early days in the whole picture.”
⚡WebRTC offers a lot of freedom, but it also demands more hands-on control.
Dan explains, “We’ve got a load of flexibility coming, but it means that you’re having to really be in control, right? If you want to send media from A to B, then you need to have a codec that you’re going to put stuff into. And then you need to have a way of sending that media up to a server you over QUIC. They might be open source things, but they’re kind of proprietary at the end of the day, right? It’s not WebRTC that kind of just works. So there’s ease with WebRTC, but there’s also complexity with WebRTC, because you’re constrained to the way that libwebrtc works.”
Up Next! WebRTC Live Episode 91
Advanced Audio Processing Techniques for WebRTC
with Jim Rand and James Meier of Synervoz
Wednesday, May 15 at 12:30 pm Eastern
