RTP打包总结

RTP协议头格式：
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|V=2|P|X| CC |M| PT | sequence number |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| timestamp |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| … |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
上图引自rfc3550，由上图中可知道RTP报文由两个部分构成–RTP报头和RTP的负载：
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 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| defined by profile | length |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| header extension |
| … |

一般情况下：扩展标志x=0,故其头长度为12个字节，因此第一个字节常为0x80。
第二个字节，如果为视频，PT常为96（0x60),如是开始帧，此值为0xe0,否则为0x60.
在RTP基于TCP传输中：
包格式为：RTP标志+RTP头+RTP负载数据
在RTP基于UDP传输中，无RTP标志。
其中：RTP标志位（4个字节）：$+channel id(1 byte)+长度（2字节）
此长度不包含本身这4个字节。
如下图1：是一个SPS,其长度为16， 16+12=28=0x1c , RTP头的第一字节为0x80，第2个字节为0xe0

图1

图2
0x05b0=1456=1500-20-20-4
RTP包最大长度： 　
ＴＣＰ：１５００－20(ip头）-20（tcp头）-4（RTP标志）=1456
UDP: 1500-20(ip头）-8(udp头）=1472

对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个 NALU 单元的开始, 必须是 “00 00 00 01” 或 “00 00 01”, NALU 头仅一个字节, 其后都是 NALU 单元内容.
打包时去除 “00 00 01” 或 “00 00 00 01” 的开始码, 把其他数据封包的 RTP 包即可.
H264的RTP中有三种不同的基本负载（Single NAL,Non-interleaved,Interleaved)
通常在SDP 参数中指定。
如:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
常用的参数：

1. packetization-mode: 表示支持的封包模式.
   当 packetization-mode 的值为 0 时或不存在时, 必须使用单一 NALU 单元模式.
   当 packetization-mode 的值为 1 时必须使用非交错(non-interleaved)封包模式.
   当 packetization-mode 的值为 2 时必须使用交错(interleaved)封包模式.
   每个打包方式允许的NAL单元类型总结(yes = 允许, no = 不允许, ig = 忽略)
   Type Packet Single NAL Non-Interleaved Interleaved
   Unit Mode Mode Mode
   0 undefined ig ig ig
   1-23 NAL unit yes yes no
   24 STAP-A no yes no
   25 STAP-B no no yes
   26 MTAP16 no no yes
   27 MTAP24 no no yes
   28 FU-A no yes yes
   29 FU-B no no yes
   30-31 undefined ig ig ig

2. sprop-parameter-sets: SPS,PPS
   这个参数可以用于传输 H.264 的序列参数集和图像参数 NAL 单元. 这个参数的值采用 Base64 进行编码. 不同的参数集间用","号隔开。

3. profile-level-id:
   这个参数用于指示 H.264 流的 profile 类型和级别. 由 Base16(十六进制) 表示的 3 个字节. 第一个字节表示 H.264 的 Profile 类型, 第三个字节表示 H.264 的 Profile 级别

Rtp payload的第一个字节 fu indicator和264的NALU类似
±--------------+
|0|1|2|3|4|5|6|7|
±±±±±±±±+
|F|NRI| Type |
±--------------+

F: 1 个比特.
forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.
NRI: 2 个比特.
nal_ref_idc. 取 00 ~ 11, 似乎指示这个 NALU 的重要性, 如 00 的 NALU 解码器可以丢弃它而不影响图像的回放. I帧应设置成11.

Type: 5 个比特.
nal_unit_type. 这个 NALU 单元的类型. 简述如下:
0 没有定义
1-23 NAL单元 单个 NAL 单元包.
24 STAP-A 单一时间的组合包
24 STAP-B 单一时间的组合包
26 MTAP16 多个时间的组合包
27 MTAP24 多个时间的组合包
28 FU-A 分片的单元
29 FU-B 分片的单元
30-31 没有定义

#ifdef BIG_ENDIAN
struct _nalu 
{
uint8_t Type : 5;
uint8_t NRI : 2;
uint8_t F : 1;
};
#else
struct _nalu 
{
uint8_t F : 1;
uint8_t NRI : 2;
uint8_t Type : 5;
};

#endif

Rtp payload的第二个字节 fuHead
±--------------+
0|1|2|3|4|5|6|7|
±±±±±±±±±+
|S|E|R| Type |
±--------------+
S:开始标志
E:结束标志 (与 Mark相同）
R:必须为0
Type:h264的NALU Type
例：使用FU-A分片，type=28
0x7C85=01111100 10000101 (开始包)
0x7C05=01111100 00000101 (中间包)
0x7C45=01111100 01000101 (结束包)

#ifdef BIG_ENDIAN
struct _fuHeader
{
uint8_t Type : 5;
uint8_t R : 1;
uint8_t E : 1;
uint8_t S : 1;
};
#else
struct _fuHeader
{
uint8_t S : 1;
uint8_t E : 1;
uint8_t R : 1;
uint8_t Type : 5;
};
#endif

易搞混的几个TYPE：
• RTP 中的PT 负载类型 Payload type (PT) : 7 bits －－发送H264视频，此值固定设成 96
• NALU 中的TYPE 描述了NALU的属性，如：7指示顺序参数集，8指示图像参数集
• RTP之后的TYPE，即13 BYTE开始，单一打包的TYPE，与NALU中的TYPE一样；FU 分片打包方式，TYPE设成28,即分片模式；

封包介绍：
 单一NAL单元模式
对于 NALU 的长度小于 MTU 大小的包, 一般采用单一 NAL 单元模式.
对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个
NALU 单元的开始, 必须是 “00 00 00 01” 或 “00 00 01”, NALU 头仅一个字节, 其后都是 NALU 单元内容.
打包时去除 “00 00 01” 或 “00 00 00 01” 的开始码, 把其他数据封包的 RTP 包即可.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1 2 3 4 5 6 7
±±±±±±±±±±±±±±±-±±±±±±±±±±±±±±±+
|F|NRI| type | |
±±±±±±±±+ |
| Bytes 2…n of a Single NAL unit |
| ±±±±±±±±±±±±±±±±+ | :…OPTIONAL RTP padding |
±±±±±±±±±±±±±±±±±±-±±±±±±±±±±±±+
例：
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F … ]
这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.
封装成 RTP 包将如下:
[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]
即只要去掉 4 个字节的开始码就可以了.
 组合封包模式
其次, 当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1 2 3 4 5 6 7
±±+±±±±±±±±±±±±±±±±±±±±±±+
| RTP Header |
±±±±±±±±±±±±±±±±±±±±±±±±-+
|STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR
±±±±±±±±±±+±±±±±±±±±±±±±±+
| NALU 1 Data |
±±±±±±±±±±±±±±±±±±±±±±±±+
| | NALU 2 Size | NALU 2 HDR |
±±±±±±±±±±±±±+±±±±±±±±±±±+
| NALU 2 Data |
| ±±±±±±±±±±±±±±±±+
| :…OPTIONAL RTP padding |
±±±±±±±±±±±±±±±±±±±±±±±±±±+
这里只介绍STAP-A模式，如果是STAP-B的话会多加入一个DON域，
例：
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F … ]

[00 00 00 01 68 42 B0 12 58 6A D4 FF … ]
封装成 RTP 包将如下:
[ RTP Header ] [78 (STAP-A头，占用1个字节)] [第一个NALU长度 (占用两个字节)] [ 67 42 A0 1E 23 56 0E 2F ] [第二个NALU长度 (占用两个字节)] [68 42 B0 12 58 6A D4 FF … ]
 分片的单元：
当NALU的长度超过MTU时,就必须对NALU单元进行分片封包.也称为Fragmentation Units(FUs).

   0               1             2                   3
   0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7  0 1 2 3 4 5 6 7  0 1 2 3 4 5 6 7 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-———+
  | FU indicator  |   FU header   |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             |
  |                                                               
  |                        FU payload                           |
  |                                                                     |                    
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure 14.  RTP payload format for FU-A

通过wireshark抓包分析：
ip 过滤设置： ip.src=x.x.x.x