[MUSIC] Push Based Media Streaming. Let's take a closer look into what this Push is. The server streams packets to the client until the client stops or interrupts the session. So it is in a form that servers can send and send and send until the receiving device says whoa, stop, I can't take anymore. The server maintains a session state with the client and listens for commands from the client regarding session-state changes. Some of the popular push based media streaming services that have been used are RTSP, which stands for Real-time Streaming Protocol and RTP, Real-time Transport Protocol. RTSP is an IETF standard based upon RFC 2326. And typically the SCP, Session Control Protocol is commonly used. On the other hand, RTP is an IETF standard based upon RFC 3550 in which UDP is commonly used. RTP on UDP lets the Server push packets to the Client. The Server bitrate is determined by the application quality of service requirements and the Client and Server characteristics. Here when we say bitrate we're talking about data traffic that is measured in units of bits per second either represented like this, bits/s or bps, bits per second for short. Push based media streaming, the disadvantages, the cons. Server has too much to do. It's too burdening. In addition, playing device's status is hard to track. Because the server and the mobile device are far away. The server is trying to keep track of the mobile device, or your PC, or laptop computer status. And it's far away. And by the time that a certain status is experienced and reported back to the server, there is a time gap. So therefore, the server is always trying to do catchup of the current status that is going on at your PC, laptop, computer, or a smartphone. Many Firewalls will block RTP packets, because they don't know if the packets that are being sent to the mobile device are based on a mobile device's request, or if this is some type of security attack. Many Internet service networks that have been replaced with CDN do not support RTP. This is because RTP is possibly dangerous, and it could be used in network attacks. We need to study about CDN. As you've seen, that content delivery networks are one of the core technologies that are used in video streaming services. So we will in the next module. Pull based adaptive streaming technology. The media Client, which is like your smartphone or your personal computer, sends HTTP requests to the server to quickly retrieve, this is you pulling in your packets, content packets in burst mode. Meaning that when you request for something, you want it to be sent very quickly such that you receive packets [SOUND] In a sequence. And then you save it in your memory, and you can replay it back on your mobile device. After the minimum required buffer level is filled up, the Media Client is able to play it, display it on the media player. For example, once you download the minimum amount that is required, then on your smartphone, you can start viewing the video. The server transmits at the media encoding bitrate that matches the media consumption rate. Meaning that, there is a certain rate that the video is being displayed, such that video packets that are in the memory are consumed. Then, the way that the media encoding bitrate is set will be matched to that rate. In addition if the client buffer level remains stable at a certain fixed level approximately, the network resources will be efficiently used. This is what we're talking about as in terms of quality network resources on how efficient we're using them, in addition to how the mobile device or your PC or laptop computer is viewing the video rate. For instance, in order to have the buffer level remain stable at the client device which is your PC, laptop, or smartphone. That means that, the speed of how the video packets are consumed and displayed on your display. And the speed of how the packets are arriving into your buffer, your memory. These are approximately the same rate. Such that the overall buffer level remains stable, meaning that it's coming in and going out at the same rate. Then, in these cases the network resources are very efficiently used. And that's good. Then, if the network packets are lost or transmission delays are experienced, then buffer underflow. The buffers will become empty because packetes will not be coming in properly. They may be coming in but if they have errors they will be dropped. They will be terminated. They will be erased. Therefore the playback may be interupted in which the video stops in the middle The server will dynamically switch to a lower bitrate stream to prevent buffer underflow. That means that the video packets that come in, they will be made in a way such that when you support a lower resolution video, then the amount of data packets that are sent in, and the packet sizes can be reduced in these cases. Therefore the overall streaming speed can be maintained because you're sending a little matching the lesser size of the network throughput. And therefore, what is being received can be displayed on your monitor very comfortably. Of course, what you lose here is the resolution of the video. To avoid noticeable video quality degradation, gradual bitrate stream reductions are used. Meaning that if you see the network conditions are degrading, they're getting poorer, then you gradually reduce the video quality. Such that lesser packets, a lesser throughput, is needed. If network conditions improve, then the server switches to a higher bit rate until the media encoding bitrate is recovered. And that's talking about if the error conditions improve, then you want to go back to the high quality that you were using before. And this is supportive if the network throughput, and the other conditions in the network are able to support this higher resolution, and higher throughput. The pull based adaptive streaming of the media works like this, in which you see over there, there are various movie bit rates, and also fragments. The details of this will be explained in the following slides. But first let me go over this example, which starts off with a request manifest of movie A. That is replied back from the server with this. A manifest comes back to the device that is going to play the video. With this manifest coming back, this means that I will support your request of movie A. Then the pull process starts and it is going to request for 200 kilobytes per second of a data rate, which is the data rate for the video streaming to be sent to it's self and the reference time is 0. Then, as the video packets come in, it will see that the network condition is pretty good. So, it will request for a higher resolution. It will request for more, and the data rate goes up to 400 kilobytes per second at two seconds. Then, it asks for even higher quality upgrade. Then 800 kilobytes per second at four seconds is what is requested and then a higher data rate is received. But then, as we're receiving at this higher rate of 800 kilobytes per second, some packet losses and some delays are experienced. So it says, whoa, this is too fast, let's reduce. And therefore, it request for at six second for a 400kilobytes per second rate, it is reducing. Then the network conditions improve and it goes back to high rate again. And requests for this service is at eight seconds, into the video service. This is how we get at this range, and this is how the adaptive media streaming is done. And, as you can see, it is based on the pull mechanism. What is requested is what is gotten. Looking into the structure of the Media Streaming file format which is based on MP4, mpeg 4 technology. You will first see at the beginning there is the file type, which is the F type, listed up there. Then we have the movie metadata. Which is the MOOV part. Then we go into the fragament part. And in the fragment part you can see that the audio video data are in the mdat boxes. The mdat stands for media data. And you will see that the mdat boxes and the meta data form a fragament. In addition fragments are retrieved in a HTTP GET request message. Looking inside the fragment, we have the overall MOOF, the movie fragment part. And then we have the media data, the mdat part. Which we explained down here. This is what is in a fragment. Then we have the movie fragment random access part. The MFRA part. And this is what we are going to be using. Looking into the HTTP request message for an example, you see that this is a GET message because at the far end you see GET, G-E-T, listed down there. Each fragment is downloaded based on a unque HTTP request response pair. In addition the HTTP request message header contains two pieces of important information. One is the bitrate and the other is the time offset of the requested fragment. Looking up here in this HTTP GET request message where is that, well you can estimate this information from these parts right here. Looking into the details of the pull base adapted media streaming structure being interactive with the server. Look over there on the top there is a GET request and at the bottom there is the response. Supporting the client manages these components, the client monitors and measures these factors and then the client will perform the certain level of adaptation based upon the network and it's own buffer conditions. Looking into the details, generic client sided pull-based adaptive streaming implementation example is now what we're going to see. And here we go. A client acquires media from fragments of a file over one or more connections according to the playout buffer state and other conditions, which include the network status as well. Over there, which is the GET request and response part. That is the key part component. At minimum, the server provides standard responses to the HTTP GET request. Meaning that it can provide at least the standard responses or it can provide more information. The Client gets a manifest file that identifies the overall media presentation and alternative bit rates. These alternative bit rates are for higher resolution or lower resolution video and audio. Then comes the client managing components. The client needs a Client-side manifest or Playlist file to map fragment requests, to specify files, or to map byte ranges, or time offsets to files. In addition, some adaptive streaming techniques. A similar file on the server translates client requests. Then we have the client monitors and measures component in which the playout buffer management selects fragments from a file at a particular bitrate in response to buffer state and other variables. This here you can see the components of what is actually measured and what is monitored. In addition clients performs adaptation based on this monitored values. Then the adaptive streaming client keeps a playout buffer of several seconds saved. And it wants to maintain this level in a stable way because if this is maintained stable then the network is going to be used very efficiently. How much does it try to keep? About 5 to 30 seconds of video playing time.
