So let's start, so our next talk is about two very interesting words, broadcast and
WebRTC.
Please welcome Dan.
Thanks everyone.
So yes, merging two worlds, broadcast and WebRTC.
So yes, I'm Dan Jenkins, I've been doing stuff with WebRTC for probably just over ten
years now, and I guess very recently I've been more involved in air quote broadcast,
and there are the ways that you can talk to me, email, Twitter, that thing that's about
to die, and Masterdom.
So merging two worlds, broadcast and WebRTC.
So I guess to talk about WebRTC and broadcast, we need a few definitions of some of the things
we're going to talk about.
So WebRTC, what is WebRTC?
How many in the room know about how WebRTC really works?
Hands up.
Okay, about 25% of you, so that's good.
So WebRTC is encrypted by default, sub-second glass-to-glass, soap and source completely,
two-way communications, no defined signaling, which is kind of a good thing, and it's got
a load of required codecs that you have to implement to be compliant, I use the word
compliant, I don't think anyone's actually going, you're not compliant, but hopefully
they will one day.
It's embedded in every single browser, so that's the key thing here, every single phone
in every single pocket can do WebRTC without having to download anything, and that is the
key thing.
You can use your own codecs, but you can't use them from within a browser today, you
could build something natively and use your own codec, but takes away some of the magic.
Delivery is over UDP, and it's got a load of NAT busting stuff with what we call ICE,
and there's one main thing called lib WebRTC that everyone talks to everyone else about
as though it's WebRTC, it's not, there's lib WebRTC provided by Google, but they don't
really provide it anymore as pre-built stuff, but then there are loads of other open source
independent versions available in many different languages.
No signaling defined in the spec, so that's a big thing here, it was a good thing when
it got made, when WebRTC first kind of became a thing, we'll come back to that later.
So then there's SRT, SRT is a secure reliable transport, how many people in the room use
SRT or know how SRT works?
Probably about 25%, but it was a different 25% than before mostly.
So again, it's open source, it's used heavily in the broadcasting industry, it is UDP based,
it really requires native apps, no browsers involved at all.
It can be encrypted optionally, most people use it encrypted, but you can use it without
and it is completely and utterly codec agnostic, but again there are usually pre-defined that
people use.
It can be sub-second, but usually it's not, and it can be used within, across the internet
or within a LAN, NDI, how many people in the room have used NDI and know how it works?
About 25%, some of the same crowd again, so network device interface, I mean who came
up with the stupid name like that, by network device interface, so what am I actually doing?
I hate the, I always forget what it's actually referring to, it is not open source and it
comes in multiple forms, so there's pure NDI which gives you a huge amount of data, then
there's HX, HX2 and HX3.
Designed to work only within a LAN, yes you can make NDI work across the internet now,
but it's not really NDI, it's actually using WebRTC to do some of the magic.
So ultimately it's designed to work within a LAN and it's not open source, but it is
free to use, but the licensing is a little bit confusing, some of the times.
So yeah, it's a bit of a weird one, but again it is hugely popular, and yes it uses UDP
as well.
All the good things with media use UDP, right?
Then there's RIST, how many people have actually used RIST, okay, how many people understand
how RIST actually works?
So for the recording, I don't know, 1% of the room, 2% of the room.
So RIST is actually really quite interesting, it is reliable internet stream transport,
and to be honest I've never used it, but I had to learn how it actually works to be
able to confidently talk about it in front of you guys.
So again it's open source, it's UDP based, it is encrypted, it's RTP based, and it's
relatively new in the grand scheme of things, and it can work within a WAN or a LAN.
The other forms of media transport are not worth talking about right now, because they're
not really real time, and I know some of you are going to look at me and go, hmm, but bear
with me.
So merging two worlds, WebRTC and Broadcast, and Broadcast and WebRTC, they're two worlds
that have not really come together in the past 10 years.
I know lots of people from the Broadcast industry look at WebRTC as a dirty thing, it doesn't
do this and it doesn't do that, but hopefully that's all changing for the better.
So they can now live in harmony, hopefully, maybe.
So because of something called WIP and WEP, so let's take a look at WIP and WEP.
WIP stands for the WebRTC HTTP ingestion protocol, and this is how it works.
I'm not going to bore you going through that, but I mean ultimately there's an HTTP request,
request response, and then media flows.
It should be as simple as that, right?
Then there's WEP, which is the WebRTC HTTP egress protocol, kind of looks similar, right?
So that's really great.
And then there's this third one called, whoa, WebRTC HTTP offer answer protocol.
I wish it did exist, I think it would be really cool, but it doesn't exist.
I messaged the author of both WIP and WEP this morning and went, we can just get rid
of WIP and WEP and just have, whoa, but no.
So yeah, these strangely look like signaling protocols to me, right?
And I said it was really great that WebRTC didn't have a signaling protocol, didn't I?
Well it was great back in the day.
It drove innovation.
It drove many, many different applications to do things in their own way that made sense
to them.
They didn't have to use XMPP, they didn't have to use SIP.
They could if they wanted to, and many did.
Or you could go build something yourself using a JSON API, GraphQL, whatever suited you
the most, right?
There was no defined way of going, here's an offer and here's an answer.
It was great until it wasn't.
I say it wasn't because no enforced signaling protocol meant that there was a lack of industry
support.
So we had all of these islands that didn't really know how to talk to one another.
One of those problems that Matrix is trying to solve.
But ultimately we had the likes of Jitsi and Teams and Google, Google me and whatever else,
all doing great WebRTC things.
They're quite great, but none of them could like interrupt with one another and that was
a real shame and it meant that when we came to the broadcast industry, no one wanted to
say implement, oh, how do I talk to Milikast?
How do I talk to Dolby?
How do I talk to Flowcast, whatever, right?
They were never going to implement these 10 SDKs, 20 SDKs to be able to talk to specific
companies, services.
So yeah, how do you use WebRTC to deliver media while implementing a different API for
everyone?
And the simple answer is you didn't, right?
The broadcast industry as a whole didn't enjoy WebRTC for many reasons, not just lack of
signaling, but many, this signaling was one of them.
So you used a different protocol that would solve everything, right, whether or not it
was RTMP, whether or not it was RIST or SRT or whatever.
So whether or not you're a fan of WebRTC or you're not, it does have its uses.
So and up until recently, you'd have to use an SDK or whatever and interrupt was really,
really difficult.
WIP and WEP.
So yep, WIP and WEP, I'm actually going to try and get Sergio to change ingestion over
to ingress or ingest, just so that it kind of flows nicely with one another.
And they're both drafts in the ITF.
Drafts are nothing to be scared of.
We all know that.
Some businesses don't.
Some businesses look at it and go, huh, it's still a draft, haha, we're not going to do
anything with that.
But we all know that drafts can be a really good thing.
So what is actually WIP and WEP?
Why have you come here today to find out what they are?
So WIP.
So you do a HTTP post up to a server.
So WIP and WEP are really designed around getting media from a server.
Not another peer that's within a firewalled NAT or anything like that.
It's designed for, here's a client, here's a server, I want to put media here or I want
to go grab media from there.
So WIP, you do an HTTP post with an SDP offer and then within the response, you get an SDP
answer.
And then you're done.
That's pretty much it, like we can all go home now.
WEP, pretty much exactly the same.
You do an HTTP post with an SDP offer and you get an SDP answer in response.
And you're done.
Like, they are pretty much not quite identical with one another, but they are.
You do one HTTP request, well, you can also like, do I trickle ice using options, requests
and whatever else, but in its most basic form, you can do one request and one response and
get media flowing.
So what does that really get us that we didn't have before?
Hardware encoders.
For me, being able to bake in WIP and WEP support into hardware encoders and software
is the biggest thing.
And yeah, the Talon hardware encoders support WIP today.
With others, I know us are about to support it as well.
Software support.
OBS.
So there's already, historically, there's been a version of OBS that was WebRTC-ified
by the Cosmo team.
But it was very much kind of designed around like offering up to Milikast mostly, but they
supported it and you could do stuff with it.
But today, there's a pull request open on OBS to add WebRTC support into OBS using WebRTC
Rust.
We've heard a lot about Rust in this room today.
And that's absolutely fantastic.
So now you'll be able to publish to a WIP endpoint and be able to just do it with a URL.
And that's really quite cool.
And then once that's been merged in, the plan is to add WEP support as far as I understand
and then add continuing added extras around extra provisions around RTP headers, specific
things.
But at the moment, it's a very basic pull request.
I say it's a basic pull request.
It's a very complicated pull request from what I understand.
But you've got to start somewhere without all the bells and whistles.
There's support.
Again, so GStreamer, GStreamer now supports WIP and WEP as syncs and sources.
And this is absolutely huge again.
Got properly released in 1.22.
It was released earlier, but obviously 1.22 is not a development release.
And so you can go and use WIP and WEP from GStreamer today.
And there's loads of platform support out there, Dolby slash Milikast support it, Cloudflare
support it in Cloudflare stream and then broadcast bridge.
My product also supports WIP and WEP.
So yay, this is great, right?
So using WebRTC for ingress and egress just got a whole load easier.
There's now a standard.
It's a fairly easy standard.
And we can just kind of get on with our lives, right?
So Simulcast and SVC are both supported.
They're called out in the draft.
You can do this.
Because ultimately, it's just an HTTP request transferring SDP, right?
Anything you could do within your SDP, you can do within WIP and WEP, basically.
Yes, SDP still remains.
If you don't know what SDP is, it's a block of text that magically says, here's how to
set up media, and it's probably at worst, I don't know, 300 lines of code.
I haven't looked recently.
It's huge.
It can be huge because it can tell either side, these are all of the codecs that I support.
These are all of the codecs that, and then the answer comes in and goes, yeah, we're
going to negotiate this.
So SDP is a mess, but it does its job really, really well at the end of the day.
And because it's just SDP, just SDP that we're using with WebRTC everywhere, it gives us
the freedom to be able to do whatever we want.
So that's extra codecs.
That's being able to just say, oh, I'm going to make a random codec that does something
very, very specific to my use case.
It's not going to work in a browser, but it does work for my use case.
And if both ends know how to talk about that codec, then you can do that.
Opus Red, for example, Opus Red hopefully will become standard in the browser.
I don't think it is today.
I think it's still behind a flag, but being able to put in redundant packets of audio
is really quite cool.
So hopefully that's going to turn up in a browser soon.
But yeah, it also allows you to do RTP header extensions like DTX, et cetera.
So yeah, I mean, you're all looking at me like, this is a bit boring, right?
And yeah, Wip and Web is a bit boring.
It's not groundbreaking at all.
And like, sorry Sergio, he's going to watch this later.
He's the author of both, or co-author of both.
Yeah, it's not groundbreaking at all, right?
It's just an HTTP offer and answer.
It should be called woe, right?
No traction for that in the room.
OK, there is some state handling in there as well, obviously.
You have to keep track of things and whatever else.
But I mean, it's really great.
So it gives everyone these two common protocols for send and receive.
And that leads to open innovation and open source projects.
So there's already projects out there that do SRT to WIP.
So you can take in your SRT that you've been using for the past however many years, and
then you can make it WIP because your media server only understands WebRTC, right?
There are projects out there, GStreamer being one of them.
There's WebServer from the Meet Echo team.
There's WebPlayer from the Meet Echo team, and Ivan from Sweden.
The WIP server, again, WIP client.
These are all browser-based tools, or they're all command line tools, or they're all server
tools that talk to Janus for you to be able to make Janus understand WIP and WEP.
So it's a great time to start looking at WebRTC if you haven't already done so in the past.
I've got the same slide twice somehow.
Side note, GStreamer, GStreamer is really cool.
It allows you to pipe all of these things to all of these things, right?
And it's really quite cool, and it even supports RTMP.
You don't have to love WebRTC, and you don't have to love everything about it.
I mean, I certainly don't love WebRTC every day.
There are times that I literally want to throw it against the wall, but it does its job really,
really well, and it is incredibly useful, and it is just another tool in the toolbox.
Sometimes SRT isn't right.
Sometimes risk isn't going to be right.
And whatever, sometimes you are just going to need WebRTC.
So WIP and WEP open up all of those possibilities, and I haven't talked in detail about any of
them, but hopefully you've got enough information to get going.
So thank you very much, and oh, one more thing, ComCon 2023 is a conference that I run in
the UK, and that's happening this year for the first time in person since before the
pandemic, so expect an announcement on dates and venue soon.
And that's me.
Thank you very, very much.
Oh, and we're hiring just like everyone else, so if you want to do software engineering
in the UK around these kinds of technologies, then go to jobs.everycastlabs.uk.
Any questions on the floor?
Have you used the WSCDI and WSCDI and WSCDI and WSCDI and WSCDI and WSCDI and WSCDI
and WSCDI and WSCDI and WSCDI and WSCDI.
I'll comment.
So I didn't catch all of the detail, AWS is, I'll say, right, no, I haven't used AWS's
product called CDI.
I try not to use anything AWS to be perfectly honest, because, you know, when's it going
to disappear?
But no, I haven't.
So AWS's product does broadcast uncompressed stuff.
Okay.
Is there any matrix effort with WIP and WEP?
So is there any matrix effort around WIP and WEP?
I honestly don't know.
I can't imagine so, because they're designed to like, matrix is designed to kind of bridge
between media servers, and so they already have ties into those media servers.
So they wouldn't need WIP and WEP.
I imagine.
But that would be a question for the matrix team.
But I don't imagine it turning up.
You had a question.
You mentioned Simon Cast and SVC are supported.
I haven't read the latest draft.
Do they have, like, a way to layer selection on the client?
So the question is, Simon Cast and SVC are supported in the draft.
Does it tell you how to layer select?
No.
There's a note that says, oh, there's nothing stopping you from doing Simon Cast or SVC.
But as far as I could see this morning, when I was finishing off my slides, there's no
detail, there's no further detail on that.
But yes, we shall see.
But there's still drafts.
There's still time to add detail and stop things from happening that we don't necessarily
agree with.
Like, yeah.
Does that hardware you showed support SVC or Simon Cast?
I don't think so.
From memory, I've not actually used the hardware myself.
I've just read the press releases and talked to people that are using it.
As far as I'm aware, they're not.
They are just using a stream that they're getting and one stream with one layer.
But yes, SVC is kind of the future of having options, right?
And so it needs to be a first-class citizen in whatever we're doing in the future.
And it's now released VP9 SVC.
And I think AV1 SVC are now released in Chrome that's going to be released into stable very,
very, very soon.
So we're going to have all of these options in the browser natively really soon.
Any more questions?
Thank you, Dan.
Thank you very much.
Thank you.