VLC搭建服务器推送RTSP流分析

RTSP流媒体服务器搭建

使用VLC播放器搭建RTSP服务器（由于是RTSP协议，即数据客户端拉取，服务器端配置端口和路径即可），RTSP方式是通过RTP进行流媒体数据的传输的，VLC的实现也是基于UDP的(后面抓包分析)。

使用wireshark抓包分析RTSP流

服务器端：ip 192.168.11.127, port:8854,path:1
客户端： ip 192.168.11.189

RTSP信令交互

过滤RTSP：

image.png

显然上面三行是TCP的三次握手；接下来才是RTSP播控通信，首先发送OPTIONS,接着发送DESCRIBE,SETUP,PLAY,TEARDOWN等RTSP播控交互命令。

追踪TCP流发现：

OPTIONS

RTSP播控命令支持：DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,GET_PARAMETER。

接着查看DESCRIBE命令的回复发现：

image.png

DESRCIBE命令回复中：
audio 0 RTP/AVP 14
video 0 RTP/AVP 32
即音视频数据推送的协议为RTP/AVP，而且交互通道有4个，即traceID=12-15；具体是包装TCP还是UDP，需要看看SETUP命令回复的Transport字段：

image.png

可以看到RTP/AVP是包装UDP的，服务器和客户端端口都有两个，分别为播控交互和音视频数据推送的端口。

接下来追踪RTP协议UDP流：

RTP

image.png

要想弄清RTP协议，首先要清楚RTP协议格式：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图6.7所示，其中：
1.V：RTP协议的版本号，占2位，当前协议版本号为2。

2. P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
3. X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。
4. CC：CSRC计数器，占4位，指示CSRC 标识符的个数。
5. M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
6. PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。
7. 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，在helix服务器中这个字段是从0开始的，同时音频包和视频包的sequence是分别记数的。
8. 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
9. 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
10. 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

如果扩展标志被置位则说明紧跟在报头后面是一个头扩展，其格式如下：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

对比协议或追踪RTP的UDP流数据：

image.png

知道：版本号为2，填充为false，扩展false，负载类型：MPEG-I/II等等信息。