2011-10-20 10:26:18| 分类: RTP|字号 订阅
H.264 视频 RTP 负载格式
1. 网络抽象层单元类型 (NALU)
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 解码器可以丢弃它而不影响图像的回放. 不过一般情况下不太关心
这个属性.
Type: 5 个比特.
nal_unit_type. 这个 NALU 单元的类型. 简述如下:
0 没有定义
1-23 NAL单元 单个 NAL 单元包.
24 STAP-A 单一时间的组合包
25 STAP-B 单一时间的组合包
26 MTAP16 多个时间的组合包
27 MTAP24 多个时间的组合包
28 FU-A 分片的单元
29 FU-B 分片的单元
30-31 没有定义
2. 打包模式
下面是 RFC 3550 中规定的 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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
负载类型 Payload type (PT): 7 bits
序列号 Sequence number (SN): 16 bits
时间戳 Timestamp: 32 bits
H.264 Payload 格式定义了三种不同的基本的负载(Payload)结构. 接收端可能通过 RTP Payload
的第一个字节来识别它们. 这一个字节类似 NALU 头的格式, 而这个头结构的 NAL 单元类型字段
则指出了代表的是哪一种结构,
这个字节的结构如下, 可以看出它和 H.264 的 NALU 头结构是一样的.
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
字段 Type: 这个 RTP payload 中 NAL 单元的类型. 这个字段和 H.264 中类型字段的区别是, 当 type
的值为 24 ~ 31 表示这是一个特别格式的 NAL 单元, 而 H.264 中, 只取 1~23 是有效的值.
24 STAP-A 单一时间的组合包
25 STAP-B 单一时间的组合包
26 MTAP16 多个时间的组合包
27 MTAP24 多个时间的组合包
28 FU-A 分片的单元
29 FU-B 分片的单元
30-31 没有定义
可能的结构类型分别有:
1. 单一 NAL 单元模式
即一个 RTP 包仅由一个完整的 NALU 组成. 这种情况下 RTP NAL 头类型字段和原始的 H.264的
NALU 头类型字段是一样的.
2. 组合封包模式
即可能是由多个 NAL 单元组成一个 RTP 包. 分别有4种组合方式: STAP-A, STAP-B, MTAP16, MTAP24.
那么这里的类型值分别是 24, 25, 26 以及 27.
3. 分片封包模式
用于把一个 NALU 单元封装成多个 RTP 包. 存在两种类型 FU-A 和 FU-B. 类型值分别是 28 和 29.
2.1 单一 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 个字节的开始码就可以了.
2.2 组合封包模式
其次, 当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3 Fragmentation Units (FUs).
而当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为 Fragmentation Units (FUs).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. RTP payload format for FU-A
The FU indicator octet has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
The FU header has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
3. SDP 参数
下面描述了如何在 SDP 中表示一个 H.264 流:
. "m=" 行中的媒体名必须是 "video"
. "a=rtpmap" 行中的编码名称必须是 "H264".
. "a=rtpmap" 行中的时钟频率必须是 90000.
. 其他参数都包括在 "a=fmtp" 行中.
如:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
下面介绍一些常用的参数.
3.1 packetization-mode:
表示支持的封包模式.
当 packetization-mode 的值为 0 时或不存在时, 必须使用单一 NALU 单元模式.
当 packetization-mode 的值为 1 时必须使用非交错(non-interleaved)封包模式.
当 packetization-mode 的值为 2 时必须使用交错(interleaved)封包模式.
这个参数不可以取其他的值.
3.2 sprop-parameter-sets:
这个参数可以用于传输 H.264 的序列参数集和图像参数 NAL 单元. 这个参数的值采用 Base64 进行编码. 不同的参数集间用","号隔开.
3.3 profile-level-id:
这个参数用于指示 H.264 流的 profile 类型和级别. 由 Base16(十六进制) 表示的 3 个字节. 第一个字节表示 H.264 的 Profile 类型, 第
三个字节表示 H.264 的 Profile 级别:
3.4 max-mbps:
这个参数的值是一个整型, 指出了每一秒最大的宏块处理速度.
完整的C/S架构的基于RTP/RTCP的H.264视频传输方案。此方案中,在服务器端和客户端分别进行了功能模块设计 。服务器端 :RTP封装模块主要是对H.264码流进行打包封装;RTCP分析模块负责产牛和发送RTCP包并分析接收到的RTCP包;QoS反馈控制模块则根据RR报文反馈信息动态的对发送速率进行调整;发送缓冲模块则设置端口发送RTP、RTCP包。客户端 :RTP模块对接收到的RTP包进行解析判断;RTCP模块根据SR报文统计关键信息,产牛并发送RR包。然后,在VC++6.0下用Socket编程,完成基于RTP/UDP/IP的H.264视频传输,并在局域网内运行较好。
基于RTP/UDP/lP的H.264视频传输结构设计
对于H.264视频的实时传输应用来说,TCP的重传机制引入的时延和抖动是无法容忍的,因此我们采用UDP传输协议。但是UDP协议本身是面向无连接的,不能提供质量保证。而基于UDP之上的高层协议RTP/RTCP可以一起提供流量控制和拥塞控制 服务。图给出了基于RTP/UDP/IP的H.264视频传输的框架。
H.264视频流的RTP封装策略
从图4—1可以看出,H.264视频数据首先经RTP进行封装 ,打包成适合网络传输的数据包才能进行传输。所以,如何设计合适的RTP封装策略对H.264视频数据进行封装是十分重要的。一般来说,在H.264中,RTP封装应该遵循几个设计原则:
1、较低的开销,因此MTU的尺寸应该限制在100—64K字节范围内。
2、易于区分分组的重要性,而不必对分组内的数据解码。
3、应能检测到数据的类型,而不需解码整个数据流,并能根据编码流之间的相关性丢弃无用数据,如网关应能检测A型分割的丢失,并能丢弃相应的B型和C型分割。
4、应支持将一个NALU拆分为若干个RTP包:不同大小的输入图片决定了NALU的长度可能会大于MTU,只有拆分后才会避免IP层在传输时出现分片。
5、支持将多个NALU汇集在一个RTP分组中,即在一个RTP包中传输超过一个NALU,当多个图片的编码输出小于M1IU时就考虑此模式,以提高网络传输效率。
RTP载荷封装设计
本文的网络传输是基于IP协议,所以最大传输单元(MTU )最大为1500字节,在使用IP/UDP/RTP的协议层次结构的时候,这其中包括至少20字节的IP头 ,8字节的UDP头 ,以及12字节的RTP头 。这样,头信息至少要占用40个字节,那么RTP载荷的最大尺寸为1460字节。
一方面,如果每个IP分组都填满1500字节,那么协议头的开销为2.7%,如果RTP载荷的长度为730字节,协议头的开销仍达到5.3%,而假设 RTP载荷的长度不到40字节,那么将有50%的开销用于头部,这将对网络造成严重资源浪费。另一方面,如果将要封装进RTP载荷的数据大于1460字 节,并且我们没有在应用层数据装载迸RTP包之前进行载荷分割 ,将会产生大于MTU的包。在IP层其将会被分割成几个小于MTU尺寸的包 , 这样将会无法检测数据是否丢失。因为IP和UDP协议都没有提供分组到达的检测,如果分割后第一个包成功接收而后续的包丢失,由于只有第一个包中包含有完 整的RTP头信息,而RTP头中没有关于载荷长度的标识,因此判断不出该RTP包是否有分割丢失,只能认为完整的接收了。并且在IP层的分割无法在应用层 实现保护从而降低了非平等包含方案的效果。由于UDP数据分组小于64K字节,而且一个片的长度对某些应用场合来说有点太小,所以应用层的打包 也是RTP打包机制的一个必要部分。最新的RFC3984标准中提供了针对H.246媒体流的RTP负载格式,主要有三种:
单个NAL单元分组、聚合分组、片分组。
NAL单元单一打包
将一个NAL单元封装进一个包中,也就是说RTP负载中只包含一个NAL单元,NAL头部兼作RTP头部。RTP头部类型即NAL单元类型1-23,如下图所示:
NAL单元的重组
此分组类型用于将多个NAL单元聚合在一个RTP分组 中。一些H.264的NAL单元的大小,如SEI NAL单元 、参数集等都非常小,有些只有几个字节,因此应该把它们组合到一个RTP包中,将会有利于减小头标(RTP/UDP/IP)的开销。目前存在着两种类型聚合分组:
NAL单元的分割
将一个NAL单元分割,使用多个RTP分组 进行传输。共有两个类型FU—A和FU—B,单元类型中分别为28和29。根据IP层MTU的大小,对大尺寸的NALU必须要进行分割,可以在分别在两个层次上进行分割:
1)视频编码层VCL上的分割
为了适应网络MTU的尺寸,可以使用编码器来选择编码Slice NALU 的大小,从而使其提供较好的性能。一般是对编码Slice的大小进行调整,使其小于1460字节 ,以免IP层的分割。
2)网络提取层NAL上的分割
在网络提取层上对NALU的分割主要是采用分片单元方案 ,H.264标准中提出了分割机制,可以使NAL单元的尺寸小于1460字节。注意:此方式是针对同一个NAL单元进行分割的 ,不适用于聚合分组。一个NAL单元采用分割分组后,每个RTP分组序列号依次递增l,RTP时间戳相同且惟一 。NAL单元的分割是RTP打包机制的一个重要环节,总结其分割机制主要有如下几个特点:
①分割NALU时,是以RTP次序号升序进行 传输。在序列号不循环的前提下,属于前一帧图像的所有图像片包以及A/B/C数据分割包的序列号要小于后帧图像中的图像片及数据分割包的序列号。
②一个符号机制来标记一个分割的NALU是第一个还是最后一个NAL单元。
3.存在另外一个符号机制用来检测是否有丢失的分块。
④辅助增强信息包和头信息包可以任意时间发送。
⑤同一帧图像中的图像片可以以任意顺序发送,但是对于低时延要求的网络系统,最好是以他们原始的编码顺序来发送。
1)单一时间聚合分组 (STAP):包括单一时间聚合分组A(STAP—A)和单一时间聚合分组B(STAP—B),按时间戳进行组合,他们的NAL单元具有相同的时间戳,一般用于低延迟环境。STAP—ASTAP—B的单元类型分别为24和25。
2)多时间聚合分组 (MTAP):包括16比特偏移多时间聚合分组(MTAPl6)和24比特偏移多时间聚合分组 (MTAP24)不同时间戳也可以组合,一般用于高延迟的网络环境,比如流媒体应用.它的打包方案相对复杂,但是大大增强了基于流媒体的H.264的性 能。MTAPl6 MTAP24的单元类型分别为26和27。
RTP包的封装流程设计
根据H.264NAL单元的分割重组的性质以及RTP打包规则,本文实行的对RTP打包的设计 如下:
1、若接收到的NAL单元小于MAX—SIZE(此时MAX-sIZE为设定的最大传输单元 ),则对它进行单一打包,也就是将此NAL单元直接放进RTP包的载荷部分,生成一个RTP包。
2、若接收到的NAL单元大于MAx—SIZE字节,则对它进行分割,然后对分割后的NAL单元进行步骤1方式打包。分割方案如下:
其中Nsize是分割前的NAL单元大小 ,N是分割后NAL单元的大小 。K分割后的单元数 。分割后最后一个单元的大小可能会小于N,这时必须使用RTP载荷填充 是其同前面的分块大小相同,此时RTP头中的填充标识位值为 1。
3、对SEI,参数集等小NAL单元重组,将它们合并到一个RTP 包中。虽然步骤3中的重组方案可以减小IP/UDP/RTP头部开销,但是对于包丢失率比较高的网络环境,这意味着一个RTP包的丢失可能会导致多片的丢失,往往一个片中就有一个P图像,解码后的视频质量必然会严重下降。因此,在丢失率的网络中可以采用NAL单元的重组方案 ,而在高丢失率的网络环境中采用NAL单元重组时要进行有效的差错控制.在本文中不使用重组方案。
RTP/RTCP包的封装实现
RTP包封装设计
RTcP包的封装设计
RTCP报文封装在UDP数据报 中进行传输,发送时使用比它所属的RTP流的端口号大1 的协议号(RTP使用偶数号,RTCP使用奇数号)。以下是RTCP头部数据结构: