In fact, it's been a problem in various guises, certainly in the UK since digital TV became popular in 1998.

But it's more of a problem now as we watch on different devices, perhaps easy things.

If we demo it, I've got the live tennis from Wimbledon.

This is coming from the area on top of the roof was interesting to be cable or satellite there.

She wouldn't make that much difference, or they do sometimes get delays between the three of them.

If we bring up the same thing on the BBC, I play, which is the online streaming service again, we're saying we want to watch this life on.

We see we got completely different part off the match you and if we would watch it for long enough, we would see that this one was ahead of this one, probably by about 90 seconds to two minutes.

If you're watching on your streaming by your device without your TV, your phone or something, you're going to get a slightly delayed video.

If I bring it up on another computer again, we're watching live by the I fare.

What we find out is.

Actually these two aren't in sync either.

Is about a three second delay by something changing on here to that, and we can work out Sean conducing clever things and work out the exact delay between that screen on the streaming one.

Is this just cause it's coming across the Internet?

It's gotta go through loaded.

Yeah.

I mean, these is way to understand why this is happening while we're getting there is actually just have a think about how streaming video work what's going on.

I understand that probably actually works best if we start how we get the picture from the camera on the back.

There is a connections here on the way.

That video normally sent these days is digital over a signal called HD SD Eye on these run depending on whether it's sth d u h d.

It could be a CZ Lois 270 megabits per second or is high sort of 1.5 gigabits, also for HD and then for you Stu talking up to sort of 12 gigabits of those, sometimes that's carried over four separate cables rather than one single one.

When things were analog and everything went over C R T type displays like the one behind me.

Things were that simple, so we had a camera so on we had TV.

Oh, I display and effectively you could connect to cable between the two.

On this camera would start producing the image.

It would be scanning across the top of the image, and they would do the next line in the next line in the next line.

And someone will see the video on interlaced for how that's no actually done assumes it was started.

Scanning would send the sink course to say, this is the beginning of the line down the cable.

It would then send the analog signal down.

The cable on the C R T display could start displaying that image on screen effectively as soon as it saw the image it was immediately displayed on screen.

The delay was effectively the length of the cable on the speed of light so effectively zero on any sort of terrestrial cable basting.

And even if we punch on Ariel in here as well, fasten Ariel on transmitted it, and we had some sort of receiver here to connect to the TV again, speed of light.

It was fascinating in the old days of analog TV than everything.

What the camera saw could be on your screen within a tiny fraction of a second.

You would see it live even if this was a digital link.

As long as you're not starting to compress it, then you start me, for example, the str connection on Shawn's camera.

We start digitizing it.

We get sent along the same thing that happened.

It would be instantaneous.

Things get more interesting when we start to do digital transmission because the bit rate.

So we said it's so high you're not going to send 12 gigabits per second out over the over the air.

You want to compress it and reduce it.

And the way that that's generally done is that you take hang on.

I've got the perfect problem for this visual aid.

Before we had video, there was film anyway, So the way that the digital compression where he's rather than working on a single frame, it would takes a region of say, That's a 12.

That's about 12 on dhe.

We compress them together into a block.

Of course, what this means is, is that if you've got a compress, the 12 all into related to each other.

You got have all 12 frames in here.

So you gotta wait while those sort of Siri's of frames come in.

And so this is gonna delay the video by?

Well, I say it's 12 frame.

That's about half a second in U K 50 Hertz land.

If that's all we did, we would have 1/2 2nd delay Next would have to wait for that half second of video to be captured into our compressor.

We compress it and saying, then we can send it, and then we can decompress it.

Actually, they're probably be some decompression delay as we sort of decompressed it as well.

But that would probably only be another frame.

Will say wouldn't be quite as long as this.

Now, you could just do it on those 12 and then you would take the next 12 or so compressed that see it end up with 1/2 2nd delay, and so you can start to see where the delay starts to come from in terms off.

Sending this thing Actually, what you tending to find is it wasn't 1/2 2nd delay it was more like two or three seconds you got on.

Part of that was that you'd actually want to try and do walk, compress things in more than one go so that if your first half second say near needed slightly more bits to encode it in the next half, second needed slightly less.

He could sort of rob from Peter to pay Paul Toe sort of managed a bit rate over a period of time, and then you'd have to buffet at the other end to make sure everything works.

So you're getting a delay because of the way the compression works.

What about if we start to do this over the Internet?

What we've seen that we can send that data down a network connection and get it to display no problem at all.

But the key difference here is that whereas when it's transmitted over the TV, it's board cast, we send the signal.

One sound of the transmitter on anyone who's got a receiving Ariel can receive that signal decoded and watch without network connection.

It's a point to point we send the packets from one machine to another machine, yet we can have broadcast and we can have multicast.

But in general it's point to point.

We send it from one machine to another.

Problem with that is, if you want more than one person to watch it, then you need Maur.

Good morning stream.

So you've got the computer, which is connected to the camera or the TV network system there.

So the video's going into that, and then he's got a network connection on Dhe for something like the eye player.

That's about five megabits per second on that, sending it out to my computer here.

But then showing decides it is fed up of filming, this computer finally wants to know what tennis is doing, so he connects his computer teary again.

That's another five megabits per second there on so on, and so on somebody, This machine is known to produce 10 megabits, so we're getting your problem.

Here is the more streams we had.

