`
fonter
  • 浏览: 869326 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

实现RTSP协议的简单例子

阅读更多

Specifications for a simple RTSP client

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的相关资料:

Experiments in Streaming Content in Java ME(1) http://fonter.iteye.com/blog/425372
Experiments in Streaming Content in Java ME(2) http://fonter.iteye.com/blog/425392
Experiments in Streaming Content in Java ME(3) http://fonter.iteye.com/blog/425427

 

 

少用System.out.println()吗?http://fonter.iteye.com/blog/423871
读取流最快方式 http://fonter.iteye.com/blog/422412
java简单解析docx、pptx、xlsx文档 http://fonter.iteye.com/blog/420319
Log4j在Java WebApp的配置 http://fonter.iteye.com/blog/418570
J2ME to android之学习笔记 http://fonter.iteye.com/blog/416112
安装Jar提示“jar文件无效”的另一个奇怪原因 http://fonter.iteye.com/blog/414188
J2ME代码认证证书的支持情况 http://fonter.iteye.com/blog/413357
S40平台播放多媒体时内存优化 http://fonter.iteye.com/blog/413022
SUN的J2ME源代码下载 http://fonter.iteye.com/blog/412094

分享到:
评论
1 楼 db6623919 2014-11-19  
直接粘贴别人帖子还是英文的,有意思?

相关推荐

    基于C#的RTSP客户端简单协议程序

    RtspClient可能是实现RTSP客户端功能的源代码文件,可能包含类库、接口定义和具体的RTSP操作实现。 为了进一步理解这个C# RTSP客户端的实现,你需要打开RtspClient.sln并查看源代码,理解每个函数和类的作用,以及...

    RTSP 协议中文版

    RTSP协议设计时考虑到了多种不同的应用场景和技术需求,因此它能够支持多种数据传输通道的选择,例如: - **UDP**:适用于对延迟敏感但对数据丢失有一定容忍度的场景。 - **组播UDP**:支持一对多的数据传输,适合大...

    利用ffmpeg实现RTSP,RTMP推流以及保存到本地录像文件

    demo目录是简单的调用例子,简单实现了抓取屏幕然后推流到RTSP,RTMP服务器,以及保存到本地。 bin目录是已经编译好的二进制文件. 有兴趣可查看BLOG: https://blog.csdn.net/fanxiushu/article/details/80996391

    movie_vlc_rtsp_简单的vlc.net播放_VLCRTSP_支持rtsp视频流播放_

    VLCRTSP是一个基于VLC库的.NET框架,它允许开发者在C#或VB.NET等.NET...注意,由于VLC和RTSP协议的特性,网络状况、服务器性能以及编码格式等因素都可能影响播放质量,因此在开发时需考虑这些因素并做好相应的优化。

    java rtsp 模拟播放

    总的来说,这个Java程序演示了如何使用基本的Java网络类来构建一个简单的RTSP客户端,执行`OPTIONS`和`DESCRIBE`请求,这些都是实现RTSP流媒体播放的基础步骤。实际应用中,可能需要更复杂的错误处理、数据解析和...

    python 通过onvif协议获取 Rtsp 视频.zip

    在IT行业中,网络视频监控设备通常使用ONVIF(Open Network Video Interface Forum)协议来实现标准化通信。ONVIF是一个开放的国际标准,旨在规范IP安防设备的接口,使其能够跨品牌互操作。本主题主要关注如何使用...

    用Android的 Media Codec播放RTSP视频流.rar

    本教程将深入探讨如何利用MediaCodec在Android上实现RTSP视频流的播放。 首先,理解RTSP协议至关重要。RTSP是一种应用层协议,用于控制多媒体数据的传输。它允许客户端向服务器请求实时数据流,如视频和音频,以便...

    基于libvcl的简单rtsp播放器

    在这款Demo中,我们将深入探讨libvlc的使用方法以及RTSP协议的基础知识。 首先,让我们了解RTSP(Real-Time Streaming Protocol)协议。RTSP是一种应用层协议,用于控制媒体服务器进行实时数据传输,如音频、视频流...

    基于pyqt实现VLC实时预览RTSP流

    在实现RTSP流的实时预览时,我们需要完成以下步骤: 1. 安装必要的库:确保已安装Python 2.7、PyQt4和`python-vlc`模块。这些可以通过pip或conda等包管理器进行安装。 2. 创建PyQt界面:使用PyQt4的QMainWindow类...

    获取rtsp流方式

    海康威视作为知名的安防设备提供商,其产品支持RTSP协议。对接时,你需要确保获取到正确的RTSP URL,通常形式为`rtsp://username:password@ip_address/channel_id`,其中`username`、`password`是设备的登录凭证,`...

    Android MediaCodec RTSP H264播放器客户端

    在实现RTSP H264播放器时,我们首先要创建一个MediaCodec实例,指定解码器类型为H264。然后,通过RTSP客户端接收的数据需要进行解析,提取出NAL单元,因为MediaCodec只能处理这种格式的输入数据。这个过程通常包括...

    live555 rtspClient源代码

    4. **实例代码**:提供的多种实例代码可以帮助开发者理解如何实际应用live555库进行多媒体流处理,这些实例可能包括简单的播放器、服务器设置、不同类型的流媒体服务等,对于学习和开发具有极高的参考价值。...

    rtsp交互实例

    RTSP(Real Time Streaming Protocol)是一种应用层协议,用于控制实时...需要注意的是,虽然RTSP协议看似简单,但实际实现时涉及许多细节,如错误处理、网络可靠性、同步问题等,这些都是开发过程中需要考虑的关键点。

    C# 将本地视频文件转换成RTSP视频流

    首先,让我们详细了解一下RTSP协议。RTSP是一种应用层协议,它允许客户端与服务器之间进行交互式时间同步的媒体数据传输。通过RTSP,客户端可以控制媒体的播放速度、暂停、快进、快退等操作,而不仅仅是简单的下载或...

    在wpf中使用Vlc 播放 rtsp视频流

    通过这个过程,你可以构建一个简单的媒体播放器,支持RTSP视频流的播放。在实际应用中,你可能还需要考虑更多细节,比如错误处理、用户界面交互以及资源管理。记住,持续学习和更新你的知识,以适应不断发展的技术...

    android rtsp player

    在Android平台上,实现RTSP(Real-Time Streaming Protocol)播放器是一项关键的技术,它允许设备接收并播放通过RTSP协议传输的流媒体内容,如网络摄像头的实时视频流。本篇文章将深入探讨如何在Android上创建一个...

    RTSP_live555 综合资料

    3. 示例代码和教程:通过实例,你可以学习如何使用Live555搭建一个简单的RTSP服务器或客户端。 4. 流媒体服务器设计和优化策略:可能包含如何提高服务器性能,处理大量并发连接等高级话题。 5. 音视频编码知识:了解...

    一个简单的调用VLC库播放RTSP的Demo

    在"一个简单的调用VLC库播放RTSP的Demo"中,我们将探讨如何利用VLC库在程序中实现RTSP流的播放。 首先,VLC库提供了跨平台的API,使得开发者能够在C++、Python、Java等多种语言环境中使用VLC的功能。在本示例中,...

    rtsp流媒体服务器开发文档

    9. **实例分析**:通过具体的案例,如设置一个简单的RTSP服务器来播放一个视频文件,理解RTSP协议的实战应用。 10. **应用领域**:RTSP广泛应用于在线教育、视频会议、远程监控等领域,提供实时、低延迟的媒体传输...

    unity3d播放rtsp视频

    在Unity3D中直接播放RTSP视频流并不简单,因为Unity的标准播放器不支持RTSP协议。为了解决这个问题,开发者通常会借助第三方库,例如VLC Media Player。VLC是一个开源的跨平台多媒体播放器,它支持多种视频和音频...

Global site tag (gtag.js) - Google Analytics