WEBVTT 00:00.000 --> 00:07.000 Yeah, I'm green. 00:07.000 --> 00:08.000 Good. 00:08.000 --> 00:09.000 Keep it back. 00:09.000 --> 00:13.000 Race cars, REC, those are low. 00:13.000 --> 00:14.000 Yeah. 00:14.000 --> 00:19.000 So this is about race cars, RTCP, video and 5G. 00:19.000 --> 00:22.000 It's kind of actually a little bit of a low level thing. 00:22.000 --> 00:26.000 What I'm going to do though, and it's mostly about... 00:26.000 --> 00:27.000 Yeah, no, I should say. 00:27.000 --> 00:34.840 I'm composing, I'm CTLP, a REC, or RTCP for small cameras, which was originally kind of 00:34.840 --> 00:37.840 for baby monitors and stuff like that. 00:37.840 --> 00:41.280 And it's been hugely based on open source modules. 00:41.280 --> 00:44.840 And this talk actually about, I kind of do a little bit of that that we've been doing. 00:44.840 --> 00:47.000 It's a race car camera. 00:47.000 --> 00:48.960 This isn't a really prototype of it. 00:48.960 --> 00:49.960 Plastic case. 00:49.960 --> 00:52.240 The real thing is aluminium and carbon fiber. 00:52.240 --> 00:56.800 I'm going to antenna a mounted on the dashboard and not, like, rabbit ears, like this. 00:56.800 --> 00:57.800 But I'll pass this round. 00:57.800 --> 01:03.800 If anyone wants to, like, have a look at it, that's final or not, doesn't really matter. 01:03.800 --> 01:13.800 So the cool thing about these things is, we're trying to get right below, some of the cockpit 01:13.800 --> 01:19.560 from the car to the... to the... to the pit. 01:19.560 --> 01:24.840 And so the idea is that the... the pit crew can hear and see what's going on in the car 01:24.840 --> 01:25.840 in real time. 01:25.840 --> 01:33.440 A low latency, and we're using 5G for that, and we're using... where do you see? 01:33.440 --> 01:40.240 So... and... we've decided, like, to try and make that work, we've been to do some testing. 01:40.240 --> 01:42.880 So we've got a chance to do a test. 01:42.880 --> 01:43.880 I'll go back. 01:43.880 --> 01:49.000 No, no, no, no, no, no, no, no, no, no, no, go back, go back, go back, go back. 01:49.000 --> 01:50.000 This is what I want. 01:50.000 --> 01:51.000 There we go. 01:51.000 --> 01:57.640 So we did a... we did a test of some data in Spain, and so what I'm going to show you is this 01:57.640 --> 02:06.760 is a card during... 130 kilopyroids round the track using 90 RTP. 02:06.760 --> 02:13.520 So we're just setting up... five megabits a second, H264 stream at 30 frames a second. 02:13.520 --> 02:18.680 And what you see is, on the... on the frame rate, it keeps flicking up and down. 02:18.720 --> 02:24.680 So typically when we sell hot, we'll lose a lot of frames in the frame rate of clock to zero. 02:24.680 --> 02:26.680 But the big thing is about constant. 02:26.680 --> 02:32.320 And what that ends up with is being pretty much unusual for the... for the pickle, because 02:32.320 --> 02:36.360 they keep getting... stills. 02:36.360 --> 02:46.920 So if you do the same thing running our software, what happens is... we vary the bit rate. 02:46.920 --> 02:50.720 And the frame rate remains pretty much constant. 02:50.720 --> 02:57.120 So there are points on this track, typically up right near the edge where the quality of 02:57.120 --> 03:02.560 the signal isn't good enough, and we have to drop the bit rate, but we can still keep 03:02.560 --> 03:03.960 a constant frame rate. 03:03.960 --> 03:07.800 So that's the kind of basic trick that we're doing here. 03:07.800 --> 03:18.840 So for those of you who prefer numbers, that's like a roughly 50 times improvement 03:18.840 --> 03:25.840 on the amount of time that the screen is frozen, which is a useful metric. 03:25.840 --> 03:30.760 So what we did... we did this test, funded by the EU, we needed to go over some money to 03:30.760 --> 03:32.800 go and do this test, which was lovely. 03:32.800 --> 03:36.640 And thanks for target expert administering that. 03:36.640 --> 03:43.960 And idiot if her own run the test track for bending their own cameras on our test track 03:43.960 --> 03:47.240 will let us take a camera though, which I really appreciate. 03:47.240 --> 03:53.360 It was an interesting set of bureaucratic negotiations, but we got there. 03:53.360 --> 03:55.760 So what's the difference between those two things? 03:55.760 --> 03:57.360 Why do we get the 50x from? 03:57.360 --> 03:58.360 How do we do it? 03:58.440 --> 04:04.600 It was literally the same hardware, literally the same network, literally both using 04:04.600 --> 04:13.360 RTP over the 5G, same codec, nothing really different, same target rate, same endpoint, 04:13.360 --> 04:14.360 same track. 04:14.360 --> 04:15.360 So what was different? 04:15.360 --> 04:18.360 And the answer is RTP. 04:18.360 --> 04:20.800 So what the heck is RTP? 04:20.800 --> 04:26.880 It's the companion protocol that goes with RTP, it's the control protocol, it's kind 04:26.880 --> 04:35.280 of feedback back channel, so that basically RTP messages come into like three categories. 04:35.280 --> 04:40.680 There's roster statistics for things like sender reports, like how many frames of a 04:40.680 --> 04:45.400 write, how many packets of a write, how many will lost those sorts of things, same thing 04:45.400 --> 04:46.400 for receiving reports. 04:46.400 --> 04:52.080 And there's a few kind of arcane control messages like buy, it doesn't actually do anything 04:52.080 --> 04:56.840 much, but it does exist, which is kind of nice, and there's these feedback messages 04:56.840 --> 05:05.760 which are, today is like picture loss, packet loss, and band estimation, and those are 05:05.760 --> 05:10.920 the ones that we're most interested in, and I should say, I got this lovely diagram from 05:10.920 --> 05:15.800 Sahi's blog, so thanks to him for that. 05:15.800 --> 05:20.840 So the bad news about RTP, I really does want this wonderful stuff for us, is it's 05:20.840 --> 05:25.800 three, it is my next favorite protocol, all the protocols I've ever implemented, it wins 05:25.800 --> 05:34.280 the prize for being ugliest, it's a massive option, everything is optional, and it used 05:34.280 --> 05:38.520 to run its own important now, it doesn't, so you don't even know exactly where it's 05:38.520 --> 05:45.160 going to be, and then it's Mark Stone RTP, which is actually the right answer, but it didn't 05:45.160 --> 05:54.400 used to be, and every extension is its own arcane weird binary format. 05:54.400 --> 06:02.480 This one is my absolute favorite for that, which is the bandwidth estimator for in RAMB, 06:02.480 --> 06:11.680 is what is it, 18-bit Mantissa, a six-bit of exponent, and 8-bit source ID, all the packed 06:11.680 --> 06:17.640 into 32 bits, so you have long packed them and do a few shifts and all of us to get 06:17.640 --> 06:25.880 a step out of it, and so as somebody who wrote S&MP stuff back in the day, like I wish 06:25.880 --> 06:30.680 it was a S&1, and I can not many people actually would say that, but I really miss S&1 for 06:30.680 --> 06:35.880 this kind of stuff, so the worst news is that to know what you're going to get, you have to 06:35.880 --> 06:43.080 do an SDP or for answer it exchange, and you'll get what comes out of that exchange, you've 06:43.080 --> 06:46.840 got no further negotiation, there's no other question and the thing, it's like, that's 06:46.840 --> 06:54.280 what's comes out, so usual arcane or SDP nonsense, so the things that you end up with in a 06:54.280 --> 07:00.760 web are you see call, but in order of how you like, whether you like to receive them or not, 07:00.760 --> 07:07.640 I guess, are in B, so are in B all transport-wide CC depending on whether you're running, 07:08.360 --> 07:13.560 if you're running multiple videos, streams, you want to use transport-wide CC, if you're running a single 07:13.640 --> 07:21.080 R&B is actually simpler, so which we are, so it's easier for us to use that, but basically 07:21.080 --> 07:26.840 an R&B gives you an estimate of what the channel is bound with the channel is capable of, 07:26.840 --> 07:35.400 and it does that by looking at packet arrival times, and as some network component in the middle 07:35.400 --> 07:42.520 starts to buffer, the packet arrival times start interval starts to grow, and you can use that to 07:42.600 --> 07:48.120 deduce that something is about to fill its buffers, and therefore you can cut back on what you're 07:48.120 --> 07:53.640 sending before it starts dropping packets, so that's the best possible outcome that you can get there 07:53.640 --> 07:59.400 before it happens, before you lose anything, and that's that where it will outcome, and that 07:59.400 --> 08:06.680 lets you minimize the latency and minimize the freezing of packets, that's one down is if you haven't 08:06.760 --> 08:13.000 managed to do that, then or something else on the network has happened, then we may have lost the 08:13.000 --> 08:16.520 packet, so now we'll tell you which packets have been lost, and we'll get off of you the opportunity 08:16.520 --> 08:25.160 to resend them, and if you can do this within something like the frame interval or two, then it's 08:25.160 --> 08:30.600 probably not visible to the user, you can close that loop fast enough, but the user probably 08:30.600 --> 08:36.520 doesn't see, if you leave it any longer than that, and it just buff goes, or you something 08:36.520 --> 08:41.640 stores, and so it's like a bad outcome, if it's longer than that, and we're the short-round trip 08:41.640 --> 08:49.480 trying time and low latency, that's actually pretty good outcome, so we limit the growth of the 08:49.480 --> 08:55.320 just above, but they're actually not servicing older requests, because we don't think it's worth 08:55.320 --> 09:03.240 the cost. The next one down is that PLI, and this is kind of the worst case, we've lost a 09:03.240 --> 09:08.840 packet, we couldn't resend it, and worst of all that packet contains something that the 09:08.840 --> 09:14.920 decoder needs in order to decode anything, but at that point you've basically, you've got a 09:14.920 --> 09:22.200 frozen screen, and so you have to send the full frame full keyframe back, and this map PLI 09:22.280 --> 09:27.320 says, is the decoder saying, hey, I'm completely lost, send me a full frame, so that is what 09:27.320 --> 09:32.920 you do, but very expensive, so you want to try and restrict that situation to the very minimum, 09:32.920 --> 09:39.640 they like 10x the size of a typical frame, and anything you can do, anything you've sent before 09:39.640 --> 09:44.840 a keyframe is now useless, because the context is wrong, so you can dump anything that's in the 09:44.840 --> 09:54.280 queue, and there's a fourth one, it's the working code S, which is RC8888, which is RTCP Feedback 09:54.280 --> 10:04.440 on L for S, so L for S is this new little tiny addition to the IP reuse of some bits in the IP header 10:05.400 --> 10:13.960 to mark that a device in the chain is allowed in the network, is allowed to say, I'm 10:13.960 --> 10:19.560 reaching the congestion state, and it can set a bit in a packet as it goes through, this isn't 10:19.560 --> 10:24.120 widely deployed yet, but it's actually going to be really interesting as a way of finding out whether 10:24.120 --> 10:33.160 whether your network is approaching congestion, I'm hopefully will, you can use it to get much better 10:33.160 --> 10:38.680 bandwidth estimation, the experience I've seen done on this so far actually generate worse 10:38.680 --> 10:47.720 results for bandwidth estimation, but hopefully that will, that will change, so the summary here 10:47.720 --> 10:55.960 is RTCP lets us go from where it's as cope with fluctuating network constraints, so like it lets us 10:55.960 --> 11:03.400 go from a framework that is widely varying on the left to a framework that's pretty stable on 11:03.400 --> 11:12.280 the right, and remember this is the top speed on this is 160 kph, the far right hand edge is the 11:12.280 --> 11:20.440 cost of 160 kph, it goes through 12 cell hops per revolution, so like we're not just sitting 11:20.440 --> 11:27.880 still, we're definitely on the move, so by using RTCP and we can do that, the big pieces that we 11:27.880 --> 11:35.880 vary is the big, that's the big win, there are some other subsequent wins with the ability to 11:37.160 --> 11:43.560 these send packets that have been lost, so you might ask what's all this got to do with open 11:43.560 --> 11:49.720 source, I mean it's a nice RTCP education, but why is it open source, the answer is actually 11:49.720 --> 11:57.000 the implementation of RTCP is an open source thing, and I wrote quite a long time ago called 11:57.000 --> 12:04.600 RTCP Lite, and I wrote it for Voxere 1012 something like that years ago, and I'm slowly 12:04.600 --> 12:12.600 been adding to it since, it's open source, it's I think in MIT license, and it has some support 12:12.600 --> 12:16.840 for RTCP which kind of way it gets into this talk and why we're using it, and there's a 12:16.840 --> 12:26.360 sample out there for WIP, which is the most basic implementation of WIP, which is the WebRTC video 12:26.360 --> 12:31.880 ingest protocol, but it uses that library, so it's a kind of way of seeing how the library fits 12:31.880 --> 12:37.080 together and how you could use it and a bigger that, and I'll actually have an ask, which is 12:37.080 --> 12:47.880 I'd really like PRs for other RTP extensions, for RTCP extensions, for tests weeks, anything 12:47.880 --> 12:53.320 you want to generate for it, I'll welcome it, that would be wonderful, and particularly anybody 12:53.320 --> 13:00.840 wants to represent transport way CC for it, that would be wonderful, and so I'm also issues, 13:00.840 --> 13:06.440 issues would be great, you know, anything like that, so contribute to that would be wonderful, 13:06.440 --> 13:14.680 so it's still a great SOTP light, so I'll take questions in the matrix room, or maybe here, 13:14.680 --> 13:22.760 we'll see how it goes, contact stuff, and I do do consulting on SOTP, RTCP, that's kind of stuff, 13:22.760 --> 13:30.360 ice, SOTP, with all our outsourced stuff, and also piong's dreamer, the other kind of 13:30.360 --> 13:36.520 real time things, and I build stuff with pipe, and just like with a few seconds left, I'm going 13:36.520 --> 13:42.360 to show you pipe in action, so this is not, this is the other camera, not the one that you're 13:43.400 --> 13:51.080 that's still going down the room, but this is a camera that's sitting outside, sitting in my home 13:51.080 --> 13:58.200 in the UK, looking out the window, it's actually really interesting because I have terrible 5G there, 13:58.280 --> 14:05.480 and what happens is that it's a row we might set the set point up there, it really won't get it, 14:05.480 --> 14:11.240 it'll come back down again, you get the latency goes hugely up, and then we negotiate back down, 14:11.240 --> 14:18.360 hopefully, the bit right, and we don't like right down in the less than half a megabit a second, 14:18.360 --> 14:25.000 but now we're kind of back to having a halfway sensible, it's struggling, actually, 14:25.080 --> 14:30.120 but you can see the trees are moving, so we're still there, so that's looking at my window 14:30.120 --> 14:38.680 in Teshire and that's over, over 5, over 4G, I suspect, actually, but yeah, O2, LTE, 14:39.880 --> 14:44.920 yeah, so that's the camera in action, and that one where it is, if I plugged it in, 14:44.920 --> 14:52.600 would do the same thing here, so yeah, that's me, I think. 14:55.240 --> 15:00.200 Oh yes, Teshire. 15:02.520 --> 15:13.000 Sorry, you're going to speak loud on a bit there? 15:13.000 --> 15:15.480 During these hardcore players, H side are we in hand-drivers or levels together with Teshire? 15:15.480 --> 15:23.560 So that task was, that we'll be the question, which was that, 15:23.560 --> 15:28.560 which was that we were with any hand overs involved in the 5G test. 15:28.560 --> 15:30.560 It was just yes lots. 15:30.560 --> 15:34.560 So that track was covered by, I don't know if I got the diagram here, 15:34.560 --> 15:39.560 that track was covered by a, I think, 7 or 8. 15:39.560 --> 15:43.560 So each of the blobs, the colored blobs is a separate cell base, 15:43.560 --> 15:46.560 so there was it, that's 7. 15:46.560 --> 15:51.560 And so there were 7 base stations and actually getting on the track, 15:52.560 --> 15:55.560 I think I counted it as out of 12 or 14 hops. 15:55.560 --> 15:58.560 So hopping between cells regularly as it goes around. 15:58.560 --> 16:01.560 And the faster you go, the hops get worse, 16:01.560 --> 16:05.560 like they're, so to that answer the question. 16:05.560 --> 16:07.560 Okay. 16:07.560 --> 16:09.560 I have one question. 16:09.560 --> 16:12.560 With the feet that you said that there's a new RFC is like, 16:12.560 --> 16:15.560 oh my hope, so you said that you get close to condition 16:15.560 --> 16:17.560 to the next hole. 16:17.560 --> 16:19.560 If you said that, that is CAT. 16:19.560 --> 16:21.560 Oh yeah, RC88. 16:21.560 --> 16:27.560 So RC888 is the RTCP feedback mechanism 16:27.560 --> 16:33.560 that covers the new use of those two bits in the IP header, 16:33.560 --> 16:36.560 which will not congestion or something. 16:36.560 --> 16:38.560 And nobody quite knew what to do with them. 16:38.560 --> 16:40.560 And recently there have been a bunch of, I say recently, 16:40.560 --> 16:44.560 last few years, been a bunch of RFCs about how to use those, 16:44.560 --> 16:46.560 make good use of those. 16:46.560 --> 16:50.560 And that's just sort of emerging now in some mobile networks. 16:50.560 --> 16:55.560 You will start to see that when equipment in the path 16:55.560 --> 16:59.560 sees that something is going into a queue or a particular queue, 16:59.560 --> 17:02.560 it's like interpretations of it vague. 17:02.560 --> 17:04.560 But it will set one of these bits. 17:04.560 --> 17:06.560 And then the endpoint that receives this can say, 17:06.560 --> 17:09.560 hey, well, I've got a packet, but it had this bit set. 17:09.560 --> 17:12.560 So I know that it was put into somebody's buffer along the chain. 17:12.560 --> 17:17.560 And where RC888 says is, okay, on the basis of that, 17:17.560 --> 17:20.560 I'm going to say the RTCP feedback message back to the sender saying, 17:20.560 --> 17:25.560 over the last 5,000 packets, this, like 17 of them, 17:25.560 --> 17:27.560 have the convent congestion bits set. 17:27.560 --> 17:30.560 So you then know that maybe you're reaching congestion. 17:30.560 --> 17:33.560 I haven't had enough experience to use it yet, 17:33.560 --> 17:38.560 so I'm like speaking from having skimmed the RFC rather than fact. 17:38.560 --> 17:43.560 And most of the end-point cases, maybe it's full by fault. 17:43.560 --> 17:46.560 So I think if you get one that where it isn't set, 17:46.560 --> 17:47.560 you will have to set it. 17:47.560 --> 17:50.560 If it's already set, you should leave it alone. 17:50.560 --> 17:53.560 That's, but this is really for realtors rather than, 17:53.560 --> 17:58.560 and then the end-point gets to say that they're interested in having it 17:58.560 --> 18:01.560 and interpret it as kind of the way it works, I think. 18:01.560 --> 18:06.560 But I can say, I still don't want to get a chance to play with. 18:06.560 --> 18:07.560 Thank you. 18:07.560 --> 18:08.560 Thanks then.