基于rtp的h264流媒体的传输机制和实现

 1、适用于 H.264 视频的传输机制 
       前面分别讨论了RTP 协议及H.264基本流的结构，那么如何使用RTP协议来传输H.264视频了?一个有效的办法就是从H.264视频中剥离出每个NALU，在每个NALU前添加相应的RTP包头，然后将包含RTP 包头和NALU 的数据包发送出去。下面就从RTP包头和NALU两方面分别阐述。 
      完整的 RTP 固定包头的格式在前面图 1 中已经指出，根据RFC3984[3]，这里详细给出各个位的具体设置。 
      V：版本号，2 位。根据RFC3984，目前使用的RTP 版本号应设为0x10。 
      P：填充位，1 位。当前不使用特殊的加密算法，因此该位设为 0。 
      X：扩展位，1 位。当前固定头后面不跟随头扩展，因此该位也为 0。 
      CC：CSRC 计数，4 位。表示跟在 RTP 固定包头后面CSRC 的数目，对于本文所要实现的基本的流媒体服务器来说，没有用到混合器，该位也设为 0x0。 
       M：标示位，1 位。如果当前 NALU为一个接入单元最后的那个NALU，那么将M位置 1；或者当前RTP 数据包为一个NALU 的最后的那个分片时（NALU 的分片在后面讲述），M位置 1。其余情况下M 位保持为 0。 
       PT：载荷类型，7 位。对于H.264 视频格式，当前并没有规定一个默认的PT 值。因此选用大于 95 的值可以。此处设为0x60（十进制96）。 
      SQ：序号，16 位。序号的起始值为随机值，此处设为 0，每发送一个RTP 数据包，序号值加 1。 
      TS：时间戳，32 位。同序号一样，时间戳的起始值也为随机值，此处设为0。根据RFC3984， 与时间戳相应的时钟频率必须为90000HZ。 
      SSRC：同步源标示，32 位。SSRC应该被随机生成，以使在同一个RTP会话期中没有任何两个同步源具有相同的SSRC 识别符。此处仅有一个同步源，因此将其设为0x12345678。
      对于每一个NALU，根据其包含的数据量的不同，其大小也有差异。在IP网络中，当要传输的IP 报文大小超过最大传输单元MTU（Maximum Transmission Unit ）时就会产生IP分片情况。在以太网环境中可传输的最大 IP 报文（MTU）的大小为 1500 字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP 包大于MTU 而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU 的NALU 单元，必须进行拆包处理。

RFC3984 给出了3 中不同的RTP 打包方案：

（1）Single NALU Packet:在一个RTP 包中只封装一个NALU，在本文中对于小于 1400字节的NALU 便采用这种打包方案。 
       （2）Aggregation Packet:在一个RTP 包中封装多个NALU，对于较小的NALU 可以采用这种打包方案，从而提高传输效率。 
       （3）Fragmentation Unit:一个NALU 封装在多个RTP包中，在本文中，对于大于1400字节的NALU 便采用这种方案进行拆包处理。

2、H.264 流媒体传输系统的实现

 一个完整的流媒体传输系统包含服务器端和客户端两个部分[5][6]。对于服务器端，其主要任务是读取H.264 视频，从码流中分离出每个NALU 单元，分析NALU 的类型，设置相应的 RTP 包头，封装 RTP 数据包并发送。而对于客户端来说，其主要任务则是接收 RTP数据包，从RTP 包中解析出NALU 单元，然后送至解码器进行解码播放。该流媒体传输系统的框架如图3 所示。