RTP协议基本分析RTSP、WebRTC使用

桃扇骨 2023-10-16 09:54 49阅读 0赞

### 1、介绍 ###

实时流传输协议（[RTSP][]：Real Time Streaming Protocol）是一种网络传输协议，旨在发送低延迟流。 该协议由RealNetworks，Netscape和哥伦比亚大学的专家在1996年开发。它定义了应如何打包流中的数 据以进行传输。

![3b962f95928744c1a002addc7c406c71.png][]

2、RTP

RTP协议原理，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RTP数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输。

RTP可以基于UDP和TCP两种方式传输，两种方式大致是一样的，下面主要都是基于UDP的分析：

RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个基数UDP端口号。

3、格式

RTP报文由两部分组成：报头和有效载荷。RTP报头格式如下图所示，其中：  
  
V：RTP协议的版本号，占2位，当前协议版本号为2。  
  
P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷  
的一部分。  
  
X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。  
CC：CSRC计数器，占4位，指示CSRC 标识符的个数。  
  
M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记帧的开  
始。  
  
PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。  
序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者  
通过序列号来检测报文丢失情况，重新排序报文，恢复数据。  
  
时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来  
计算延迟和延迟抖动，并进行同步控制。  
  
同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的  
两个同步信源不能有相同的SSRC。  
  
特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP  
报文有效载荷中的所有特约信源。  
![5ce14db9fb0f4d3baff9289e0cab9a9f.png][]1 typedef struct \_rtp\_header\_t  
2 \{  
3 uint32\_t v:2; /\* protocol version \*/  
4 uint32\_t p:1; /\* padding flag \*/  
5 uint32\_t x:1; /\* header extension flag \*/  
6 uint32\_t cc:4; /\* CSRC count \*/  
7 uint32\_t m:1; /\* marker bit \*/  
8 uint32\_t pt:7; /\* payload type \*/  
9 uint32\_t seq:16; /\* sequence number \*/  
10 uint32\_t timestamp; /\* timestamp \*/  
11 uint32\_t ssrc; /\* synchronization source \*/  
12 \} rtp\_header\_t;

同步信源：是指产生媒体流的信源，例如麦克风、摄像机、RTP混合器等。它通过RTP报头中的一个32位数

字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报

文的分组。

特约信源：是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报

文，并把混合器作为组合RTP报文的SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者

知道组成组合报文的各个SSRC。  
![e058fb398cb44a12b8af01fbf67bc100.png][]

例如：

有三个信号源各发出一路rtp流，RTP1携带的SSRC是SSRC1，RTP2携带的SSRC是SSRC2，

RTP3携带SSRC3，这三路RTP流到达混合器时，混合器会将这三路流混合成一路流发出去，它会把这三

路流的SSRC记录下来，形成一个列表，叫CSRC表，在发送的混合RTP流中，SSRC域填充的字段是混合

器本身的SSRC4，而CSRC字段则会根据该包的负载的源来填入。

如当前的RTP包的负载是来自SSRC1的，那么在当前RTP包的CSRC字段填入SSRC1。

这样接收者就可以根据CSRC来区分不同的信源。

4、RTP打包H264

RTP的特点不仅仅支持承载在UDP上，这样利于低延迟音视频数据的传输，另外一个特点是它允许

通过其它协议接收端和发送端协商音视频数据的封装和编解码格式，这样固定头的playload type字

段就比较灵活。

H.264标准协议定义了两种不同的类型：一种是VCL即Video Coding Layer ， 一 种 是 NAL 即

Network Abstraction Layer。其中前者就是编码器吐出来的原始编码数据，没有考虑传输和存储

问题。后面这种就是为了展现H.264的网络亲和性，对VCL输出的slice片数据进行了封装为

NALUs(NAL Units)，然后再封装为RTP包进行传输。

NALU的基本格式是：NALU Header + NALU Data,其中NALU的头由一个字节组成如下所示：  
![4eb8d13efc8b484489035f355d4e03a0.png][]![ee1b2427793e4892af399ae6e1a7982c.png][]

