使用RTP传输H.264格式视频

一、H.264码流

H.264功能分为两层:视屏编码层(VCL)和网络提取层(NAL)

VCL:被压缩编码的视频数据序列

NAL:VCL需要封装到NAL单元中进行传输存储

NAL单元分析

Nal头 RBSP Nal头 RBSP

几个概念:

  • SODB:数据比特串–>最原始的编码数据

  • RBSP:原始字节序列载荷–>在SODB后面添加结尾比特(一比特1和若干比特0)字节对齐

  • EBSP:扩展字节序列载荷–>在RBSP基础上加入仿校验字节(0x03)

原因:在NALU加到Annexb上时,需要在NALU之前添加开始码。如果该NALU对于的slice为一帧的开始则用4位字节0x00000001表示,否则用3位字节0x000001。为了确保NALU主体中不包括与开始码相冲突,在编码时没遇到连续两字节的0就添加一个字节的0x03。解码时在去掉该字节脱壳。

一个NAL单元由:1字节的HAL头即3个定长的字段、1个字节数不定的编码段组成

NAL头:(5bit)NALU类型、(2bit)重要性指示、(1bit)禁止位

NALU类型:1~12由H.264使用,24~31由H.264以外的应用使用。

重要性指示:标志该NAL单元用于重建时的重要性,值越大,越重要。

禁止位:网络发现NAL单元有比特错误时可设置该比特为1,以便接收方丢掉该单元

使用RTP传输H.264格式视频_第1张图片

NAL类型介绍:

(1)参数集:以往视频编解码标准中GOB\GOP\图像等头信息是至关重要的,包含这些信息的包的丢失常导致与这些信息相关的图像不能解码。为此H.264将这些很少变化并且对大量VCL NALU起作用的信息放在参数集中传送。参数集分为两种,即序列参数集和图像参数集。为适应多种网络环境,参数集可以带内传送,也可以采用带外方式传送。

  • SPS :序列的参数集(SPS):包括了一个图像序列的所有信息

  • PPS :图像的参数集(PPS):包括了一个图像所有片的信息。

二、RTP/RTCP协议

RTP 协议是在 1996 年提出的适合实时数据传输的新型协议。

RTP 协议实际上是由实时传输协议RTP(Real-time Transport Protocol)和实时传输控制协议RTCP(Real-time Transport Control Protocol)两部分组成。RTP 协议基于多播或单播网络为用户提供连续媒体数据的实时传输服务;RTCP 协议是 RTP 协议的控制部分,用于实时监控数据传输质量,为系统提供拥塞控制和流控制。

RTP包头格式

一个 RTP 数据包都由固定包头(Header )和载荷(Payload)两个部分组成,其中包头前12个字节的含义是固定的,而载荷则可以是音频或视频数据。
使用RTP传输H.264格式视频_第2张图片

其中比较关键的参数设置解释如下:

  • 标示位(M ):1 位,该标示位的含义一般由具体的媒体应用框架(profile )定义, 目的在于标记处RTP 流中的重要事件。
  • 载荷类型(PT):7 位,用来指出RTP负载的具体格式。在RFC3551中,对常用的音视频格式的RTP 传输载荷类型做了默认的取值规定,例如,类型2 表明该RTP数据包中承载的是用ITU G.721 算法编码的语音数据,采用频率为 8000HZ,并且采用单声道。
  • 序号:16 位,每发送一个 RTP 数据包,序号加 1。接受者可以用它来检测分组丢失和恢复分组顺序。
  • 时间戳:32 位,时间戳表示了 RTP 数据分组中第一个字节的采样时间,反映出各RTP 包相对于时间戳初始值的偏差。对于RTP 发送端而言,采样时间必须来源于一个线性单调递增的时钟。

三、使用RTP传输H.264

使用RTP协议来传输H.264视频一个有效的办法就是从H.264视频中剥离出每个NALU,在每个NALU前添加相应的RTP包头,然后将包含RTP 包头和NALU 的数据包发送出去。

对RTP包头的设置

RTP包头的格式如上图,如下介绍详细设置:

  • 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。

RTP分包

对于每一个NALU,根据其包含的数据量的不同,其大小也有差异。在IP网络中,当要传输的IP 报文大小超过最大传输单元MTU(Maximum Transmission Unit )时就会产生IP分片情况。在以太网环境中可传输的最大 IP 报文(MTU)的大小为 1500 字节。如果发送的IP数据包大于MTU,数据包就会被拆开来传送,这样就会产生很多数据包碎片,增加丢包率,降低网络速度。对于视频传输而言,若RTP 包大于MTU 而由底层协议任意拆包,可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU 的NALU 单元,必须进行拆包处理。

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

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

四、H.264传输系统实现

一个完整的流媒体传输系统包含服务器端和客户端两个部分。

H.264服务端客户端传设计

对于服务器端,其主要任务是读取H.264 视频,从码流中分离出每个NALU 单元,分析NALU 的类型,设置相应的 RTP 包头,封装 RTP 数据包并发送。而对于客户端来说,其主要任务则是接收 RTP数据包,从RTP 包中解析出NALU 单元,然后送至客户端进行解码播放。该流媒体传输系统的框架如图3 所示:
使用RTP传输H.264格式视频_第3张图片

服务端处理流程如下图4:

使用RTP传输H.264格式视频_第4张图片

H.264解码过程

如下图解码流程图:
使用RTP传输H.264格式视频_第5张图片

NAL 单元解码的流程为:首先从 NAL 单元中提取出 RBSP 语法结构,然后按照如图 4 所示的流程处理 RBSP 语法结构。输入的是 NAL 单元,输出结果是经过解码的当前图像的 样值点。

NAL 单元中分别包含了序列参数集和图像参数集。图像参数集和序列参数集在其他 NAL 单元传输过程中作为参考使用,在这些数据 NAL 单元的片头中,通过语法元素 pic_parameter_set_id 设置它们所使用的图像参数集编号;而相应的每个图像参数集中,通过 语法元素 seq_paramter_set_id 设置他们使用的序列参数集编号。

参考连接:

http://blog.csdn.net/china_video_expert/article/details/7211302

http://blog.chinaunix.net/uid-23883288-id-3034586.html

http://blog.csdn.net/yu_yuan_1314/article/details/8984179

你可能感兴趣的:(Android知识点)