- 浏览: 96809 次
- 性别:
- 来自: 南京
文章分类
最新评论
Abstract
This document describes a simple implementation of the client side of an RTSP session, including the minimal requirements to complete a successful dialogue with the IFI extension of the Darwin Streaming Server RTSP implementation. Here, emphasis is made on making parsing and error control as simple as possible, not necessarily following all the aspects of the RTSP standard (RFC 2326) requirements.
Connecting
The client is initially supplied with an RTSP URL, on the form:
rtsp://server.address:port/object.sdp
The URL is either supplied within a simple text file, the file name being supplied as a command line parameter when the client is started, or hopefully, the client is able to accept user input in a text box in the client's graphical user interface.
There are a number of things the client should check while parsing the URL:
- Whether the URL starts with "rtsp://" (no case sensitivity)
- Whether the server address is invalid or not (either DNS name or IP address should be accepted)
- If port number is included (simply check for a colon, ':'), it should check if this port number is valid (an unsigned integer, less than 65536)
What comes after the last slash ('/'), we can leave to the server parser (in our case, however, it would be nice to check whether the object ends with ".sdp", since this is required to activate our reflector capabilities in the RTSP server).
After parsing the URL, the client should have a valid server address (at least lexically), and possibly a port number. If no port number is supplied, the default "well known port" for RTSP is assumed, which is 554.
As soon as the URL is parsed, a TCP connection should be made to the obtained server address/port. The client should then transmit the DESCRIBE request as follows:
Client: Here, of course, '/r/n' is not to be taken literally, but as return and newline characters (as in printf in the C programming language). The describe request should include the RTSP URL exactly as supplied by the user/caller. The "CSeq" header field is used in sequence numbering, and not really necessary to operate the RTSP server (it is mandatory according to the standard, however). It is mainly practical when not operating with an open TCP connection during the entire session, for the client to make sure no messages are lost. The server will blindly echo the sequence number, including a "CSeq" header in the response messages.
The TCP connection can remain open for the duration of the session, but there is no reason why the connection should be maintained after the first SETUP request. It is necessary, however, to keep the connection alive while doing the DESCRIBE and the following SETUP requests, because of the the way in which the server is implemented.
Receiving SDP information
The server may respond to the DESCRIBE request in any number of ways (or it might not respond at all), but it is safe to assume that any other response than "RTSP/1.0 200 OK" in the first line might indicate an error situation (and a good excuse to give up on this particular session). A successful response to the DESCRIBE might look as follows:
Server: It's not necessary to parse the SDP information entirely. It will suffice to extract the lines containing "a=control:trackID=x" and keep hold of these control strings. It will also be necessary to extract the associated "m=..." lines kbdceding the control attributes. These indicate the nature of the media stream, and hence which tool is required to render it ("video" and "audio" indicating vic and rat, respectively).
What to do if there are other media descriptors than "video" or "audio" is not decided, but the best thing to do might be to ignore them altogether, telling the user that "unknown media types were encountered". If no known media type is found, the client must terminate gracefully.
Setting up
To set up, the "SETUP" request must be issued. It might look like this:
Client:
SETUP rtsp://server.address:port/object.sdp/trackID=1 RTSP/1.0/r/n CSeq: 2/r/n Transport: RTP/AVP;unicast;client_port=9000-9001/r/n /r/n
This request must be issued for each of the control strings obtained above (leaving out the ones rekbdsenting media types we can't handle, of course). Note that the original URL is used, augmented by a slash ('/') and the control string. For the first one of these requests, the server (if all goes well) will respond with:
Server:
RTSP/1.0 200 OK/n Server: QTSS(IFI)/v88/n Cseq: 2/n Session: 1234567890;timeout=60 Transport: rtp/avp;source=129.240.65.208;server_port=9000-9001;client_port=9000-9001/n /n
All consecutive SETUP requests must include the session header field. It looks like this:
Client:
SETUP rtsp://server.address:port/object.sdp/trackID=2 RTSP/1.0/r/n CSeq: 3/r/n Session: 1234567890/r/n Transport: RTP/AVP;unicast;client_port=9000-9001/r/n /r/n
Even though in this example, the session identifier contains only numbers, the standard allows alpha characters as well. So making the client able to accept 2Ak432zDQr just as well as 1234567890 would be a good idea (case-sensitive, of course). The standard requires the identifier to be at least 8 octets long.
Again, anything other than "RTSP/1.0 200 OK" might indicate error, and should result in termination. In the responses, the information worth making a note of is the source attribute in the transport header field, and the client_port attribute. These will be needed to start the media tools later on.
Setting up a reflector session is only required if the client host is not capable of multicast on the MBone. However, using the returned SDP information to start the Meccano tools will require a much more elaborate parsing. For the sake of simplicity, we might assume that the client is not MBone capable.
Otherwise we might issue the SETUP request with "multicast" instead of "unicast" in the transport header field. The server can then respond with the appropriate multicast address/port numbers instead of setting up the reflector. This, however, remains to be implemented in the server. Other problems might arise as well, since the multicast sessions visible to the reflector/listener system might not be visible to the client. A more complete client would parse the SDP information, determine whether the multicast session is reachable, and initiate rendering on its own.
Start playing
To start getting the media packets, all we have to do is to send a "PLAY" request to the server. It looks like this:
Client: Note that the control string is omitted, hence the request applies to all streams currently set up. Again, other responses than "RTSP/1.0 200 OK" is handled as a fatal error.
Now is the time for starting up the media tools, using the source address and port number obtained above. Note that the media tools only require one of the port numbers acquired, for an example, if the transport header from the server includes "client_port=9000-9001", the media tool only needs port number 9000 in its command line parameters.
Pausing
This is handled the same way as playing. These two actions might be implemented using a single button in the client's graphical user interface, toggling between play and pause.
Client:
Tearing down
The request "TEARDOWN" is only issued at the very end of the session. This makes the server release all its resources pertaining to the session, and new SETUP requests will have to be sent in order to restart the media streams. It looks like this:
Client: The server will reply:
Server: When the reply to this message is received, the client can safely disconnect. The sequence number is really not required. However, the Session: header field is mandatory.
Important: The TEARDOWN must be issued before the client application is allowed to terminate, otherwise the reflector is liable to swamp the client host with unwanted udp packets. Another thing which might pose a problem, is that of client bandwidth. If reflector output surpasses available bandwitdh between itself and the client, TCP traffic to the RTSP server might be blocked. This situation is extremely undisirable, because the client internet connection in effect becomes unusable. The solution to this problem (at the moment), has been to implement a refresh timeout in the server. The client is required to send "dummy" requests within certain intervals. The most suited request for this, is OPTIONS. The timeout period (in seconds) is indicated by the SETUP reply message, in the session header field. To keep the session alive, just send along an OPTIONS request every now and then. It's done like this:
Client: Failure to pass these refresh "requests" would in effect mean the same as a TEARDOWN request.
Summary
The client may operate in three distinct states, disconnected, playing and paused. When the application is started, the state is of course "disconnected". After starting up, the client issues the requests DESCRIBE, SETUP and PLAY, and enters the "playing" state. The play button changes into a pause button, and the media rendering tools are started. During this state, the client sends the OPTIONS request regularly.
When the user kbdsses the recently appeared pause button, the PAUSE request is sent, and state is transferred into "paused". The pause button changes into a play button. When the user kbdsses the exit button (or exits the client application), TEARDOWN is sent, the TCP channel is broken, and the media tools are terminated.
An example of how the client dialog might look like, is included below.
OPTIONS rtsp://server.address:port/object.sdp RTSP/1.0/r/n CSeq: 6/r/n Session: 1234567890/r/n /r/n
RTSP/1.0 200 OK/n Server: QTSS(IFI)/v88/n Cseq: 6/n Session: 537103309/n Connection: Close/n /n
TEARDOWN rtsp://server.address:port/object.sdp RTSP/1.0/r/n CSeq: 6/r/n Session: 1234567890/r/n /r/n
PAUSE rtsp://server.address:port/object.sdp RTSP/1.0/r/n CSeq: 5/r/n Session: 1234567890/r/n /r/n
PLAY rtsp://server.address:port/object.sdp RTSP/1.0/r/n CSeq: 4/r/n Session: 1234567890/r/n /r/n
RTSP/1.0 200 OK/n Server: QTSS(IFI)/v88/n Cseq: 1/n Content-Type: application/sdp/n Content-Base: rtsp://bildeus.ifi.uio.no:8000/12.sdp//n Content-length: 785/n /n n=2236805513 2236805513 932036356 224.2.127.254 9875 127 trusted/n v=0/n o=yozo 3138827440 3138828177 IN IP4 aohakobe.ipc.chiba-u.ac.jp/n s=Places all over the world/n i=Low bandwidth video (10kb/s) with views from all over the world. Audio is primarily for feedback for the senders of video. (looks like there's some problem for the session announcement from sweden distributes to the whole MBone, I'm repeating the announcement from japan. -- yozo.)/n e=Yozo TODA at IPC, Chiba University, JAPAN <yozo@ipc.chiba-u.ac.jp.>/n p=+81-43-290-3539/n c=IN IP4 224.2.213.113/127/n t=3138827400 3141246600/n a=tool:sdr v2.6.1/n a=type:test/n m=audio 20154 RTP/AVP 0/n c=IN IP4 224.2.213.113/127/n a=ptime:40/n a=control:trackID=1/n m=video 51482 RTP/AVP 31/n c=IN IP4 224.2.172.238/127/n a=control:trackID=2/n
DESCRIBE rtsp://server.address:port/object.sdp RTSP/1.0/r/n CSeq: 1/r/n /r/n
发表评论
-
RTSP协议研究及其在一种VOD中的实现
2007-08-02 14:05 753随着计算机网络的发展和人们对信息多样化需求的不断提高,流媒体技 ... -
移动视频: QuickTime for Java API 入门
2007-08-05 12:45 567在 Java 平台上创建 iPod 视频内容 ... -
技术交流:QuickTime流媒体和Java(图)
2007-08-05 12:46 593这并不是即将问世的Quic ... -
JMF下载安装与支持格式
2007-08-05 12:47 828JMF开发进度不是很快,所以目前还是比较薄弱。 JMF,全名 ... -
基于RTP协议和MPEG-4的流媒体系统分析与实现
2007-08-09 15:09 778摘要:在简述MPEG-4压缩标准编码特性和RTP/RTCP协议 ... -
RTSP简单命令
2007-08-14 11:52 737OPTIONS rtsp://server.address:p ... -
Darwin Streaming Server 安裝操作備忘
2007-08-22 15:02 881Darwin Streaming Server 是蘋果公司推出 ... -
Windows Media Server搭建流媒体服务器
2007-08-27 10:25 852随着Internet和Intranet应用日益丰富,视频点播也 ... -
Windows Mobile的安装与流媒体的安装设置
2007-09-05 17:29 797本文重点描述了在Windows Mobile下使用流媒体服务 ...
相关推荐
RTSP 流媒体,rtsp client 测试例程
简单的linux_rtsp_client
rtspclient_rtspclient_RTSPClient_rtsp_rtspclient_源码.rar
实现rtsp的客户端,可以正常发送RTP命令,获取视频流
java rtsp client.....
基于rtsp的客户端,帮助初学者步步深入研究rtsp协议的代码实现
A simplified java rtsp client source code
rtspclient_rtspclient_RTSPClient_rtsp_rtspclient.zip
基于live555封装的rtspClient, 解决了默认live555 rtspClient demo 掉线问题,支持网络断线重连,支持多摄像机接入。文件包括播放demo及封装的Lib,包括rtspClient的封装实现源码。
我自己改写的RTSP接收MP3流媒体纯C代码,在Linux系统下编译测试验证过。解析接收下来的mp3文件或者buffer可以正常播放。附加相关标准文档。 纯C代码方便移植到其他平台。
用C语言编写的RTSP的客户端,在海思平台经过数据验证。
RtspClient > - [x] 实现基本框架 > - [x] 支持以UDP方式接收RTP报文 [ ] 优化UDP报文解码 > - [x] 支持以TCP方式接收RTP报文 [ ] 优化TCP报文重组 > - [x] 实现RTP报文重组 [x] 支持FU-A报文重组 [x] 支持单包NAL...
it s a rtsp_client program you can bulid it in vc6.0
rtspclient demo高并发100路高清视频,在linux下开发和运行
C++ 解析rtsp流后返回Iplimage,用Opengl显示.VS2012,opencv是2.4.10.代码完整,下载可直接使用。
RTSP server and RTSP Client
live555 官方源代码,内含RTSP服务器,RTSP客户端、多种多媒体编程实例
支持用户名+密码验证的rtsp客户端程序测试程序源码,支持海康IPC。只是测试RTSP协议的demo,未整理代码,与海康IPC交互测试通过。
在live555 srv运行h264,用此client可以接收到h264。在fwrite的地方加上自己的回调,就可以融入到自己的项目中去。 此代码我也应用于项目中了,代码中的ip或h264文件名之类的自己做微调即可。
詳細說明:RTSP 使用標準的 process. 利用 File Server 方式來做,以大華/ 海康 做為例子.