H264RTP封包原理

H.264RTP封包原理1.引言随着信息产业的发展，人们对信息资源的要求已经逐渐由文字和图片过渡到音频和视频，并越来越强调获取资源的实时性和互动性。但人们又面临着另外一种不可避免的尴尬，就是在网络上看到生动清晰的媒体演示的同时，不得不为等待传输文件而花费大量时间。为了解决这个矛盾，一种新的媒体技术应运而生，这就是流媒体技术。流媒体由于具有启动时延小、节省客户端存储空间等优势，逐渐成为人们的首选，流媒体网络应用也在全球范围内得到不断的发展。其中实时流传输协议RTP详细说明了在互联网上传递音频和视频的标准数据包格式，它与传输控制协议RTCP配合使用，成为流媒体技术最普遍采用的协议之一。H.264/AVC是ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT）共同努力制订的新一代视频编码标准，它最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上,是MPEG-4的1.5～2倍。同时，采用视频编码层（VCL）和网络提取层（NAL）的分层设计，非常适用于流媒体技术进行实时传输。本文就是基于RTP协议，对H.264视频进行流式打包传输，实现了一个基本的流媒体服务器功能，同时利用开源播放器VLC作为接收端，构成一个完整的H.264视频传输系统。2.RTP协议关键参数的设置RTP协议是IETF在1996年提出的适合实时数据传输的新型协议。RTP协议实际上是由实时传输协议RTP（Real-timeTransportProtocol）和实时传输控制协议RTCP（Real-timeTransportControlProtocol）两部分组成。RTP协议基于多播或单播网络为用户提供连续媒体数据的实时传输服务；RTCP协议是RTP协议的控制部分，用于实时监控数据传输质量，为系统提供拥塞控制和流控制。RTP协议在RFC3550中有详细介绍。每一个RTP数据包都由固定包头（Header）和载荷（Payload）两个部分组成，其中包头前12个字节的含义是固定的，而载荷则可以是音频或视频数据。RTP固定包头的格式如图1所示：其中比较关键的参数设置解释如下：（1）标示位（M）：1位，该标示位的含义一般由具体的媒体应用框架（profile）定义，目的在于标记处RTP流中的重要事件。（2）载荷类型（PT）：7位，用来指出RTP负载的具体格式。在RFC3551中，对常用的音视频格式的RTP传输载荷类型做了默认的取值规定，例如，类型2表明该RTP数据包中承载的是用ITUG.721算法编码的语音数据，采用频率为8000HZ，并且采用单声道。（3）序号:16位，每发送一个RTP数据包，序号加1。接受者可以用它来检测分组丢失和恢复分组顺序。（4）时间戳：32位，时间戳表示了RTP数据分组中第一个字节的采样时间，反映出各RTP包相对于时间戳初始值的偏差。对于RTP发送端而言，采样时间必须来源于一个线性单调递增的时钟。从RTP数据包的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息。这些都为实时的流媒体传输提供了相应的基础。而传输控制协议RTCP为RTP传输提供了拥塞控制和流控制，它的具体包结构和各字段的含义可参考RFC3550，此处不再赘述。3.H.264基本流结构及其传输机制3.1H.264基本流的结构H.264的基本流（elementarystream,ES）的结构分为两层，包括视频编码层（VCL）和网络适配层（NAL）。视频编码层负责高效的视频内容表示，而网络适配层负责以网络所要求的恰当的方式对数据进行打包和传送。引入NAL并使之与VCL分离带来的好处包括两方面：其一、使信号处理和网络传输分离，VCL和NAL可以在不同的处理平台上实现；其二、VCL和NAL分离设计，使得在不同的网络环境内，网关不需要因为网络环境不同而对VCL比特流进行重构和重编码。H.264的基本流由一系列NALU（NetworkAbstractionLayerUnit）组成，不同的NALU数据量各不相同。H.264草案指出[2]，当数据流是储存在介质上时，在每个NALU前添加起始码：0x000001，用来指示一个NALU的起始和终止位置。在这样的机制下，解码器在码流中检测起始码，作为一个NALU得起始标识，当检测到下一个起始码时，当前NALU结束。每个NALU单元由一个字节的NALU头（NALUHeader）和若干个字节的载荷数据（RBSP）组成。其中NALU头的格式如图2所示：F：forbidden_zero_bit.1位，如果有语法冲突，则为1。当网络识别此单元存在比特错误时，可将其设为1，以便接收方丢掉该单元。NRI：nal_ref_idc.2位，用来指示该NALU的重要性等级。值越大，表示当前NALU越重要。具体大于0时取何值，没有具体规定。Type：5位，指出NALU的类型。具体如表1所示：需要特别指出的是，NRI值为7和8的NALU分别为序列参数集（sps）和图像参数集（pps）。参数集是一组很少改变的，为大量VCLNALU提供解码信息的数据。其中序列参数集作用于一系列连续的编码图像，而图像参数集作用于编码视频序列中一个或多个独立的图像。如果解码器没能正确接收到这两个参数集，那么其他NALU也是无法解码的。因此它们一般在发送其它NALU之前发送，并且使用不同的信道或者更加可靠的传输协议（如TCP）进行传输，也可以重复传输。3.2适用于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（MaximumTransmissionUnit）时就会产生IP分片情况。在以太网环境中可传输的最大IP报文（MTU）的大小为1500字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP包大于MTU而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU的NALU单元，必须进行拆包处理。RFC3984给出了3中不同的RTP打包方案：（1）SingleNALUPacket:在一个RTP包中只封装一个NALU，在本文中对于小于1400字节的NALU便采用这种打包方案。（2）AggregationPacket:在一个RTP包中封装多个NALU，对于较小的NALU可以采用这种打包方案，从而提高传输效率。（3）FragmentationUnit:一个NALU封装在多个RTP包中，在本文中，对于大于1400字节的NALU便采用这种方案进行拆包处理。4.H.264流媒体传输系统的实现一个完整的流媒体传输系统包含服务器端和客户端两个部分[5][6]。对于服务器端，其主要任务是读取H.264视频，从码流中分离出每个NALU单元，分析NALU的类型，设置相应的RTP包头，封装RTP数据包并发送。而对于客户端来说，其主要任务则是接收RTP数据包，从RTP包中解析出NALU单元，然后送至解码器进行解码播放。该流媒体传输系统的框架如图3所示。