H264关于RTP协议的实现

完整的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头部数据结构：

(ilovejoy)