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

本是古典何须时尚 2024-02-20 11:43 42阅读 0赞

### 1、介绍 ###

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

![a0be9d5c07c54c43b1e6c37450f45d05.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
    报文有效载荷中的所有特约信源。

![f38f8bdef8834225a1176cb20fdab60d.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。

![7342d034a4544bf08465262f55527eb2.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的头由一个字节组成如下所示：  
![c4c809c61d4e4918a6ec5609f86b4077.png][]

![8abd486e52c544a697a71d4ea742fad2.png][]

![54fc93136259447ea8cc5cff2bacd3a0.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:  
![58475544e49b453c89344d7b12617c3c.png][]

**RTP包中的SPS:**

![6fc8c3c8c07c457295e79fb97a7d84fe.png][]

![be8f918d39b64cd4a620f808baebeb00.png][]

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

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

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

![597d6bfc27cc464ab6f23d33470b8a4b.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  
![7f2fc31884cb4dd48450808196efd53b.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第一个切片 #####

![0c1f5498e7cc4262b86ac0631d1919e1.png][]

![35fd08c390bb4292b7ef694e739221ca.png][]

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

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

![44a87fe5244e420cb0e5ce3a196b898e.png][]

![bd675f16696945d9a88490424c6e3ea0.png][]

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

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

![639117a1b2f94d45901d19e658424bf5.png][]

![6b4e584cf0ad4014a74f2fa52f93e0c2.png][]

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

### 5、RTP打包AAC ###

过程：

1.  需要将aac的前7个（或9个）字节的ADTS去掉，即是跳过adts header。
2.  添加RTP Header。
3.  添加AU\_HEADER\_LENGTH。
4.  添加AU\_HEADER。
5.  添加AU（去掉ADTS的aac数据）数据。
    
    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的格式为：
    
    ![c618a12a2a2a4e3da8862306ea3c237b.png][]
6.  samplingFrequencyIndex的取值：![0a317d1e58d2441e9cd1e7334817cdae.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数据段的格式  
    ![cac0c29e7b554cc18d99cec13c81231b.png][]
7.  ![51b172827bce43fdbdcf139ccc726999.png][]
8.  其它的值都是可选的, 如果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  
    1  
    如果一个rtp中只有一个aac包, 不需要加AU-Header, 那么sdp中的aac参数可以简化为
    
    a=fmtp:96 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=1  
    38856e500;

[a0be9d5c07c54c43b1e6c37450f45d05.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/399ed303f503444587b4fd630160aa37.png
[f38f8bdef8834225a1176cb20fdab60d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/1ac454b2513a461fb1a6a4ec08550891.png
[7342d034a4544bf08465262f55527eb2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/e8c4fab07530445e8d67af03326ae89e.png
[c4c809c61d4e4918a6ec5609f86b4077.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/ae7c9e87a34b4b1a9d316878aa0508b0.png
[8abd486e52c544a697a71d4ea742fad2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/6fb0c66786774f98a674222fd507beba.png
[54fc93136259447ea8cc5cff2bacd3a0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/f86aa3db27b24afbae1df47054966ef8.png
[58475544e49b453c89344d7b12617c3c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/5b64c10730384e198fa958556a4f0acd.png
[6fc8c3c8c07c457295e79fb97a7d84fe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/83b748b2f3b7461783d50ef9abc0445f.png
[be8f918d39b64cd4a620f808baebeb00.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/d3ec21274fa349c88692d7d618263ae5.png
[597d6bfc27cc464ab6f23d33470b8a4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/54d0812174424b71ac5a4ef4ed60ad64.png
[7f2fc31884cb4dd48450808196efd53b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/d4ec1f368c0844188f2b404015a45a07.png
[0c1f5498e7cc4262b86ac0631d1919e1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/d60a188eb69a467595c527662b7d819f.png
[35fd08c390bb4292b7ef694e739221ca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/5192649be5dd4647a615f95ff5911e62.png
[44a87fe5244e420cb0e5ce3a196b898e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/5f71b215eeb341e2bf3636f97a0fa57a.png
[bd675f16696945d9a88490424c6e3ea0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/d8520e17a6ed4f879812209f2fa22705.png
[639117a1b2f94d45901d19e658424bf5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/0d65f1afc59a47fc8e8b4b4c25755166.png
[6b4e584cf0ad4014a74f2fa52f93e0c2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/86858e16613b4e888186901a6b3bfb5e.png
[c618a12a2a2a4e3da8862306ea3c237b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/4928180922d64c218652bcc349079581.png
[0a317d1e58d2441e9cd1e7334817cdae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/788ffa49c97c4d728be020f783bc7961.png
[cac0c29e7b554cc18d99cec13c81231b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/5519a82af921495f9cba551bdd17ace2.png
[51b172827bce43fdbdcf139ccc726999.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/46f297eb50af4680899fadf869928e42.png