you we've all suffered from this 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 the easiest thing is if
we demo it i've got the live tennis from
wimbledon this is coming from the aerial
on top of the the roof we could just
need to be cable or satellite does it
wouldn't make that much difference
although you do sometimes get delays
between the three of them if we bring up
the same thing on the bbc iplayer which
is the online streaming service again
we're saying we want to watch this live
and we see we've got completely
different part of
the match here and if we were to watch
it for long enough we would see that
this one
was ahead of this one probably by about
90 seconds to two minutes so if you're
watching on your
streaming via your device whether that's
your tv or 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
via the iplayer what we find out is
actually these two aren't in sync either
there's about a three second delay by
something changing on here
to there
and we can work out sean can do some
clever things and work out the exact
delay between that screen
and the streaming one is this just
because it's coming across the internet
it's got to go through loads of servers
um yeah i mean the easiest way to
understand why this is happening why are
we getting those is actually just have a
think about how streaming video works
what's going on we understand that it
probably actually works best if we start
how we get the picture
from the camera on the back there is a
connections here and the way that video
normally sent these days is digital over
a signal called hd sdi and these run
depending on whether it's sd hd uhd it
can be as low as 270 megabits per second
or as high
um sort of 1.5 gigabits or so for hd and
then for uhd you're talking up to sort
of 12 gigabits although sometimes that's
carried over four separate cables rather
than one single one when things were
analog and everything went over crt type
displays like the one behind me
things were dead simple so we had
our camera
like so and we had
a tv
or our display and effectively you could
connect a cable
between the two
and this camera would start producing
the image it would be scanning across
the top of the image and then you'll do
the next line and the next line and the
next line and so on we'll see the video
on interlaced for how that's not
actually done as soon as it started
scanning it would send a sync pulse to
say this is the beginning of the line
down the cable it would then send the
analog signal down the cable and the crt
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 and the speed of
light so effectively zero on any sort of
terrestrial cable based thing and even
if we put an aerial in here as well
that's that's an aerial and transmitted
it and we had some sort of receiver here
to connect to the tv again speed of
light it was fast enough so in the old
days of analog tv
then 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 i mean for example the
sdi connection on sean's camera we start
digitizing it we get sent along the same
thing would happen it would be
instantaneous
things get more interesting when we
start to do digital transmission because
the bit rates that we said are 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
um hang on i've got a perfect prop for
this
a visual aid
sort of before we had video there was
film
anyway so the way that
um the the digital compression would
work is rather than working on a single
frame it would take say a region of say
let's say 12 that's about 12
and we compress them together
into a block now of course what this
means is is that
if you've got to compress the 12 all
interrelated to each other you've got to
have all 12 frames
in here so you've got to wait
while those sort of series of frames
come in
and so this is going to
delay
the video
by well let's say that's 12 frame that's
about half a second in the uk 50 hertz
land if that's all we did we would have
a half second delay in there we'd have
to wait for that half second of video to
be captured into our compressor we can
press it and think then we can send it
and then we can decompress it actually
there'd probably be some decompression
delay as we sort of decompressed it as
well but that would probably only be
another frame or so it 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
and compress that so you'd end up with a
half second delay and so you can start
to see where
the delay starts to come from in terms
of
sending this thing
actually what you tended to find is it
wasn't a half second delay it was more
like two or three seconds you got and
part of that was that you'd actually
want to try and do more 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
you could sort of rob from peter to
paypal to sort of manage the bitrate
over a period of time and then you'd
have to buffer it 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 well 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 broadcast we send the signal
once out of the transmitter
and anyone who's got a receiving aerial
can receive that signal decode it and
watch with our network connection it's a
point to point we send the packets from
one machine
to another machine yeah 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 the
problem with that is if you want more
than one person to watch it then you
need more than one stream so you've got
the computer which is connected to the
camera
or the tv network system there so the
video is going into that and then it's
got a network connection and for
something like the iplayer that's about
five megabits
per second and that's sending it out to
my computer
here but then sean decides he's fed up
for filming this computer file he wants
to know what the tennis is doing so he
connects his computer to it again that's
another five megabits
a second there and so on and so on
somebody this machine is going to
produce 10 megabits so we're getting a
problem here is the more streams we add
we have to send it out multiple times
this is a bandwidth issue it's a
bandwidth issue it takes five megabits
per stream if we want two streams that's
10 megabits four streams that's 20 and
so on up to 100 megabit card you could
probably get 20 streams and so on so
what what do we need to do 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 and if we're very clever what we'd
actually do is we start moving these
computers to be closer to where their
users are so using less of the network
and so what we could do is actually have
this computer here say this was in my
local isp
it could just take the same data coming
from this one and send it on to
sean's computer and he could send it on
to my computer
here and then perhaps the braid is as
well
when australia were playing and so
actually we now have five megabits from
this
and five from each of these because it
can copy these out to each of them and
of course
this is going to increase the delay
slightly but it's going to be marginal
so it doesn't really make any difference
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
radius machine my machine shaun's
machine how do we make sure that the
packets we want to send here get
to these machines particularly as
the way you want to do is 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 was i
think apple first came with a thing
called http live streaming but his
equivalence from adobe microsoft and the
standard that tends to be used now is
something called
mpeg-dynamically adaptive streaming
over http and the the way this works is
sort of on a
sort of bigger 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 that being time involved here
and we start off and it continues
playing up until some point the idea is
rather than sending it as one long
continuous stream
like we were doing earlier is he saying
well okay let's break it up into a
series of segments and let's break it up
say every three or four seconds we
encode a segment that is
three seconds long we encode another
segment that is three seconds long so
that takes up to six seconds another
segment that's
three seconds long nine seconds and so
on and we just break the video up
into three second
chunks be a lot more film but you get
the idea
and what we do is we encode that first
chunk into
a compressed video file say mpeg4 it
doesn't really matter which one it is
you use and you get a file just like if
you can press 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
does an http get request for that file
after three seconds we can encode this
file that will take some amount of time
let's say it takes well you want it to
take less than three seconds hopefully
but it takes some amount of time to
encode that then we download it put it
on the web server we download it and of
course we can reuse all the content
delivery networks 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 it's going
to 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 and we put that
onto the web as well and we stretch this
one so we can then start playing that
one out as soon
as this video has finished playing so we
play the first three seconds and then we
start playing back for the next one and
the process repeats until we get to the
end of our video so this explains why
the two iplayer 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 when we saw the next one it started
playing from the beginning of that chunk
and so we got up to sort of three
seconds
worth of delay and if we just go back we
can actually see those chunks arriving
i'm looking at what my web browser is
doing the debugger built into safari so
if we watch there at the bottom
as we start the video playing so you can
see it continuing updating as each bit
of this file comes and is downloaded m4s
so what does that mean well that's just
a little bit of mpeg video it's not
quite full it doesn't have all the
header stuff in there and things so at
the moment we've got the um video
playing and it's playing at
2.9 megabits per second 2009 but if i
full screen it will see in a second that
it will switch
from the 2.9 megabit section
to the five megabit version
it's just dropped out so it's just
dropped so for some reason there's
something on the network maybe there's
more people watching it maybe people are
downloading things here at the
university so it's actually said i'm
struggling to get the 2.9 meg stream 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 stream so we've seen them coming
in but you can actually be really clever
here because as as we saw in that demo
there that actually your network
conditions aren't always fixed if
they're not always sending at 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 you
can do with this sort of approach is as
well as encoding a high resolution
version you can also encode a slightly
smaller version
and 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 version it could say
okay i'm going to pull the small version
down and actually play the smaller
version here and as long as you make
sure that all the segments line 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're 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 why we get a sort 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 of one of the
segments although there are ways you can
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 i have to
start downloading all this bit first
but sean starts watching at this point
where he only has to download that but
so you will get some variability there
but in general
that's why we get variations in it
why do you sometimes see this to be 90
seconds delayed from actual real time
the answer is probably quite boringly
simple in that to make sure all this
works to make sure that the video is all
available on all the web servers and
they're passed out to all the different
content delivery network servers close
to where the clients are rather than
being stored at the server wherever the
video is being encoded is that you put
in a certain amount of buffering both
at the server end so that you will
encode several things and then have them
being passed out
while others are being encoded with a
delay so that if one gets delayed for
some reason you can catch up but also
you do the same thing in your client
your client would buffer things up so he
knew hang on i can't download this one
which is taking too long i can switch to
the low one and hopefully have time to
get it
and switch to the low one before you
notice it sort of stuttering on the
display you just continue
playing it so basically the reason why
is there's a heck of a lot of buffering
going on while you're just waiting for
things to sort of buffer up in a waiting
for things to be downloaded storing them
in your memory and then playing them out
after a certain amount of time surely
the more people that use streaming as
opposed to broadcast the worse this
problem's going to get before it gets
better right um so it's probably not
related to the number of people
because the more people you are the more
servers you need but you then you just
fan out
at different points so it's probably the
number of clients watching probably
won't make any difference to the actual
delays more just the buffering time
that's built into the processes but if
we hit play on a live stream yeah we
wait maybe a few seconds and it plays
yes so that's our buffer yeah all of the
rest of it really is happening at the
encoding but the thing is is that your
buffer you start from where what video
file you actually start playing back
with
so if you'd imagine that you've got
the current three seconds of being
encoded perhaps you've got sort of
three or four minutes worth that you can
go if not further back so you can rewind
the video streams and so on you might
start there and start pulling them down
faster i mean we're encoding at five
megabits i can pull things down at one
gigabit
here so i will download those files very
very quickly so i might start
reading several in so and i said well
actually if i can down this quickly i
might catch up a bit but yeah a lot of
it is
in the server and making sure that it's
all encoded
um and then split up sent out to all the
servers and so on and that happens
before
the client needs them of course the
simple thing would be the best way for
transmitting live video
over the internet is if you only have to
send the packet out once and then it was
copied to everyone who actually wanted
to receive it which is what happens when
you broadcast it from the aerial you can
actually do that there is a technology
called multicast and networks support
things called broadcast um but it's it's
actually fraught with all sorts of
interesting complexities your routers
have to support it
um to make sure that it actually gets to
the right point um it has some
interesting effects with wi-fi because
you have to guarantee that every um
machine on the network can receive it
regardless of how far away they are from
the wi-fi based stations you have to
transmit it at the slowest rate that the
wi-fi base station supports so they can
all receive it and so on so actually
it's it will probably happen we'll
probably come to a point where this is
all multicast out
um where each machine receives copies of
the one packet that's being sent out but
i think that's probably two or three
years away even though the technology
has been around for several years
and only we can decrypt the whole
message because we have all the keys
what's really interesting is the
properties that this gives us the first
thing is that k2 doesn't need to know
anything except the address of k1 and
the address of k3 it doesn't need to
know who i am right it receives a
message