![2eb67c92e96747c983f888132c732cfd.png][]

一、

1-11就是NALU的单个包类型，但是一个NALU的大小是不一样的，如果是非视频数据的

SPS PPS才十几个字节，对于IDR帧，则有可能几十KB。

这样把NALU打包到RTP方式就很多，分为：

一个RTP包承载一个NALU；

多个NALU合并到一个RTP；

一个大的NALU切分成多个RTP。

二、

同时由于时间戳的问题，就有了24-29几种类型。

但是对于发送端组RTP包的一方来说，尽可能找简单的打包方式。对于接受端则需要适配各种发送

端的打包方式，因为无法决定输入源的打包方式。

（打包的时候不要搞太复杂的模式）

我们对于NALU的长度<=1400（rtp payload size）的则采用的是单一NALU打包到单一的RTP

包中；

我们对于NALU的长度>1400的则采用了FU-A的方式进行了打包，这种就是把一个大的NALU进

行了切分，最后接收方则进行了合并，把多个RTP包合并成一个完整的NALU即可；

为什么NALU的长度大于1400字节就要进行FU-A切片，是因为底层MTU大小值一般为1500，从

传输效率讲，使用1400作为切分条件。

RTP最大数据包（包含RTP头部） = MTU - UDP首部 - IP 报文首部

4.1、H264打包方式之Single NAL Unit

一个RTP包打包一个单独的NALU方式，其实最好理解，就是在RTP固定头后直接填充NLAU

单元数据即可，即：

RTP Header + NALU Header + NALU Data; （不包括startcode）

文件中的SPS:  
![885937647c464abcb74d17e238578152.png][]

**RTP包中的SPS:**

![3b72d2f0be6f42248427d3bfed1853e2.png][]

### 4.2、H264打包方式之FU-A ###

需要了解两个数据包头即FU indicator和Fu header。

#### 4.2.1、FU indication ####

![1cf8685d892a4a5c8d5a59ba6a1c5096.png][]

这里面的的F和NRI就是NALU头的前面三个bit位，后面的

TYPE就是NALU的FU-A类型28，这样在RTP固定头后面第一字节的后面5bit提取出来就确认了该

RTP包承载的不是一个完整的NALU，是其一部分。

那么问题来了，一个NALU切分成多个RTP包传输，那么到底从哪里开始哪里结束呢？

可能有人说RTP包固定头不是有mark标记么，注意区分那个是以帧图像的结束标记，这里要确定是NALU结束

的标记，其次NALU的类型呢？那么就需要RTP固定12字节后面的Fu Header来进行区分。

4.2.2、FU header  
![896fbd5b60e642348300fb21045a3f8f.png][]

字段解释：  
S: 1 bit 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开  
始，开始位设为0。  
  
E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束，即, 荷载的最后字节也是分片NAL单元的最后  
一个字节，当跟随的FU荷载不是分片NAL单元的最后分片,结束位设置为0。  
也就是说一个NALU切片时，第一个切片的SE是10，然后中间的切片是00，最后一个切片时11。  
  
R: 1 bit  
保留位必须设置为0，接收者必须忽略该位。  
  
Type: 5 bits  
此处的Type就是NALU头中的Type,取1-23的那个值，表示 NAL单元荷载类型定义。  
4.2.3、第一个IDR帧的NALU第一个切片

![8b59b1b37aef41a9a2ec925e4572cb1b.png][]

FU indication：
    十六机制：0x7C
    二进制：0111 1100
    FU header：
    十六进制：0x85
    二进制：1000 0101
    这里的SE是10，则说明该RTP包承载的NALU的第一个切片。

4.2.4、第一个IDR帧的NALU第二个切片

![2fb7b2b07ba34820a6eb14901d37e518.png][]

FU indication：
    十六机制：0x7C
    二进制：0111 1100
    FU header：
    十六进制：0x05
    二进制：0000 0101
    这里的SE是00，则说明该RTP包承载的NALU的中间切片。

4.2.5、第一个IDR帧的NALU最后一个切片

![a910d1e973f543e8bd5163ebf1baf6f7.png][]

FU indication：  
十六机制：0x7C  
二进制：0111 1100  
FU header：  
十六进制：0x45  
二进制：0100 0101  
这里的SE是01，则说明该RTP包承载的NALU的最后一个切片。  
5、RTP打包AAC  
过程：

需要将aac的前7个（或9个）字节的ADTS去掉，即是跳过adts header。

添加RTP Header。

添加AU\_HEADER\_LENGTH。

添加AU\_HEADER。

添加AU（去掉ADTS的aac数据）数据。  
![8cff0519bf9d441586ab0edc95f8eea9.png][]

注意：一个RTP包中可以有一个AU-headers-length 和 n个AU-header和 n个AU（AU每包实际音频数据流）

5.1、AU-headers-length

头两个字节表示au-header的长度，单位是bit。 一个AU-header长度是两个字节（16bit）因为可以有多

个au-header所以AU-headers-length的值是 16的倍数，一般音频都是单个音频数据流的发送，所以

AU-headers-length的值是16

//AU\_HEADER\_LENGTH

bytes\[12\] = 0x00; //高位

bytes\[13\] = 0x10; //低位 只有一个AU\_HEADER

因为单位是bit, 除以8就是auHeader的字节长度；又因为单个auheader字节长度2字节，所以再除以2就

是auheader的个数。

（注意：AU-header长度并不是固定为2字节，具体要看SDP）

5.2、AU-header

au-header的高13个bits就是一个au 的字节长度：

//AU\_HEADER

bytes\[14\] = (byte)((len & 0x1fe0) >> 5); //高位

bytes\[15\] = (byte)((len & 0x1f) << 3); //低位

（注意：AU-header长度并不是固定为2字节，具体要看SDP）

5.3、AU

音频实际数据（去掉ADTS的aac数据）

5.4、RTSP/SDP中AAC相关配置

1 v=0  
2 o=- 16128587303007558182 16128587303007558182 IN IP4 WINDOWS-75ID  
U9Q  
3 s=Unnamed  
4 i=N/A  
5 c=IN IP4 0.0.0.0  
6 t=0 0  
7 a=tool:vlc 3.0.5  
8 a=recvonly  
9 a=type:broadcast  
10 a=charset:UTF-8  
11 a=control:rtsp://192.168.2.195:8554/  
12 m=audio 0 RTP/AVP 96  
13 b=AS:128  
14 b=RR:0  
15 a=rtpmap:96 mpeg4-generic/22050  
16 a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config  
=138856e500; sizeLength=13; indexLength=3; indexDeltaLength=3; Pr  
ofile=1;  
17 a=control:rtsp://192.168.2.195:8554/trackID=4  
18 m=video 0 RTP/AVP 96  
19 b=AS:800  
20 b=RR:0  
21 a=rtpmap:96 H264/90000  
22 a=fmtp:96 packetization-mode=1;profile-level-id=42c01e;sprop-para  
meter-sets=Z0LAHtoCQKeX/8CgAJ/EAAADAZAAAF2qPFi6gA==,aM43IA==;  
23 a=control:rtsp://192.168.2.195:8554/trackID=5  
streamtype对于AAC, 固定为5。

profile-level-id固定为1。

config, SizeLength, IndexLength, IndexDeltaLength作用：

config是16进制的, 前两个字节 1388 , 表示采样率为22050, 1个channel。

前两个字节的为ios-14996-3中定义的AudioSpecificConfig, 前13个bits的格式为：

![01040aa2967045d2948d3cc548280bb6.png][]

samplingFrequencyIndex的取值：![263c4435ac764003986b2acd06b048bd.png][]

1388 转换成2进制为 0001 0011 1000 1000

audioObjectType为 00010 , 即 2

samplingFrequencyIndex为 0111 , 即 7 , 对应的采样频率为 22050

channelConfiguration为 0001 , 表示channel数量为1。

