H264关于RTP协议的实现

1、H264 关于 RTP 协议的实现2010-07-22 13:35完整的C/S架构的基于RTP/ RTCP的H . 264视频传输方案。此方案 中，在服务器端和客户端分别进行了 功能模块设计 。服务器端 ：RTP 封装模块主 要是对 H264 码流进行打包封装； RTCP 分析模块负责产牛和发送 RTCP 包并 分析接收到的RTCP包;QoS反馈控制模块则根据RR报文反馈信息动态的对发 送速率进行调整；发送缓冲模块则设置端口发送 RTP、RTCP 包。 客户端 ：RTP 模块对接收到的RTP包进行解析判断；RTCP模块根据SR报文统计关键信息， 产牛并发送RR包。然后，在VC+6 . 0下用S

2、ocket编程，完成基于RTP/ UDP/IP 的 H264 视频传输，并在局域网内运行较好。基于 RTP/ UDP /lP 的 H264 视频传输结构设计对于 H264 视频的实时传输应用来说， TCP 的重传机制引入的时延和抖 动是无法容忍的， 因此我们采用 UDP 传输协议。 但是 UDP 协议本身是面向无连 接的，不能提供质量保证。而基于 UDP之上的高层协议RTP/RTCP可以一起 提供流量控制和拥塞控制服务。图给出了基于RTP/UDP/IP的H . 264视频 传输的框架。图4T基于RTP/UDP/1P的出264衩频（专输框图H. 264视频流的RTP封装策略从图4 1可以看出，H

3、 . 264视频数据首先经RTP进行封装，打包成适合网络传输的数据包才能进行传输。所以，如何设计合适的 RTP封装策略对H . 264视频数据进行封装是十分重要的。 一般来说，在H .264中，RTP封装应该遵循几个设计原则：I、较低的开销，因此 MTU的尺寸应该限制在100 64K字节范围内。2、易于区分分组的重要性，而不必对分组内的数据解码。3、应能检测到数据的类型，而不需解码整个数据流，并能根据编码流之间的相关性丢弃无用数据，如网关应能检测 A型分割的丢失，并能丢弃相应的B型和C型分割。4、应支持将一个NALU拆分为若干个RTP包：不同大小的输入图片决定了 NALU的 长度可能会大于MT

4、U，只有拆分后才会避免IP层在传输时出现分片。5、支持将多个NALU汇集在一个RTP分组中，即在一个RTP包中传输超过一个 NALU , 当多个图片的编码输出小于 M1IU时就考虑此模式，以提高网络传输效率。RTP载荷封装设计本文的网络传输是基于IP协议，所以最大传输单元（MTU）最大为1500字节，在使用IP/UDP/ RTP的协议层次结构的时候， 这其中包括至少20字节的IP头，8字节 的UDP头，以及12字节的RTP头。这样，头信息至少要占用 40个字节，那么RTP 载荷的最大尺寸为1460字节。TP报头UDP报头RTP报头有效载荷（20字节）（8字节）（12字节）表4-2网络传输中26

5、4的封装格式一方面，如果每个IP分组都填满1500字节，那么协议头的开销为 2 . 7 %，如 果RTP载荷的长度为730字节，协议头的开销仍达到 5 . 3 %，而假设 RTP载荷的长 度不到40字节，那么将有50 %的开销用于头部，这将对网络造成严重资源浪费。另 一方面，如果将要封装进 RTP载荷的数据大于1460字节，并且我们没有在应用层数 据装载迸RTP包之前进行载荷分割，将会产生大于MTU的包。在IP层其将会被分割 成几个小于MTU尺寸的包，这样将会无法检测数据是否丢失。因为IP和UDP协议都没有提供分组到达的检测，如果分割后第一个包成功接收而后续的包丢失，由于只有第一个包中包含有完

