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).