We have to send it out multiple times.

This is a band with issue.

It's a band with this, you know it takes five megabits per stream.

We want two streams as 10 megabits, four streams as 20 and so on.

Up to 100 megabyte card, you could probably 20 streams and so on.

So what?

What we need to do what?

We could put another computer in here, another server and feed the video.

And then we could actually start adding other people and load balancing them to get there.

And so on on, if we're very clever, what we'd actually do is we start moving these computers to be closer to where they use is also using less of the network.

And so what we could do is actually have this computer here said it was in my local I p.

It could just take the same data coming from this one and send it on toe Shawn's computer, and he could send it on to my computer here on then Captain Brady's as well when Australia were playing.

So actually, we now have five megabits from this on dhe five from each of these, because it can copy the easy out to each of them.

And of course, this is gonna increase the delay slightly, but it's going to be marginal.

Seats are really making it, but that's not explaining why we get those delays.

So we need to build up lots of machines transmitting it, move them closer.

The problem with this approach is that we were sending data from the encoding computer to Brady's machine, my machine insurance machine.

How do we make sure that the packets we want to send here get to these machines particularly ist the way you do?

They're using a system called GDP, not the standard TCP that was doing there.

And you had issues with people's firewalls getting in the way.

So the way they got around that Waas I think Apple first came up with a thing called http Live streaming his equivalents from a daily Microsoft and standard.

It tends to be used now is something called MPEG dash dynamically adaptive streaming over H, D, g, P and the The way this works is sort of on a sort of biggest scale version of what we saw happening at the lower end.

If we imagine what we're watching, whether it's a video recorded like this YouTube video or something that's happening live, we can think of their being time involved here, and we start off on.

It continues playing up until some point, the idea is, rather than sending as warm long, continuous stream like we're doing earlier, he said.

Well, okay, let's break it up into a Siri's off segments on Let's break it up.

Say, every three or four seconds, we encode a segment that is three seconds long.

We incurred another secondment that is three seconds long.

So it takes up to six seconds.

Another segment that's three seconds long.

Nine seconds.

And so now we just break the video into three second jumps to be a lot more film.

But you get the idea on what we do is we encode that first chunk into a compressed video file, say, and back four doesn't really matter which one it is you use and you get the file just like if you compress the video on your computer.

And then you put that file onto the web and you tell your client to download that file from the web.

So it doesnt.

Http, get requests for that file.

After three seconds, we can encode this file that will take some amount of time that say it takes what you wanted to take less than three seconds Hopefully.

But it takes amount of time to encode that they were down there, put it on the website we download and because we can reuse all the content delivering that works that we've already got in place for the Web to distribute this out as we're going.

So this can then get that file.

And while this is then playing out this file here and of course there's gonna be three seconds later, we can do the same thing with the next chunk.

We can encode that we get another segment of the thing when we put that onto the Web as well.

And we stretch this one so we can then start playing that one out there soon as this video has finished playing.

So I play the 1st 3 seconds and then we start playing back for the next one on the process repeats until we get to the end off our video.

So this explains why the two I play ones were out of sync with each other because this one we started first it started playing from this junk and it got somewhere through it would be so the next one.

It started playing from the beginning of that junk, and so we got up to three seconds worth of delay, and if we just go back, we can actually see those chunks arriving.

I'm looking at what?

My weapon as is doing the de burger built into safari.

So if we watch their the bottom as we start the video playing to consider continuing updating as each bit of this file comes in his downloaded M four s, so what does that mean?

That's just a little bit of that pig video.

It's not quite fully doesn't have all the head of stuff in them things.

So the moment we've got the video playing on Diz, playing at 2.9 megabits per 2nd 2009 to 5 full screen it.

We'll see in a second that it will switch from the 2.9 megabits section to the five megabit version.

Let's just drop it, just drop.

So, for some reason, something on the network.

But there's more people watching.

It may be that people are downloading things here with the university, so it's actually said I'm struggling to get the 2.9 extreme.

I'm going to drop down to the 1.7 megabits per second stream, so the moment we just assume that this is actually encoding for one video streams.

We've seen them coming in.

But you can actually be really clever here because, as we saw in that demo there, that actually your network conditions aren't always fixed.

If they're not always sending a five megabits per second, you can't necessarily always do that.

Even when you've got a gigabit connection onto the Internet like we've got here.

What we you can do with this sort of approaches as well as encoding Ah, high resolution version.

You could also encode a slightly smaller version on an even smaller version of that.

And then if the computer realizes that when it gets to this one that it can't download the large Russian it gets Okay, I'm gonna pull the small version down and actually play the smaller version here.

Andi, as long as you make sure that all the segments lined up, they start at the same point.

They finish at the same point, then you can dynamically, hence the dash switch between them, so that you always able to play the video even if the quality is going up and down, depending on the network connections that are fluctuating okay, We can see what we get.

A set of three second delay as we wait to encode those videos.

And we can see why we get a sort of delay between the two, because we have to start at the beginning off one of the segments, although there are ways you could jump in.

But even then, if you think about it, if I start watching it and jump in here, I have to start playing from here and have to start downloading all this bit first.

But Sean starts watching at this point.

We're here.

He asked it down, though, that you will get some variability there in general.

That's why we get variations in it.

Why do you sometimes see this to being 90 seconds delayed from actual real time?