[00:00.000 --> 00:11.000]  So let's start, so our next talk is about two very interesting words, broadcast and
[00:11.000 --> 00:12.000]  WebRTC.
[00:12.000 --> 00:18.480]  Please welcome Dan.
[00:18.480 --> 00:19.480]  Thanks everyone.
[00:19.480 --> 00:23.520]  So yes, merging two worlds, broadcast and WebRTC.
[00:23.520 --> 00:29.560]  So yes, I'm Dan Jenkins, I've been doing stuff with WebRTC for probably just over ten
[00:29.560 --> 00:38.600]  years now, and I guess very recently I've been more involved in air quote broadcast,
[00:38.600 --> 00:43.640]  and there are the ways that you can talk to me, email, Twitter, that thing that's about
[00:43.640 --> 00:47.680]  to die, and Masterdom.
[00:47.680 --> 00:51.960]  So merging two worlds, broadcast and WebRTC.
[00:51.960 --> 00:56.680]  So I guess to talk about WebRTC and broadcast, we need a few definitions of some of the things
[00:56.680 --> 00:58.360]  we're going to talk about.
[00:58.360 --> 01:01.120]  So WebRTC, what is WebRTC?
[01:01.120 --> 01:05.760]  How many in the room know about how WebRTC really works?
[01:05.760 --> 01:06.760]  Hands up.
[01:06.760 --> 01:10.520]  Okay, about 25% of you, so that's good.
[01:10.520 --> 01:17.360]  So WebRTC is encrypted by default, sub-second glass-to-glass, soap and source completely,
[01:17.360 --> 01:23.360]  two-way communications, no defined signaling, which is kind of a good thing, and it's got
[01:23.360 --> 01:30.440]  a load of required codecs that you have to implement to be compliant, I use the word
[01:30.440 --> 01:35.800]  compliant, I don't think anyone's actually going, you're not compliant, but hopefully
[01:35.800 --> 01:37.400]  they will one day.
[01:37.400 --> 01:42.120]  It's embedded in every single browser, so that's the key thing here, every single phone
[01:42.120 --> 01:48.960]  in every single pocket can do WebRTC without having to download anything, and that is the
[01:48.960 --> 01:50.840]  key thing.
[01:50.840 --> 01:55.200]  You can use your own codecs, but you can't use them from within a browser today, you
[01:55.200 --> 02:03.680]  could build something natively and use your own codec, but takes away some of the magic.
[02:03.680 --> 02:09.120]  Delivery is over UDP, and it's got a load of NAT busting stuff with what we call ICE,
[02:09.120 --> 02:15.240]  and there's one main thing called lib WebRTC that everyone talks to everyone else about
[02:15.240 --> 02:22.440]  as though it's WebRTC, it's not, there's lib WebRTC provided by Google, but they don't
[02:22.440 --> 02:31.120]  really provide it anymore as pre-built stuff, but then there are loads of other open source
[02:31.120 --> 02:35.800]  independent versions available in many different languages.
[02:35.800 --> 02:41.000]  No signaling defined in the spec, so that's a big thing here, it was a good thing when
[02:41.000 --> 02:47.600]  it got made, when WebRTC first kind of became a thing, we'll come back to that later.
[02:47.600 --> 02:53.440]  So then there's SRT, SRT is a secure reliable transport, how many people in the room use
[02:53.440 --> 02:56.800]  SRT or know how SRT works?
[02:56.800 --> 03:01.920]  Probably about 25%, but it was a different 25% than before mostly.
[03:01.920 --> 03:08.480]  So again, it's open source, it's used heavily in the broadcasting industry, it is UDP based,
[03:08.480 --> 03:13.000]  it really requires native apps, no browsers involved at all.
[03:13.000 --> 03:21.720]  It can be encrypted optionally, most people use it encrypted, but you can use it without
[03:21.720 --> 03:27.200]  and it is completely and utterly codec agnostic, but again there are usually pre-defined that
[03:27.200 --> 03:29.080]  people use.
[03:29.080 --> 03:37.760]  It can be sub-second, but usually it's not, and it can be used within, across the internet
[03:37.760 --> 03:45.120]  or within a LAN, NDI, how many people in the room have used NDI and know how it works?
[03:45.120 --> 03:50.560]  About 25%, some of the same crowd again, so network device interface, I mean who came
[03:50.560 --> 03:56.760]  up with the stupid name like that, by network device interface, so what am I actually doing?
[03:56.760 --> 04:06.080]  I hate the, I always forget what it's actually referring to, it is not open source and it
[04:06.080 --> 04:12.320]  comes in multiple forms, so there's pure NDI which gives you a huge amount of data, then
[04:12.320 --> 04:15.640]  there's HX, HX2 and HX3.
[04:15.640 --> 04:23.360]  Designed to work only within a LAN, yes you can make NDI work across the internet now,
[04:23.360 --> 04:29.560]  but it's not really NDI, it's actually using WebRTC to do some of the magic.
[04:29.560 --> 04:34.520]  So ultimately it's designed to work within a LAN and it's not open source, but it is
[04:34.520 --> 04:39.880]  free to use, but the licensing is a little bit confusing, some of the times.
[04:39.880 --> 04:47.280]  So yeah, it's a bit of a weird one, but again it is hugely popular, and yes it uses UDP
[04:47.280 --> 04:48.280]  as well.
[04:48.280 --> 04:51.000]  All the good things with media use UDP, right?
[04:51.000 --> 04:59.000]  Then there's RIST, how many people have actually used RIST, okay, how many people understand
[04:59.000 --> 05:03.400]  how RIST actually works?
[05:03.400 --> 05:08.800]  So for the recording, I don't know, 1% of the room, 2% of the room.
[05:08.800 --> 05:14.600]  So RIST is actually really quite interesting, it is reliable internet stream transport,
[05:14.600 --> 05:19.360]  and to be honest I've never used it, but I had to learn how it actually works to be
[05:19.360 --> 05:22.960]  able to confidently talk about it in front of you guys.
[05:22.960 --> 05:28.600]  So again it's open source, it's UDP based, it is encrypted, it's RTP based, and it's
[05:28.600 --> 05:34.680]  relatively new in the grand scheme of things, and it can work within a WAN or a LAN.
[05:34.680 --> 05:38.080]  The other forms of media transport are not worth talking about right now, because they're
[05:38.080 --> 05:45.240]  not really real time, and I know some of you are going to look at me and go, hmm, but bear
[05:45.240 --> 05:46.240]  with me.
[05:46.240 --> 05:53.320]  So merging two worlds, WebRTC and Broadcast, and Broadcast and WebRTC, they're two worlds
[05:53.320 --> 05:58.360]  that have not really come together in the past 10 years.
[05:58.360 --> 06:03.520]  I know lots of people from the Broadcast industry look at WebRTC as a dirty thing, it doesn't
[06:03.520 --> 06:08.480]  do this and it doesn't do that, but hopefully that's all changing for the better.
[06:08.480 --> 06:13.000]  So they can now live in harmony, hopefully, maybe.
[06:13.000 --> 06:18.760]  So because of something called WIP and WEP, so let's take a look at WIP and WEP.
[06:18.760 --> 06:25.400]  WIP stands for the WebRTC HTTP ingestion protocol, and this is how it works.
[06:25.400 --> 06:32.800]  I'm not going to bore you going through that, but I mean ultimately there's an HTTP request,
[06:32.800 --> 06:35.040]  request response, and then media flows.
[06:35.040 --> 06:37.600]  It should be as simple as that, right?
[06:37.600 --> 06:45.520]  Then there's WEP, which is the WebRTC HTTP egress protocol, kind of looks similar, right?
[06:45.520 --> 06:46.920]  So that's really great.
[06:46.920 --> 06:52.880]  And then there's this third one called, whoa, WebRTC HTTP offer answer protocol.
[06:52.880 --> 06:57.360]  I wish it did exist, I think it would be really cool, but it doesn't exist.
[06:57.360 --> 07:02.320]  I messaged the author of both WIP and WEP this morning and went, we can just get rid
[07:02.320 --> 07:07.720]  of WIP and WEP and just have, whoa, but no.
[07:07.720 --> 07:13.040]  So yeah, these strangely look like signaling protocols to me, right?
[07:13.040 --> 07:18.520]  And I said it was really great that WebRTC didn't have a signaling protocol, didn't I?
[07:18.520 --> 07:22.520]  Well it was great back in the day.
[07:22.520 --> 07:23.580]  It drove innovation.
[07:23.580 --> 07:27.720]  It drove many, many different applications to do things in their own way that made sense
[07:27.720 --> 07:28.720]  to them.
[07:28.720 --> 07:31.840]  They didn't have to use XMPP, they didn't have to use SIP.
[07:31.840 --> 07:34.960]  They could if they wanted to, and many did.
[07:34.960 --> 07:40.400]  Or you could go build something yourself using a JSON API, GraphQL, whatever suited you
[07:40.400 --> 07:41.400]  the most, right?
[07:41.400 --> 07:46.600]  There was no defined way of going, here's an offer and here's an answer.
[07:46.600 --> 07:49.800]  It was great until it wasn't.
[07:49.800 --> 07:55.960]  I say it wasn't because no enforced signaling protocol meant that there was a lack of industry
[07:55.960 --> 07:56.960]  support.
[07:56.960 --> 08:02.120]  So we had all of these islands that didn't really know how to talk to one another.
[08:02.120 --> 08:04.680]  One of those problems that Matrix is trying to solve.
[08:04.680 --> 08:13.040]  But ultimately we had the likes of Jitsi and Teams and Google, Google me and whatever else,
[08:13.040 --> 08:16.800]  all doing great WebRTC things.
[08:16.800 --> 08:21.840]  They're quite great, but none of them could like interrupt with one another and that was
[08:21.840 --> 08:27.080]  a real shame and it meant that when we came to the broadcast industry, no one wanted to
[08:27.080 --> 08:30.000]  say implement, oh, how do I talk to Milikast?
[08:30.000 --> 08:31.480]  How do I talk to Dolby?
[08:31.480 --> 08:35.760]  How do I talk to Flowcast, whatever, right?
[08:35.760 --> 08:42.160]  They were never going to implement these 10 SDKs, 20 SDKs to be able to talk to specific
[08:42.160 --> 08:46.240]  companies, services.
[08:46.240 --> 08:54.120]  So yeah, how do you use WebRTC to deliver media while implementing a different API for
[08:54.120 --> 08:55.120]  everyone?
[08:55.120 --> 08:59.000]  And the simple answer is you didn't, right?
[08:59.000 --> 09:05.640]  The broadcast industry as a whole didn't enjoy WebRTC for many reasons, not just lack of
[09:05.640 --> 09:10.400]  signaling, but many, this signaling was one of them.
[09:10.400 --> 09:16.320]  So you used a different protocol that would solve everything, right, whether or not it
[09:16.320 --> 09:20.960]  was RTMP, whether or not it was RIST or SRT or whatever.
[09:20.960 --> 09:27.320]  So whether or not you're a fan of WebRTC or you're not, it does have its uses.
[09:27.320 --> 09:34.240]  So and up until recently, you'd have to use an SDK or whatever and interrupt was really,
[09:34.240 --> 09:35.880]  really difficult.
[09:35.880 --> 09:38.760]  WIP and WEP.
[09:38.760 --> 09:45.800]  So yep, WIP and WEP, I'm actually going to try and get Sergio to change ingestion over
[09:45.800 --> 09:53.200]  to ingress or ingest, just so that it kind of flows nicely with one another.
[09:53.200 --> 09:55.760]  And they're both drafts in the ITF.
[09:55.760 --> 09:57.640]  Drafts are nothing to be scared of.
[09:57.640 --> 09:59.080]  We all know that.
[09:59.080 --> 10:00.200]  Some businesses don't.
[10:00.200 --> 10:04.400]  Some businesses look at it and go, huh, it's still a draft, haha, we're not going to do
[10:04.400 --> 10:05.880]  anything with that.
[10:05.880 --> 10:08.520]  But we all know that drafts can be a really good thing.
[10:08.520 --> 10:11.280]  So what is actually WIP and WEP?
[10:11.280 --> 10:15.680]  Why have you come here today to find out what they are?
[10:15.680 --> 10:16.680]  So WIP.
[10:16.680 --> 10:20.480]  So you do a HTTP post up to a server.
[10:20.480 --> 10:24.760]  So WIP and WEP are really designed around getting media from a server.
[10:24.760 --> 10:29.280]  Not another peer that's within a firewalled NAT or anything like that.
[10:29.280 --> 10:35.040]  It's designed for, here's a client, here's a server, I want to put media here or I want
[10:35.040 --> 10:37.360]  to go grab media from there.
[10:37.360 --> 10:44.920]  So WIP, you do an HTTP post with an SDP offer and then within the response, you get an SDP
[10:44.920 --> 10:46.240]  answer.
[10:46.240 --> 10:47.240]  And then you're done.
[10:47.240 --> 10:51.480]  That's pretty much it, like we can all go home now.
[10:51.480 --> 10:55.040]  WEP, pretty much exactly the same.
[10:55.040 --> 10:59.920]  You do an HTTP post with an SDP offer and you get an SDP answer in response.
[10:59.920 --> 11:00.920]  And you're done.
[11:00.920 --> 11:09.720]  Like, they are pretty much not quite identical with one another, but they are.
[11:09.720 --> 11:16.360]  You do one HTTP request, well, you can also like, do I trickle ice using options, requests
[11:16.360 --> 11:23.640]  and whatever else, but in its most basic form, you can do one request and one response and
[11:23.640 --> 11:26.700]  get media flowing.
[11:26.700 --> 11:31.920]  So what does that really get us that we didn't have before?
[11:31.920 --> 11:33.560]  Hardware encoders.
[11:33.560 --> 11:43.120]  For me, being able to bake in WIP and WEP support into hardware encoders and software
[11:43.120 --> 11:45.880]  is the biggest thing.
[11:45.880 --> 11:52.680]  And yeah, the Talon hardware encoders support WIP today.
[11:52.680 --> 11:57.120]  With others, I know us are about to support it as well.
[11:57.120 --> 11:58.120]  Software support.
[11:58.120 --> 11:59.120]  OBS.
[11:59.120 --> 12:06.760]  So there's already, historically, there's been a version of OBS that was WebRTC-ified
[12:06.760 --> 12:10.280]  by the Cosmo team.
[12:10.280 --> 12:16.600]  But it was very much kind of designed around like offering up to Milikast mostly, but they
[12:16.600 --> 12:19.400]  supported it and you could do stuff with it.
[12:19.400 --> 12:27.760]  But today, there's a pull request open on OBS to add WebRTC support into OBS using WebRTC
[12:27.760 --> 12:28.760]  Rust.
[12:28.760 --> 12:32.120]  We've heard a lot about Rust in this room today.
[12:32.120 --> 12:33.920]  And that's absolutely fantastic.
[12:33.920 --> 12:44.520]  So now you'll be able to publish to a WIP endpoint and be able to just do it with a URL.
[12:44.520 --> 12:46.880]  And that's really quite cool.
[12:46.880 --> 12:51.880]  And then once that's been merged in, the plan is to add WEP support as far as I understand
[12:51.880 --> 13:01.760]  and then add continuing added extras around extra provisions around RTP headers, specific
[13:01.760 --> 13:02.760]  things.
[13:02.760 --> 13:06.120]  But at the moment, it's a very basic pull request.
[13:06.120 --> 13:07.520]  I say it's a basic pull request.
[13:07.520 --> 13:10.320]  It's a very complicated pull request from what I understand.
[13:10.320 --> 13:15.960]  But you've got to start somewhere without all the bells and whistles.
[13:15.960 --> 13:16.960]  There's support.
[13:16.960 --> 13:23.680]  Again, so GStreamer, GStreamer now supports WIP and WEP as syncs and sources.
[13:23.680 --> 13:27.120]  And this is absolutely huge again.
[13:27.120 --> 13:31.120]  Got properly released in 1.22.
[13:31.120 --> 13:37.560]  It was released earlier, but obviously 1.22 is not a development release.
[13:37.560 --> 13:44.040]  And so you can go and use WIP and WEP from GStreamer today.
[13:44.040 --> 13:49.600]  And there's loads of platform support out there, Dolby slash Milikast support it, Cloudflare
[13:49.600 --> 13:56.080]  support it in Cloudflare stream and then broadcast bridge.
[13:56.080 --> 13:59.280]  My product also supports WIP and WEP.
[13:59.280 --> 14:02.000]  So yay, this is great, right?
[14:02.000 --> 14:07.000]  So using WebRTC for ingress and egress just got a whole load easier.
[14:07.000 --> 14:08.440]  There's now a standard.
[14:08.440 --> 14:11.520]  It's a fairly easy standard.
[14:11.520 --> 14:13.840]  And we can just kind of get on with our lives, right?
[14:13.840 --> 14:18.920]  So Simulcast and SVC are both supported.
[14:18.920 --> 14:20.520]  They're called out in the draft.
[14:20.520 --> 14:21.920]  You can do this.
[14:21.920 --> 14:27.160]  Because ultimately, it's just an HTTP request transferring SDP, right?
[14:27.160 --> 14:33.320]  Anything you could do within your SDP, you can do within WIP and WEP, basically.
[14:33.320 --> 14:36.400]  Yes, SDP still remains.
[14:36.400 --> 14:40.440]  If you don't know what SDP is, it's a block of text that magically says, here's how to
[14:40.440 --> 14:46.840]  set up media, and it's probably at worst, I don't know, 300 lines of code.
[14:46.840 --> 14:49.160]  I haven't looked recently.
[14:49.160 --> 14:50.160]  It's huge.
[14:50.160 --> 14:56.720]  It can be huge because it can tell either side, these are all of the codecs that I support.
[14:56.720 --> 15:01.600]  These are all of the codecs that, and then the answer comes in and goes, yeah, we're
[15:01.600 --> 15:04.720]  going to negotiate this.
[15:04.720 --> 15:10.240]  So SDP is a mess, but it does its job really, really well at the end of the day.
[15:10.240 --> 15:17.640]  And because it's just SDP, just SDP that we're using with WebRTC everywhere, it gives us
[15:17.640 --> 15:21.280]  the freedom to be able to do whatever we want.
[15:21.280 --> 15:23.160]  So that's extra codecs.
[15:23.160 --> 15:28.120]  That's being able to just say, oh, I'm going to make a random codec that does something
[15:28.120 --> 15:30.440]  very, very specific to my use case.
[15:30.440 --> 15:34.880]  It's not going to work in a browser, but it does work for my use case.
[15:34.880 --> 15:39.120]  And if both ends know how to talk about that codec, then you can do that.
[15:39.120 --> 15:44.240]  Opus Red, for example, Opus Red hopefully will become standard in the browser.
[15:44.240 --> 15:45.240]  I don't think it is today.
[15:45.240 --> 15:54.920]  I think it's still behind a flag, but being able to put in redundant packets of audio
[15:54.920 --> 15:56.640]  is really quite cool.
[15:56.640 --> 15:59.160]  So hopefully that's going to turn up in a browser soon.
[15:59.160 --> 16:04.720]  But yeah, it also allows you to do RTP header extensions like DTX, et cetera.
[16:04.720 --> 16:10.560]  So yeah, I mean, you're all looking at me like, this is a bit boring, right?
[16:10.560 --> 16:12.760]  And yeah, Wip and Web is a bit boring.
[16:12.760 --> 16:15.400]  It's not groundbreaking at all.
[16:15.400 --> 16:17.760]  And like, sorry Sergio, he's going to watch this later.
[16:17.760 --> 16:20.360]  He's the author of both, or co-author of both.
[16:20.360 --> 16:22.960]  Yeah, it's not groundbreaking at all, right?
[16:22.960 --> 16:25.200]  It's just an HTTP offer and answer.
[16:25.200 --> 16:27.560]  It should be called woe, right?
[16:27.560 --> 16:30.400]  No traction for that in the room.
[16:30.400 --> 16:33.800]  OK, there is some state handling in there as well, obviously.
[16:33.800 --> 16:36.520]  You have to keep track of things and whatever else.
[16:36.520 --> 16:39.120]  But I mean, it's really great.
[16:39.120 --> 16:43.720]  So it gives everyone these two common protocols for send and receive.
[16:43.720 --> 16:47.880]  And that leads to open innovation and open source projects.
[16:47.880 --> 16:52.560]  So there's already projects out there that do SRT to WIP.
[16:52.560 --> 16:57.600]  So you can take in your SRT that you've been using for the past however many years, and
[16:57.600 --> 17:03.080]  then you can make it WIP because your media server only understands WebRTC, right?
[17:03.080 --> 17:05.880]  There are projects out there, GStreamer being one of them.
[17:05.880 --> 17:10.360]  There's WebServer from the Meet Echo team.
[17:10.360 --> 17:18.800]  There's WebPlayer from the Meet Echo team, and Ivan from Sweden.
[17:18.800 --> 17:23.560]  The WIP server, again, WIP client.
[17:23.560 --> 17:29.400]  These are all browser-based tools, or they're all command line tools, or they're all server
[17:29.400 --> 17:37.400]  tools that talk to Janus for you to be able to make Janus understand WIP and WEP.
[17:37.400 --> 17:44.880]  So it's a great time to start looking at WebRTC if you haven't already done so in the past.
[17:44.880 --> 17:47.240]  I've got the same slide twice somehow.
[17:47.240 --> 17:50.520]  Side note, GStreamer, GStreamer is really cool.
[17:50.520 --> 17:54.160]  It allows you to pipe all of these things to all of these things, right?
[17:54.160 --> 17:59.760]  And it's really quite cool, and it even supports RTMP.
[17:59.760 --> 18:03.320]  You don't have to love WebRTC, and you don't have to love everything about it.
[18:03.320 --> 18:07.560]  I mean, I certainly don't love WebRTC every day.
[18:07.560 --> 18:14.400]  There are times that I literally want to throw it against the wall, but it does its job really,
[18:14.400 --> 18:20.840]  really well, and it is incredibly useful, and it is just another tool in the toolbox.
[18:20.840 --> 18:22.640]  Sometimes SRT isn't right.
[18:22.640 --> 18:24.120]  Sometimes risk isn't going to be right.
[18:24.120 --> 18:29.360]  And whatever, sometimes you are just going to need WebRTC.
[18:29.360 --> 18:36.400]  So WIP and WEP open up all of those possibilities, and I haven't talked in detail about any of
[18:36.400 --> 18:41.720]  them, but hopefully you've got enough information to get going.
[18:41.720 --> 18:48.560]  So thank you very much, and oh, one more thing, ComCon 2023 is a conference that I run in
[18:48.560 --> 18:54.200]  the UK, and that's happening this year for the first time in person since before the
[18:54.200 --> 19:00.200]  pandemic, so expect an announcement on dates and venue soon.
[19:00.200 --> 19:01.200]  And that's me.
[19:01.200 --> 19:04.200]  Thank you very, very much.
[19:04.200 --> 19:14.080]  Oh, and we're hiring just like everyone else, so if you want to do software engineering
[19:14.080 --> 19:19.680]  in the UK around these kinds of technologies, then go to jobs.everycastlabs.uk.
[19:19.680 --> 19:22.680]  Any questions on the floor?
[19:22.680 --> 19:37.800]  Have you used the WSCDI and WSCDI and WSCDI and WSCDI and WSCDI and WSCDI and WSCDI
[19:37.800 --> 19:42.800]  and WSCDI and WSCDI and WSCDI and WSCDI.
[19:42.800 --> 19:45.400]  I'll comment.
[19:45.400 --> 19:56.600]  So I didn't catch all of the detail, AWS is, I'll say, right, no, I haven't used AWS's
[19:56.600 --> 19:59.320]  product called CDI.
[19:59.320 --> 20:04.640]  I try not to use anything AWS to be perfectly honest, because, you know, when's it going
[20:04.640 --> 20:05.640]  to disappear?
[20:05.640 --> 20:08.800]  But no, I haven't.
[20:08.800 --> 20:13.640]  So AWS's product does broadcast uncompressed stuff.
[20:13.640 --> 20:14.640]  Okay.
[20:14.640 --> 20:21.040]  Is there any matrix effort with WIP and WEP?
[20:21.040 --> 20:24.240]  So is there any matrix effort around WIP and WEP?
[20:24.240 --> 20:25.880]  I honestly don't know.
[20:25.880 --> 20:32.320]  I can't imagine so, because they're designed to like, matrix is designed to kind of bridge
[20:32.320 --> 20:38.280]  between media servers, and so they already have ties into those media servers.
[20:38.280 --> 20:40.760]  So they wouldn't need WIP and WEP.
[20:40.760 --> 20:41.760]  I imagine.
[20:41.760 --> 20:44.320]  But that would be a question for the matrix team.
[20:44.320 --> 20:48.040]  But I don't imagine it turning up.
[20:48.040 --> 20:49.040]  You had a question.
[20:49.040 --> 20:50.040]  You mentioned Simon Cast and SVC are supported.
[20:50.040 --> 20:51.040]  I haven't read the latest draft.
[20:51.040 --> 20:58.160]  Do they have, like, a way to layer selection on the client?
[20:58.160 --> 21:04.200]  So the question is, Simon Cast and SVC are supported in the draft.
[21:04.200 --> 21:07.240]  Does it tell you how to layer select?
[21:07.240 --> 21:08.240]  No.
[21:08.240 --> 21:15.040]  There's a note that says, oh, there's nothing stopping you from doing Simon Cast or SVC.
[21:15.040 --> 21:19.840]  But as far as I could see this morning, when I was finishing off my slides, there's no
[21:19.840 --> 21:23.320]  detail, there's no further detail on that.
[21:23.320 --> 21:26.160]  But yes, we shall see.
[21:26.160 --> 21:27.160]  But there's still drafts.
[21:27.160 --> 21:33.240]  There's still time to add detail and stop things from happening that we don't necessarily
[21:33.240 --> 21:35.240]  agree with.
[21:35.240 --> 21:37.240]  Like, yeah.
[21:37.240 --> 21:43.920]  Does that hardware you showed support SVC or Simon Cast?
[21:43.920 --> 21:46.720]  I don't think so.
[21:46.720 --> 21:50.200]  From memory, I've not actually used the hardware myself.
[21:50.200 --> 21:54.440]  I've just read the press releases and talked to people that are using it.
[21:54.440 --> 21:56.120]  As far as I'm aware, they're not.
[21:56.120 --> 22:02.760]  They are just using a stream that they're getting and one stream with one layer.
[22:02.760 --> 22:10.280]  But yes, SVC is kind of the future of having options, right?
[22:10.280 --> 22:14.720]  And so it needs to be a first-class citizen in whatever we're doing in the future.
[22:14.720 --> 22:18.080]  And it's now released VP9 SVC.
[22:18.080 --> 22:23.960]  And I think AV1 SVC are now released in Chrome that's going to be released into stable very,
[22:23.960 --> 22:25.640]  very, very soon.
[22:25.640 --> 22:30.840]  So we're going to have all of these options in the browser natively really soon.
[22:30.840 --> 22:37.840]  Any more questions?
[22:37.840 --> 22:38.840]  Thank you, Dan.
[22:38.840 --> 22:39.840]  Thank you very much.
[22:39.840 --> 23:03.840]  Thank you.