H264码流进行RTP包封装

一.H264基本概念

H.264从框架结构上分为视频编码层（VCL）和网络抽象层（NAL），VCL功能是进行视频编解码，包括运动补偿预测，变换编码和熵编码等功能；NAL用于采用适当的格式对VCL视频数据进行封装打包。

VCL数据即被压缩编码后的视频数据序列，在VCL数据封装到NAL单元中之后，才可以用来传输或存储。NAL单元（NALU）是NAL的基本语法结构，它包含一个字节的头信息和一系列来自VCL的称为原始字节序列载荷（RBSP）的字节流。

nalu header

RBSP

nalu header

RBSP

nalu header

RBSP

H264是一种视频压缩的标准，与H265、SVAC等压缩方式一样，主要目的是对视频流进行压缩，以便减少网络传输对网络带宽的占用，H264压缩后的帧类型分为I帧/P帧/B帧等。

二,NAL单元数据结构

NALU头前通常包含一个 StartCode，StartCode 必须是 0x00000001 或者 0x000001，紧接着就是一个字节的NALU?header，NALU?header格式如下：

+------------------------------+
????? |0 |1|2 |3|4|5|6|7|
+-++-+-+-+-+-+-+-+-+-+-+
????? |F|NRI|? Type? ? |
+------------------------------+

2.1NALU?header格式下的标志位取值如下：

F（禁止位）: 1 个比特.

禁止位在编码中默认值为0，当网络识别此单元中存在比特错误时，可将其设为1，以便接收方丢掉该单元。主要用于适应不同种类的网络环境（比如有线无线相结合的环境）。例如对于从无线到有线的网关，一边是无线的非IP环境，一边是有线网络的无比特错误的环境。假设一个NAL单元到达无线那边时，校验和检测失败，网关可以选择从NAL流中去掉这个NAL单元，也可以把已知被破坏的NAL单元前传给接收端。在这种情况下，智能的解码器将尝试重构这个NAL单元（已知它可能包含比特错误）。而非智能的解码器将简单地抛弃这个NAL单元。

NRI: 2 个比特.
? nal_ref_idc. 取 00 ~ 11, 指示这个 NALU 的重要性,?用于在重构过程中标记一个NAL单元的重要性，值越大，越重要。值为0表示这个NAL单元没有用于预测，因此可被解码器抛弃而不会有错误扩散；值高于0表示此NAL单元要用于无漂移重构，且值越高，对此NAL单元丢失的影响越大。

TYPE: 5 个比特.

TYPE 5位表示的含义不相同, nalu表示的是slice类型，对于rtp payload代表后面的数据的打包方式。type取值如下:

0	没有定义
1-23	NAL单元 单个 NAL 单元包.
24	STAP-A 单一时间的组合包
25	STAP-B 单一时间的组合包
26	MTAP16 多个时间的组合包
27	MTAP24 多个时间的组合包
28	FU-A 分片的单元
29	FU-B 分片的单元
30-31	没有定义

三.NAL单元的类型

以上类型大概可以分为三类，即?H.264可以有三种RTP打包方式：

• 单个 NAL 单元包：一个RTP包包含一个完整的NALU，荷载中只包含一个 NAL 单元。 NAL 头类型域等于原始 NAL 单元类型, 即在范围 1到 23 之间;?
• 聚合包：对于较小的NALU，一个RTP包可包含多个完整的NALU，本类型用于聚合多个 NAL 单元到单个 RTP 荷载中。有四种版本, 单时间聚合包类型 A(STAP-A) ，单时间聚合包类型 B (STAP-B) ，多时间聚合包类型(MTAP)16 位位移(MTAP16), 多时间聚合包类型(MTAP)24 位位移(MTAP24) 。赋予 STAP-A, STAP-B, MTAP16, MTAP24 的 NAL 单元类型号分别是 24,25, 26, 27;
• 分片单元： 对于较大的NALU，一个NALU可以分为多个RTP包发送，由于单个nal的大小超过了一个rtp传输负载的mtu,所以将其进行分片，用于分片单个 NAL 单元到多个 RTP 包。 现存两个版本 FU-A， FU-B, 用 NAL 单元类型 28，29 标识；

---

四.RTP包的格式

首先要明确，RTP包的格式是绝不会变的，永远都是RTP头+RTP载荷

? ? ? ? ?RTP头

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?RTP载荷

RTP头部是固定的，那么只能在RTP载荷中去添加额外信息来说明这个RTP包是表示同一个NALU

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

===========================================================

五.RTP组合封包模式

5.1单一 NAL 单元模式封包

5.2分片单元（FU-A、FU-B）

5.2.1FU-A封包

第一个字节位FU Indicator，其格式如下

高三位：与NALU第一个字节的高三位相同

F（禁止位）: 1 个比特位，

NRI: 2 个比特位，

Type：28，表示该RTP包一个分片，为什么是28？因为H.264的规范中定义的，此外还有许多其他Type，这里不详讲.

======================================================

第二个字节位FU Header，其格式如下

S: 1 bit
当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0，?标记该分片打包的第一个RTP包。
E: 1 bit
当设置成1, 结束位指示分片NAL单元的结束，即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的FU荷载不是分片NAL单元的最后分片,结束位设置为0，比较该分片打包的最后一个RTP包。
R: 1 bit
保留位必须设置为0，接收者必须忽略该位。

Type：5bit

NALU的Type，表示组合方式。

5.2.2FU-B封包

数据流分析：

// 数据流
80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kI      
e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.
cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?
f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??
cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????
    
其中，
80               是V_P_X_CC
e0               是M_PT
00 1e          	 是SequenceNum
00 00 d2 f0 	 是Timestamp
00 00 00 00		 是SSRC
    
换成二进制：
0X80 = 1000 0000 
     = 10|0|0|0000
        v|p|x|cc 
    
0Xe0 = 1110 0000  
     = |1|1100000
       |m|pt

六.RTP结构体和总图概要

RTP头的结构体

struct RtpHeader
{
    /* byte 0 */
    uint8_t csrcLen : 4;//CSRC计数器，占4位，指示CSRC 标识符的个数。
    uint8_t extension : 1;//占1位，如果X=1，则在RTP报头后跟有一个扩展报头。
    uint8_t padding : 1;//填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
    uint8_t version : 2;//RTP协议的版本号，占2位，当前协议版本号为2。
    /* byte 1 */
    uint8_t payloadType : 7;//有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。
    uint8_t marker : 1;//标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
    /* bytes 2,3 */
    uint16_t seq;//占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。
    /* bytes 4-7 */
    uint32_t timestamp;//占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
    /* bytes 8-11 */
uint32_t ssrc;//占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
客户端发起rstp拉流请求请流，服务端推流随机生产ssrc。
   /*标准的RTP Header 还可能存在 0-15个特约信源(CSRC)标识符  
   每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源*/
};

RTP包的结构体

struct RtpPacket
{
??? struct RtpHeader rtpHeader;
??? uint8_t payload[0];
};

H264结构和RTP打包总图概要