林老师最后一次大作业的要求翻译:Project 10 – RTSP Windows Client: RFC 2326

来源:互联网 发布:中国联通4g网络设置 编辑:程序博客网 时间:2024/06/01 07:48
题目:Project 10 – RTSP Windows Client: RFC 2326

RSTP的windows客户端:RFC 2326


A. Overview

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.

译:A.总览
1.介绍RTSP
实时流传输协议(RTSP,RFC 2326)是一种在娱乐和交流系统中被用于控制流媒体服务器的网络控制协议。该协议被用于在两个端点(译者:最好简单理解为一个播放MP3的播放器的客户端,和一个服务端)之间建立和控制媒体的交流。媒体的客户端能够发出类似于VCR的命令行,例如播放、暂停,因此有利于实时控制来自服务器的媒体文件的播放。


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

译:RTSP并不负责流数据的传输。大多数RTSP服务器使用实时传输协议(RTP, RFC 3550, 3551)传输流数据。然而大多数供应商也会考虑使用自己发明的协议。

某种意义上讲与HTTP协议相似,RTSP定义了有利于控制多媒体播放的控制序列。然后HTTP没有状态,而RTSP是有状态的(译者:RTSP协议在播放音乐时有播放、暂停的状态)。如果需要,会有一个标示符用于跟踪并发的会话。类似于HTTP,RTSP使用TCP维持端到端的联接,并且,当大多数RTSP控制消息被客户端发送至服务端的同时,也有一些命令从服务端发送到客户端。

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.

  1. OPTIONS
    An OPTIONS request returns the request types the server will accept.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. TEARDOWN
    A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session related data on the server.
  7. 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").
