H.264多媒体数据实时传送方法

专利名称：H.264多媒体数据实时传送方法
技术领域：
本发明涉及多媒体数据传送方法，特别涉及H.264多媒体数据实时传送方法。
背景技术：
随着计算机互联网(Internet)和移动通信网络的飞速发展，流媒体技术的应用越来越广泛，从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。当前网上传送视频、音频主要有下载(Download)和流式传送(Streaming)两种方式。流式传送是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传送有顺序流式传送(Progressive Streaming)和实时流式传送(Realtime Streaming)两种方式。实时流式传送是实时传送，特别适合现场事件，实时流式传送必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传送带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
尤其是随着第三代移动通信系统(3rd Generation，简称“3G”)的出现和普遍基于网际协议(Internet Protocol，简称“IP”)的网络迅速发展，视频通信正逐步成为通信的主要业务之一。而双方或多方视频通信业务，如可视电话、视频会议、移动终端多媒体服务等，更对多媒体数据流的传送及服务质量提出苛刻的要求。不仅要求网络传送实时性更好，而且等效的也要求视频数据压缩编码效率更高。
鉴于媒体通信的需求现状，国际电信联盟标准部(InternationalTelecommunication Union Telecommunication Standardization Sector，简称“ITU-T”)继制定了H.261、H.263、H.263+等视频压缩标准后，于2003年正式发布了H.264标准。这是ITU-T和国际标准化组织(InternationalStandardization Organization，简称“ISO”)的运动图像专家组(Moving PictureExperts Group，简称“MPEG”)一起联合制定的适应新阶段网络媒体传送及通信需求的高效压缩编码标准。它同时也是MPEG-4标准第10部分的主要内容。
制定H.264标准的目的在于更加有效地提高视频编码效率和它对网络的适配性。事实上由于其优越性，H.264视频压缩编码标准很快就已经逐渐成为当前多媒体通信中的主流标准。大量的采用H.264多媒体实时通信产品(如会议电视，可视电话，3G移动通信终端)和网络流媒体产品先后问世。是否支持H.264已经成为这个市场领域中决定产品竞争力的关键因素。可以预测，随着H.264的正式颁布和广泛使用，基于IP网络和3G、后3G无线网络的多媒体通信必然进入一个飞跃发展的新阶段。
如前所述多媒体通信不仅要求媒体压缩编码效率高，而且要求网络传送的实时性。目前多媒体流传送基本上都是采用实时传送协议(Real-timeTransport Protocol，简称“RTP”)及其控制协议(Real-time Transport ControlProtocol，简称“RTCP”)。RTP是针对Internet上多媒体数据流的一个传送协议，由互联网工程任务组(Internet Engineering Task Force，简称“IETF”)发布。RTP被定义为在一对一或一对多的传送情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在用户数据包协议(UserDatagram Protocol，简称“UDP”)上，但也可以在传送控制协议(TransportControl Protocol，简称“TCP”)或异步传送模式(Asynchronous Transfer Mode，简称“ATM”)等其他协议之上工作。
RTP本身只保证实时数据的传送，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTCP负责管理传送质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传送速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传送效率最佳化，故特别适合传送网上的实时数据。
而H.264多媒体数据在IP网络上传送，不例外的也是基于UDP和其上层的RTP协议。RTP本身在结构上对于不同的媒体数据类型都能够适用，但是在多媒体通信中不同的高层协议或媒体压缩编码标准(如H.261，H.263，MPEG-1/-2/-4，MP3等)，IETF都会制定针对该协议的RTP净荷(Payload)打包方法的规范文件，详细规定RTP封装打包的方法，对于该具体协议是经过优化的。同样的，对于H.264也存在对应的IETF标准是RFC 3984RTPPayload Format for H.264 Video。该标准目前是H.264视频码流在IP网络上传送的主要标准，应用很广泛。在视频通信领域，各主流厂商的产品都是基于RFC 3984的，也是目前仅有的H.264/RTP传送方式。
事实上，H.264和以往其它的视频压缩编码协议不同的关键地方在于H.264定义了一个新的层面，称为网络抽象层(Network Abstract Layer，简称“NAL”)。H.264为了增加其视频编码层(Video Coding Layer，简称“VCL”)和下面具体的网络传送协议层的分离和无关性，带来更大的应用灵活性，定义了NAL这个新的层面，该层在ITU-T早期的视频压缩编码协议比如H.261，H.263/H.263+/H.263++中都是没有的。然而，如何在NAL和RTP协议承载协同工作中针对H.264的优点设计效率更高、更好的方案，使得RTP对于H.264的承载性能更好，是一个很值得研究和有很大应用价值的问题。
RFC3984规范所提出的RTP承载H.264的NAL层数据的方法是目前仅有的技术方案，该方案在RTP协议(RFC 3550)的基础上，将NAL层数据封装在RTP净荷中进行承载。NAL层位于VCL和RTP之间，规定要把视频码流按照定义的规则和结构，分割成一连串的NAL数据单元(NAL Units，简称“NALU”)。在RFC3984中定义了RTP净荷对于NALU的封装格式。下面依次简单介绍RTP的帧格式和现有技术中NALU的封装方法。
RTP设计的主要目的是实时多媒体会议和连续数据存储、交互分布式仿真、控制和测量应用等。RTP通常被承载于UDP协议之上，以利用其多路复用和校验的功能。如果底层提供多点分发，RTP支持多地址传送。RTP提供的功能包括载荷类型鉴别，序列编号，时间戳，和发送监测。
RTP包的格式如下RTP头信息基本选项占用12字节(最小情况)，而IP协议和UDP协议的头信息分别占用20字节和8字节，因此RTP包封装在UDP包再封装在IP包中，总的头信息占用字节数是12+8+20＝40字节。RTP包的头信息的详细结构如图1所示。
图1中所示从前到后RTP头信息依次为第1字节(字节0)为一些关于头信息结构本身的字段，第2字节(字节1)为定义净荷类型，第3、4字节(字节2、3)为包序号(Sequence Number)，第5-8字节为时间戳(timestamp)，第9-12字节为同步贡献源标识符(Synchronous Source Identifier，简称“SSRCID”)，最后为贡献源标识符(Contributing Source Identifiers，简称“CSRCIDs”)的列表，其数目不确定。注意到，在本文描述中第1个字节为标注的字节0，之后依此类推。
其中前12个字节出现在所有不同类型的RTP数据包中，而头信息中的其它数据，比如贡献源标识符标识只有当混合器插入时才有。因此CSRC一般用于存在媒体混合时候的情况，比如在多方会议中，音频需要混合，视频也可以用这种方法提供多画面的功能。而同步源标识SSRC其实就是所承载媒体流的标识。
上述各个字段的具体意义及全称分别描述如下
V字段为版本(Version)信息，占2比特(bits)，目前采用的版本为2，因此置V＝2，而其他值如V＝1表示更早的RTP版本，V＝0表示最原始的RTP前身，即在早期Mbone网络上使用的语音IP(VOIP)通信系统中采用，后来演化成了RTP，而V＝3则尚未定义，因此是本发明可以利用的；P字段为填充标识(Padding)，占1bit，P如果置位，则表示数据包末尾包含一个或多个填充字节(Padding)，填充不属于有效载荷的一部分；X字段为扩展标识比特(Extension)，占1bit，X如果置位，则RTP头的最后必须跟一个可变长的头扩展(如果有CSRC列表，头扩展要跟在其后)，主要是保留用于某些应用环境下头信息字段不够用的情况，该头信息扩展包含一个16比特的长度字段来计数扩展中有多少个32比特长的字，头扩展的前16比特是左开放的，以便区分标识符和参数，这16比特的格式由具体的层面规范定义，该头扩展的格式定义在RFC3550第5.3.1节中有详细描述，此处限于篇幅不再给出；CC字段为贡献源数目(CSRC Count)，占4bits，指明头信息最后面的CSRC标识符的个数，接收方根据CC字段可以确定头信息后面的CSRC IDs列表长度；M字段为标识比特(Marker)，占1bit，该标识比特的解释在特定的层面(Profile)中定义，它允许标识出数据包流中的重要事件，一个层面可以定义附加的标识比特或规定没有标识比特，这里所谓层面就是指具体的应用环境设置，由通信双方具体协定，不受协议的限定；PT字段为载荷类型(Payload Type，简称“PT”)，共7bits，标识RTP载荷的格式并确定他在应用程序中的解释；标志比特和载荷类型共一个字节携带层面规定信息，这个字节可能会被具体层面重新定义以适应不同需求，在具体应用中可以定义所谓的profile，其实就是一组静态(即通信双方事先约定好的)对应关系，将PT比特不同的取值和不同的媒体格式对应起来。当然也可以通过RTP之外的信令来进行动态协商定义PT取值和媒体格式之间的关系。在一个RTP会话(Session)中，RTP源是可以变更PT的。
接着的字段就是序号共16bits，每发送一个RTP数据包，该序号值加一，这样接收者可以用它来检测数据包丢失和恢复数据包顺序，一次通信中的序号初始值可以随机给定，不影响通信。
时间戳占32bits，它反映了RTP数据包中第一个字节的采样时间，这里的采样时间必须来源于一个单调线性增长的时钟，接收方根据其调整媒体播放时间或者进行同步。
同步源SSRC ID占32bits，其具体值可随机选择，但要确保同一个RTP会话中的唯一性，即能唯一标识一个媒体源，如果一个源改变了源传送地址，必须选择一个新的SSRC标志符。
贡献源CSRC列表，可以根据需要为0-15项，每项占32bits，该列表的长度即CSRC ID的数目正好由CC字段的4个bit标出。事实上，用于标识某个媒体源的CSRC标识符与其对应的贡献源的SSRC标识符是一致的，只不过在不同的接收方的角色不同，而被置为SSRC或CSRC。在多方通信中，CSRC ID是由混合器插入。
在承载H.264视频的情况下，RTP把H.264的NALU封装打包成RTP包流。在RFC 3984文件中主要定义了NALU，并且基于此给出H.264层NAL数据在RTP中的封装打包格式。这种NALU的RTP封装格式如图2所示。
图2中给出一个NALU在RTP的净荷中的封装结构，前面第一个字节为NALU头信息，之后为NALU的数据内容，多个NALU首尾相接的填充到RTP包的净荷中，在最后还有可选的RTP填充，这是RTP包格式规定的内容，是为了使得RTP包的长度符合某种特定要求(比如达到固定长度)，可选的RTP填充数据一般都填零。
NALU头信息即第1个字节，也称为八比特组(Octet)，其共有三个字段，意义和全称分别描述如下F字段定义为禁止比特(forbidden_zero_bit)，占1bit，用于标识语法错等情况，如果有语法冲突则置为1，当网络识别此单元中存在比特错误时，可将其设为1，以便接收方丢掉该单元，主要用于适应不同种类的网络环境(比如有线无线相结合的环境)；NRI字段定义为NAL参考标识(nal_ref_idc)，占2bits，用于指示NALU数据的重要程度，其值为00表示NALU的内容不用于重建帧间预测的参考图像，而非00则表示当前NALU是属于参考帧的条带(slice)或序列参数集(Sequence Parameter Set，简称“SPS”)、图像参数集(Picture ParameterSet，简称“PPS”)等重要数据，该值越大表示当前NAL越重要；Type字段定义为NALU类型(Nal_unit_type)，共5bits，可以有32种NALU的类型，其值和具体类型的对应关系在表1中详细给出。
表1NALU头信息中Type字段取值与类型对应关系表

可见，NALU的头信息的一个字节中给出的信息主要包含NALU的有效性、重要性等级，根据这些信息可以确定RTP所承载的数据重要性。
综上所述，可以将现有技术的方案归纳如下首先在NAL层将H.264的视频比特流按照一定的规则分割形成NALU流，这一步实际上属于H.264实现的范畴，比如可以把一帧图像作为一个NALU，也可以把一个Slice作为一个NALU，然后根据和应用相关的封装打包策略把NALU流封装打包形成RTP数据包流。RTP数据包中，在头信息之后就是NALU数据区，如果一个RTP数据包封装多个H.264的NALU，那么这些NALU首尾相接排列，每个NALU占据一段连续的比特，每个NALU的第一个字节是NALU头信息字节，而在RTP数据包的最后，根据需要，可能存在一些可选性的填充数据比特。有一点需要注意，在传送过程中，底层RTP协议并不处理NALU的具体信息。
在实际应用中，上述方案存在以下问题该方案中H.264的NALU头信息没有能够体现在RTP包的头信息中。而NALU头信息字节中，其实含有很多重要的信息，比如NRI指示对应的NALU包含的数据是H.264非参考帧还是参考帧或者其它重要图像数据比如参数集等。
因为RTP协议本身不提供任何服务质量(Quality of Service，简称“QoS”)机制，并且不提供关于承载数据重要性优先级等的信息，所以在IP和无线网络上RTP本身没有任何针对网络丢包等错误的容错能力，或称为错误弹性(Error Resilience)。
如果能够在RTP数据包的头信息中，反映H.264 NALU的一些信息，则可以通过直接扫描RTP包头信息获得关于H.264 NALU属性的信息。根据这些信息，网络设备就有可能对于RTP数据包作有区别的处理，从而保证重要数据在传送过程中的优先性。
另外，该方案在效率上还有改进的余地，如果一个RTP数据包中封装了多个H.264 NALU，一般这些NALU的类型都一样，那么这些NALU的头信息字节其实是完全相同的，如果有N个NALU在一个RTP包中，那么这N个NALU头信息字节其实可以用一个字节替代，不损失任何信息，但是效率提高了，因为可以减少N-1个冗余字节。
造成这种情况的主要原因在于，现有技术方案中将NALU的头信息完全封装在净荷当中，使得RTP协议无法直接获知有关净荷的属性、级别、重要程度等，从而无法实现基于此的QoS机制。其次，这样的封装格式还造成了NALU头信息占用净荷资源，因为每个NALU的都附带头信息，导致在很多情况下，由于一个RTP中多个相同类型的NALU的头信息都是一样的，从而浪费了RTP传送带宽资源。

