 What what are the requirements for our different applications of her streaming video making a voice call? What do we need for the network for the application to work? Well Well, the the data rates vary for example voice audio applications need data rates of tens to hundreds of kilobits per second Video we have more information. So we need higher data rates the number of errors in the network impact upon the performance on the application performance the amount of delay and jitter what I'm going to do is try and demonstrate using a video and see how some of these criteria impact on our performance so What I'm going to do is stream a video between my two laptops and See and change some of those network characteristics and see what happens with performance What have we got the? We're going to clean stream from a server to a client my blue laptop is the server and Gray one is the client and the server has some video on it. I think it's mp4. We'll see in a moment So what I want to do is use the network To send instead of playing the video on the server, but to send the video To the client and as the client receives the packets containing that video display them on the client I've connected my two laptops via a LAN cable. So we're going to use the LAN cable gives us a data rate of 100 megabits per second with my LAN cards How do I stream video anyone anyone know with some software to stream video? between two computers You need a of course. You need two pieces of software You need the application at the server to just generate the stream and send the packets so what the server does is it takes the video and And codes it or in fact takes the video and puts it into packets To be sent across the network and there are different ways to stream There are different protocols to be to be used We'll use one called RTP to stream And so the server takes a video and puts it into packets sends to the client and the client receives those packets and Essentially has received the video and then uses its decoder to display the video. So we need a Streaming server and a client to play it in my case. I'm going to use a program called VLC, which is a Multi-media player, but it also can act as a server a streaming server Let's just check The top terminal here is my client and The bottom I'm logged in to also my server as well. So Let's just ping and check the network. I think the server address is one one one. Just remember Server is one dot one dot one dot one and client one dot one dot one dot two We see in our network the risk the response time the round trip time is about half a millisecond Get there and back is about half a millisecond Now let's take a video on my server and stream it the instructions or some of the instructions I've got on a Web page that describes the things I'm doing here. So let's just go through them I will not explain all the commands I use But you'll get a basic idea and I need to remember them. Let's start the stream So what we need to do is start the server and also start the client I'll in fact start the client first The client programs called VLC not 1010 what I'm going to tell my client to do is To receive and That's the clients IP address one one one two and the port number I'm using for this streaming application is five thousand and four and RTPs the protocol that the the video is encoded in We'll see a description of RTP later, but let's just see see it work to get started So if the server is going to use RTP to send packets to the client I'll also need to start of course the streaming server and I have a video. I use VLC The C means the command line version. There's no graphical user interface Choose the video and I've got a trailer for some old movie here We'll see it in a moment and then tell the server to output So what the server does is takes this video an mp4 video and outputs it as packets out onto the network So the command line to do that. It's a bit complex. It takes some time to learn Says use RTP The destination is my client one one one two the port is five thousand and four and The method for encoding the video into packets is called TS the multiplexing method You don't need to remember or understand all of those details yet just know that this command will take the video at the server and Output packets onto the network to the client. I'll start the The client It's not receiving anything yet. We'll show it over here When the server starts it should start seeing something. So this is on the client computer here We should start seeing the video Okay, the video starts and it goes for What brings you to the land of the gatekeepers, I'd note the quality I'm searching for someone So That's our baseline. That's what it should look like and sound like with a normal stream So we have a network which is fast in our case a hundred megabits per second Is the data rate supported by my network round trip time? The delay is small We want to see what happens when we change different characteristics of the network What happens if we change the round trip time increase it? How does that impact on the quality of the video and what happens if we for example introduce packet loss? So let's try some of those things and see what happens in our video Shut that and this is somehow related to your assignment in that we'll use TC and IP tables to look at the impact of packet drops and delay Let's stop the server Let's first try packet drops on the on the client The one at the top. I'll use IP tables to Drop packets coming in So packets coming into my client I'll use the statistic module to randomly drop packets With some probability Let's start with what? Start smaller One in one thousand okay, this is one in one thousand packets will be dropped so IP tables is a it's a firewall, but here's a module the statistics module that says of a A certain number of packets that come into my computer. I'm going to drop Take the action to drop some of them The probability point zero zero one means drop one in one thousand packets Okay, we've set that up and now let's run the video again and see what happens. So we need to run it on the I'll get the client ready. I'll just move it across so we can see it See if you notice any difference in the quality People can't see the video What brings you to the land of the gatekeepers see what difference? I'm searching for some very hard to notice any difference there that it's Chases it looks fine. It looks like the original video. So there was a small amount of packet loss there The network We'll see later. How many packets are sent but of it one thousand packets sent one of them was being dropped It had almost no impact upon the end application the application still works well so in this is the case of the packet drops a Small amount will not impact upon the application with multi-media applications Let's increase it. Let's change it to delete that one and change to 2% Two in 100 just to make it a bit bigger start the client Start the server See if you notice any difference in the quality this time See the artifacts that what brings you to keep the problems I'm searching for 2% in this case Our multi-media applications in this case. It's streaming. So in this case We're sending the data across the network Some packet loss some data loss we can tolerate the application still works fine with a Web download sending an email. We cannot tolerate any packet loss And hence we use TCP to to have retransmissions here. We're not using TCP It's in fact using UDP if we look closely some packet loss okay, but Large packet loss Starts to have an impact from the user's perspective. Let's try Something else let's remove that So we're back to normal. We're no longer having a packet loss. Let's look at Delay in the network. Currently the delay is the one-way delays 250 micro seconds Round trip time is there and back With streaming we really care about one direction. We're sending packets just in this direction our video The delay from when I create the packet here Until it's received at the client is half of the round trip time 250 micro seconds Let's increase the delay Let's say we had a network from here to somewhere on the other side of the world where the delay was much larger And we can use TC to do that and I'll do it at the server. I have to remember TC We add a queuing discipline What we what we can do to add this Delay is to use TC which in the server when it sends the packets before it sends them it Introduces this extra delay So it creates the packet. It's about to send it and TC will delay that packet for a specified amount of time And that's what we're going to specify here It emulates some network net M Let's add 500 milliseconds half a second delay The second value. What have I done there? 500 milliseconds 1ms The second value is not important yet. That's we'll see the impact later. That's the jitter the delay variation so the idea here is that This 500 milliseconds now From server to client will have delay of not 250 micro seconds, but 500 milliseconds What's going to happen with our application? Is the video going to look okay? Hands up for yes Hands up for no Okay, let's try. So I start that Gotta do it correct. I've done something wrong. I know what I've done. I've It's Let's try again. I've already got a delay on my I Think I've typed that wrong and now my computer is delayed by 50 seconds Let's try again Delay 500 milliseconds 1 millisecond variation Okay, and let's ping just a test so now when I ping from server to client The round trip time is the normal round trip time plus the 500 milliseconds Okay, because I've introduced this this fake delay into one of the computers. Let's see how that impacts on our On our video the client ready Start the server now starting the video that what brings you to the land of the gatekeepers I'm searching for someone Yes, wrong the video is fine. I've been alone for as long as I can remember well fine Except the startup It took longer to start playing the video Okay, so for streaming delay is not a big issue for stored streaming Because what happens is that the server Starts creating the packets to send sends them They take a long time to get to the client because of the delay in this case They take 500 milliseconds half a second to get there but for Playback of the video once we start receiving them We actually receiving the packets at a constant rate and we can play back the video at a constant rate giving a smooth playback Okay, so the delay is not an issue in this case it impacts upon the startup But not once it started So let's try something else Here we can think of the delay was 500 milliseconds plus or minus 1 millisecond So some packets were delayed 499 some 500 some 501 that's the idea this delay variation let's increase the delay variation and Let's try and let's make it big because just to demonstrate the impact the delay variation is now 100 milliseconds I have to change that not add if it's right and let's try a ping and see if that's working see now the The ping is Varying between about 400 milliseconds and 600 milliseconds because the delay we've introduced is 500 plus or minus 100 So there's some random variation in the ping here. So we have delay variation Let's see how that impacts on our video. It's receiving something Audio started again because of this delay Delays the video What brings you to the land of the gatekeepers Searching for some quality is impacted a little bit there because of that delay variation Especially especially in the fast-moving scenes You notice when there's a lot of motion there Quality goes down and that's the way that videos are encoded in that The what the way to compress video is Okay video is made up of multiple frames one simple way to compress the video to store it in a smaller space is instead of storing every frame Take one frame and store the difference between That frame and the next frame Because in if you look at two frames in a period of what 20 milliseconds Many of the pixels will not change especially if there's not much motion. So if the videos Has low motion then there's not much change between frames and therefore you don't have to store so much You can compress it much more but if there's a lot of motion the pixels change a lot between frames and It cannot be compressed as much or in other words you need to send much more information across the network so and the way that it's decoded at the to playback means that With a smaller or with amount of jitter that we had in this case or delay variation Especially when there's high motion. There was some impact upon the quality one more Test what else can we test more jitter? Let's try again quickly, let's Let's try again actually Change the jitter to a different value Plus or minus 200 milliseconds. I forgot TC. What brings you to the land of the gatekeepers? I'm searching for some But you can still see some And at the end even okay What We were not changed right now, but what data rate is needed to send this video across the network our Network supported a hundred megabits per second. What is needed to send across that network? Well, it depends upon how much information we have encoded in that video Let's look at the size of the video. So at the server the video is What's this? 4.3 megabytes That's the size of the video so effectively at the server We have the video and as we stream it. We need to send that video to The other side in fact when we play we can look at some statistics. Let's just remove our remove our delay Reverb back to the normal network statistics content bitrate What brings you to the land of the gatekeepers? 1,000 kilobits per second. It's going up and down I'm searching for some Loan for as long as I can remember So that is showing how fast or how much content is being streamed in this case And it varies because with a video again because of the video with different motion. It's compressed and there's At different times there's a different amount of information to send so the the rate at which My client is receiving the data and that's what we're showing here The content bit rate the rate at which I'm receiving the content is varying Usually when there's a lot of motion it was high and we may have noticed it went up to about 2,000 kilobits per second two megabits per second and there were some low cases in fact in the the credits at the end Down to just a hundred two hundred kilobits per second What is the content that we're sending? We'll come back to this rate and look at the average in a moment this shows the Format or the codecs used for this video of course a video in this case contains the the video and the audio The movie contains both So the video in this case use the mpeg for codec the resolution was 854 by 480 854 by 480 Pixels so 850 for across 480 down Frame rate of 48 frames per second each frame had this number of pixels Let's assume each pixel doesn't say here was 24 bits 24-bit color if we have 854 times 480 pixels each pixel is 24 bits and that tells us how many bits we need in one frame and Then we can work out how many bits per second That raw video is to use a calculator. We have 854 times 480 times 24 24 bits per Pixel so that's 9.8 million bits per frame and There's 48 frames per second so that is What do we get? 472 megabits per second the raw video Excluding the audio because that's even more the raw video in this case without compression is 472 megabits per second So if we want to stream this raw video across our network, it wouldn't work My network has a data rate or a capacity of a hundred megabits per second. I've got to Smoothly play back that video by streaming. I send at 472 megabits per second But only a hundred of those 472 arrive every second the others will be lost or delayed and it will be terrible unwatchable playback at the client if I sent the raw video. This is the raw data rate but mpeg 4 compresses that video and The rate that we actually need to send varied between 500 and 200 502,000 kilobits per second So about 2 megabits per second maximum so from 470 megabits per second down to 2 megabits per second that's 200 and almost 250 times Less information because of compression so with video we can compress a lot saving our resources for the network if my data rate was One megabit per second Not 100 megabits per second You would see if you tried to stream that video you wouldn't be able to watch it or the quality would be very poor at the receiver The data rate of your link or of your your network Needs to be larger than what we're trying to send out to get smooth playback So what impacts upon streaming a video and the same with streaming of audio because we had audio in that case main impact is packet loss We can tolerate some packet loss But once we get above some level we start to see the impact at the receiver and the other one is jitter or delay variation Not the actual delay, but the variation between the delay in the packets First packet has 500 millisecond delay. Next packet is 480 milliseconds. Next one is 520 milliseconds The delay of each packet is varying That makes it hard for the client to smoothly play back that video any questions on how that those concepts work are the main things that we need to pick up from this demo and the impacts of performance on our Multimedia application. So sometimes you say on YouTube you stream a video and maybe it plays back smoothly and then it It stops for some time for a few seconds and then starts playing back again And we'll see that's because most likely because of some jitter or Some significant increase in delay or reduction in in the capacity It's what's happening there is that Instead of getting what we saw where we see this pixelation where we don't see all the pixels correctly what the the application is doing is Buffering what I have what it does is it plays back and once it detects that there's some jitter in the network Which is too large. It just stops the playback at the client pauses it effectively and Then keeps receiving packets buffers them up until it can play them back smoothly again And then it starts playing back again, and you may see it plays it stops and plays again so most likely because of some jitter in the network or Some low throughput or capacity We will see that when we look at the slides an example of that so after the evaluation you We will look at jitter and buffering of our video to the course evaluation and then we'll continue