Project 10 - RTSP Windows Client: RFC 2326
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Project Specifications for
CS400 Advance Windows Network Programming
School of Computing, Communication University of China
December 17, 2014. Due January 19, 2015
Tools and Platform
The following tools and platforms are to be used in the projects:
Operating System: Microsoft Windows
Language: C++
Development Tools: Microsoft Visual Studio 201x
Winsock 2.2
Project 10 – RTSP Windows Client: RFC 2326
A. Overview
1. Introduction of RTSP
The Real Time Streaming Protocol (RTSP, RFC 2326, http://www.cs.columbia.edu/~hgs/rtsp/) is a
network control protocol designed for use in entertainment and communications systems to
control streaming media servers. The protocol is used for establishing and controlling media
sessions between end points. Clients of media servers issue VCR-like commands, such as play and
pause, to facilitate real-time control of playback of media files from the server.
The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP
servers use the Real-time Transport Protocol (RTP, RFC 3550, 3551, http://www.cs.columbia.edu/~hgs/rtp/)
for media stream delivery; however some vendors implement proprietary transport protocols.
While similar in some ways to HTTP, RTSP defines control sequences useful in controlling
multimedia playback. While HTTP is stateless, RTSP has state; an identifier is used when needed
to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection
and, while most RTSP control messages are sent by the client to the server, some commands
travel in the other direction (i.e. from server to client).
Presented here are the basic RTSP requests. Some typical HTTP requests, like the
OPTIONS request, are also available. The default transport layer port number is 554.
l OPTIONS
An OPTIONS request returns the request types the server will accept.
l DESCRIBE
A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply
data that can be handled. The default port for the RTSP protocol is 554 for both UDP
and TCP transports. This reply includes the presentation description, typically in
Session Description Protocol (SDP, RFC 4566) format. Among other things, the
presentation description lists the media streams controlled with the aggregate URL. In
the typical case, there is one media stream each for audio and video.
l SETUP
A SETUP request specifies how a single media stream must be transported. This
must be done before a PLAY request is sent. The request contains the media stream
URL and a transport specifier. This specifier typically includes a local port for receiving
RTP data (audio or video), and another for RTCP data (meta information). The server
reply usually confirms the chosen parameters, and fills in the missing parts, such as the
server's chosen ports. Each media stream must be configured using SETUP before an
aggregate play request may be sent.
l PLAY
A PLAY request will cause one or all media streams to be played. Play requests
can be stacked by sending multiple PLAY requests. The URL may be the aggregate
URL (to play all media streams), or a single media stream URL (to play only that
stream). A range can be specified. If no range is specified, the stream is played from the
beginning and plays to the end, or, if the stream is paused, it is resumed at the point it
was paused.
l PAUSE
A PAUSE request temporarily halts one or all media streams, so it can later be
resumed with a PLAY request. The request contains an aggregate or media stream URL.
A range parameter on a PAUSE request specifies when to pause. When the range
parameter is omitted, the pause occurs immediately and indefinitely.
l TEARDOWN
A TEARDOWN request is used to terminate the session. It stops all media
streams and frees all session related data on the server.
l GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter of a
presentation or stream specified in the URI. The content of the reply and response is
left to the implementation. GET_PARAMETER with no entity body may be used to
test client or server liveness ("ping").
2. Introduction of LIVE555
We will use LIVE555 as the streaming server for testing your RTSP Windows client player.
LIVE555 is an open source (LGPL) C++ library for multimedia streaming. This code
forms a set of C++ libraries for multimedia streaming, using open standard protocols
(RTP/RTCP, RTSP, SIP). The libraries are already being used to implement applications such as:
l "the LIVE555 Media Server" (a RTSP server application, http://www.live555.com/mediaServer/);
l "liveCaster"(http://www.live555.com/liveCaster/) and "playRTPMPEG"
(http://www.live555.com/multikit/playRTPMPEG.html)(for streaming MP3 audio using
RTP/RTCP);
l and "vobStreamer"(http://www.live555.com/vobStreamer/) (for streaming DVD content
using RTP/RTCP/RTSP).
The libraries can also be used to stream, receive, and process MPEG, H.264, H.263+, DV
or JPEG video, and several audio codecs. They can easily be extended to support additional
(audio and/or video) codecs, and can also be used to build basic RTSP or SIP clients and servers,
and have been used to add streaming support to existing media player applications, such as
"VLC"(http://www.videolan.org/vlc/) and "MPlayer"(http://www.live555.com/mplayer/).
B. Specification
Your assignment is to write a RTSP client that should work with LIVE555 Media Server.
1. Your implementation should follow the specification in the Real Time Streaming
Protocol (RTSP, RFC 2326, http://tools.ietf.org/html/rfc2326), so that your version of RTSP
Client is able to work together with the LIVE555 MediaServer.
2. Your implementation should follow the specification in the Real-time Transport
Protocol (RTP, RFC 3550, 3551) and RTP Payload Format for MPEG1/MPEG2
Video (RFC 2250), so that your version of RTSP Client is able to handle RTP
packets correctly. You may achieve this by writing your own code or just using a
third party library, such as:
l The JRDPLIB is an open-source project for packetizing/de-packetizing
video/audio data over RTP (http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib).
(The JRTPLIB has routines for RTCP, but RTCP is not needed in your
implementation because you are not required to encode/decode the audio/video
stream data dynamically.), you can also refer to a programming instruction
(http://blog.csdn.net/blog51/article/details/2408531) in Chinese.
l A tiny RTP library (http://icourse.cuc.edu.cn/networkprogramming/assignments/
RTSP/70565912.blog.51cto.com/Rtsp.rar) introduced by http://70565912.blog.51cto.com.
3. The example version RTSP Client (openRTSP, http://www.live555.com/openRTSP/) is
a linux command-line program that can be used to open, stream, receive, and
(optionally) record media streams that are specified by a RTSP URL - i.e., an URL that
begins with rtsp://.
Your
newly
developed
application
should
be
a
MFC
application
on
Windows
platform,
but
you
are
free
to
choose
any
mechanisms
for
socket
I/O
multiplexing
(Blocking with Multi-threading, the select( ) system call, asynchronous programming
with WSAAsyncSelect or any other models).
It
is
important
that
you
should
implement
the
RTSP
client
to
be
independent
of
the
LIVE555
libraries
(that
means
using
any
source
codes
of
LIVE555
in
your
implementation
is
not
permitted.).
4. Your RTSP Client Must accomplish basic and advanced functions:
l Basic function: Visit the on-demand file stream from the Live555MediaServer
with URL:“rtsp://127.0.0.1:8554/mp3AudioTest” (Windows version) or
“rtsp://127.0.0.1:554/test.mp3” (Linux version). The file “test.mp3” will be
ready for your RTSP request. The basic task of your RTSP Client is that it can
record the steam as a local media file.
l Advanced function: The advanced task of your RTSP Client is that it can play
the media file (mp3 only) from the on-demand streaming server. You can do this
by taking advantage of the libvlc-library, which is the core component of the
VLC media player. An example can be found at
http://www.codeproject.com/Articles/38952/VLCWrapper-A-Little-C-wrapper-Around-libvlc. Please
refer to libvlc (http://www.videolan.org/vlc/libvlc.html) and find the libs on the VideoLan
site (ftp://ftp.videolan.org/pub/videolan/vlc/2.1.5/) in special ZIP files intended for
developers. Note: You should use VLC to play mp3 only, please write your
own code to interpret RTSP/RTP and stream down the mp3 file.5. Implementations
that
do
not
use
Object-‐Oriented
Programming
will
not
be
accepted.
That
also
means
it
is
not
acceptable
to
write
this
project
in
a
single
function
(or
even
just
a
couple
of
functions).
Notes:
You can download the live555 on the course website. There are two versions (Linux @
http://icourse.cuc.edu.cn/networkprogramming/assignments/RTSP/live-linux.rar and Windows@
http://icourse.cuc.edu.cn/networkprogramming/assignments/RTSP/live-wondows.rar ), both include
source and executable files. You can use the source code to analyze the RTSP protocol, and run the
executable file to test your client.
If you choose the Linux version, you can find the server (live555MediaServer) under
“live/mediaServer/”, and if you choose the Windows version, you can find the server (server.exe)
under “live/bin/”.
And you can use “live/testProgs/testMp3Receiver.cpp” as the demo of the client. But a more
sophisticated version of multimedia player, "VLC" can be used for a clear demonstration.
1) Download latest VLC @ http://www.videolan.org/vlc/download-windows.html and setup
VLC.
2) Open the Open Media Dialog by click menu [Media] -> [Open Network Stream]
3) In the blank, type “rtsp://computing.cuc.edu.cn/Angel.mp3” for a test run.C. Grading
Your project will be tested to make sure it works properly with the live555 media server.
Here is a rough breakdown of the grading:
l Basic function goes well 50%
l Advanced function goes well 20%
l Dealing with impolite requests, unexpected messages 10%
l Error handling, Style/Code structure, etc. 20%
l Extra credits:
Ø Well defined project report +5 p
Ø Elegant GUI interface +5 p
Note: 20% of your project grade depends on the how "well your code is written". These points
include the following:
l Error handling (check every system call for an error!).
l Safe code (avoiding buffer overflow, etc).
l How well we can understand your code. There is no required format for your code; there is
no requirement like "you must have one comment for every 2.35 lines of code". Feel free to
provide whatever level of commenting you believe is appropriate to make sure that other
competent programmers could easily understand and make changes to your code.
Note:
• All functions will be tested on different machines.
• Submissions that do not use Object Oriented Programming with C++ will not
be accepted.
• If the submitted source code cannot be compiled by Visual Studio 201x, your
grade will be deducted.
• Late submission will be punished with grade deductions.
You can also read