发明内容
有鉴于此，本发明的主要目的在于提供一种H.264多媒体数据实时传送方法，使得RTP协议能够高效承载H.264多媒体视频数据，在兼容现有采用RTP协议的设备及传送方式的前提下增加服务质量保证机制。
为实现上述目的，本发明提供了一种H.264多媒体数据实时传送方法，所述H.264多媒体数据在网络抽象层被分为网络抽象层单元流，所述网络抽象层单元包含头信息，所述网络抽象层单元头信息依次包含禁止比特字段，用于指示所述网络抽象层单元是否出错；网络抽象层参考标识字段，用于指示所述网络抽象层单元的重要性；类型字段，用于指示所述网络抽象层单元的类型，包含以下步骤A发送方按改进实时传送协议封装格式将头信息相同的至少一个网络抽象层单元封装在同一个改进实时传送协议包中，并在该改进实时传送协议包头信息中设改进实时传送协议标识以区别实时传送协议包；B接收方根据该改进实时传送协议标识判断该包为改进实时传送协议包，并根据改进实时传送协议封装格式处理该改进实时传送协议包，获取所承载的网络抽象层单元；其中，在所述改进实时传送协议封装格式中，将其所承载的网络抽象层单元所具有的相同头信息综合体现在该改进实时传送协议包的头信息中，并将所承载的网络抽象层单元去掉其头信息再填充入该改进实时传送协议包的净荷中。
其中，在所述改进实时传送协议封装格式中，所述网络抽象层单元头信息中的网络抽象层参考标识字段和类型字段填充在所述改进实时传送协议包头信息的净荷类型字段中，该净荷类型字段位于所述改进实时传送协议包头信息的第2个字节的后7比特。
此外在所述方法中，在所述步骤A、B中，所述改进实时传送协议标识为所述改进实时传送协议包头信息的版本信息字段取值为二进制值11，该版本信息字段位于所述改进实时传送协议包头信息的第1个字节的前2比特。
此外在所述方法中，在所述改进实时传送协议封装格式中，所述网络抽象层单元头信息中的禁止比特字段填充在所述改进实时传送协议包头信息的标记字段中，该标记字段位于所述改进实时传送协议包头信息的第2个字节的前1比特；且在所述步骤B中，接收方根据所述改进实时传送协议包的标记字段判断其所承载的网络抽象层单元是否出错；其中，所述接收方包含通信终端和网络中间设备。
此外在所述方法中，在所述步骤A、B中，所述改进实时传送协议标识为所述改进实时传送协议包头信息的标记字段取值为二进制值1，该标记字段位于所述改进实时传送协议包头信息的第2个字节的前1比特。
此外在所述方法中，在所述改进实时传送协议封装格式中，忽略所述网络抽象层单元头信息中的禁止比特字段；在所述步骤A中，对于所述禁止比特字段指示的出错网络抽象层单元，采用实时传送协议包封装；在所述步骤B中，判断该实时传送协议包后按实时传送协议封装格式处理该实时传送协议包。
此外在所述方法中，所述步骤A包含以下子步骤发送方首先判断至少一个所述网络抽象层单元的头信息中的禁止比特字段是否有效，据此将其分为正常网络抽象层单元和出错网络抽象层单元；然后按所述改进实时传送协议封装格式将所述正常网络抽象层单元封装成所述改进实时传送协议包，并设所述改进实时传送协议标识；按所述实时传送协议封装格式将所述出错网络抽象层单元封装成所述实时传送协议包；所述步骤B包含以下子步骤接收方首先根据接收到的包的头信息中是否含有所述改进实时传送协议标识，将其分为所述改进实时传送协议包和所述实时传送协议包；然后根据所述改进实时传送协议封装格式处理所述改进实时传送协议包，根据所述实时传送协议包封装格式处理所述实时传送协议包。
此外在所述方法中，在所述改进实时传送协议封装格式中，当所述网络抽象层单元的所有类型少于16种时，仅用所述类型字段的低4比特表征，而所述类型字段的最高比特作为扩展保留比特。
此外在所述方法中，多媒体传送设备根据所述改进实时传送协议头信息获知其所承载的网络抽象层单元的相关信息，并据此实施所述H.264多媒体数据实时传送的服务质量策略。
通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，给出一种改进的RTP协议(MRTP)用于承载NALU数据，通过将同一个RTP包中的所有NALU的头信息字节结合到其头信息中，采用了一种结合方式使得既不影响现有RTP协议及设备的运作，而且能够将NALU净荷的属性直接体现在MRTP头信息中，一方面使得MRTP对NALU的封装承载效率大大提高，另一方面使得通过MRTP对净荷NALU属性的体现提供了QoS机制实现的基础；另外通过对现有RTP头信息中相关字段比如M、F字段的改进，给出区别现有RTP和MRTP的标识方法，这使得现有网络媒体设备同时支持RTP和MRTP进行工作成为可能，提高了MRTP的兼容性；并且给出相应的对于存在语法错误(syntactical errors)或者误码的NALU的传统RTP单独传送方法，和MRTP与RTP数据包交替处理的方案。
这种技术方案上的区别，带来了较为明显的有益效果，即通过本发明改进的MRTP协议的头信息携带H.264的NALU头信息，从而在不用对于NALU进行解码的情况下，通过对于MRTP头信息的快速扫描即可以确定MRTP数据包承载NALU的重要性，从而采取相应的措施，实现QoS策略等，进一步提高服务质量；同时，通过剥离掉MRTP数据包中同类H.264 NALU的头信息字节，达到降低冗余、提高传送效率的目的，对于IP网络多媒体视频通信提高视频传送质量和用户体验有很好效果；另外，对于MRTP和RTP的区别实现了与现有技术的兼容，给出交替处理MRTP和RTP数据包的解决方式，以及错误NALU的单独传送方案，这些都提高了MRTP这种新方法的健壮性。