6、 整的RTP头信息，而RTP头中没有关于载荷长度的标识，因此判断不出该RTP包是否有分割丢失，只能认为完整的接收了。并且在IP层的分割无法在应用层 实现保护从而降低了非平等包含方案的效果。由于UDP数据分组小于64K字节，而且一个片的长度对某些应用场合来说有点太小，所以应用层的打包 也是RTP打包机制的一个必要部分。最新的 RFC3984标准中提供了针对 H . 246媒体流的RTP负载 格式，主要有三种：单个NAL单元分组、聚合分组、片分组。NAL单元单一打包将一个NAL单元封装进一个包中，也就是说 RTP负载中只包含一个 NAL单元，NAL 头部兼作RTP头部。RTP头部类型即NAL单元类

7、型1-23，如下图所示：NAL单元类 型NAL单元类型名称0未使用1 1不分区，非IDR图橡的片2A型分割3B型分割4(:型分割5IDR图像中的片6增强信息SEI7序列参数集8图像参数集9分界符10序列结束11码流结束12申充13-23保留24单一時间聚合分组STAP-A25单时间聚合分组STAP-B26多时间聚合分纽WTAP1627多时间聚合分组MTAP2428片分组方式FU-A29片分组方武FtFB30-31为定义|表4-3 NAL单元类型及苴名称NAL单元的重组此分组类型用于将多个NAL单元聚合在一个RTP分组中。一些H . 264的NAL单元的大小，如SEI NAL单元、参数集等都非常

8、小，有些只有几个字节，因此应该把它们组合到一个 RTP包中，将会有利于减小头标(RTP/UDP/IP)的开销。 目前存在着两种类型聚合分组：NAL 单元的分割将一个NAL单元分割，使用 多个RTP分组进行传输。共有两个类型FUA和 FUB,单元类型中分别为28和29。根据IP层MTU的大小，对大尺寸的NALU 必须要进行分割，可以在分别在两个层次上进行分割：1) 视频编码层 VCL 上的分割为了适应网络 MTU 的尺寸，可以使用编码器来选择 编码 Slice NALU 的大小， 从而使其提供较好的性能。 一般是对编码 Slice 的大小进行调整， 使其小于 1460 字节，以免 IP 层的分割

9、。2) 网络提取层 NAL 上的分割在网络提取层上对 NALU 的分割主要是采用 分片单元方案 ， H264 标准中提出 了分割机制，可以使 NAL 单元的尺寸小于 1460 字节。注意：此方式是针对 同 一个NAL单元进行分割的，不适用于聚合分组。一个NAL单元采用分割分组后， 每个RTP分组序列号依次递增I， RTP时间戳相同且惟一 。NAL单元的分割是 RTP 打包机制的一个重要环节，总结其分割机制主要有如下几个特点： 分割NALU时，是以RTP次序号升序进行传输。在序列号不循环的前提下， 属于前一帧图像的所有图像片包以及 A/B/C 数据分割包的序列号要小于后帧 图像中的图像片及数据分

10、割包的序列号。 一个符号机制来标记一个分割的 NALU 是第一个还是最后一个 NAL 单元。 3.存在另外一个符号机制用来检测是否有丢失的分块。辅助增强信息包和头信息包可以任意时间发送。同一帧图像中的图像片可以以任意顺序发送， 但是对于低时延要求的网络系统， 最好是以他们原始的编码顺序来发送。1) 单一时间聚合分组(STAP):包括单一时间聚合分组 A(STAPA)和单一时间聚合分组B(STAP B),按时间戳进行组合，他们的 NAL单元具有相同的时间戳，一般用于低延迟环境。STAPASTAP B的单元类型分别为24和25。2) 多时间聚合分组(MTAP):包括16比特偏移多时间聚合分组(MT

11、AP16)和24比特偏移多时间聚合分组 (MTAP24) 不同时间戳也可以组合，一般用于高延迟 的网络环境， 比如流媒体应用 它的打包方案相对复杂， 但是大大增强了基于流 媒体的 H264 的性 能。 MTAPl6 MTAP24 的单元类型分别为 26 和 27。RTP包的封装流程设计根据H . 264NAL单元的分割重组的性质以及 RTP打包规则，本文实行的对RTP 打包的设计 如下:1、若接收到的NAL单元小于MAX SIZE(此时MAX-sIZE为设定的最大传输单元)，则对它进行单一打包，也就是将此NAL单元直接放进RTP包的载荷部分， 生成一个 RTP 包。2、若接收到的NAL单元大于

