基于EasyDarwin的实现无人机远程视频传输--RTSP协议分析篇

标签：

申明该文章参考了http://blog.csdn.net/haolipengzhanshen/article/details/50802081 的文章，在这里标示感谢！

这篇文章主要从几个方面分析EasyDarwin的RTSP内容
RTSP协议概述
wireshark抓包实例分析 一次完整RTSP的交互流程
EasyDarwin项目代码中 RTSP的初始化
EasyDarwin项目代码中 RTSP请求的处理过程

如果你是只想实现视频流的传输，对转发服务器没有太大要求，建议只要研究EasyDarwin的客户端即可，客户端涉及到解码播放显示在地面站上。对于EasyDarwin的使用在EasyDarwin的官方有详细说明。

第一部分:RTSP协议

一、RTSP协议概述

RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。HTTP协议相信大家都比较熟悉了.

RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。

一次基本的RTSP操作过程是:
首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。
流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。
流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。
在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话

二、RTSP 重要方法
 C->S 表示从客户端给服务器发数据，S->C表示从服务器给客户端发数据。通过以上几个方法完成客户端和服务器之间的指令交互，构成RTSP协议的基本框架。

我们用 wireshark来分析下这个RTSP的命令流程熟悉指令流程对于我们理解EasyDarwin有很重要的帮助。

来分析下rtsp包：

图1.1 客户端推流给服务器

                                        图1.2 播放器从服务器获得视频流

RTSP协议基本流程,我们打开EasyDarwin工程运行，流媒体服务器。

1.C->S:OPTION request //询问S有哪些方法可用 
1.S->C:OPTION response //S回应信息中包括提供的所有可用方法 

2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息 
2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp 
客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。 
OPTIONS 字段后的rtsp://192.168.1.100:8003/st0.sdp RTSP/1.0\r\n 
是请求的Server上的URI资源。
Content-Type: application/sdp //表示回应为SDP信息
Content-Length: 1383 //以下为具体的SDP信息 媒体描述是我们分析时常用的。

v=<version> 
o=<username> <session id> <version> <network type> <address type> <address> 
s=<session name> 
i=<session description> 
u=<URI> 
e=<email address> 
p=<phone number> 
c=<network type> <address type> <connection address> 
b=<modifier>:<bandwidth-value> 
t=<start time> <stop time> 
r=<repeat interval> <active duration> <list of offsets from start-time> 
z=<adjustment time> <offset> <adjustment time> <offset> .... 
k=<method> 
k=<method>:<encryption key> 
a=<attribute> 
a=<attribute>:<value> 
m=<media> <port> <transport> <fmt list> 
v = （协议版本） 
o = （所有者/创建者和会话标识符） 
s = （会话名称） 
i = * （会话信息） 
u = * （URI 描述） 
e = * （Email 地址） 
p = * （电话号码） 
c = * （连接信息） 
b = * （带宽信息） 
z = * （时间区域调整） 
k = * （加密密钥） 
a = * （0 个或多个会话属性行） 
时间描述： 
t = （会话活动时间） 
r = * （0或多次重复次数） 
媒体描述： 
m = （媒体名称和传输地址） 
i = * （媒体标题） 
c = * （连接信息 — 如果包含在会话层则该字段可选） 
b = * （带宽信息） 
k = * （加密密钥） 
a = * （0 个或多个媒体属性行）

3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话 
3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息 

用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误”455 Method Not Valid In This State”

4.C->S:PLAY request //C请求播放 
4.S->C:PLAY response //S回应该请求的信息 
方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。

5.S->C:发送流媒体数据 

6.C->S:TEARDOWN request //C请求关闭会话 
6.S->C:TEARDOWN response //S回应该请求 
一个完整的RTSP协议请求流程就是这样

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。

其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。

更多内容请看:http://www.amovauto.com/?p=481 阿木社区

QQ群: 526221258

基于EasyDarwin的实现无人机远程视频传输--RTSP协议分析篇

标签：

原文地址：http://blog.csdn.net/msq19895070/article/details/51011507