2018/1/31 20:01:54当前位置推荐好文程序员浏览文章

整体而言,RTSP 通常工作于可靠的传输协议 TCP 之上,就像 HTTP 那样,用于发起/结束流媒体传输,交换流媒体元信息。RTP 通常工作于 UDP 之上,用于传输实际的流媒体数据,其中的载荷格式因具体流媒体类型的不同而不同,通常有专门的 RFC 规范对其进行定义,如 H.264 编码格式视频数据的载荷格式在 RFC 6184, RTP Payload Format for H.264 Video 中定义,其它流媒体数据类型有其它的规范进行定义。RTCP 同样通常工作于 UDP 之上,用于对 RTP 进行控制,流媒体数据的收发端在传输过程中相互发送 RTCP 数据包,将自己这一端检测到的 QoS 等信息传递给对方,使用 RTP/RTCP 协议的应用程序,利用这些信息对收发过程进行控制。RTP 和 RTCP 在传输过程中,工作于不同的端口上。

我们通过 Wireshark 抓包来看一下 RTSP/RTP/RTCP 的基本工作过程。我们启动 live555MediaServer,其工作目录下存有一些流媒体文件,其中包括 H.264 原始码流格式的文件 raw_h264_stream.264。启动 Wireshark 抓包。然后通过 ffplay 请求 live555MediaServer 并播放 raw_h264_stream.264

$ ffplay rtsp://10.240.248.20:8554/raw_h264_stream.264

其中 URI 中的 IP 地址为 live555MediaServer 运行的主机的 IP 地址,端口号为其采用的端口号。在 Wireshark 中,通过 Display Filter 过滤仅显示 RTSP/RTP/RTCP 包,将看到类似下面这样的包序列:

可以看到,首先是 RTSP 数据的交互,建立媒体传输会话,随后开始通过 RTP/RTCP 传输数据。RTSP 协议在制定时较多地参考了 HTTP/1.1 协议,甚至许多内容与 HTTP/1.1 完全相同。与 HTTP/1.1 类似,RTSP 客户端首先向服务器发送请求,随后服务器发回响应,以此实现数据的交互。RTSP 同样定义了一系列方法,表示对 URI 标识的资源所执行的操作。RTSP 具体定义的方法有如下这些:

      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

回到 Wireshark 抓的包来看 RTSP/RTP/RTCP 的基本工作过程。

客户端首先向服务器发送了一个方法为 OPTIONS 的请求,如第 112 号包,该请求内容如上图所示,携带有 URL,RTSP 版本号,User-Agent 等信息。RTSP 的 OPTIONS 与 HTTP/1.1 的对应方法具有相同的语义,具体在 HTTP/1.1 规范 RFC 2616 的 9.2 节 中定义。客户端通过这个方法了解服务器为 URL 提供了哪些方法的支持。

第 112 号包是 RTSP 服务器对客户端的 OPTIONS 请求的响应,其具体内容如下:

服务器将该 URL 支持的方法的列表返回给客户端。对于这里的情况,也就是 OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

然后客户端向服务器发送了一个 DESCRIBE 请求,即第 116 号包,该请求内容如下:

DESCRIBE 方法用于客户端提取由所请求的 URL 标识的表示或媒体对象的描述信息。它可以使用 Accept 头部指定客户端理解的描述格式。服务器则用所请求的资源的描述作为响应。DESCRIBE 应答响应对构成RTSP的媒体初始化阶段。

对于这里的情况,DESCRIBE 请求的 Accept 头部值为 application/sdp,表示客户端希望收到 SDP 格式的媒体表示。

服务器以一个 RTSP/SDP 包作为响应,如图中的第 118 号包:

这个 SDP 包实际内容的文本格式如下:

v=0o=- 1504179985128927 1 IN IP4 10.240.248.20s=H.264 Video, streamed by the LIVE555 Media Serveri=raw_h264_stream.264t=0 0a=tool:LIVE555 Streaming Media v2017.07.18a=type:broadcasta=control:a=range:npt=0-a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Servera=x-qt-text-inf:raw_h264_stream.264m=video 0 RTP/AVP 96c=IN IP4 0.0.0.0b=AS:500a=rtpmap:96 H264/90000a=fmtp:96 packetization-mode=1;profile-level-id=42802A;sprop-parameter-sets=Z0KAKtoBEA8eXlIKDAoNoUJq,aM4G4g==a=control:track1

服务器通过 SDP 包,告知流媒体数据传输所用的协议,以及流媒体本身的一些信息,这里所用的协议为 RTP/RTCP。通常的 SDP 文件中,“Media Description” 选项,即以 “m” 开头的那一行中会指定,会指定客户端接收 RTP 包所需要监听的端口,但在这里这个端口为 0。传输中客户端和服务器所选择的用于 RTP/RTCP 包收发的端口将在后面的 RTSP 请求中交换。