sizeLength=13; indexLength=3; indexDeltaLength=3涉及到音频的AU Header。

5.5、AU-Header数据段的格式  
![10d4c14dcb0b4fa7ae0105630cea093a.png][]

![5fdae519eae44078bd2e19e13cf70a1a.png][]

其它的值都是可选的, 如果sdp中没有出现相关的参数(或者为0), 则表示它们不出现。

以最简单的情况举例, 假设aac数据长度为200字节, 只有一个au-header。

200 的二进制为 0000011001000。 (补足为13 bits)

AU-headers-length 值为16, 因为只有一个au-header, au-header中

只有AU-size和AU-Index, 共占用16bits。

整个au-header数据段的内容为

0000 0000 0000 1000 0000011001000 000  
如果一个rtp中只有一个aac包, 不需要加AU-Header, 那么sdp中的aac参数可以简化为

a=fmtp:96 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=1  
38856e500;

[RTSP]: https://so.csdn.net/so/search?q=RTSP&spm=1001.2101.3001.7020
[3b962f95928744c1a002addc7c406c71.png]: https://img-blog.csdnimg.cn/3b962f95928744c1a002addc7c406c71.png
[5ce14db9fb0f4d3baff9289e0cab9a9f.png]: https://img-blog.csdnimg.cn/5ce14db9fb0f4d3baff9289e0cab9a9f.png
[e058fb398cb44a12b8af01fbf67bc100.png]: https://img-blog.csdnimg.cn/e058fb398cb44a12b8af01fbf67bc100.png
[4eb8d13efc8b484489035f355d4e03a0.png]: https://img-blog.csdnimg.cn/4eb8d13efc8b484489035f355d4e03a0.png
[ee1b2427793e4892af399ae6e1a7982c.png]: https://img-blog.csdnimg.cn/ee1b2427793e4892af399ae6e1a7982c.png
[2eb67c92e96747c983f888132c732cfd.png]: https://img-blog.csdnimg.cn/2eb67c92e96747c983f888132c732cfd.png
[885937647c464abcb74d17e238578152.png]: https://img-blog.csdnimg.cn/885937647c464abcb74d17e238578152.png
[3b72d2f0be6f42248427d3bfed1853e2.png]: https://img-blog.csdnimg.cn/3b72d2f0be6f42248427d3bfed1853e2.png
[1cf8685d892a4a5c8d5a59ba6a1c5096.png]: https://img-blog.csdnimg.cn/1cf8685d892a4a5c8d5a59ba6a1c5096.png
[896fbd5b60e642348300fb21045a3f8f.png]: https://img-blog.csdnimg.cn/896fbd5b60e642348300fb21045a3f8f.png
[8b59b1b37aef41a9a2ec925e4572cb1b.png]: https://img-blog.csdnimg.cn/8b59b1b37aef41a9a2ec925e4572cb1b.png
[2fb7b2b07ba34820a6eb14901d37e518.png]: https://img-blog.csdnimg.cn/2fb7b2b07ba34820a6eb14901d37e518.png
[a910d1e973f543e8bd5163ebf1baf6f7.png]: https://img-blog.csdnimg.cn/a910d1e973f543e8bd5163ebf1baf6f7.png
[8cff0519bf9d441586ab0edc95f8eea9.png]: https://img-blog.csdnimg.cn/8cff0519bf9d441586ab0edc95f8eea9.png
[01040aa2967045d2948d3cc548280bb6.png]: https://img-blog.csdnimg.cn/01040aa2967045d2948d3cc548280bb6.png
[263c4435ac764003986b2acd06b048bd.png]: https://img-blog.csdnimg.cn/263c4435ac764003986b2acd06b048bd.png
[10d4c14dcb0b4fa7ae0105630cea093a.png]: https://img-blog.csdnimg.cn/10d4c14dcb0b4fa7ae0105630cea093a.png
[5fdae519eae44078bd2e19e13cf70a1a.png]: https://img-blog.csdnimg.cn/5fdae519eae44078bd2e19e13cf70a1a.png