Yeah, I'm green.
Good.
Keep it back.
Race cars, REC, those are low.
Yeah.
So this is about race cars, RTCP, video and 5G.
It's kind of actually a little bit of a low level thing.
What I'm going to do though, and it's mostly about...
Yeah, no, I should say.
I'm composing, I'm CTLP, a REC, or RTCP for small cameras, which was originally kind of
for baby monitors and stuff like that.
And it's been hugely based on open source modules.
And this talk actually about, I kind of do a little bit of that that we've been doing.
It's a race car camera.
This isn't a really prototype of it.
Plastic case.
The real thing is aluminium and carbon fiber.
I'm going to antenna a mounted on the dashboard and not, like, rabbit ears, like this.
But I'll pass this round.
If anyone wants to, like, have a look at it, that's final or not, doesn't really matter.
So the cool thing about these things is, we're trying to get right below, some of the cockpit
from the car to the... to the... to the pit.
And so the idea is that the... the pit crew can hear and see what's going on in the car
in real time.
A low latency, and we're using 5G for that, and we're using... where do you see?
So... and... we've decided, like, to try and make that work, we've been to do some testing.
So we've got a chance to do a test.
I'll go back.
No, no, no, no, no, no, no, no, no, no, no, go back, go back, go back, go back.
This is what I want.
There we go.
So we did a... we did a test of some data in Spain, and so what I'm going to show you is this
is a card during... 130 kilopyroids round the track using 90 RTP.
So we're just setting up... five megabits a second, H264 stream at 30 frames a second.
And what you see is, on the... on the frame rate, it keeps flicking up and down.
So typically when we sell hot, we'll lose a lot of frames in the frame rate of clock to zero.
But the big thing is about constant.
And what that ends up with is being pretty much unusual for the... for the pickle, because
they keep getting... stills.
So if you do the same thing running our software, what happens is... we vary the bit rate.
And the frame rate remains pretty much constant.
So there are points on this track, typically up right near the edge where the quality of
the signal isn't good enough, and we have to drop the bit rate, but we can still keep
a constant frame rate.
So that's the kind of basic trick that we're doing here.
So for those of you who prefer numbers, that's like a roughly 50 times improvement
on the amount of time that the screen is frozen, which is a useful metric.
So what we did... we did this test, funded by the EU, we needed to go over some money to
go and do this test, which was lovely.
And thanks for target expert administering that.
And idiot if her own run the test track for bending their own cameras on our test track
will let us take a camera though, which I really appreciate.
It was an interesting set of bureaucratic negotiations, but we got there.
So what's the difference between those two things?
Why do we get the 50x from?
How do we do it?
It was literally the same hardware, literally the same network, literally both using
RTP over the 5G, same codec, nothing really different, same target rate, same endpoint,
same track.
So what was different?
And the answer is RTP.
So what the heck is RTP?
It's the companion protocol that goes with RTP, it's the control protocol, it's kind
of feedback back channel, so that basically RTP messages come into like three categories.
There's roster statistics for things like sender reports, like how many frames of a
write, how many packets of a write, how many will lost those sorts of things, same thing
for receiving reports.
And there's a few kind of arcane control messages like buy, it doesn't actually do anything
much, but it does exist, which is kind of nice, and there's these feedback messages
which are, today is like picture loss, packet loss, and band estimation, and those are
the ones that we're most interested in, and I should say, I got this lovely diagram from
Sahi's blog, so thanks to him for that.
So the bad news about RTP, I really does want this wonderful stuff for us, is it's
three, it is my next favorite protocol, all the protocols I've ever implemented, it wins
the prize for being ugliest, it's a massive option, everything is optional, and it used
to run its own important now, it doesn't, so you don't even know exactly where it's
going to be, and then it's Mark Stone RTP, which is actually the right answer, but it didn't
used to be, and every extension is its own arcane weird binary format.
This one is my absolute favorite for that, which is the bandwidth estimator for in RAMB,
is what is it, 18-bit Mantissa, a six-bit of exponent, and 8-bit source ID, all the packed
into 32 bits, so you have long packed them and do a few shifts and all of us to get
a step out of it, and so as somebody who wrote S&MP stuff back in the day, like I wish
it was a S&1, and I can not many people actually would say that, but I really miss S&1 for
this kind of stuff, so the worst news is that to know what you're going to get, you have to
do an SDP or for answer it exchange, and you'll get what comes out of that exchange, you've
got no further negotiation, there's no other question and the thing, it's like, that's
what's comes out, so usual arcane or SDP nonsense, so the things that you end up with in a
web are you see call, but in order of how you like, whether you like to receive them or not,
I guess, are in B, so are in B all transport-wide CC depending on whether you're running,
if you're running multiple videos, streams, you want to use transport-wide CC, if you're running a single
R&B is actually simpler, so which we are, so it's easier for us to use that, but basically
an R&B gives you an estimate of what the channel is bound with the channel is capable of,
and it does that by looking at packet arrival times, and as some network component in the middle
starts to buffer, the packet arrival times start interval starts to grow, and you can use that to
deduce that something is about to fill its buffers, and therefore you can cut back on what you're
sending before it starts dropping packets, so that's the best possible outcome that you can get there
before it happens, before you lose anything, and that's that where it will outcome, and that
lets you minimize the latency and minimize the freezing of packets, that's one down is if you haven't
managed to do that, then or something else on the network has happened, then we may have lost the
packet, so now we'll tell you which packets have been lost, and we'll get off of you the opportunity
to resend them, and if you can do this within something like the frame interval or two, then it's
probably not visible to the user, you can close that loop fast enough, but the user probably
doesn't see, if you leave it any longer than that, and it just buff goes, or you something
stores, and so it's like a bad outcome, if it's longer than that, and we're the short-round trip
trying time and low latency, that's actually pretty good outcome, so we limit the growth of the
just above, but they're actually not servicing older requests, because we don't think it's worth
the cost. The next one down is that PLI, and this is kind of the worst case, we've lost a
packet, we couldn't resend it, and worst of all that packet contains something that the
decoder needs in order to decode anything, but at that point you've basically, you've got a
frozen screen, and so you have to send the full frame full keyframe back, and this map PLI
says, is the decoder saying, hey, I'm completely lost, send me a full frame, so that is what
you do, but very expensive, so you want to try and restrict that situation to the very minimum,
they like 10x the size of a typical frame, and anything you can do, anything you've sent before
a keyframe is now useless, because the context is wrong, so you can dump anything that's in the
queue, and there's a fourth one, it's the working code S, which is RC8888, which is RTCP Feedback
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
to mark that a device in the chain is allowed in the network, is allowed to say, I'm
reaching the congestion state, and it can set a bit in a packet as it goes through, this isn't
widely deployed yet, but it's actually going to be really interesting as a way of finding out whether
whether your network is approaching congestion, I'm hopefully will, you can use it to get much better
bandwidth estimation, the experience I've seen done on this so far actually generate worse
results for bandwidth estimation, but hopefully that will, that will change, so the summary here
is RTCP lets us go from where it's as cope with fluctuating network constraints, so like it lets us
go from a framework that is widely varying on the left to a framework that's pretty stable on
the right, and remember this is the top speed on this is 160 kph, the far right hand edge is the
cost of 160 kph, it goes through 12 cell hops per revolution, so like we're not just sitting
still, we're definitely on the move, so by using RTCP and we can do that, the big pieces that we
vary is the big, that's the big win, there are some other subsequent wins with the ability to
these send packets that have been lost, so you might ask what's all this got to do with open
source, I mean it's a nice RTCP education, but why is it open source, the answer is actually
the implementation of RTCP is an open source thing, and I wrote quite a long time ago called
RTCP Lite, and I wrote it for Voxere 1012 something like that years ago, and I'm slowly
been adding to it since, it's open source, it's I think in MIT license, and it has some support
for RTCP which kind of way it gets into this talk and why we're using it, and there's a
sample out there for WIP, which is the most basic implementation of WIP, which is the WebRTC video
ingest protocol, but it uses that library, so it's a kind of way of seeing how the library fits
together and how you could use it and a bigger that, and I'll actually have an ask, which is
I'd really like PRs for other RTP extensions, for RTCP extensions, for tests weeks, anything
you want to generate for it, I'll welcome it, that would be wonderful, and particularly anybody
wants to represent transport way CC for it, that would be wonderful, and so I'm also issues,
issues would be great, you know, anything like that, so contribute to that would be wonderful,
so it's still a great SOTP light, so I'll take questions in the matrix room, or maybe here,
we'll see how it goes, contact stuff, and I do do consulting on SOTP, RTCP, that's kind of stuff,
ice, SOTP, with all our outsourced stuff, and also piong's dreamer, the other kind of
real time things, and I build stuff with pipe, and just like with a few seconds left, I'm going
to show you pipe in action, so this is not, this is the other camera, not the one that you're
that's still going down the room, but this is a camera that's sitting outside, sitting in my home
in the UK, looking out the window, it's actually really interesting because I have terrible 5G there,
and what happens is that it's a row we might set the set point up there, it really won't get it,
it'll come back down again, you get the latency goes hugely up, and then we negotiate back down,
hopefully, the bit right, and we don't like right down in the less than half a megabit a second,
but now we're kind of back to having a halfway sensible, it's struggling, actually,
but you can see the trees are moving, so we're still there, so that's looking at my window
in Teshire and that's over, over 5, over 4G, I suspect, actually, but yeah, O2, LTE,
yeah, so that's the camera in action, and that one where it is, if I plugged it in,
would do the same thing here, so yeah, that's me, I think.
Oh yes, Teshire.
Sorry, you're going to speak loud on a bit there?
During these hardcore players, H side are we in hand-drivers or levels together with Teshire?
So that task was, that we'll be the question, which was that,
which was that we were with any hand overs involved in the 5G test.
It was just yes lots.
So that track was covered by, I don't know if I got the diagram here,
that track was covered by a, I think, 7 or 8.
So each of the blobs, the colored blobs is a separate cell base,
so there was it, that's 7.
And so there were 7 base stations and actually getting on the track,
I think I counted it as out of 12 or 14 hops.
So hopping between cells regularly as it goes around.
And the faster you go, the hops get worse,
like they're, so to that answer the question.
Okay.
I have one question.
With the feet that you said that there's a new RFC is like,
oh my hope, so you said that you get close to condition
to the next hole.
If you said that, that is CAT.
Oh yeah, RC88.
So RC888 is the RTCP feedback mechanism
that covers the new use of those two bits in the IP header,
which will not congestion or something.
And nobody quite knew what to do with them.
And recently there have been a bunch of, I say recently,
last few years, been a bunch of RFCs about how to use those,
make good use of those.
And that's just sort of emerging now in some mobile networks.
You will start to see that when equipment in the path
sees that something is going into a queue or a particular queue,
it's like interpretations of it vague.
But it will set one of these bits.
And then the endpoint that receives this can say,
hey, well, I've got a packet, but it had this bit set.
So I know that it was put into somebody's buffer along the chain.
And where RC888 says is, okay, on the basis of that,
I'm going to say the RTCP feedback message back to the sender saying,
over the last 5,000 packets, this, like 17 of them,
have the convent congestion bits set.
So you then know that maybe you're reaching congestion.
I haven't had enough experience to use it yet,
so I'm like speaking from having skimmed the RFC rather than fact.
And most of the end-point cases, maybe it's full by fault.
So I think if you get one that where it isn't set,
you will have to set it.
If it's already set, you should leave it alone.
That's, but this is really for realtors rather than,
and then the end-point gets to say that they're interested in having it
and interpret it as kind of the way it works, I think.
But I can say, I still don't want to get a chance to play with.
Thank you.
Thanks then.