Video Streaming Over Internet

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

2. 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-toback 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.

3. 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:EL514moviesb.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.

4. (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 stopbutton?

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