12、MAx SIZE字节，则对它进行分割，然后对分割后的 NAL 单元进行步骤 1 方式打包。分割方案如下:If (MMAXSI2E)0)K=( N* / MAX.SIZE)+1elseK= N>( / MAX3IZEif (NLim %KX»N= Ng %K+1elseN= JU /K其中Nsize是分割前的NAL单元大小，N是分割后NAL单元的大小。K分割后 的单元数。分割后最后一个单元的大小可能会小于 N，这时必须使用RTP载荷 填充是其同前面的分块大小相同，此时 RTP头中的填充标识位值为1。3、对SEI，参数集等小NAL单元重组，将它们合并到一个RTP包中。虽然步骤3中的

13、重组方案可以减小IP/UDP/RTP头部开销，但是对于包丢失率比较高的 网络环境，这意味着一个RTP包的丢失可能会导致多片的丢失，往往一个片中 就有一个P图像，解码后的视频质量必然会严重下降。 因此，在丢失率的网络中 可以采用NAL单元的重组方案，而在高丢失率的网络环境中采用 NAL单元重组 时要进行有效的差错控制在本文中不使用重组方案。RTP/ RTCP包的封装实现RTP包封装设计将K264码流进行RTP数据封装.下面是H. 2“中的UTP包头的数据结构Typed色f structunsigned int y； unsigned int p； unsigned int 和 unsigned

14、int cc； unsigned int unsigned int pt： unsigned intunsigned int tinpestfunpi unsigned int ssrc： byte* payload： unsigned int py byt&+ packet； unsigned int packlen： KTPPacketsRTcP包的封装设计/版本号 2比特.值为0X2/填充标识1比特值为0/扩充标识.1比特，值为。/ CSRC计数.4比特，值为0/标识位.1比符/标识负戟类型7个比轄/ RTP序列号个比特/时间II32个比特/同步源标识符.32个比持/载荷类型 毂

15、荷的长度NALL Length/把头部和較荷打包/包的长度RTCP报文封装在UDP数据报中进行传输，发送时使用比它所属的 RTP流的端口号大1的协议号（RTP使用偶数号，RTCP使用奇数号）。以下是RTCP 头部数据结构：(unsigned int vjunsigned int p：unsigned int rc；unsigned int pt$unsigned int length； RTCP_Header：Typedef struct/发送竭报吿类堂为200/接收瑞报吿类型为20】/源墻描述报文类型为202/给束报文类型为203/应用程序特定报文类型为204/版本号.2比特，儼为0X2 /

16、填充标识，1比特，值为0 /援收报吿计数.5比符/ RTCP包的类型.8比特/包的长度RTCPttf用5个慕本报文类型允许发送端和搖收端交換有关会话估息.Typedef enuaRTCP SR-200sRTCP_RR=201：RTCP_SDES 二202$RTCP BYE=203sRTCP_APP=204：1 RTCP_TypeRTCP接收者报文RR的封装数据结构:Typedef structunsignedintssrc：unsignedintLostPacket；unsignedinxLostRate；unsignedintMiixSeq?unsignedintJ i tter：unsignedintLsrt/同步源标识符/丢包数/丢包率/凰大序列号/到达间隔抖动/最后到达的SR的时间戳unsigned int DIsttiRTCPReceiver；RTCPSiSffliSH的封慕数据结构:Typedef structIunsigned ini TiveStawpunsigned ini Packet