3/15/22, 10:16 PM PA3.1 - EECS 3214 | PrairieLearn
https://ca.prairielearn.com/pl/course_instance/2384/instance_question/21502834/ 1/5
PA3.1. RTSP client
After completing this assignment, you should be:
Able to read and implement a protocol specification;
Familiar with out-of-band data transmission;
Able to work with a combination of UDP and TCP sockets;
Able to visualize issues related to timing in multimedia streaming.
All policies listed on the eClass page for Assignments Policies and Procedures apply to this
assignment.
Special Note
Although this assignment's autograder tests the most common input issues and produces an
initial score, this score is going to be overwritten by a manual review by the course staff. This
manual review will ensure your code works not only based on the simple cases listed in the
resulting tests, but also for other considerations listed in the RFC and for additional tests.
TAs will also review your code quality in terms of clarity and use of comments.
Introduction
In this assignment you will implement a streaming video client for stored video. A specific
video file is requested by the client, and streamed from the server over the network to the
client. The client will then play the video as it arrives.
The client and server communicate requests and responses between each other using a
simplified version of the Real-Time Streaming Protocol (RTSP) and send the video data using
a subset of the Real-time Transfer Protocol (RTP). We have provided you with an executable
JAR file with the implementation of an RTSP server and the user interface of the client. Your
task is to implement the RTSP and RTP protocols in the client. You are not allowed to modify
any other part of the application other than what is necessary to provide network
communication functionality. For a list of files that can be modified, refer to the submission
area at the bottom of this page.
When implementing this assignment you should write small pieces of code and then test and
verify their functionality before proceeding. You are strongly encouraged to implement the
assignments functionality incrementally in the order it is presented in the description.
Provided Files
The following files are provided to you to use during the implementation of this assignment:
a basic implementation of the RTSP server in Java. The source code is not provided,
but it is not necessary for the implementation of your code, neither should you depend
on it.
RTSPServer.jar
the starting code for the client implementation.
RTSPClient.zip
sample video files for transmission. Note that the server accepts a very specific video
format.
movie1.Mjpeg
movie2.Mjpeg
movie3.Mjpeg
Running the server
In this assignment you are provided with the server executable. In order to test your client,
you should first start the server on a particular port. To start an RTSP server on Windows or
Mac OS, you may double-click the JAR file in the location where you downloaded it. The
server will request the port number in a dialog box. You should provide a valid TCP port
number (ideally between 1025 and 65535). The server will then accept RTSP connections on
the provided port.
Programming
Assignment 3
Assessment
overview
Total points: 0/100
Score:
0%
Question
Value:
History:
Awarded points:
Report an error in this
question
100
0/100
Previous question
Next question
Attached files
No attached files
Attach a file
Attach text
3/15/22, 10:16 PM PA3.1 - EECS 3214 | PrairieLearn
https://ca.prairielearn.com/pl/course_instance/2384/instance_question/21502834/ 2/5
Alternatively, if you prefer to run your server in a terminal, without a GUI (in "Headless
mode"), you can use the following command:
java -Djava.awt.headless=true -jar RTSPServer.jar server_port
Where server_port is the port your server listens to for incoming RSP connections. Using 0
as the server_port will choose a random available port, which will be printed on the terminal.
The server will print some relevant information on its GUI Window (if running with a GUI), or
on the terminal (if running in Headless mode).
For simplicity, make sure the video files you will use for transmission are saved in the same
folder as the one you are running the server from. You may use any of the Mjpeg files
provided above.
Running the client
If you are using IntelliJ, the ZIP file above contains a folder that can be imported into IntelliJ
as a project. You may then run the application from inside IntelliJ. If you are using another
IDE besides IntelliJ, you will need to compile the files in the src folder, and run the
ca.yorku.rtsp.client.ui.MainWindow class.
Upon starting the client you will be presented with a dialog box to provide the hostname of
the machine the server is running on (you can use localhost if the server is running on the
same computer as the client), and the port number the server is listening on. The client will
then establish a TCP connection to the server. This connection will be used for RTSP, but at
this time no messages are sent or received.
Once connected to the RTSP server, the user interface will provide five buttons. Each button
is associated with an RTSP operation, as listed in the RTSPConnection.java file. Details
about what is expected to happen in each method are provided in the method comments,
but a brief description is provided below:
Open: asks for a file name and sends a SETUP request to the server. This command sets
up the session and establishes an RTP datagram socket (using UDP).
Play: sends a PLAY request to the server. This command starts the playback of the
video in its first run, or continues a playback that was previously paused.
Pause: sends a PAUSE request to the server. This command pauses the playback of the
video.
Close: sends a TEARDOWN request to the server. This command stops the video and
closes the RTSP session and RTP connection, but maintains the RTSP connection
open.
Disconnect: closes the RTSP connection.
Note that you will maintain two different sockets open simultaneously, one regular (stream)
socket for the RTSP connection and one datagram socket for the RTP connection. It is your
responsibility to open, maintain and close these connections appropriately, and handle
connection interruptions.
Since this assignment uses only a subset of the functionality of RTSP and RTP, you don't
need to understand these protocols in depth to complete this assignment. Besides other
limitations, the video streaming is implemented using individual JPEG images to represent an
individual video frame. There is no inter-frame compression, audio track, or control track.
This also means that, once the video ends, the server will stop sending frames. The server
will not send any message over the RTSP connection informing the client that the video
ended. You are, naturally, not required to do any additional processing at the end of the
video.
The RTSP protocol
You are welcome to read the RTSP RFC (RFC 2326) if you wish to, but since this assignment
only uses a small subset of this protocol, a simple example should be enough to understand
the functionality required for this assignment. In the example below, the client's requests
with a blue background, while the server's replies have a light grey background.
3/15/22, 10:16 PM PA3.1 - EECS 3214 | PrairieLearn
https://ca.prairielearn.com/pl/course_instance/2384/instance_question/21502834/ 3/5
SETUP movie.Mjpeg RTSP/1.0
CSeq: 1
Transport: RTP/UDP; client_port= 25000
RTSP/1.0 200 OK
CSeq: 1
Session: 123456
PLAY movie.Mjpeg RTSP/1.0
CSeq: 2
Session: 123456
RTSP/1.0 200 OK
Seq: 2
Session: 123456
PAUSE movie.Mjpeg RTSP/1.0
CSeq: 3
Session: 123456
RTSP/1.0 200 OK
CSeq: 3
Session: 123456
PLAY movie.Mjpeg RTSP/1.0
CSeq: 4
Session: 123456
RTSP/1.0 200 OK
CSeq: 4
Session: 123456
TEARDOWN movie.Mjpeg RTSP/1.0
CSeq: 5
Session: 123456
RTSP/1.0 200 OK
CSeq: 5
Session: 123456
Note that the RTSP message format is somewhat similar to the HTTP format. As in HTTP,
each request and each response ends with an empty line. The empty line indicates the end
of the message.
The Session header in the PLAY, PAUSE and TEARDOWN must be the same as the one returned
by the server in the response to the SETUP command. The value of the CSeq header is a
number which is incremented by one for each request you send, and will have its value
matched in the corresponding response.
The Transport header in the SETUP command is of particular relevance. The provided server
will only accept the RTP/UDP transport method. Before sending the SETUP command, the
client must open a new UDP (datagram) socket. The transport header will then include the
listening port number used by this socket. Once the PLAY command is issued, this datagram
socket will receive video frames, one per packet, until a PAUSE or TEARDOWN command is
issued or the video ends. Note that, based on the nature of UDP, it is possible that an
incorrect port number might not trigger an error, but it might cause the frames to be lost.
One of the key differences between HTTP and RTSP is that in RTSP each session has a
state. In this assignment you will need to keep the client's state up-to-date. The client
changes state when it receives a reply from the server according to the following state
diagram. Note that, although the server's state diagram is somewhat similar to the client's,
the server and client might not necessarily be in the same state.
The RTP protocol
3/15/22, 10:16 PM PA3.1 - EECS 3214 | PrairieLearn
https://ca.prairielearn.com/pl/course_instance/2384/instance_question/21502834/ 4/5
The video streaming frames will be transferred using RTP packets. This assignment will use
only a small subset of the RTP protocol. You are responsible for parsing the packet data and
generate a Frame object based on that data. Each datagram packet will contain exactly one
frame, corresponding to a JPEG image.
When the server receives the PLAY request from the client, it starts a timer. Every 40ms (i.e.,
25 times per second) the server will read one video frame from the file and send it to the
client, encapsulated as an RTP packet. Your job is to read this packet and convert the
information in that packet into appropriate values.
The format of the RTP packet header is described in section 5.1 of the RFC for the RTP
protocol, as well as in section 9.4.1 of the textbook. You don't need to read the other
sections of the RFC, since they are not relevant to this assignment. In particular, note that
padding (P), extension (X), CSRC count (CC) and synchronization source (SSRC) are not
used in this assignment, and you can ignore their values. Also note that there are no CSRC
headers, so the header ends after the SSRC identifier (i.e., the header contains exactly 12
bytes).
After the RTP packet header (i.e., starting at position 12 in the packet array), the payload
(content of the frame) starts. The number of bytes in the payload is given by the total size of
the datagram packet minus the header size.
The numbers represented in the RTP packet are in network byte order (also known as big-
endian). You must make sure that when you fill the integer fields of the frame (such as
timestamp and sequence number), that the bytes are added in proper order.
The Funky Servers
This part of the assignment is only for information. There are no deliverables required, and
you don't need to change your assignment to account for this behaviour.
So far, you've only dealt with a well behaved video stream. Since connections on the Internet
aren't always well behaved, we've created a server that simulates some of the problems a
video streaming application might encounter.
To run the server with simulated problems, open the server as before, and then select one of
the scenario buttons on the top. The REGULAR scenario (default) runs the server with no
problems. The other scenarios (FUNKY_A, FUNKY_B, ... FUNKY_J) introduce predefined network
problems. If you are running the server in a command-line interface, just add a letter (A
through J) as an additional argument, like the following:
java -Djava.awt.headless=true -jar RTSPServer.jar server_port A
After you complete the implementation of the assignment, you are encouraged to run your
client and interact with each of the "funky" scenarios. You should be able to observe some
interesting behaviour based on how the simulated server or network treats the data, and
notice how it affects the video playback experience. Examples of simulated events include
differences in transmission rates, lost packets, delayed packets and burst of congestion.
If you have identified the problems with the funky servers, you are invited to update your
client to mitigate the playback problems presented by the various funky server scenarios.
Your client should try to deliver the best user experience possible under the circumstances.
In other words, it should play the video as smoothly as possible. You don't need to submit
these changes, but you are welcome to discuss your strategies in office hours or on the
discussion forum if you'd like to take this challenge. Note that there are several possible
implementations that could improve the playback experience. Some implementations may
require additional threads, additional timers, or additional buffers.
Submitting your file
You must submit your assignment using the boxes below. Once the files are uploaded, you
must save your submission for it to be marked.
You may save your submission as many times as you wish before the deadline. Your latest
submission will be considered for grades.
3/15/22, 10:16 PM PA3.1 - EECS 3214 | PrairieLearn
https://ca.prairielearn.com/pl/course_instance/2384/instance_question/21502834/ 5/5
NOTE: The autograder functionality for this assignment will be released in a few days
Drop files here or click to upload.
Only the files listed below will be accepted—others will be ignored.
The combined size limit of all uploaded files is 5MB.
Files
RTSPConnection.java
not uploaded
Save This question will be manually graded.

欢迎咨询51作业君