译:下面列出来的都是基本的RTSP请求消息,另外一些典型的HTTP的请求消息,比如OPTIONS,也是可以使用的。默认的传输层的端口号是554.

  1. OPTIONS:使用该请求消息,将会返回服务器将要接受的请求类型。
  2. DESCRIBE:该请求消息包括一个RTSP的URL(rtsp://...),并且能够被处理的回应数据的类型。对于UDP和TCP的传输,RTSP默认的端口号是554。回应包括了会话描述协议格式(SDP, RFC 4566)的表示描述,此外,表示描述还列出了被聚合URL控制的媒体流。在典型的情况下,这里各有一个媒体流负责音频和视频。
  3. SETUP:该请求消息详细说明了一个单独的媒体流将如何被传输。该消息必须先于PLAY消息发送。该消息应该包含媒体流的URL和一个传输的标示符。这个标示符应该包含一个本地的端口用于接收RTP的数据(包括音频或者视频),和另一个端口用于接收RTCP数据(元信息)。服务端作出回应时,通常会确认一些参数,并且填满遗失的部分,包括服务端的端口。每一个媒体流都必须确认已经在一个聚合的PLAY请求消息发送之前已经使用了SETUP请求消息
  4. PLAY:该请求消息将使得一个或者多个媒体流被播放了。如果多个PLAY消息被发送了,将会使用栈的结构来处理它。URL也可以是一个聚合的URL(即是:播放所有的媒体流),或者一个单独的媒体流URL(只播放一个流)。播放范围也是可以指定的,如果没有指定范围,那么这个流将会被从头播放结尾,或者如果流被暂停了,将会在它暂停的地方开始播放。
  5. PAUSE:该请求消息能够暂时暂停一个或者多个媒体流,所以这个暂停可以被之后的PLAY消息回复。这个请求包含一个聚合或者单独的媒体流URL。存在于PAUSE里面的参数可以指定何时暂停。如果不指定何时暂停,那么这个暂停将会立刻发生。
  6. TEARDOWN:该请求消息将用于暂停这个会话,它将会暂停所有的媒体流,并且释放所有存在于服务器与会话相关的数据。
  7. GET_PARAMETER:该请求消息可以得到一个表示描述或者以URL指定的流的所有参数的值。我们还可以指定回应的内容和反应。一个没有实体内容的GET_PARAMETER将会用于测试客户端或者服务器的是否活着(类似于ping)。

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: 

  • "the LIVE555 Media Server" (a RTSP server application, http://www.live555.com/mediaServer/);
  • "liveCaster"(http://www.live555.com/liveCaster/) and "playRTPMPEG" (http://www.live555.com/multikit/playRTPMPEG.html)(for streaming MP3 audio using RTP/RTCP);
  • 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/).

译:我们将会使用LIVE5555作为流提供服务器用于测试你的基于RTSP协议的客户端播放器。LIVE5555一个开源(LGPL) 的C++库,主要用于多媒体流。代码都是一个C++库的集合,使用了开放的标准协议(RTP/RTCP, RTSP, SIP)服务多媒体流。使用该库实现的应用程序有如下:

  • "the LIVE555 Media Server" (一个基于RTSP的服务端应用程序);
  • "liveCaster"and "playRTPMPEG" (使用 RTP/RTCP协议播放MP3的音频);
  • "vobStreamer"(使用RTP/RTCP/RTSP播放DVD流的内容). 

这个库也可以用于处理流的接收,还有处理如下格式:MPEG, H.264, H.263+, DV, JPEG video以及其它的几种多媒体编码格式。该库可轻易的扩展,支持其他的音频或者视频的格式,当然也可以用于建立基本的RTSP或SIP的客户端或者服务端,并且还能被用于改善已存的媒体播放器,使其可以播放流,比如:VLC,MPlayer。


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:
  • 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.   
  • 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.
译:
你的作业主要是写一个基于RTSP的客户端,这个客户端能够和LIVE 媒体服务器通信。
1、你在实现的过程中一定遵守实时流传输协议(RTSP, RFC 2326)的具体说明,如此你开发出来的客户端才可以与LIVE555媒体服务器通信。
2、你在实现的过程中一定遵守实时传输协议(RTP, RFC 3550, 3551)的具体说明,此外,RTP的有效载荷格式必须遵守MPEG1/MPEG2(RFC 2250)的具体说明。如此,你的RTSP客户端才能够正确处理RTP包。你可以完全自己写代码实现,当然也可以使用现存的类库,比如:

  • JRDPLIB 是一个开源项目,用于封装或者解码传输于RTP的视频或者音频数据。(JRTPLIB 经常使用RTCP,但是RTCP对我们的实现来说并不是必须的,因为我们并不要求动态解码或者编码视频或者音频流。当然,你也可以参考一些编码指导,中文的哟)
  • 一个小小的RTP库,其介绍请猛击此处。
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, butyou are free tochoose any mechanisms for socket I/Omultiplexing (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:
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.0.4/win32/ ) 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 thatdo not use Object-Oriented Programming will not be accepted. That also means itis not acceptable towrite thisproject in a single function (or even just a couple of functions).

3、有一个RTSP客户端的例子(openRTSP),这是一个基于linux命令行的程序,可以用来打开流、接收流,以RTSP URL的格式来记录媒体流(这样的URL往往是这样的:rtsp://)

你自己开发的一个程序应该是基于windows平台的MFC框架下的应用程序,然而,你可以自由选择任何基于I/O多路复用的socket通信机制(这个要找老师确定一下),无论是使用多线程来阻塞,或者使用select()系统调用,使用异步的WSAAsyncSelect 和其他任何模式)。你必须独立于LIVE555库来实现你的RTSP客户端,也就是说不能调用LIVE555库中与通信相关的函数,或者使用LIVE555库中的代码。

4、 你的RTSP的客户端应该完成基本和高级的功能:

基本功能:按需使用URL访问Live555Media服务端的资源文件。在windows上,URL应该类似于:rtsp://127.0.0.1:8554/mp3AudioTest。在Linux上,应该类似于:rtsp://127.0.0.1:554/test.mp3,当然,在服务端肯定存在test.mp3的文件来满足客户端的请求。你完成的RTSP客户端的基本功能应该能后将传输过来的流,保存在本地。

高级功能:按需从服务端传过来的流中播放音频文件(只是MP3格式)。为了此项功能,你可以好好利用:libvlc库,这是VLC播放器的核心组件。一个例子可供您使用:猛击可得。请您尽可能的参考libvlc的说明,并且请到网站VideoLan下载专门供开发人员使用的zip压缩文件。注意:你只可以使用VLC去播放Mp3文件,但是请写出代码,用于完成RTSP/RTP的传输和下载流保存到本地。

5、必须使用面向对象的思维来完成代码的实现。当然,你不能将一个工程写一个单一的函数中(或者一大堆函数)。

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.
Download latest VLC @  http://www.videolan.org/vlc/download-windows.html  or http://icourse.cuc.edu.cn/networkprogramming/assignments/RTSP/VLC/vlc-2.0.4-win32.zip  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.

注意:

你可能下载Live555在本课程的网页上,这里有两个版本,一个是在linux平台下使用,一个是在windows平台下使用。都含有代码和可执行文件。你可以使用其中的源码来分析RTSP的协议,并且启动可执行文件,用于测试你的客户端。

如果你选择Linux的版本,那么你可以在目录:“live/mediaServer/”下得到服务端可执行文件,即:live555MediaServer。如果你选择的windows的版本,你可以在目录:“live/bin/”下找到可执行文件server.exe。当然,你也利用一个小小的客户端的例子进行分析,代码位于:“live/testProgs/testMp3Receiver.cpp”。但是一个更高级的多媒体播放工具将能向您更清晰的展示功能,类似于一下步骤:

1、下载最新版本的VLC,并且安装。站点1,站点2

2、打开open media对话框,通过点击菜单栏的 [Media] -> [Open Network Stream]。

3、在空白处,输入:rtsp://computing.cuc.edu.cn/Angel.mp3,可测试播放曲目test。如下图所示。



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:
  • Basic function goes well                    50%
  • Advanced function goes well              20%
  • Dealing with impolite requests, unexpected messages         10%
  • Error handling, Style/Code structure, etc.            20%
  • 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:
  • Error handling (check every system call for an error!).
  • Safe code (avoiding buffer overflow, etc).
  • 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.
译:
你的项目将会被测试,能够很要的与Live555服务器通信,并且工作良好。
下面是一个大致的评分细则:

  • 基本功能运行良好                  50%
  • 高级功能运行良好                   20%
  • 处理了不合理的请求和不可预料的情况    10%
  • 错误处理,代码结构等                                  20%
  • 额外加分: 
  • Ø  优秀的完成了作业报告            +5 p
  • Ø  漂亮的UI界面                    +5 p

注意:20%的分数将依据你的代码写的好不好,这主要是指:

  • 错误处理,检查每一个有问题的系统调用。
  • 代码安全,避免缓冲区溢出等。
  • 代码是否让人容易理解,虽然没有明确要求你代码该如何写,比如没有如此的要求:你必须每2.35行代码就写一句注释。请自由发挥地添加注释,只要你相信这样做能够使得别的程序员能够很好地理解你的代码、利用你的代码、进一步修改你的代码。


(全文完)

0 0
原创粉丝点击