客户端在收到服务器发来的 SDP 包之后,会选择两个端口,分别用于 RTP 和 RTCP 包的收发,并发送了一个 SETUP 请求用于建立媒体会话,如第 119 号包:

客户通过 SETUP 请求的 Transport 头部,将为 RTP 和 RTCP 选择的端口、协议及通信方式(UDP 单播还是多播)发送给客户端。这里可以看到,客户端选择了 19008 和 19009 两个端口来进行 RTP 和 RTCP 包的收发。

随后服务器对 SETUP 请求做出了响应,如第121 号包:

服务器通过这个响应,把它为媒体会话开启的用于收发 RTP、RTCP 包的端口,会话的标识符,超时时间等信息通知给客户端。随后,客户端分别在 RTP 和 RTCP 的端口上,向服务器的 RTP 和 RTCP 端口上发送了两个包,如第 122 号包和第 123 号包:

122 号包123 号包

这两个包中携带的都是无意义的数据。发送它们的目的,大概主要是为了 NAT 穿墙。

随后客户端向服务器发送了一个 PLAY 请求,来启动播放,如第 124 号包:

PLAY 请求中会携带从前面的 SETUP 请求的响应获得的会话标识符。

随后服务器向客户端发送了一个 RTCP 包,如第 125 号包:

在这个包中,服务器把 RTP 时间戳,服务器的 SSRC,服务器的 CNAME 等信息发送给客户端。之后,服务器发送了 PLAY 请求的响应:

在这个包中,发送的 RTP 包的初始序列号,RTP 时间等重要信息被发送给客户端。

至此媒体会话最终建立完成,后面就可以开始通过 RTP 传输视频数据了。请求的 H.264 视频文件的前两个 NALU,即 SPS 和 PPS 如下所示:

00000000   00 00 00 01  67 42 80 2A  DA 01 10 0F  1E 5E 52 0A  ....gB......^R.00000010   0C 0A 0D A1  42 6A 00 00  00 01 68 CE  06 E2

开始的两个 RTP 包,即第 127 号包和第 128 号包内容如下:

127 号包128 号包

它们的内容与 H.264 视频文件的前两个 NALU 的内容完全吻合,即 live555 通过两个 RTP 包发送了前两个 NALU SPS 和 PPS。

从 RTSP 的 OPTIONS 请求开始,到首个视频数据 NALU 开始发送,经过了总共大概 102 ms 的时间,媒体会话完全建立完成。

视频数据经过一端时间的稳定传输,最终以服务器向客户端发送的一个 RTCP BYE 包而结束,如第 6451 号包:

总结一下这个过程:

  1. 客户端首先向服务器发送一个方法为 OPTIONS 的请求,了解服务器为 URL 提供了哪些方法的支持。
  2. 服务器将该 URL 支持的方法的列表返回给客户端。
  3. 客户端向服务器发送了一个 DESCRIBE 请求,提取由所请求的 URL 标识的表示或媒体对象的描述信息。
  4. 服务器通过 SDP 包,告知流媒体数据传输所用的协议,以及流媒体本身的一些信息。
  5. 客户端在收到服务器发来的 SDP 包之后,会选择两个端口,分别用于 RTP 和 RTCP 包的收发,并发送了一个 SETUP 请求用于建立媒体会话。
  6. 服务器发回 SETUP 响应,把它为媒体会话开启的用于收发 RTP、RTCP 包的端口,会话的标识符,超时时间等信息通知给客户端。
  7. 客户端分别在 RTP 和 RTCP 的端口上,向服务器的 RTP 和 RTCP 端口上发送了两个包。
  8. 客户端向服务器发送一个 PLAY 请求,来启动播放。
  9. 服务器向客户端发送一个 RTCP 包,把 RTP 时间戳,服务器的 SSRC,服务器的 CNAME 等信息发送给客户端。
  10. 服务器发送 PLAY 请求的响应,其中包含 RTP 包的初始序列号,RTP 时间等重要信息。至此媒体会话最终建立完成。
  11. 通过 RTP/RTCP 发送流媒体数据。
  12. 服务器向客户端发送一个 RTCP BYE 包结束会话。

live555 源码分析系列文章

live555 源码分析:简介
live555 源码分析:基础设施
live555 源码分析:MediaSever
Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程
live555 源码分析:RTSPServer
live555 源码分析: DESCRIBE 的处理
live555 源码分析: SETUP 的处理
live555 源码分析: PLAY 的处理
live555 源码分析:RTSPServer 组件结构
live555 源码分析:ServerMediaSession
live555 源码分析:子会话 SDP 行生成
live555 源码分析:子会话 SETUP
live555 源码分析:播放启动

网友评论