Live555源码解析(2)

来源：互联网发布：淘宝联盟怎么设置佣金编辑：程序博客网时间：2024/05/29 15:00

上一篇Live555源码解析(1) - Main 寻根问祖，留其筋骨将main()函数脉络做了整体分析，理论上本篇将从服务器的创建开始讲起，但众所周知，Live555媒体服务器是RTSP服务器的实现，因此继续追踪源码前，先整体介绍下RTSP协议及相关协议内容。如读者已掌握RTSP内容，则可跳过本篇，继续下一篇Live555源码解析(3) - 服务开启，愿者上钩的阅读。

编写本篇前，尽可能详细地翻译了RTSP Sepc，如有兴趣，可同时阅读[RTSP Spec中文版](http://www.jianshu.com/p/b0474f65e729)。

1. RTSP简史

RTSP出现以前，最热的大概就是HTTP协议。想象一下，当你需要欣赏网络中的某一段视频，通过HTTP协议访问其URL，开始下载，下载完成后播放。对于很久以前的视频采集设备、网络带宽或是负责播放的显示器而言，似乎多给予一点耐心、多重连几次断开的HTTP连接、甚至多校验几次下载后文件的完整性，体验上也还能过得去，毕竟那时候的分辨率、帧率、带宽限制了互联网途径传播媒体文件的大小，也因此各种硬盘、U盘、光盘才在大文件传输的路上独领风骚。

但时代在发展，采集设备分辨率在提升，显示器支持了更高的帧率，网络带宽也指数增长，我们不再需要像以前一样拥有良好的性格，才能静下心来观赏下载了半天的几分钟低清视频。当然下载后观看的场景HTTP依然是够用的，但伴随着网络资源的日益丰富，用户时间的稀缺性日益凸显，我们希望能够以在线的方式快速浏览、暂停、或是跳过某些对于个体信息量低的片段（如片头、片尾），此时，HTTP不再能够满足需求，也因此，RTSP站在其肩膀上，直面痛点，脱颖而出。

RTSP全称实时流协议（Real Time Streaming Protocol），它是一个网络控制协议，设计用于娱乐、会议系统中控制流媒体服务器。RTSP用于在希望通讯的两端建立并控制媒体会话，客户端通过发出VCR-style命令如play、record和pause等来实时控制媒体流。

RTSP处理流时会根据端点间可用带宽大小，将大数据切割成小分组，以使得客户端可以在播放一个分组的同时，可以解压第二个甚至同时下载第三个分组。这样一来，用户将不会感觉到数据间存在停顿。至于RTSP的特性，则主要体现在如下方面：

多服务器兼容：媒体流可来自不同服务器
可协商：客户端和服务器可协商feature支持程度
HTTP亲和性：尽可能重用HTTP概念，包括认证、状态码、解析等
易解析：HTML或MIME解析器均可在RTSP中适用
易扩展：新的方法或参数甚至协议本身均可添加或定制
防火墙亲和性：传输层或应用层防火墙均可被协议较好处理
服务器控制：控制概念易于理解，服务器不允许向客户端传输不能被客户端关闭的流
多场景适用：RTSP提供帧级别精度，适用于更多媒体应用场景

1.1 相关协议介绍

RTSP组合使用了可靠传输协议TCP（控制）和高效传输协议UDP（内容）来串流内容给用户，即文件开始传输而客户端不用等待整个文件内容抵达就开始播放。其实不仅仅是点播服务，RTSP还支持传输不能以传统方式下载后播放的直播内容。

RTSP也并不负责数据传输，通常（非必须）是通过RTP（Real-time Transport Protocol）来完成，而RTP中，又通过RTCP负责完成同步、QOS管理等功能。具体应用中，它们三者的关系如下图所示：

RTSP RTCP RTP

2. RTSP方法

RTSP中并没有连接的概念，而是通过会话（Session）进行管理。每个会话有对应的会话ID，会话中可能可能涉及一至多个流，会话生命周期中，客户端也可能切换连接（如TCP）来传递RTSP请求（request）。

method direction object requirement DESCRIBE C->S P,S recommended ANNOUNCE C->S, S->C P,S optional GET_PARAMETER C->S, S->C P,S optional OPTIONS C->S, S->C P,S required(S->C:optional) PAUSE C->S P,S recommended PLAY C->S P,S required RECORD C->S P,S optional REDIRECT S->C P,S optional SETUP C->S S required SET_PARAMETER C->S,S->C P,S optional TEARDOWN C->S P,S required

P: 呈现（Presentation），S:流（Stream）

对于一个完整的RTSP应用如点播，其生命周期内，完整会话（所有交互）如下图所示：

2.1 必选方法

对于上述交互中涉及的RTSP方法，说明如下：

OPTIONS
用于请求服务器所支持的所有方法

C->S    OPTIONS rtsp://video.foocorp.com:554 RTSP/1.0        CSeq: 1S->C    RTSP/1.0 200 OK        CSeq: 1        Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, RECORD

DESCRIBE（推荐级别）
用于请求URL指定对象的描述信息，通常描述信息使用SDP(Session Description Protocol)格式。
```
C->S    DESCRIBE rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0        CSeq: 2S->C    RTSP/1.0 200 OK        CSeq: 2        Content-Type: application/sdp        Content-Length: 210         m=video 0 RTP/AVP 96        a=control:streamid=0        a=range:npt=0-7.741000        a=length:npt=7.741000        a=rtpmap:96 MP4V-ES/5544        a=mimetype:string;"video/MP4V-ES"        a=AvgBitRate:integer;304018        a=StreamName:string;"hinted video track"        m=audio 0 RTP/AVP 97        a=control:streamid=1        a=range:npt=0-7.712000        a=length:npt=7.712000        a=rtpmap:97 mpeg4-generic/32000/2        a=mimetype:string;"audio/mpeg4-generic"        a=AvgBitRate:integer;65790        a=StreamName:string;"hinted audio track"
```
SDP协议格式
SDP(Session Description Protocol)是一个用来描述多媒体会话的应用层控制协议，是一个基于文本的协议，用于会话建立过程中的媒体类型和编码方案的协商等。SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，<类型>是一个字母，<值>是结构化的文本串，其格式依<类型>而定。
```
＜type＞=<value>[CRLF]
```
sdp的格式:
```
v=<version>   (协议版本)
```
o=
(所有者/创建者和会话标识符)
s= (会话名称)
i= (会话信息)
u= (URI 描述)
e= (Email 地址)
p= (电话号码)
c= (连接信息)
b=: (带宽信息)
t= (会话活动时间)
r= (0或多次重复次数)
z= ….
k=
k=: (加密密钥)
a= (0 个或多个会话属性行)
a=:
m= (媒体名称和传输地址)
SETUP
用于请求URL使用指定传输格式，必须在PLAY前发出。
```
C->S    SETUP rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0        CSeq: 3        Transport: rtp/udp;unicast;client_port=5067-5068S->C    RTSP/1.0 200 OK        CSeq: 3        Session: 12345678        Transport: rtp/udp;client_port=5067-5068;server_port=6023-6024
```
客户端请求中，指明了用于接收RTP数据（音视频）的本地端口5067，以及RTCP数据（元信息）的端口5068。这里图示说明下RTSP（554/8554）、RTP、RTCP端口关系。

可以看到，RTCP端口是基于RTP的，且始终为其端口值+1。
服务器回复中，确认了客户端所请求的端口，并给出服务器端对应开辟的端口值6023/6024。
PLAY
用于请求服务器使用SETUP中确认的机制开始传输数据，客户端不应在SETUP请求未被确认应答成功前发出PLAY请求。另外需要注意，PLAY请求是需要排队的，其中可携带Range域以指明区间。
```
C->S    PLAY rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0        CSeq: 4        Range: npt=5-20        Session: 12345678S->C    RTSP/1.0 200 OK        CSeq: 4        Session: 12345678
```

TEARDOWN
用于请求终止会话，将停止会话中所有相关流，并释放资源。

C->S    TEARDOWN rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0        CSeq: 5        Session: 12345678S->C    RTSP/1.0 200 OK        CSeq: 5

2.2 可选方法

除了上一小节中提到的5种必选方法外，还有如下方法是可选的。

ANNOUNCE
ANNOUNCE方法有两个用途：
- 从服务器发送给客户端时：用于更新实时会话描述
- 从客户端发送给服务器时：推送URL指定的呈现或媒体对象的描述
如果呈现途中插入新流，应重发完整描述，而不仅仅是增量。这样一来，也就支持了动态移除组件。
C->S: ANNOUNCE rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0
CSeq: 10
Session: 47112344
Content-Type: application/sdp
Content-Length: 332
```
     v=0     o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4     s=SDP Seminar     i=A Seminar on the session description protocol     u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps     e=mjh@isi.edu (Mark Handley)     c=IN IP4 224.2.17.12/127     t=2873397496 2873404696     a=recvonly     m=audio 3456 RTP/AVP 0     m=video 2232 RTP/AVP 31
```
S->C: RTSP/1.0 200 OK
CSeq: 10

GET_PARAMETER
用于请求URI指定呈现或流的参数值。回复的内容有待实现，不带任何实体主体的GET_PARAMETER可用于测试客户端或服务器是否在线（类似“ping”程序）。

S->C:   GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0        CSeq: 431        Content-Type: text/parameters        Session: 12345678        Content-Length: 15        packets_received        jitterC->S:   RTSP/1.0 200 OK        CSeq: 431        Content-Length: 46        Content-Type: text/parameters        packets_received: 10        jitter: 0.3838

SET_PARAMETER
SET_PARAMETER请求用于设置URI指定呈现或流的参数值。
每条请求应当只包含一个参数以允许客户端确定失败原因，如果请求中包含多个参数，服务器必须只在所有参数都能成功设置情况下生效。服务器应当允许同一参数多次设置同一值，但可拒绝设置为不同值。
注意：媒体流传输参数必须通过SETUP请求来设置
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-Length: 20
Content-type: text/parameters
```
        barparam: barstuffS->C:   RTSP/1.0 451 Invalid Parameter        CSeq: 421        Content-Length: 10        Content-type: text/parameters        barparam
```
PAUSE
PAUSE请求会临时中断流传输，如果URL指定的是某一个流，则该流的播放和录制会被暂停。例如，对于音频而言，相当于静音操作。如果URL指定的是一组流，则呈现或组中所有活动流将会被暂停。当恢复播放或录制时，所有轨道的流必须进行同步。
此过程中，所有服务器资源均会保留，除非SETUP时，头中有参数指定延时，那么服务器可能在触发延时后关闭会话并释放资源。
```
C->S:   PAUSE rtsp://example.com/fizzle/foo RTSP/1.0        CSeq: 834        Session: 12345678S->C:   RTSP/1.0 200 OK        CSeq: 834        Date: 23 Jan 1997 15:35:06 GMT
```
RECORD
RECORD方法用于开始录制当前呈现描述中的一段媒体数据，UTC格式时间戳包含开始点和结尾点。如未给出时间范围，则使用呈现描述中的开始点和结尾点。如会话已处于运行中，则立即开始录制。
服务器决定将录制数据保存在请求URI或其他URI，如使用其他URI，需回复“201（Created）”并包含实体以描述请求状态和新资源位置信息。
一个支持直播情境下录制的服务器必须支持clock格式，这里smpte格式并没有意义。
```
C->S:   RECORD rtsp://example.com/meeting/audio.en RTSP/1.0        CSeq: 954        Session: 12345678        Conference: 128.16.64.19/32492374
```
REDIRECT
REDIRECT请求用于提示客户端它必须连接至另一个服务器，其中强制包含了Location头，以指明新的服务器URL。其中还可能包含Range参数，指明何时重定向将生效。如果客户端希望向该URI发送和接收媒体，则客户端必须先对当前会话发出TEARDOWN请求，然后向目标主机发出SETUP请求新的会话。
```
S->C:   REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0        CSeq: 732        Location: rtsp://bigserver.com:8001        Range: clock=19960213T143205Z-
```

2.3 RTSP状态机

RTSP Status Machine

2.4 嵌入式二进制数据（Embedded (Interleaved) Binary Data）

某些防火墙设计或其他环境因素可能迫使服务器将RTSP方法交错进流数据中。该种交错操作应尽可能避免，因为它提高了客户端和服务器操作的复杂度，也增加了额外的开销。嵌入式二进制数据应当只在RTSP通过TCP传输时使用。

C->S    SETUP rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 3        Transport: RTP/AVP/TCP;interleaved=0-1S->C    RTSP/1.0 200 OK        CSeq: 3        Date: 05 Jun 1997 18:57:18 GMT        Transport: RTP/AVP/TCP;interleaved=0-1        Session: 12345678C->S    PLAY rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 4        Session: 12345678S->C    RTSP/1.0 200 OK        CSeq: 4        Session: 12345678        Date: 05 Jun 1997 18:59:15 GMT        RTP-Info: url=rtsp://example.com/media.mp4;                  seq=232433;rtptime=972948234S->C    $\000{2 byte length}{"length" bytes data, w/RTP header}        $\000{2 byte length}{"length" bytes data, w/RTP header}        $\001{2 byte length}{"length" bytes RTCP packet}