图1是RTP数据包的头信息结构示意图；图2是现有技术在RTP包净荷中对NALU数据的封装格式示意图；图3是根据本发明的实施方式的MRTP数据包的头信息结构示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
本发明旨在提供一种方案能够在RTP的头信息中体现H.264 NALU的头信息。其基本原理是利用目前RTP头信息中的某个或者某些字节或者比特来体现NALU的头信息，而这些字节或者比特在RTP中定义的目的就是为和所承载的具体媒体协议结合留下发展空间的。改进后的RTP协议还不会影响与支持原RTP协议的设备之间的互通性，即在通信中有些终端采用按照本发明改进的RTP协议，另外的终端采用未改进的RTP协议，这些终端之间完全能够正常通信。这一点是靠在MRTP头信息中设置标志比特，用以区分传统的RTP数据包，同时终端也可以针对不同的情况，采取不同的处理措施，实现MRTP与RTP交替传送处理的方案。这里面也包括了对语法错误NALU的处理方案，用传统RTP传送语法错误NALU即可解决其F标志比特被用于区别MRTP所带来的问题。
MRTP对现有RTP的改进主要涉及到RTP数据包头信息中的净荷类型PT字段和版本信息V字段的重新定义。该方案的两个潜在价值是为H.264数据的传送提供一定的QoS机制；提高RTP封装H.264 NALU的效率。
本文采用改进的RTP(Modified RTP，简称“MRTP”)格式封装NALU数据，下面给出具体实施方式
的描述，但是有一点需要说明的是，下面给出的所有有关MRTP的描述中将只提到其与现有RTP所不同的地方。MRTP与RTP最基本的不同点在于，在MRTP封装过程中，将具有相同头信息的NALU包的头信息综合入MRTP的头信息中。
前面已经提到过NALU头信息结构，这里再次强调以下，NALU信息依次包含占1比特的F字段，用于指示所述NALU是否出错；占2比特的NRI字段，用于指示所述NALU的重要性；占5比特的Type字段，用于指示所述NALU的类型。
本发明的第一实施方式中收发双方的执行步骤如下所述。
发送方按MRTP封装格式将头信息相同的多个NALU封装在同一个MRTP包中，并在该MRTP包头信息中设MRTP标识以区别RTP包。这里有一点值得注意本发明要求的一个合理前提条件是，在同一个MRTP数据包中只存放同一种类型的H.264NALU，即具有相同的头信息。
根据实际工程经验，在一般情况下，因为H.264比特流总是存在相邻的部分其对应的NALU类型相同这个属性，这个假设总是可以满足的。即使在某些情况下无法满足，也可以有几种对策可以处理这样的情况第一种可以将相同类型的NALU累积，直到满足一定的数目后在封装到MRTP中，另一种如果相同类型的NALU的数目达不到一定的数目的话，采用RTP填充的方法，虽然浪费一点带宽，但这微不足道，还有一种方法是如果类型不同的NALU非常多，则可以采用RTP封装，反正在接收方能够根据MRTP标识来识别，进行对应的处理。
接收方根据该MRTP标识判断该包为MRTP包，并根据MRTP封装格式处理该MRTP包，获取所承载的NALU。这里接收方根据MRTP标识可以识别MRTP包，主要是区别于RTP包，这样可是使得采用MRTP协议的终端不影响现有的RTP协议正常通信，具备向下兼容性。
上面提到的在所述MRTP封装格式中，将其所承载的NALU所具有的相同头信息综合在该MRTP包的头信息中，并将所承载的NALU去掉其头信息再填充入该MRTP包的净荷中。这一点也就是MRTP于RTP的主要区别，前面提过很多，这样带来方便功能扩展和节约带宽的好处。
那么如何将NALU头综合到MRTP头中的，又如何在MRTP头标识该包是MRTP包呢？下面将具体给出两套方案以解决这个几个问题。
本发明第二实施方式在第一实施方式的基础上，在MRTP封装格式中，NALU头信息中的NRI字段和Type字段填充在MRTP包头信息的PT字段中，前面已经叙述，该PT字段位于MRTP包头信息的第2个字节的后7比特。在图3中示出了这样一个MRTP头的格式，其中与RTP不同的地方已经用粗体部分表示，另外图中有些地方在后面还会解释。
该实施方式的另外两个要点是第一，将MRTP包头中的V字段作为MRTP标识，如果是MRTP包则将其V字段取值为3(二进制值11)，前面已提到，该V字段位于MRTP包头信息的第1个字节的前2比特，即版本信息字段；第二，NALU头信息中的F字段填充在MRTP包头信息的M字段中，该M字段位于MRTP包头信息的第2个字节的前1比特，在接收方则根据MRTP包的M字段判断其所承载的NALU是否出错，也就实现了F字段的禁止比特功能。
可见在本发明的第二实施方式中，令MRTP的当前版本V取值3，相当于是新版本的RTP，现行的RTP版本V取值为2。通过版本的区别，可以告诉RTP数据包的接收方，该RTP协议是改进版本MRTP，从而在后面的处理，就要按照针对改进RTP协议的处理流程进行。后面我们还将描述一种替代方案，可以不修改V也能达到表示MRTP和RTP之间的差别的目的。
在该实施方式中，将NALU头信息字节(8个比特)替换原RTP头信息中的标识M字段1个比特和PT字段7个比特共8个比特。具体的替换顺序比如可以是这样F比特替换M比特；NRI2个比特替换PT7个比特中的最高2个比特；Type5个比特替换PT7个比特中的最低5个比特；实际上，这样的替换方案是有其合理性的。PT7个比特本来就是可以自由使用的，前面已经提到。M字段的用途在RTP(RFC 3550)中规定如下某种具体的层面(Profile)可以规定不使用M比特，而是把它并入PT，这样PT最多可以有8个比特，区别256种不同的类型。因此，用F比特替换M比特完全是符合RTP规定的，不会引起MRTP和传统RTP之间互通的问题。
容易看出本发明MRTP的封装格式具有明显的三个优点第一，额外开销少，尤其是一个RTP中有多个NALU时，明显节省传送比特数；第二，不用对RTP数据包中的H.264 NALU数据解码就可以判别这些NALU的相对重要性；第三，不用对RTP数据包中的H.264 NALU数据解码就可识别由于其它的比特丢失而是否会造成该RTP包能否正确解码。
为了进一步详细描述本发明第二实施方式的技术细节，下面给出一个MRTP封装和去封装的过程描述。在进行上述处理后，在同一个MRTP数据包中的多个H.264 NALU类型完全相同，即它们的头信息字节都相同，那么在他们封装到MRTP数据包中的时候，可以剥离掉原来的头信息字节，这样如果有N个NALU，可以减少N个字节。去封装时，就是把NALU从MRTP数据包中提取出来还原为原来的形式，即将这N个NALU从他们所在的MRTP数据包中提取出来，然后把MRTP头信息中的PT的7个比特拷贝到一个字节H(8比特)中的最低7个比特中去，而H的最高比特作为F比特，设置为0。然后把生成的H字节附加到每个提取出来的NALU的最前面，这样就还原了每个NALU。当然如果说MRTP包头中的F字段为1的话，说明该MRTP包中的NALU出错，因此直接丢弃即可，节省了处理时间。
本发明的第三实施方式在第一实施方式的基础上给出第二种解决方案，该方案与第二实施方式有一点是相同的，即也是将NALU头中的NRI和Type字段填充到MRTP头的PT字段的7个比特中。不同的地方有两点不再采用V字段标识MRTP，还是取值为V＝2，但是采用M字段标识MRTP，这样带来的一个问题就是F字段没有地方填充了，该实施方式中将F是否置位的两类NALU分别对待，对于F置位的出错NALU还是采用原先的RTP传送，而对于正常的则采用MRTP传送，但忽略该F比特。具体细节如下所述。
第三实施方式中，将M字段取值为1来标识MRTP包，该M字段位于所述MRTP包头信息的第2个字节的前1比特。而对于F比特，在H.264协议中规定如果有语法冲突或者错误，则为1。当网络识别此单元中存在比特错误时，可将其设为1，以便接收方丢掉该单元。主要用于适应不同种类的网络环境，比如有线无线相结合的环境。具体的使用原则是一般情况下通信的发送方和接收方在对于视频进行H.264编码和解码的时候，不对于该比特进行“写”操作，解码端对于该比特进行“读”操作。如果发现F＝1，则接收方在解码过程中将丢弃该NALU。根据目前的业界普遍应用情况来看，对于F比特进行“写”操作，主要是在两种不同网络之间的网关上进行，比如进行编码转换的情况(MPEG-4到H.264，H.263到H.264等)。
因此，本发明的第三实施方式将F比特忽略，不用于原来H.264定义的目的。从而使得原先用于填充F比特的M字段可以保留，用于未来的扩展携带更多信息，这里就是用于标识MRTP包。这样做的好处是，不需要对于版本信息V＝2进行修改，MRTP还是用原来版本V取值2。这也是节约了目前仅有的RTP版本信息资源。
然而不可避免的是，在实际应用中可能出现需要使用F比特的小概率情况，比如NALU语法错的时候，本发明第三实施方式对于这种情况做如下处理在MRTP封装格式中，忽略所述NALU头信息中的F字段；但在发送方，对于F字段有效的出错NALU，仍旧采用RTP包封装，仅对正常的NALU采用MRTP包装；在接收方则判断该包为MRTP还是RTP包后按相应封装格式处理该包。也就是说，当F比特在某些特殊情况下，要用于原来H.264定义的目的，即要用于表示可能存在的H.264 NALU语法错误的情况，如果一个中间设备比如网关在对于视频按照H.264协议进行视频编码的时候，发现某个NALU存在语法错误，那么就要对于该NALU单独进行封装处理。
归纳上述MRTP和RTP交替处理的方法流程如下发送方首先判断至少一个NALU的头信息中的F字段是否有效，据此将其分为正常NALU和出错NALU；然后按MRTP封装格式将正常NALU封装成MRTP包，并设MRTP标识；按RTP封装格式将出错NALU封装成RTP包；接收方首先判断接收到的包的头信息是否设MRTP标识，将其分为MRTP包和RTP包；然后根据MRTP封装格式处理MRTP包，根据RTP包封装格式处理RTP包。
可见，在本发明的第三实施方式中，网关对于正常的NALU，按照前面描述的方法，对于类型相同的H.264 NALU按照一定的规则(由具体应用决定，主要规定每个MRTP数据包中封装多少个同类的NALU)进行MRTP封装，一旦发现某个NALU存在语法错误，那么就要对于该NALU采用常规RTP封装。这个时候常规的RTP数据包中也许就只含有一个H.264 NALU。
以上方法的假设是在连续的H.264 NALU流中，偶尔出现单独的语法错误NALU，这个时候把错误的NALU单独拿出来用RTP封装。在接收方，如果收到MRTP数据包，就按MRTP的规则进行H.264 NALU的去封装处理；如果收到RTP的数据包，就按RTP的规则进行H.264 NALU的去封装处理。
在更加极端的情况下，中间设备出现H.264编码错误，出现连续多个有语法错误的H.264 NALU，比如M个连续的语法错误NALU出现，那么可以把这M个NALU仍然采取传统RTP来封装。另外，即使NALU流中出错NALU陆续不绝，那么可以将这些出错NALU累积，直到达到满足一个RTP包的长度后再用RTP打包，这样可以节约带宽，同时不影响接收方，因为接收方可以根据序号得知哪些NALU丢失。
不难看出，这种方案虽然采用了用传统RTP来传送，但完全不会影响MRTP带来的好处。因为正常的NALU都能够用MRTP封装，其好处都可以享受，比如基于头信息可能采用的QoS机制等。而对于出错的NALU，在接收方的处理一般都是丢弃，因此它们享受不到MRTP带来的好处是合理的。
最后还需要说明的一点是，注意到前文提到的表1中给出的NALU的类型及其对应Type字段的取值，可以发现现有的类型不足16种，也就是说Type的5个比特完全可以缩减为4个，这不影响现有的H.264传送，因此在本发明的第四实施方式种，在MRTP封装格式中，当NALU的所有类型少于16种时，仅用Type字段的低4比特表征，而Type的最高比特作为扩展保留比特，称作C字段，如图3中所示。将该C比特留待以后使用，继续进行功能扩展。将比特C进行保留后，表1中给出的NALU类型要做相应修改共16个值，取值0-12与表1相同，取值13-15为保留。
当然虽然目前H.264的NALU类型只有13种，但是H.264后续会发展，可能会产生更多的NALU类型，如果未来NALU类型增加到16种以上，那么还是需要用PT 7个比特中的最低4个比特加上C比特作为类型指示。
行文最后，需要提及的是本发明的MRTP带来的最大好处也就是，多媒体传送设备可以根据MRTP头信息直接获知其所承载的NALU的相关信息，并据此实施H.264多媒体数据实时传送的QoS策略。这一点在现有的RTP是无法实现的，因为对于RTP层来说，NALU层信息是不关心的，也就无法获知净荷中的每个NALU的头信息，从而无法实现QoS策略。
虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。
权利要求
1.一种H.264多媒体数据实时传送方法，所述H.264多媒体数据在网络抽象层被分为网络抽象层单元流，所述网络抽象层单元包含头信息，其特征在于，包含以下步骤A发送方按改进实时传送协议封装格式将头信息相同的至少一个网络抽象层单元封装在同一个改进实时传送协议包中，并在该改进实时传送协议包头信息中设改进实时传送协议标识以区别实时传送协议包；B接收方根据该改进实时传送协议标识判断该包为改进实时传送协议包，并根据改进实时传送协议封装格式处理该改进实时传送协议包，获取所承载的网络抽象层单元；其中，在所述改进实时传送协议封装格式中，将其所承载的网络抽象层单元所具有的相同头信息综合体现在该改进实时传送协议包的头信息中，并将所承载的网络抽象层单元去掉其头信息再填充入该改进实时传送协议包的净荷中。
2.根据权利要求1所述的H.264多媒体数据实时传送方法，其特征在于，所述网络抽象层单元头信息依次包含禁止比特字段，用于指示所述网络抽象层单元是否出错；网络抽象层参考标识字段，用于指示所述网络抽象层单元的重要性；类型字段，用于指示所述网络抽象层单元的类型；
3.根据权利要求2所述的H.264多媒体数据实时传送方法，其特征在于，在所述改进实时传送协议封装格式中，所述网络抽象层单元头信息中的网络抽象层参考标识字段和类型字段填充在所述改进实时传送协议包头信息的净荷类型字段中，该净荷类型字段位于所述改进实时传送协议包头信息的第2个字节的后7比特。
4.根据权利要求3所述的H.264多媒体数据实时传送方法，其特征在于，在所述步骤A、B中，所述改进实时传送协议标识为所述改进实时传送协议包头信息的版本信息字段，该版本信息字段位于所述改进实时传送协议包头信息的第1个字节的前2比特。
5.根据权利要求4所述的H.264多媒体数据实时传送方法，其特征在于，在所述改进实时传送协议封装格式中，所述网络抽象层单元头信息中的禁止比特字段填充在所述改进实时传送协议包头信息的标记字段中，该标记字段位于所述改进实时传送协议包头信息的第2个字节的前1比特；且在所述步骤B中，接收方根据所述改进实时传送协议包的标记字段判断其所承载的网络抽象层单元是否出错。其中，所述接收方包含通信终端和网络中间设备。
6.根据权利要求3所述的H.264多媒体数据实时传送方法，其特征在于，在所述步骤A、B中，所述改进实时传送协议标识为所述改进实时传送协议包头信息的标记字段，该标记字段位于所述改进实时传送协议包头信息的第2个字节的前1比特。
7.根据权利要求6所述的H.264多媒体数据实时传送方法，其特征在于，所述步骤A包含以下子步骤发送方首先判断至少一个所述网络抽象层单元的头信息中的禁止比特字段是否有效，据此将其分为正常网络抽象层单元和出错网络抽象层单元；然后按所述改进实时传送协议封装格式将所述正常网络抽象层单元封装成所述改进实时传送协议包，并设所述改进实时传送协议标识，在所述改进实时传送协议封装格式中，忽略所述网络抽象层单元头信息中的禁止比特字段；按所述实时传送协议封装格式将所述出错网络抽象层单元封装成所述实时传送协议包；所述步骤B包含以下子步骤接收方首先根据接收到的包的头信息中是否含有所述改进实时传送协议标识，将其分为所述改进实时传送协议包和所述实时传送协议包；然后根据所述改进实时传送协议封装格式处理所述改进实时传送协议包，根据所述实时传送协议包封装格式处理所述实时传送协议包。
8.根据权利要求3-7中任意一项所述的H.264多媒体数据实时传送方法，其特征在于，在所述改进实时传送协议封装格式中，当所述网络抽象层单元的所有类型少于16种时，仅用所述类型字段的低4比特表征，而所述类型字段的最高比特作为扩展保留比特。
9.根据权利要求3-8中任意一项所述的H.264多媒体数据实时传送方法，其特征在于，多媒体传送设备根据所述改进实时传送协议头信息获知其所承载的网络抽象层单元的相关信息，并据此实施所述H.264多媒体数据实时传送的服务质量策略。
全文摘要
本发明涉及多媒体视频数据传送方法，公开了一种H.264多媒体视频数据实时传送方法，使得RTP协议能够高效承载H.264多媒体视频数据，在兼容现有采用RTP协议的设备及传送方式的前提下增加服务质量保证机制。本发明中，给出一种改进的RTP协议用于承载H.264数据，通过将同一个RTP包中的所有H.264 NALU的头信息字节结合到RTP包自身的头信息中，使得既不影响现有RTP协议及设备的运作，而且能够将H.264 NALU净荷的属性直接体现在MRTP头信息中；另外通过对现有RTP头信息中相关字段比如M、F字段的改进，给出区别现有RTP和MRTP的标识方法，这使得现有网络媒体设备同时支持RTP和MRTP进行工作成为可能，提高了MRTP的兼容性和应用的灵活性。
文档编号H04N7/24GK1863314SQ20051011394
公开日2006年11月15日 申请日期2005年10月17日 优先权日2005年10月17日
发明者宋彬, 罗忠 申请人:华为技术有限公司