Color Transmission In TV: Multiplexing/Demultiplexing Of YIQ By Matlab Simulation

EE4414 Multimedia Communication Systems II Experiment III Video Streaming Over Internet

Yao Wang and Xiaofeng Xu

1. Introduction In this lab, you will experiment with video streaming over the Internet. The lab consists of two parts. In the first part, you will be streaming video from a server running the Helix universal server. You will use RealOne player© to stream and play the video, and observe the video quality under different network conditions. In the second part, you are given a video streaming server and client application program that implements the basic Real-Time Streaming Protocol (RTSP) operations. You will use these programs to see the request and response between the client and servers when using the RTSP protocol. This will give you some insights as to the underlying operations that are hidden with the commercial server and player applications.

2. Experiment

Because the video server in Part I can only serve a limited client requests, we require that half of the students do Part II of the experiment first, while the other half work on Part I. This will be coordinated by the Teaching Assistant at the lab.

Part I --- Video Streaming Using RealServer and RealOne Player

For this part, you will use RealOne Player to stream videos from a streaming server running the Helix Server, both from RealNetworks, Inc. The server and player implement the RTSP protocol for video streaming applications. The player can decode standard MPEG video formats (including MPEG1 and MPEG2) as well as several proprietary format video, including “.rm” format from RealNetwork, Inc.

In this part of the experiment, you will request video from the server, and observe the quality of the played video as well as the underlying network traffic condition by using the “PlaybackStatistics” tool available in the RealOne Player. You are asked to stream a low bit rate video and a high rate video, with and without interfering traffic, and to compare the bandwidth usage and packet loss statistics under different conditions.

The server program sits on a computer with IP 128.238.139.1 and has several videos that are available for downloading. For this experiment, we have downloaded a free, trial version of the server program (the basic version of the Helix Universal Server), which allows up to 1 mbps aggregate outgoing traffic. If you get a busy signal from the server, it means too many other students are trying to access the same server, and you should wait and send your request again sometimes later.

(1) Open RealOne player from Window’s start menu bar. On your RealOne player, choose the option “Play-->continuous playback” so that a video is played back-to- back in loop mode. (2) Choose “File->Open”, and type into input box the address “rtsp://128.238.139.1/real9video.rm”. A short video with a bit rate 225 kbps will be shown on the computer screen. This video is encoded using the proprietary “rm” format. (3) While the player is still playing, choose the “Tools->Playback Statistics” to see the network output bandwidth and packet loss rate. You should see windows shown in figure 1 when you click on “bandwidth” and “packets”, respectively. The “bandwidth” panel illustrates how does the network bandwidth varies in time, whereas the “packets” panel provides information about packet losses. The bandwidth refers to the instantaneous total data rate received at the player. The lost packet ratio indicates the percentage of packets sent by the server that did not reach the destination, and the late packet ratio specifies the percentage of packets that arrived at the client later than its scheduled play-out time. The RealServer and RealPlayer allow retransmission of lost packets. The “packets” panel also shows the statistics about retransmission. Record the minimum, maximum, and average bandwidth, lost packet ratio, late packet ratio, and total packet loss ratio, number of requested retransmission and number of received retransmission, and average retransmission time. Figure 1. An example of Playback Statistics Window

(4) Now request another video using “rtsp://128.238.139.1/movie/a.mpg. Record the same set of network statistics as in part (3). What is the bit rate of the video? Which one (real9video.rm or a.mpg) consumes more network bandwidth? Which one has more retransmitted packets and higher total packet loss? (5) Copy H:\EL514\movies\b.mpg to your local machine and watch “real9video.rm” at the same time. Did you observe any changes in the video quality compared to part (3)? Did you notice any temporary freeze of the video or any blocks/segments in the video that are of lower quality than its neighbors? Again record the network statistics as before, and compare them with those in (3).

Part II --- Experimenting with a RTSP server and client

For this part, you are given a streaming server program and a streaming client program. The server implements the basic Real-Time Streaming Protocol (RTSP) server operations and packetizes the data using the Real-time Transport Protocol (RTP) and then sends the data using UDP. The client implements basic RTSP client operations, depacketization, video decoding and playback. Both server and client programs are written to handle extremely simplified application scenarios. For example, the server can only respond to one request at a time, and the client can only play video coded in motion-JPEG format. The programs were written in JAVA 1 and pre-compiled for you. By running these programs, you can see the request and response between the client and server following the RTSP protocol. These requests and responses are typically hidden from you when you run a commercial streaming software such as RealServer and RealPlayer. This part of the experiment is intended to help you to get a better understanding of the RTSP protocol. For this experiment, we ask that each team runs the server and client programs on the same computer, although it is possible to run the server and client on any two separate computers.

1 The JAVA programs are provided by Keith Ross. (1) First you need to find the IP address of the computer that you are using. Click Window’s “Run” menu. Type “cmd” in the input box to open a command window. In the command window, type the “ipconfig” command and write down your machine’s IP.

(2) Change your current direction to “Z:\”.

(3) In the same command window, type “java Server 1000” to run the server program. Here, “Server” is the server application in JAVA, sitting on the Z: drive, “1000” is the port number that the server listens to for incoming RTSP connections.

(4) Open another command widow, and type “java Client IP 1000 movie.Mjpeg” to run the client program. Here “Client” is the client application in JAVA, sitting on the Z: drive, “IP” should be replaced with the actual IP address you obtained from step (1). You can also use the server name instead of IP. “movie.Mjpeg” is the name of the requested video file. A simple client GUI will be brought up, which allows you to issue different RTSP requests.

(5) You can send RTSP requests to the server by pressing appropriate buttons in the client GUI. A normal RTSP interaction goes as follows.  Client sends SETUP. This command is used to set up the session and transport parameters.  Client sends PLAY. This starts the playback.  Client may send PAUSE if it wants to pause during playback.  Client sends TEARDOWN. This terminates the session and closes the connection.

(6) After you click each button, observe the outputs in two command windows. The output in the server window is the actual request received by the server, and the output in the client window is the reply from the server that the client received in response to the client request. Record these outputs and explain their meanings, after you issue each request.

(7) Do you observer slow playback speed when you play video with this java program? Why? (We assume that network transmission is lossless since we simulate server and client in the same machine).

(8) The GUI on the client has 4 buttons for the 4 actions. If you compare this to a standard media player, such as RealOne Player, you can see that they have only 3 buttons for the same actions, namely, PLAY, PAUSE, and STOP (roughly corresponding to TEARDOWN). There is no SETUP-button available to the user. Given that SETUP is mandatory in an RTSP-interaction, when does the client send the SETUP? Is it appropriate to send TEARDOWN when user clicks on the stop- button? 3. Report Your report should start with a general description of what you did in this experiment, followed by the results and observations you obtained. You should answer all the questions (written in italics in the proceeding instructions).