CN100466725C

CN100466725C - 多媒体通信方法及其终端

Info

Publication number: CN100466725C
Application number: CNB2006100690163A
Authority: CN
Inventors: 罗忠; 宋彬
Original assignee: Huawei Technologies Co Ltd
Current assignee: Wang Miaomiao
Priority date: 2005-11-03
Filing date: 2005-11-03
Publication date: 2009-03-04
Anticipated expiration: 2025-11-03
Also published as: WO2007051425A1; CN1863302A

Abstract

本发明涉及多媒体通信技术，公开了一种多媒体通信方法及其终端的设计和实现，实现不等保护，方便于QoS保证的实现。本发明采用ERRTP在现有RTP协议基础上提供了可以携带错误弹性编码方案相关信息的传送层封装格式，使得多媒体数据在ERRTP上传送的同时标记其相应的错误弹性编码方案信息，从而将错误弹性机制融入传送层；针对H.264 NALU结构给出专用的ERRTP封装方法和协议头信息的改造方案，能够将同一个ERRTP包中的所有NALU的头信息字节结合到其头信息中，从而在ERRTP头信息中体现NALU的重要信息，并且提高传送效率。

Description

多媒体通信方法及其终端

技术领域

本发明涉及多媒体通信技术，特别涉及支持错误弹性的多媒体通信技术。

背景技术

随着计算机互联网(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无线网络的多媒体通信必然进入一个飞跃发展的新阶段。

下面简单介绍H.264标准的消息构成及发送机制:H.264标准采用分层模式，定义了视频编码层(Video Coding Layer，简称“VCL”)和网络抽象层(Network Abstraction Layer，简称“NAL”)，后者专为网络传送设计，能适应不同网络中的视频传送，进一步提高网络的“亲和性”。H.264引入了面向IP包的编码机制，有利于网络中的分组传送，支持网络中视频的流媒体传送；具有较强的抗误码特性，特别适应丢包率高、干扰严重的无线视频传送的要求。H.264的所有待传送数据，包括图像数据及其他消息均封装为统一格式的包传送，即网络抽象层单元(NAL Unit，简称“NALU”)。每个NALU是一个一定语法元素的可变长字节字符串，包括包含一个字节的头信息，可用来表示数据类型，以及若干整数字节的负荷数据。一个NAL单元可以携带一个编码片、各自类型数据分割或一个序列或图像参数集。为了加强数据可靠性，每帧图像都被分为若干个条带(Slice)，每个Slice由一个NALU承载，Slice又是由若干个更小的宏块组成，即为最小的处理单元。一般的说，前后帧对应位置的Slice相互关联，不同位置的Slice相互独立，这样可以避免Slice之间发生误码相互扩散。

H.264数据包含非参考帧的纹理数据、序列参数、图像参数、补充增强消息(Supplemental Enhancement Information，简称“SEI”)、参考帧纹理数据等。其中，SEI消息是在H.264视频的解码、显示及其它方面起辅助作用的消息的统称。现有技术定义了各类SEI消息，同时保留了SEI预留消息，为未来的各种可能应用留下了扩展余地。根据H.264，SEI消息并非在解码过程重构亮度和色度图像所必需的。符合H.264标准的解码器，是不需要对于SEI作任何处理的。也就是说，不是所有符合H.264基本要求的终端都能够处理SEI消息的，但是对于不能处理SEI消息的终端，发送SEI对于它是没有影响的，它会简单地忽略掉它不能处理的SEI消息。按照SEI语法规则，用户可以利用预留消息传送自定义消息，实现功能扩展。

下面首先介绍SEI消息的结构及文法等相关资料。H.264中提供了多种可以进行消息扩展的机制，其中包括SEI。H.264中定义了补充增强信息(SEI)，它的数据表示区域与视频编码数据独立，它的使用方法在H.264协议中NAL的描述中给出。H.264码流的基本单位是NALU，NALU可以承载各种H.264数据类型，比如视频序列参数(Sequence parameters)，图像参数(Picture parameters)，Slice数据(即具体图像数据)，以及SEI消息数据。SEI用于传递各种消息，支持消息扩展。因此SEI域内用于传送为特定目的而自定义的消息，而不会影响基于H.264视频通信系统的兼容性。承载SEI消息的NALU叫做SEI NALU。一个SEI NALU含有一个或多个SEI消息。每个SEI消息含有一些变量，主要是载荷类型(payloadType)和载荷大小(payloadSize)，这些变量指明了消息载荷的类型和大小。在H.264AnnexD.8，D.9中定义了一些常用的H.264SEI消息的文法和语意。NALU中包含的载荷叫做原始字节序列载荷(Raw-Byte Sequence Payload，简称“RBSP”)，SEI是RBSP的一种类型。

SEI的数据表示区域简称为SEI域。每个SEI域包含一个或多个SEI消息，而SEI消息又由SEI头信息和SEI有效载荷组成。SEI头信息包括两个字段:一个给出SEI消息中载荷的类型，另一个给出载荷的大小。当载荷类型在0到255之间时用一个字节0x00到0xFE表示，当类型在256到511之间时用两个字节0xFF00到0xFFFE表示，当类型大于511时表示方法以此类推，这样用户可以自定义任意多种载荷类型。其中类型0到类型18标准中已定义为特定的信息如缓存周期、图像定时等。由此可见H.264中定义的SEI域可根据需求存放足够多的用户自定义信息。对于不支持解析这些用户自定义信息的H.264解码器，会自动丢弃SEI域中的数据。因此，在SEI域内记入有用的自定义信息不会影响基于H.264视频通信系统的兼容性。

如前所述多媒体通信不仅要求媒体压缩编码效率高，而且要求网络传送的实时性。目前多媒体流传送基本上都是采用实时传送协议(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 3984:RTPPayload Formatfor 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的承载性能更好，是一个很值得研究和有很大应用价值的问题。

RFC 3984规范所提出的RTP承载H.264的NAL层数据的方法是目前主流传送方法，该方案在RTP协议(RFC 3550)的基础上，将NAL层数据封装在RTP净荷中进行承载。NAL层位于VCL和RTP之间，规定要把视频码流按照定义的规则和结构，分割成一连串的NAL数据单元(NAL Units，简称“NALU”)。在RFC 3984中定义了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)，占1比特，P如果置位，则表示数据包末尾包含一个或多个填充字节(Padding)，填充不属于有效载荷的一部分；

X字段为扩展标识比特(Extension)，占1比特，X如果置位，则RTP头的最后必须跟一个可变长的头扩展(如果有CSRC列表，头扩展要跟在其后)，主要是保留用于某些应用环境下头信息字段不够用的情况，该头信息扩展包含一个16比特的长度字段来计数扩展中有多少个32比特长的字，头扩展的前16比特是左开放的，以便区分标识符和参数，这16比特的格式由具体的层面规范定义，该头扩展的格式定义在RFC 3550第5.3.1节中有详细描述。

CC字段为贡献源数目(CSRC Count)，占4比特，指明头信息最后面的CSRC标识符的个数，接收方根据CC字段可以确定头信息后面的CSRCIDs列表长度；

M字段为标识比特(Marker)，占1比特，该标识比特的解释在特定的层面(Profile)中定义，它允许标识出数据包流中的重要事件，一个层面可以定义附加的标识比特或规定没有标识比特，这里所谓层面就是指具体的应用环境设置，由通信双方具体协定，不受协议的限定；

PT字段为载荷类型(Payload Type，简称“PT”)，共7比特，标识RTP载荷的格式并确定他在应用程序中的解释；标志比特和载荷类型共一个字节携带层面规定信息，这个字节可能会被具体层面重新定义以适应不同需求，在具体应用中可以定义所谓的profile，其实就是一组静态(即通信双方事先约定好的)对应关系，将PT比特不同的取值和不同的媒体格式对应起来。当然也可以通过RTP之外的信令来进行动态协商定义PT取值和媒体格式之间的关系。在一个RTP会话(Session)中，RTP源是可以变更PT的。

接着的字段就是序号共16比特，每发送一个RTP数据包，该序号值加一，这样接收者可以用它来检测数据包丢失和恢复数据包顺序，一次通信中的序号初始值可以随机给定，不影响通信。

时间戳占32比特，它反映了RTP数据包中第一个字节的采样时间，这里的采样时间必须来源于一个单调线性增长的时钟，接收方根据其调整媒体播放时间或者进行同步。

同步源SSRC ID占32比特，其具体值可随机选择，但要确保同一个RTP会话中的唯一性，即能唯一标识一个媒体源，如果一个源改变了源传送地址，必须选择一个新的SSRC标志符。

贡献源CSRC列表，可以根据需要为0-15项，每项占32比特，该列表的长度即CSRC ID的数目正好由CC字段的4个比特标出。事实上，用于标识某个媒体源的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_比特)，占1比特，用于标识语法错等情况，如果有语法冲突则置为1，当网络识别此单元中存在比特错误时，可将其设为1，以便接收方丢掉该单元，主要用于适应不同种类的网络环境(比如有线无线相结合的环境)；

NRI字段定义为NAL参考标识(nal_ref_idc)，占2比特，用于指示NALU数据的重要程度，其值为00表示NALU的内容不用于重建帧间预测的参考图像，而非00则表示当前NALU是属于参考帧的条带(slice)或序列参数集(Sequence Parameter Set，简称“SPS”)、图像参数集(PictureParameter Set，简称“PPS”)等重要数据，该值越大表示当前NAL越重要；

Type字段定义为NALU类型(Nal_unit_type)，共5比特，可以有32种NALU的类型，其值和具体类型的对应关系在表1中详细给出。

表1 NALU头信息中Type字段取值与类型对应关系表

Type值	NALU内容的类型
Type值	NALU内容的类型	0	未指定
1	非IDR图像的编码slice	0	未指定
1	非IDR图像的编码slice	2	编码slice数据划分A
3	编码slice数据划分B	2	编码slice数据划分A
3	编码slice数据划分B	4	编码slice数据划分C
5	IDR图像中的编码slice	4	编码slice数据划分C
5	IDR图像中的编码slice	6	SEI(补充增强信息)
7	SPS(序列参数集)	6	SEI(补充增强信息)
7	SPS(序列参数集)	8	PPS(图像参数集)
9	接入单元定界符	8	PPS(图像参数集)
9	接入单元定界符	10	序列结束
11	码流结束	10	序列结束
11	码流结束	12	填充数据
13-23	保留	12	填充数据
13-23	保留	24-31	未指定

可见，NALU的头信息的一个字节中给出的信息主要包含NALU的有效性、重要性等级，根据这些信息可以确定RTP所承载的数据重要性。

当前H.264/RTP的多媒体通信框架下，主要通过运用配合控制协议RCTP来完成服务质量(Quality of Service，简称“QoS”)监测的，以及基于此的拥塞控制和流量控制。RTCP主要用于RTP协议的控制和报告。报告的主要内容就是和QoS相关的信息。RTCP采取的报告方法是周期性报告，即周期性向两方或多方会话(Session)中的所有参与方传送控制数据包，报告采用和RTP数据包同样的分发机制。底层协议提供数据和控制数据包的多路复用(例如各自使用单独的UDP端口号等)。在RFC 3550文件中，建议为RTCP而增加的会话带宽为媒体带宽的5％。

下面介绍RTCP数据包的类型和结构。RTCP中定义了以下几种RTCP数据包类型来携带多种控制信息:发送方报告(Sender Report，简称“SR”)，有关主动发送方的传送和接收的统计信息；接收方报告(Receiver Report，简称“RR”)从不是主动发送方的参与方接收统计信息；资源描述项(SourceDescription，简称“SDES”)，里面包括CNAME；参与方结束(退出)标识(BYE)；专用功能(Application-specific function，简称“APP”)。

RTCP发送和接收报告的包结构如图3所示，可以按内容类型分为三段，最前面的是头信息，接着是发送方信息，其次是报告内容块，最后的是特定层面(Profile)的扩展(所谓层面表示针对某种特定应用场景需要而制定的具体规则特例)。图3中示出的各个具体字段的意义及全称详细描述如下:

V字段为版本信息(Version，简称“V”)，占2比特，当前RTCP的版本号为V＝2；

P字段为填充标志比特(Padding)，占1比特，如果P置位，则表示这个RTCP数据包在尾部包含一些不属于控制信息的附加的填充字节，但这些字节计算在长度字段中；

RC字段为接收报告计数(Reception Report Count，简称“RC”)，占5比特，数据包中包含的接收报告块的数目，允许为0；

PT字段为数据包类型(Payload Type，简称“PT”)，占8比特，取值200的时候标识这是一个SR数据包；

长度(Length)字段，占16比特，等于RTCP数据包以32-比特字(32bitWord)为单位的长度减1，包含头和任何填充；

发送方的SSRC，占32比特，指示这个SR数据包的发起者的同步源标识符(Synchronous Source Identifier，简称“SSRC”)，这里的同步源唯一标识一个媒体数据源，比如一路视频的源；

NTP timestamp字段为网络时间协议时间戳(Network Time Protocol，简称“NTP”)，占64比特，当该报告发送之后，指示了wallclock(绝对日期和时间)，与RTP时间戳结合使用；

RTP timestampe字段为RTP时间戳，占32比特，即RTP协议产生的时间戳；

发送方的数据包计数字段，占32比特，指示从发送建立到产生这个SR数据包期间发送方传送的RTP数据包总数；

发送方字节计数字段，共32比特，指示从发送建立到产生这个SR数据包期间，发送方在RTP数据包中传送载荷(Payload)的总字节数(不包括头或填充)，该字段可以用来估算载荷的平均速率；

之后的字段包含了0个或多个接收报告块，具体块个数依赖于从上个报告发送方得知的其它源数目，每一个接收报告块传递从单个同步源收到的RTP数据包的统计信息，这些统计信息包括:

碎片丢失(fraction lost)占8比特，表示继上一个报告发送后，来自该源的媒体的丢失碎片数；累积丢失包数，占24比特，表示开始接收以来累积丢包的数目；

其次就是接收到的扩展最大序号、到达时延抖动，都反映网络传送状况；

上一个SR(Last SR，简称“LSR”)占32比特，是指该源上一个SR报告的时间戳标记，取值为上一个SR的NTP的中间32比特；

自上一个SR以来的时延(Delay since Last SR，简称“DLSR”)，占32比特，是指自上一个SR到这个SR期间的时间间隔长度，这个参数是用来计算QoS报告的关键参数。

接收报告(RR)数据包格式同发送报告(SR)的区别是:数据包类型字段的值为201；没有发送方信息部分。

根据RTP/RTCP协议标准，RTCP完成四项功能如下:

基本功能，为实时多媒体数据传送质量提供反馈报告机制，这是RTP作为传送层协议的有机组成部分，这种反馈功能通过RTCP来传递发送方报告(SR)和接收方报告(RR)来实现；

RTCP为每一个RTP源传送一个永久传送层标识，称为规范名(CanonicalName，简称“CNAME”)，SSRC标识在发现冲突或程序重启时可能发生改变，因此接收方需要通过CNAME来跟踪每个参与方；

前两项功能需要所有的参与方都发送RTCP数据包，因此为了让RTP能按比例地增加参与方的数目，必须控制RTCP数据包的速率；

第四项为可选功能，即传送尽可能少的控制信息。

可见，采用RTCP协议传送QoS报告，按照RTCP协议规定的报告内容来报告这些QoS信息，基于此实现对H.264等承载媒体的QoS监测。

然而应该指出的是，RTCP在带来能够提供QoS报告机制的同时，因为采用周期性报告方法，导致了额外网络带宽的开销，最高可以达到5％。如果网络出现拥塞(Congestion)，导致传送QoS下降，那么RTCP产生的额外流量将使得问题更加恶化。

在了解了H.264/RTP及其基于RTCP的服务质量监测的传送结构之后，下面简单介绍有关于视频网络传送的错误弹性和相关技术背景。

H.264视频是未来多媒体通信的主要协议，未来的多媒体通信应用的网络主要是以IP为代表的数据包交换网络和无线网络。这两大类网络都无法提供很好的服务质量(Quality of Service，简称“QoS”)保证，因此视频在网络上传送必然会受到各种传送错误而丢包的影响，从而使得通信质量降低。这里面的一个最主要的问题是IP网络实现“尽力”(best effort)传送，并不能保证传送视频数据的QoS。特别是对经过高效压缩编码的H.264码流，问题更为突出。IP网络上的尽力传送不能保证实时视频通信的QoS，具体表现在三个方面:数据包丢失、时延和时延抖动。其中，数据包丢失对恢复视频的质量影响最大，由于H.264压缩编码算法使用运动估值和运动补偿技术，一旦有数据包丢失存在，不仅影响当前解码图像，而且会影响后续解码图像，即误码扩散。误码扩散对恢复视频质量的影响非常大，只有结合编码端和解码端联合抗误码，才能完全避免误码扩散。

错误弹性(Error Resilience)是指传送机制具有预防错误发生或者在错误发生后能够以一定能力纠正的能力(错误强度在一定范围内，可以完全纠正；超过一定范围，只能部分纠正)。在未来的广泛(可以说无所不在)的多媒体通信环境中，一种视频传送机制是否具有错误弹性将是非常关键的。

存在多种错误弹性机制，比如前向纠错(Forward Error Correction，简称“FEC”)、自动重发请求(Automatic Retransmission Request，简称“ARQ”)、错误掩盖(Error Concealment)、信源信道联合编码(Joint Source-ChannelCoding，简称“JSCC”)、交织(Interleaving)及消除误码扩散等。对于H.264视频在数据包网络上传送，FEC是一种很实用的技术，效果很好。该方法主要采用多种纠错编码来对于要保护的数据进行编码，实质是形成数据冗余，从而增加抗御错误的能力。

在数据包网络上主要的错误是丢包错误，这种错误在纠错编码理论中叫做删除错误(Erasure Error)。针对删除错误的纠错编码是一大类叫做纠删码(Erasure Codes)。所谓纠删码就是把数据码流顺序逐段分割成大小相同的一个个单元(Unit)，也叫做数据节点(Data Nodes)，为表示方便，假设共有n个数据节点。然后按照一定的数学运算规则对于这些数据节点进行计算产生出校验节点(Parity Nodes或Check Nodes)，为了增强保护能力，还可以对于这些校验节点继续按照相同或者不同的数学运算规则运算产生出第二层校验节点，依次类推，可以生成第三层，第四层，直至第N层校验节点。

一般来说，如果涉及多层校验节点，每层上的节点数目相对于上一层是按照一定规律(最常见的是等比规律)递减的，这样就行成一个逐层递缩的多层节点结构。可以形象地表示为一个向右转90度的金字塔。其中，最左边是数据节点层，向右排列依次是第一层校验节点，第二层校验节点，......，第N层校验节点。

其中一类纠删码具有一种非常重要的性质，即处理需要的时间复杂度是和数据节点数n存在线性关系，因此叫做线性时间特性(linear-time)。而很多其它的纠删码比如著名的Reed-Solomon码需要的时间复杂度就要高得多，是n^*log2n^*log(logn)数量级的。因此，具有线性时间性的纠删码其在实时通信中的用途要好得多。

Tornado纠删码(下文均简称Tornado码)是1998年前后出现的一种的新型纠删码。Tornado码结构简单；运算高效，因为它具有线性时间性；保护能力强。在实际应用中，获得了很好的效果。目前已经获得较为广泛的应用。根据最新的ITU-T动态，其中的SG16目前正在考虑对于错误控制编码类(Error Control Codes)技术进行标准化的可能性，主要是针对视频音频网络传送进行保护。Tornado码及其多个变种很可能是其中的重要技术。

在Tornado码中，从数据节点逐层产生出多个校验节点层。校验节点和数据节点都由发送端通过网络发送给接收端。如果在网络传送过程中，部分节点丢失了，因为上层节点参加了下层节点的生成，因此上层节点的信息已经包含在了下层节点以及更下层节点中，因此丢失节点的信息可以通过足够多数目的下层节点或者更下层节点来完全恢复。如果每个节点是一个包，则丢失的包可以由正确接收到的其它包完全恢复。设数据节点个数为n，产生的校验节点数为1。则定义纠删码的码率和冗余率分别是:r＝n/(n+1)，1-r＝1/(n+1)；在其它条件相同情况下(保护能力，造成的延迟等)，码率越高(必然地，冗余率越低)，则纠删码的效率越高。

图4示出了一种典型的Tornado码数据节点及各层校验节点间的关系。图中节点之间的连线称为边，表示边的左侧节点参与计算右侧节点，可见前后两层节点之间是一种多对多的逻辑关系。设数据节点个数为n，总的校验节点个数为m，则定义纠删码的码率r＝n/(n+m)和冗余率1-r＝m/(n+m)，在相同情况下(保护能力，造成的延迟等)，码率越高、冗余率越低，则纠删码的效率越高。Tornado码的结构和性能主要由三个因素决定:(a)数据节点的数目以及逐层递缩的规律，一般按等比例递缩；(b)产生下一层节点的计算方法；(c)相邻两层节点之间的关联关系。

Tornado码各个参数之间可以推得以下关系，数据节点的数目设为n，校验节点数目设为m，递缩比例设为p，校验节点层数为i，则前i-1层校验节点的数目分别为np、np²、...、np^i-1，而最后一层即第i层的数目定为npⁱ/(1-p)，这样得到总节点数n+m＝n+n+np²+..+np^i-1+npⁱ/(1-p)＝n/(1-p)，则有m＝np/(1-p)，即为递缩比例与校验节点数之间满足的隐含关系。因为要保证每层的节点数np、np²、...、np^i-1及npⁱ/(1-p)都是整数，即可根据给定的i和p计算出n的可行值，比如i＝4，p＝1/2，则可以推算出n必须为16的倍数。

Tornado码产生过程中最常采用的计算方法是异或运算，因为异或运算具有很方便的恢复功能。对于两个等长的比特序列A＝[a₀，a₁，a₂，.....，a_L]，B＝[b₀，b₁，b₂，.....，b_L]，按比特进行异或运算得到同样长的比特序列C，则有以下性质:A与C异或得到B，B与C异或得到A；同样的对于多个序列之间的异或运算，也有相应的恢复方法。可见，经过异或运算后，数据节点或者校验节点之间即建立相互联系，任意一个节点丢失后，均可由所有其余节点恢复。由于最后一层校验节点的递缩比例不同，因此一般采用常规的纠错编码策略进行计算，比如Reed-Solomon码。

Tornado码的另一个重要因素就是前后层之间的关联关系，即下层的某个节点是由前一层的哪些节点计算得到的。根据图论，前后两层节点之间形成一个二部图，任意一条边的两端分别在前一层和后一层，前一层节点也称为左侧节点，后一层节点称为右侧节点，每个节点与其关联的边的条数称为度。根据Luby等人的随机图论数学证明，决定Tornado码的保护能力的参数实际上是前后层构成的二部图的两侧节点的度的向量，而这个度向量是随机产生的。在实际应用中，Tornado编码之前需要先确定节点度向量的随机分布，然后按照该分布随机匹配产生各级二部图，根据二部图左右节点间的关联即确定了前后层节点之间的关联关系。

在目前的Tornado码策略中，通过给定保护能力和其它要求，比如数据节点大小合理性，可以接受的最大网络延迟等，确定参数n，m，i，p等，并给定节点度向量的随机分布，并可进行Tornado编码。在接收端进行解码时，根据每一级的二部图，如果有一个右节点被正确接收，且与它相关联的所有左节点中只有一个节点丢失，那么该丢失的节点就可以通过这个右节点与所有未丢失的左节点恢复得到，即达到了纠错的效果。

其实，纠删码的范围很大，Tornado码只是其中比较典型的一种，另外还有比如RS(Reed-Solomon)码、低密度校验码(Low Density Parity Codes，简称“LDPC”)等。

纠删码的一个重要的性能指标就是其纠错能力(或者叫做保护能力)，直接体现为能够完全纠正丢包错误所允许的最大丢包数量(在一定包的总数前提下)，或者当丢包高于这个最大允许数量条件下，能够正确纠正包的百分比。一般来说，在其他条件相同情况下，保护能力越高，冗余率越高。

保护能力不仅适用于纠删码，在更大范围内，所有FEC编码都可以用保护能力来度量。在视频数据中，有些数据相对重要性高，比如视频序列的结构参数、图像的结构参数、头信息等；另外一些数据的重要性相对低，比如图像内容数据等。在使用FEC进行保护时，对于相对重要的数据采用保护能力较强的编码；而对于相对不重要的数据采用保护能力较弱的编码。这样可以在保护能力和效率之间达成平衡。不能一味强调保护能力，因为这样会导致很高的冗余，牺牲了效率。这种根据数据相对重要性来进行不同保护能力的FEC保护的方法叫做不等保护(Unequal Protection，简称“UEP”)。通过不等保护，容易实现视频通信服务的QoS保证。

不等保护的思想是对于多媒体数据中具有不同重要性(相对的)的数据采用不同保护能力/保护强度的保护机制进行保护。不同的保护机制可以指大类或者小类，比如大类在原理上不同，小类仅仅在结构或者参数上不同。分级保护是对于保护机制按照保护能力分成多个级别，这些级别可以是跨大类的，也可以是在一个大类中跨小类的，即仅仅是结构和参数上的不同。在网络传送中，网络状况随时间变化，这种变化规律是复杂的预先无法确定的，因此，分级保护其实是一种自适应的策略，根据网络瞬时的状况，按照一组预先定义的规则选择最优的保护措施。不等保护和分级保护是可以结合起来，形成更为复杂和强有力的保护策略的。

在实际H.264视频通信中，由于丢包等引起的删除错误导致图像质量退化是非常严重的，更甚于引起解码端系统的崩溃。这是由于H.264相对于其它视频编码标准来说能力更强、效率更高、功能更丰富，反过来对于删除错误的承受能力也更低。因此，在基于H.264标准的视频通信中，除了错误弹性保护策略之外，必须采用有效的抗丢包等删除错误的技术，并结合多种视频抗误码方法，来保证恢复图像的质量。

现有的抗丢包错误技术大体可以分为两类:(a)主动防错型:事先采取保护措施，比如引入冗余机制，尽量保证数据包不丢失或者确保接收端能够恢复少量丢失的数据；(b)错误补偿型:在发生误码情况下采取一定的补偿措施，比如在网络状况恶化严重情况下，丢包率非常高，主动防错方法失去效果，这时就需要对已经发生的误码进行补偿。

错误补偿的误码消除方法根据侧重点不同又分为错误掩盖和误码扩散消除两种。其中，错误掩盖是侧重于补偿误码当前的影响，比如接收端当前视频帧或者Slice丢失，则图像无法正确显示，即采取一定措施进行补偿，使得对于用户产生的影响最小。而误码扩散消除则是消除误码在空间和时间上扩散带来的后续影响，比如接收端收到的帧丢失或者部分丢失，由于该帧可能是后续帧的预测参考帧，其误码将会在时间域上扩散到后续帧中；或者由于H.264中可能存在的帧内预测，以及环路滤波，都可能使得该帧的误码通过空间预测扩散到该帧的其它位置。误码扩散消除就是采用一定的措施，在空间上要限制误码影响在有限区域内，在时间上要限制在有限时间内，避免视频通信失败，更甚于解码器系统工作紊乱和崩溃。

可见在误码环境下，误码扩散不仅使出错帧的恢复图像质量下降，而且可能会给后续帧造成不可恢复的损失，即使解码端使用了错误掩盖技术，也不能避免恢复图像质量的下降。另外，由于视频通信的实时性要求强，通常不采用ARQ方式重传发生错误的数据。

通过错误掩盖，即通过用发生误码部分在空间上和时间上相邻部分的正确数据进行简单代替或者复杂的预测，插值等掩盖错误部分的方法，可以解决补偿误码问题。这在接收端即可实现，无需发送端参与。而误码扩散问题则更加复杂，需要发送端和接收端配合起来采取适当的策略才能抑制和消除。

需要注意的是，错误掩盖也会导致误码扩散的产生。事实上，由于错误掩盖会造成编码端和解码端重构图像缓存内容不匹配，从而导致误码在时间域上的扩散。例如，当解码第n-1帧有丢包时，解码端会使用第n-2帧对应位置图像数据进行错误掩盖，而在发送端编码时并不知第n-1帧有丢包，会使用正确的第n-1帧图像来编码第n帧图像，而在接收端解码第n帧时却会用第n-2帧代替第n-1帧解码，由此引起误码扩散。

现有的H.264/RTP传送架构以及基于RTCP的QoS报告方法，采用RTP直接封装NALU进行传送，用RTCP的SR/RR报告监测QoS信息，前面已经介绍相关技术细节。

另外，现有技术中采用的Tornado码是一种比较复杂的方案。采用Tornado码实现基于H.261/H.263/H.263+/H.263++/H.264视频压缩编码的数据传送保护方法包括如下步骤:

在步骤1、设计Tornado码的结构。具体为:根据给定的保护能力、其它要求、具体的数据类型如音频还是视频、速率大小等因素决定数据节点大小为L1比特，根据具体应用中可以接受的最大网络延迟等因素确定数据节点数目n、总校验节点数目L、中间校验层的层数m、各层之间节点数目的递缩比例因子

等，确定任何相邻两层的节点之间的二部图的左边度分布向量和右边度分布向量。

到步骤2、根据上述左边度分布向量和右边度分布向量采用随机图匹配的方式生成每个相邻两层节点之间的随机二部图。

到步骤3、开始数据传送过程，发送端的H.261/H.263/H.263+/H.263++/H.264视频编码器产生数据码流，这个数据码流是需要进行数据传送保护的。

到步骤4、把需要保护的数据码流，分割成具有L1比特的大小相等的数据节点D₀、D₁、D₂、D₃....D_T。

到步骤5、令t＝0。

到步骤6、获取D_t、D_t+1....D_t+n-1共n个数据节点。

到步骤7、根据步骤2确定的相邻两层节点之间的随机二部图为上述n个数据节点D_t、D_t+1....D_t+n-1逐层生成各个中间校验节点层MC⁽⁰⁾、MC⁽¹⁾...MC^(m)和最后校验节点层FC。

到步骤8、将数据节点D_t、D_t+1....D_t+n-1和通过步骤7生成的各校验节点层中的校验节点全部通过UDP/IP或者TCP/IP等网络打包方式打包后发送至接收端。

到步骤9、发送端根据t、T的数值判断所有的数据节点是否处理完毕，如果所有的数据节点已处理完毕，到步骤10；否则，t＝t+n，到步骤6。

在步骤10、发送端的通信过程结束。

由于在实时通信过程中发送端往往是一边进行编码压缩一边发送的，所以上述步骤3至步骤8表示的并不是时间上的先后顺序，而是逻辑上的先后顺序。

上述过程是对发送端进行描述的，对于接收端，在接收端接收到一批数据节点和校验节点后，首先应判断哪些数据节点是应该收到而实际上丢失了、并可恢复的数据节点，然后，对于上述丢失了的且可恢复的数据节点按照Tornado码的一般解码过程进行解码恢复。接收端重复上述接收并恢复过程，直到通信过程结束。

另外，现有的误码消除方法都是独立的错误掩盖方法或者误码扩散消除方法，都有很多种实现技术细节不同的方法。错误掩盖方法有时间域掩盖、空间域掩盖、时空联合掩盖等。误码扩散消除又有帧内编码、标识、自适应帧内块刷新等。

时间域掩盖方法就是采用时间轴上相邻的帧的信息来推算丢失数据。推算的方法可以是:简单采用相邻帧相同位置的数据代替丢失数据；考虑运动预测因素，根据相邻帧数据进行运动预测。除此还有更加复杂的掩盖策略，但是计算量非常大。

空间域掩盖方法就是利用丢失数据区域的空间相邻区域来进行错误掩盖。同样的有:简单用领域替代；基于数据融合的有多个空间相邻区域推算丢失数据，比如空间插值；代数反演法，把丢包过程用一个线性模型建模，其输入是丢包前数据，输出是正确接收到的数据，利用代数反演的方法，比如最小二乘法，从输出来反演输入，用反演结果来替代错误数据，这种方法计算量大。

时空联合掩盖方法则是联合使用空间域和时间域的错误掩盖。比如，根据丢失数据的特点和相邻时间数据和空间数据的情况，采用某种策略确定用空间域掩盖还是时间域掩盖更好，然后实施这种更好的掩盖策略。或者，融合空间数据和时间数据，共同进行掩盖。

基于帧内编码的误码扩散消除方法是将受误码影响的宏块采用帧内编码，即利用运动矢量的前向依赖关系进行准确误码跟踪，并对受误码影响的宏块采用帧内编码，可以有效地防止误码扩散。首先给出由于运动补偿所引起的帧间依赖性；然后根据运动矢量前向依赖性和权重因子的相关性计算误码的“能量”，对“能量”最大的宏块使用帧内编码，从而防止误码扩散。

基于标识的误码扩散消除方法是将受误码影响的宏块做标识，使得编码时避免采用标识过的宏块做参考帧，直接防止了扩散。该方法需要建立重发送端到接收端的反馈机制，接收端将丢失数据的信息反馈到发送端，编码端根据错误信息将同一块组中出错宏块以后的像素全部用一个特定的值来标识，在之后的若干帧的编码中不参考已标识的区域，避免了接收端的误码扩散。

基于自适应帧内块刷新策略的误码扩散消除方法是基于编码端的“误码灵敏性尺度”来衡量每一个编码宏块对信道误码的易损性，然后进行自适应的帧内块刷新。该方法不需要反馈信道。编码端先初始化“误码灵敏性尺度”值:距离同步标志越远的宏块，对误码的敏感性越高；编码宏块的比特数越多，越容易受到误码破坏。在编码过程中，通过计算每个宏块“误码灵敏性尺度”值的积累来更新这个尺度，然后根据ESM尺度选择宏块进行帧内编码。

此外，现有技术中由于没有方便的能够提供网络状况监测的方案以及数据相对重要性的描述，都没有实现多级保护和不等保护。

在实际应用中，上述方案存在以下问题:现有技术中的Tornado码方案过于复杂，效率低，应用于视频数据的保护，延时大，无法满足实时通信的性能要求。

同时缺乏一种能够报告网络状况的机制，因此，通信双方无法根据网络状况来决策采用合适的保护机制，从而不等保护和自适应分级保护都无法有效使用，多媒体通信的可靠性不能达到要求。

而且错误掩盖和误码扩散消除两种方法没有很好的统一起来，有的时候相互矛盾，其作用相互抵消。

现有技术中，H.264 NAL和RTP协议的联合工作机制缺乏，如何基于H.264 NAL和相应的RTP封装方法来提供保护机制没有定义，是一个空白。进一步来说，好的方法，比如高效率的Tornado编码和其他保护措施、以及不等保护和自适应分级保护等现在还不能应用于H.264视频数据。

现有技术没有能够利用H.264的消息扩展机制来实现网络状况和QoS信息的报告，缺少这种机制，很多好的技术就没有了应用的必要前提条件。

现有技术都比较零散，缺乏集成，彼此的效果没有相互增强。同时很多技术还停留在学术探讨阶段，没有进入到通信协议层面的定义和开发，影响了实际应用。在这些技术的整合上，必须考虑实时通信性能要求的约束，选择的技术必须要性能好同时计算不能过于复杂。

造成这种情况的主要原因在于，现有技术用固定的纠删码策略保护视频通信流，无法适应网络通信变化；错误掩盖方法采用的替代机制会引起误码扩散；误码扩散消除方法都需要复杂的机制或者额外的反馈信道，耗费系统处理资源和网络带宽资源。

现有技术方案中将NALU的头信息完全封装在净荷当中，使得RTP协议无法直接获知有关净荷的属性、级别、重要程度等，从而无法实现基于此的QoS机制。其次，这样的封装格式还造成了NALU头信息占用净荷资源，因为每个NALU的都附带头信息，导致在很多情况下，由于一个RTP中多个相同类型的NALU的头信息都是一样的，从而浪费了RTP传送带宽资源。

H.264/RTP的多媒体通信框架采用了一种通用的配合控制协议RTCP来传送QoS报告，以实现QoS监测，然而RTCP本身对于H.264这样的特定视频通信应用不一定是最合适的，由于其本身的带外重开逻辑通道来传送QoS报告，影响了网络状况，导致了矛盾的产生。

关键的地方在于，现有技术没有实现传输层的错误弹性保护策略，无法提供多媒体传送的可靠性和通信质量。

发明内容

有鉴于此，本发明的主要目的在于提供一种多媒体通信方法及其终端，实现不等保护，方便于QoS保证的实现。

为实现上述目的，本发明提供了一种多媒体通信方法，其通信过程包含以下步骤，

A 发送端根据基于实时传送协议的错误弹性保护策略对多媒体数据进行保护，并将其发送给接收端，所述错误弹性保护策略的相关信息携带在封装所述多媒体数据的错误弹性实时传送协议包中；

B 所述接收端接收所述多媒体数据，在出现传送错误的情况下，按所述封装所述多媒体数据的错误弹性实时传送协议包携带的错误弹性保护策略恢复或部分恢复所述多媒体数据。

其中，其通信过程还包含以下步骤，

C 所述接收端统计通信质量，生成服务质量报告，将其发回给所述发送端；

所述步骤A中，所述发送端根据所述服务质量报告调整所述错误弹性保护策略。

此外在所述方法中，其通信过程还包含以下步骤，

D 所述接收端统计传送错误信息，并且实施错误掩盖策略；

所述步骤C中，所述接收端还将所述传送错误信息反馈给所述发送端；

E 所述发送端根据所述传送错误信息实施误码扩散消除策略。

此外在所述方法中，所述步骤A包含以下子步骤:

A1 发送端选择错误弹性编码方案对多媒体数据进行前向纠错编码；

A2 所述发送端用错误弹性实时传送协议封装编码后的多媒体数据，并在所述错误弹性实时传送协议包头信息中携带所述错误弹性编码方案相关信息，然后发送到接收端；

所述步骤B包含以下子步骤:

B1 所述接收端将收到的错误弹性实时传送协议包去封装，并从所述错误弹性实时传送协议包头信息中提取所述前向纠错编码方案相关信息；

B2 如果在传送过程中发生了数据节点对应的错误弹性实时传送协议包的丢失，那么所述接收端根据所述错误弹性编码方案相关信息，选择所述前向纠错解码方案进行前向纠错解码，恢复或者部分恢复所述丢失的多媒体数据；如果没有发生数据节点的丢失，则不需要进行前向纠错解码。

此外在所述方法中，所述前向纠错编码后的多媒体数据分为数据节点和校验节点两类。

此外在所述方法中，在所述步骤A1中，所述发送端至少根据以下因素之一选择所述前向纠错编码方案:

当前网络传送状况、和待发送多媒体数据的服务质量等级，其中待发送多媒体数据的服务质量等级取决于不同数据的相对重要性。

此外在所述方法中，所述错误弹性实时传送协议包头信息中包含:

错误弹性实时传送协议标识字段，用于指示以区别于实时传送协议；

前向纠错编码类型字段，用于指示所述前向纠错编码方案采用的前向纠错码类型；

前向纠错编码子类型字段，用于指示所述前向纠错编码方案的相关参数设置；

数据包长度字段，用于指示所述前向纠错编码方案在对所述多媒体数据进行前向纠错编码后得到的节点的长度；

数据包数目字段，用于指示该错误弹性实时传送协议包所承载的所述节点的数目。

此外在所述方法中，在所述步骤A1中，所述发送端将至少一个所述H.264网络抽象层单元划分为等长的至少一个数据节点，然后对其进行前向纠错编码，得到至少一个校验节点；

在所述步骤A2中，所述发送端将所述数据节点和所述校验节点分组封装在至少一个所述错误弹性实时传送协议包中进行发送；

在所述步骤B1中，所述接收端在接收到所述错误弹性实时传送协议包后，去封装得到所述数据节点和所述校验节点；

在所述步骤B2中，如果发生了传送过程中的数据节点丢失，则所述接收端根据所述校验节点对所述丢失的数据节点进行基于前向纠错解码的恢复或者部分恢复，并划分得到所述H.264网络抽象层单元。

此外在所述方法中，在开始传送之前，还包含步骤，

所述发送端和所述接收端协商确定:对于各种所述前向纠错码类型，所述前向纠错码子类型字段的取值与其所指示的该种前向纠错码的相关参数设置的对应关系。

此外在所述方法中，所述发送端和所述接收端都根据所述前向纠错编码子类型字段指示的对应关系建立对应关系表，用于根据所述前向纠错编码类型字段和所述前向纠错编码子类型字段查询所对应的前向纠错编码或前向纠错解码处理模块；

在所述步骤A1中，所述发送端调用相应前向纠错编码处理模块进行前向纠错编码；

在所述步骤B2中，所述接收端调用相应前向纠错解码处理模块进行前向纠错解码。

此外在所述方法中，在所述步骤A1中，所述发送端根据所述H.264网络抽象层单元的头信息中的网络抽象层参考标识字段和网络抽象层单元类型字段中的任意一者或两者的组合，以及任何其他可以事先定义的规则来评估对应数据的相对重要性，从而确定所述服务质量等级，进而选择所述前向纠错编码方案，确定所述前向纠错编码类型字段和前向纠错编码子类型字段。

此外在所述方法中，在所述步骤A中，所述发送端根据所述接收端反馈的传送报告评价所述网络传送状况，进而选择所述前向纠错编码方案，确定所述前向纠错编码类型字段和前向纠错编码子类型字段。

此外在所述方法中，所述错误弹性实时传送协议包头信息中的版本信息字段取值为二进制值“11”或十进制值“3”，以区别于实时传送协议；

所述前向纠错编码类型字段位于贡献源标识符列表之后，占4比特；

所述前向纠错编码子类型字段位于所述前向纠错编码类型字段之后，占9比特；

所述数据包长度字段位于所述前向纠错编码子类型字段之后，占11比特；

所述数据包数目字段位于所述数据包长度字段之后，占8比特。

此外在所述方法中，所述步骤A中，所述发送端将头信息相同的至少一个网络抽象层单元去掉其头信息后再一起进行划分、编码和封装入所述错误弹性实时传送协议包，并将该网络抽象层单元所具有的相同头信息综合在该错误弹性实时传送协议包的头信息中；

所述步骤B中，所述接收端从接收到的所述错误弹性实时传送协议包的头信息中获取所承载的头信息，并添加到从所述错误弹性实时传送协议包提取出的剥离了头信息的网络抽象层单元的头部，获得完整的网络抽象层单元；如果存在传送错误，则根据预置策略有进行前向纠错解码恢复或者部分恢复数据节点，然后再从中提取出网络抽象层单元。

此外在所述方法中，在所述错误弹性实时传送协议头信息中，所述网络抽象层单元头信息中的网络抽象层参考标识字段和类型字段填充在所述错误弹性实时传送协议包头信息的净荷类型字段中，该净荷类型字段位于所述错误弹性实时传送协议包头信息的第2个字节的后7比特。

此外在所述方法中，所述错误弹性实时传送协议标识字段为所述错误弹性实时传送协议包头信息的版本信息字段，该版本信息字段位于所述错误弹性实时传送协议包头信息的第1个字节的前2比特。

此外在所述方法中，在所述错误弹性实时传送协议封装格式中，所述网络抽象层单元头信息中的禁止比特字段填充在所述错误弹性实时传送协议包头信息的标记字段中，该标记字段位于所述错误弹性实时传送协议包头信息的第2个字节的前1比特；

且在所述步骤B中，接收端根据所述错误弹性实时传送协议包的标记字段判断其所承载的网络抽象层单元是否出错。

此外在所述方法中，在所述步骤A、B中，所述错误弹性实时传送协议标识为所述错误弹性实时传送协议包头信息的标记字段取值，该标记字段位于所述错误弹性实时传送协议包头信息的第2个字节的前1比特。

此外在所述方法中，所述步骤A包含以下子步骤:

所述发送端首先判断至少一个所述网络抽象层单元的头信息中的禁止比特字段是否有效，据此将其分为正常网络抽象层单元和出错网络抽象层单元；

然后按所述错误弹性实时传送协议封装格式将所述正常网络抽象层单元封装成所述错误弹性实时传送协议包，并设所述错误弹性实时传送协议标识；

按所述实时传送协议封装格式将所述出错网络抽象层单元封装成所述实时传送协议包；

所述步骤B包含以下子步骤:

所述接收端首先判断接收到的包的头信息是否设所述错误弹性实时传送协议标识，将其分为所述错误弹性实时传送协议包和所述实时传送协议包；

然后根据所述错误弹性实时传送协议封装格式处理所述错误弹性实时传送协议包，根据所述实时传送协议包封装格式处理所述实时传送协议包。

此外在所述方法中，所述步骤C以下子步骤，

C1 所述接收端统计生成所述服务质量报告；

C2 所述接收端用H.264扩展消息承载所述服务质量报告，发给所述发送端。

此外在所述方法中，所述H.264扩展消息为补充增强信息；

所述服务质量报告在所述补充增强信息中的封装格式如下:

第1个字节为载荷类型字段，用于指示载荷为对应服务质量报告；

第2、3个字节为载荷长度字段，用于指示对应服务质量报告长度；

第4个字节及以后为载荷，用于填充对应服务质量报告。

此外在所述方法中，所述服务质量报告分为发送方报告和接收方报告，由所述载荷类型字段指示区分；

当所述服务质量报告被填充于所述补充增强信息的载荷中时，所述补充增强信息的载荷包含:

版本信息字段，占2比特；

填充字段，占1比特，用于指示是否有填充内容；

接收报告数字段，占5比特，用于指示该服务质量报告中所报告接收报告块数目；

发送方同步源标识符字段，占32比特，用于标识该服务质量报告的发送方；

当所述服务质量报告为发送方报告时，还包含发送方信息块，用于描述该服务质量报告的发送方的相关信息；

包含至少一块所述接收报告块，用于描述来自不同源的多媒体统计信息；

包含特定层面扩展，用于特定层面的保留功能扩展。

此外在所述方法中，用于承载所述服务质量报告的所述补充增强信息进一步由抽象网络层单元承载；

所述通信终端根据所述服务质量报告传送的可靠性要求设置该抽象网络层单元的网络抽象层参考标识。

此外在所述方法中，所述通信终端根据当前网络状态和高层应用需求来动态调整所述服务质量报告的统计生成及发送的周期。

此外在所述方法中，当所述通信终端用所述补充增强消息混合承载至少一种媒体流的服务质量报告时，

该服务质量报告中包含所承载的至少一种媒体流相应的所述接收报告块。

此外在所述方法中，所述步骤C中，所述接收端根据接收到的所述视频流数据的网络抽象层单元序号，统计丢失的所述网络抽象层单元数目，生成所述服务质量报告，发回给所述发送端；

所述步骤A中，所述发送端根据所述丢失的网络抽象层单元序号，计算得到所述累计丢包率，据此调整所述错误弹性保护策略。

此外在所述方法中，所述接收端根据接收到的服务质量报告，分析计算网络状况参数；所述参数包括端到端的瞬时带宽、延时和抖动。

此外在所述方法中，所述发送端设置不同等级的错误弹性保护策略系列，在所述步骤A中根据所述服务质量报告选择使用相应等级的所述错误弹性保护策略。

此外在所述方法中，所述步骤C中，所述接收端根据接收到的所述视频流数据的网络抽象层单元序号，统计得到丢失视频流数据的定位信息，并将其发回给所述发送端；

所述步骤A中，所述发送端根据所述丢失视频流数据的定位信息，重新发送所述丢失视频流数据给所述接收端。

此外在所述方法中，在所述步骤E中，所述发送端根据所述传送错误信息获得所述丢失条带的定位信息，通过对该丢失条带进行分段逐次帧内编码，以实现所述误码扩散消除策略。

此外在所述方法中，所述分段逐次帧内编码包含以下步骤，

E1 从所述丢失条带中分割一组连续的宏块，组成新条带，剩余的所述宏块仍属于所述丢失条带，进入步骤E2；

E2 对所述新条带进行帧内编码，在下一帧时发送，在此之后该新条带做常规编码，进入步骤E3；

E3 在下一帧编码时，判断所述丢失条带是否还包含未处理的宏块，如果是，则返回步骤E1，否则结束帧内编码。

此外在所述方法中，在所述步骤E1中，每次分隔的所述一组连续宏块的大小满足:该组连续宏块进行帧内编码后，本帧的数据率在H.264数据率控制范围内。

此外在所述方法中，所述步骤D包含以下子步骤，

D1 所述接收端检测传送错误，并统计传送错误信息；

D2 所述接收端在发生传送错误后，进行视频信息重同步；

D3 所述接收端根据所述传送错误信息实施所述错误掩盖策略。

此外在所述方法中，所述步骤D1中，所述接收端根据网络抽象层单元序号的不连续情况来检测并统计传送错误信息。

此外在所述方法中，在所述步骤D1中，所述接收端根据所述网络抽象层单元序号的中断情况获得丢失条带的定位信息，该定位信息包含所述丢失条带所在的帧号和所述丢失条带在该帧的位置。

此外在所述方法中，所述错误掩盖策略包含步骤:所述接收端用所述丢失条带所在帧的前一帧的相应条带，来替代该丢失条带。

此外在所述方法中，所述错误弹性编码方案包含改进的“Tornado”纠删码；

所述改进的“Tornado”纠删码对于一组所述数据节点仅生成一层所述校验节点。

此外在所述方法中，所述步骤B中的传送错误包含数据包丢失、或随机比特错误。

本发明还提供了一种多媒体通信终端，包含用于实现多媒体通信的基本功能模块，其中包含至少包含用于实现多媒体编解码功能的编解码模块，还包含以下模块:

错误弹性实时传送控制协议模块，用于将通过所述编解码模块编码后的所述多媒体数据进行错误弹性保护后再在网络侧传送，对来自网络侧的所述多媒体数据进行纠错后再传给所述编解码模块进行解码，所述进行错误弹性保护的相关信息携带在封装所述多媒体数据的错误弹性实时传送协议包中。

其中，还包含以下模块:

保护方法和策略协商模块，用于负责在通信双方之间进行错误弹性保护策略协商，确定保护策略集合，供所述错误弹性实时传送控制协议模块选择；

前向纠错模块，用于实现至少一种前向纠错保护方法，维护所述前向纠错保护方法的相关参数，其中所述保护方法和策略协商模块控制所述前向纠错模块以实现不等保护和自适应分级保护功能，所述错误弹性实时传送控制协议模块通过调用该前向纠错模块实现错误弹性保护和纠错功能。

此外，还包含

错误掩盖模块，用于实现错误掩盖功能；

所述编解码模块用于实现H.264编解码标准，还用于误码扩散消除功能；

还包含网络状况分析计算模块，用于分析计算网络状况，并向所述错误掩盖模块和所述编解码模块提供信息。

此外，还包含

补充增强消息扩展处理模块，用于实现服务质量报告和网络状况报告功能，并将报告发送给所述网络状况分析计算模块。

此外，其传送层基于所述错误弹性实时传送协议/实时传送控制协议，用于实现支持错误弹性的多媒体传送功能；

其应用协议层包含保护机制和策略协商子层，用于实现分级保护和不等保护功能；

其H.264视频编码层包含补充增强消息扩展报告层，用于实现基于补充增强消息扩展的报告功能；

其H.264网络抽象层中包含前向纠错编码层，用于实现前向纠错编码功能。

此外，所述用于实现多媒体通信的基本功能模块包含以下之一或其任意组合:

主控模块，用于负责整个终端的控制；

用户接口模块，用于负责用户输入输出的交互和信息的显示；

网络通信模块，用于负责和网络进行通信，提供下层传送通道；

输入输出和底层驱动模块，用于负责对于硬件设备进行驱动；

业务模块，用于实现高层业务；

通信过程控制模块，用于控制通信过程；

应用协议模块，用于实现应用协议功能；

实时传送控制协议模块，用于实现实时传送控制协议功能；

H.264网络抽象层模块，用于实现网络抽象层功能；

音频编解码模块，用于实现音频编解码功能。

通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，采用了错误弹性实时传送协议(ERRTP)，在现有RTP基础上提供了可以携带错误弹性编码方案相关信息的传送层封装格式，使得多媒体数据在ERRTP上传送的同时标记其相应的错误弹性编码方案信息，从而将错误弹性机制融入传送层；

针对H.264NALU结构给出专用的ERRTP封装方法和协议头信息的改造方案，通过将同一个ERRTP包中的所有NALU的头信息字节结合到其头信息中，采用了一种巧妙的结合方式使得既不影响现有ERRTP协议及设备的运作，而且能够将NALU净荷的属性直接体现在ERRTP头信息中，一方面使得承载效率大大提高，另一方面提供了QoS机制实现的基础；

基于H.264消息扩展机制，通过接收端统计通信质量并反馈给发送端，直接采用高层媒体协议H.264本身的扩展消息机制来承载QoS报告信息，避免使用额外的信道，实现了一种＂带内＂QoS报告机制；

在发送端还可以根据当前网络状况和多媒体数据重要性等级等因素来选择采用各种备用的错误弹性编码方案，从而达到不等保护的目的，实现保护能力和传送效率的均衡；

在从接收端到发送端的反馈机制的基础上，实现不等保护和多种错误弹性方案的交替混合使用，发送端根据接收端反馈的QoS报告以及相关网络传送状况消息，选择使用不同等级的保护策略，另外基于从ERRTP头信息反映的数据重要性等级，也可以选择对不同等级的数据使用合适的保护策略；

针对H.264 NALU数据流，给出错误掩盖和误码扩散消除结合的方案，综合体现两种技术的优点，通过误码信息反馈机制和分段逐次帧内编码实现误码扩散消除；

还提供了一种高效的Tornado码方案，在确保数据传送保护能力没有显著下降的情况下，通过设置仅具有一层校验节点层的纠删码，减少了纠删码生成校验节点层的运算量，减少了数据传送延迟时间，使数据传送保护性能与代价比得到提高；

最后，将上述各种多媒体通信相关的增强技术整合在多媒体通信系统上，并模块化实现了各种技术及协议架构，各种技术相互协调工作，彼此进一步增强多媒体通信可靠性。

这种技术方案上的区别，带来了较为明显的有益效果，即ERRTP协议传送架构在传送层实现错误弹性机制大大简化错误弹性传送结构，节省了网络传送带宽；不等保护的实现，达到了保护能力和传送效率的均衡，方便于多媒体传送的QoS保证的实现，进一步提高服务质量，降低冗余、提高传送效率，实现了与现有技术的兼容，都提高了ERRTP这种新方法的健壮性；

基于H.264的消息扩展机制的QoS报告，在带内实现QoS监测，降低带宽开销，且降低系统实现的复杂性，提高目前H.264视频网络传送质量的报告机制的效果和效率，从而提升H.264视频网络传送质量；

不等保护和多级保护策略更加灵活、准确、及时地适应网络传送需求，提高保护能力，提高系统效率和可靠性，能保证统计信息精确无误而且节省系统资源；

结合错误掩盖和误码扩散消除，避免由错误掩盖引起的误码扩散，在简单复杂度前提下，达到理想的误码消除效果，提高视频传送质量，节省开销、简化机制，且保证系统兼容性；

使用改进的Tornado纠删码方案，提高数据传送保护性价比、提高数据传送效率、促进H.264等新技术应用；

将多种增强技术综合在多媒体通信系统中，共同提高多媒体通信质量，可以大大提高基于H.264的多媒体通信产品比如会议电视、可视电话在IP网络上应用的性能和用户体验，提高产品竞争力，带来显著的经济效益，有不可限量的实用价值。

附图说明

图1是RTP数据包的头信息结构示意图；

图2是RTP包净荷对NALU数据的封装格式示意图；

图3是基于RTCP协议的QoS报告数据包格式示意图；

图4是Tornado纠删码原理示意图；

图5是根据本发明的第一实施方式的支持错误弹性多媒体通信终端模块结构示意图；

图6是根据本发明的第一实施方式的多媒体通信协议栈结构示意图；

图7是根据本发明的第二、三实施方式的ERRTP数据包的头信息结构示意图；

图8是根据本发明的第四实施方式的承载QoS报告的SEI封装格式示意图；

图9是根据本发明的第六实施方式的基于分段逐次帧内编码的误码扩散消除原理示意图。

图10是本发明的纠删码结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

本发明将各种增强技术综合在一个多媒体通信系统上实现，将各种增强技术的各自的优点结合共同提高系统性能、传送可靠性和通信质量。这些增强技术包含了将FEC融合于RTP协议的错误弹性实时传送协议(ErrorResilience Real-time Transport Protocol，简称“ERRTP”)、将NALU头信息综合于RTP包头的技术、采用SEI扩展消息承载QoS报告及网络状况的反馈技术、基于反馈实现的多级保护和不等保护机制、采用错误掩盖和扩散消除结合的技术以及改进的Tornado编码方案。

本发明将各种增强技术模块化之后，组合在一个多媒体通信系统中，实现错误弹性H.264视频通信，该系统包括一般的主控模块、用户接口、网络通信模块、I/O和底层驱动模块、各种业务模块、通信过程控制模块、应用协议模块等，还包括实现各种增强技术的保护方法和策略协商模块、FEC模块、ERRTP模块、RTCP模块、H.264NAL模块、H.264编码器模块、H.264解码器模块、音频编解码模块、错误掩盖模块、SEI消息扩展处理模块、网络状况分析计算模块。

在本发明的第一实施例中，将多种增强技术实现并模块化综合在一个多媒体通信系统中，主要是指多媒体通信终端，下面首先从终端的各个组成功能模块来进行该装置的实现描述，一个完整的终端内部模块结构图如图5所示。应当说明，这里所说的功能模块，都是从功能上来定义的，具体的实现方式可以是软件、硬件、固件(firmware)及软件硬件混合方式。一个完整的多媒体通信终端首先必须包含以下模块:

主控模块:负责整个终端系统的控制；

用户接口(或者叫界面)模块:负责用户输入输出的交互，用户通过界面控制元素如菜单按钮等进行操作，同时显示反馈信息，比如当前系统状态，参数，网络状况等；

网络通信模块:负责和网络进行通信，提供TCP，UDP，IP和更下层的通信协议栈如Ethernet，PPP，ATM等；

I/O和底层驱动模块:负责对于硬件设备进行驱动，比如视频，音频采集设备和显示/播放设备的驱动，同时负责视频，音频数据的输入和输出；

各种业务模块:实现各种具体的业务，比如可视电话，多方会议，视频邮件，及时消息，视频聊天等等；

通信过程控制模块:在具体的通信过程中进行控制，比如在多方会议中实现申请主席，释放主席，申请发言，控制广播某个会场，会场浏览等；

应用协议模块:可以是H.323体系(包括其下的H.225.0，RAS，H.245，H.235，H.460等)和SIP等具体的应用协议。一般来说，这个协议是一系列协议的总称，叫做“协议伞”(protocol umbrella)；

此外对应于各种增强技术，分别在以下模块中实现:

保护方法和策略协商模块:该模块负责在通信双方之间进行保护方法协商，确定允许集合，然后根据允许集合，来协商一组保护方法混合和交替使用的策略。协商通过“应用协议模块”来进行通信完成。该模块控制FEC模块，后者实现不同的FEC保护方式，不等保护和自适应分级保护等功能；

FEC模块:该模块支持多种FEC保护方法，它们作为子类可以属于多个大类，假设共支持T种不同的方法。根据协商的结果(来自“保护方法和策略协商模块”)，对于H.264视频数据和音频数据(不在本专利范围内)进行保护。该模块内部保存了各种FEC子类对应的生成规则和参数，因此含有一个内部的数据库，用于存储这些数据。该模块可以实现不同保护方法的混合和交替应用；

ERRTP模块:实现ERRTP协议，关于ERRTP的协议封装格式以及对应H.264的相关封装去封装步骤在下面的实施例中还会详细描述；

RTCP模块:实现正常的RTCP功能，虽然本发明提供了基于H.264 SEI消息扩展的报告机制，可以实现主要RTCP信息的报告，但是并不排除RTCP的使用，两种报告机制可以并存，这样做主要是考虑兼容性和互通性，因此对方终端可能不支持采用SEI消息扩展报告机制；

H.264 NAL模块:实现H.264网络抽象层的功能；

H.264编码器模块:除了实现正常H.264编码器功能外，还实现了本发明的误码扩散消除功能，所以据的信息来自“网络状况分析计算模块”；

H.264解码器模块:实现正常的H.264解码器功能；

音频编解码模块:实现音频的编解码功能，支持的协议可以是ITU-TG.711，G.722，G.723.1，G.728，G.728，G.722.2(3GPP AMR)，MPEG组织的MP3，AAC等等；

错误掩盖模块:实现本发明提供的错误掩盖功能。所依据的信息来自“网络状况分析计算模块”和“H.264编码器模块”；

SEI消息扩展处理模块:实现本发明的基于SEI消息扩展的QoS和网络状况报告功能，在发送端，收集数据形成RTCP SR，RR报告，然后通过SEI扩展消息封装发送出去；在接收端从SEI扩展消息中提取RTCP SR，RR报告，然后把这些数据发给“网络状况分析计算模块”进行分析和计算；

网络状况分析计算模块:根据来自“SEI消息扩展处理模块”的数据，进行分析计算获得网络状况数据，比如丢包率，抖动，延时，顺时端到端的带宽(throughput)等等，然后，用这些数据来控制“H.264编码器模块”和“错误掩盖模块”，同时还把这些数据发送到“用户接口模块”可以显示出来给用户看。

在整体了解通信终端的模块构成之后，再来从协议栈的层次方面来描述这种终端。一个通信终端系统实现了多个不同层面的协议，这些协议构成了协议栈(Protocol Stack)。对于本发明的终端，其协议栈和普通的多媒体通信终端有相同的地方，也有不同的地方，在某些地方增加了一些新的层次。图6示出了根据本发明的第一实施例的多媒体通信协议栈结构示意图。

本发明的H.264/ERRTP的多媒体传送架构与传统的H.264/RTP架构区别主要在于:

用ERRTP/RTCP层取代了一般终端协议栈中的RTP/RTCP层，使用支持错误弹性的ERRTP后，将错误弹性保护机制结合在传送层实现；

在应用协议层中增加了一个“保护机制和策略协商层”，这一层主要用于通信双方在实现多级保护和不等保护时协商各种保护等级及其相关保护方案；

在H.264 VCL层和NAL层之间增加了“SEI扩展报告层”，这一层方便于收发双方实现基于SEI扩展消息的QoS监测和网络传送状况反馈；

在H.264 NAL层和ERRTP/RTCP层之间增加了“FEC层”，这一层实现了对于H.264的NALU数据流的节点划分、编码和封装。

熟悉本领域的技术人员可以理解，上述本发明的第一实施例中以典型的H.264业务为例给出基本模块化结构及协议栈组成，对于其他协议或未来出现的多媒体通信协议或者应用，只需在本发明的原理基础之上按照具体应用实现相关技术细节，达到发明目的，不影响本发明的实质和范围。

在给出系统整体架构的前提下，下面将依次描述每一种增强技术的实现细节。

针对现有技术存在的诸多问题，本发明提出一种改进的支持错误弹性的RTP协议，旨在将错误弹性机制融入传送层协议，不但可以简化传送结构降低复杂度，而且还能提高错误弹性机制灵活性增强传送可靠性。由于具有错误弹性，本发明称这种改进的RTP协议为错误弹性实时传送协议(ErrorResilience Real-time Transport Protocol，简称“ERRTP”或者“ER2TP”)。ERRTP与RTP的主要区别在于ERRTP协议数据包头信息扩展可以携带错误弹性编码方案相关信息，比如FEC类型、保护能力、编码参数等。

在ERRTP基础上，本发明很方便地实现了不等保护，首先提供多种保护能力不同的保护措施可供选择使用，然后发送端在收集得到网络状况和多媒体数据重要性等信息后，可以根据这些因素来选择合适的保护措施，从而达到不等保护的目的，实现保护能力和传送效率的均衡。由于在每个ERRTP数据包上都携带了其所采用的FEC相关信息，因此发送端只需将所选择的方案的信息填入ERRTP包头信息中，接收端就能根据其进行正确恢复或纠错。

最后对于H.264的NALU数据传送应用，给出了基于纠删码保护的具体实现方法，包括划分、生成、封装和解封装数据节点和校验节点的步骤。将连续一串NALU一起等长地划分为若干个数据节点，然后用Tornado码产生校验节点，所有这些节点又分布在若干个ERRTP包中传送，接收端则进行这个逆过程。

本发明的第二实施例在第一实施例的基础上，收发双方基于ERRTP实现不等保护，主要步骤如下所述:

发送端选择错误弹性编码方案对多媒体数据进行纠删编码，用ERRTP封装编码后的多媒体数据，并在ERRTP包头信息中携带错误弹性编码方案相关信息，然后发送到接收端；

接收端将收到的ERRTP包解封装，并从ERRTP包头信息中提取错误弹性编码方案相关信息，然后根据错误弹性编码方案相关信息，选择错误弹性编码方案进行错误弹性解码，获得多媒体数据。

其中，不等保护体现在发送端是根据当前网络传送状况和/或待发送多媒体数据的服务质量等级来选择错误弹性编码方案的。

首先介绍ERRTP的具体结构，下面给出具体ERRTP的头信息结构实施例。图7是根据本发明的第一实施例的ERRTP头信息结构示意图。从图中可以看出，版本信息字段V取值为3，表示ERRTP协议，以区别于传统的RTP协议(V＝2)。其中在头信息扩展也就是最后附有关于错误弹性编码方案的相关信息字段，此例中包括:错误弹性编码类型字段、错误弹性编码参数字段、数据包长度字段、数据包数目字段。

错误弹性编码类型字段，用于指示错误弹性编码方案采用的纠删码类型，也可以称为FEC Type字段，即指示FEC编码类型，占4比特，可以表示16种不同的FEC类型，从实际应用中，是足够的。这里定义的类型其实是大的类型，后面还将继续细分为各种不同的方案，称为子类型，实际应用中的大类型例如:0010表示Tornado码，0011表示RS码等。该字段可标识16种不同的FEC码大类型，通信双方需要事先约定一个FEC编码类型和编码类型代号之间对应关系的查表(Look-Up Table，简称“LUT”)称为FECTypeLUT。

错误弹性编码子类型字段，用于指示错误弹性编码方案的相关参数设置，对于每种类型的FEC编码还需要确定各种参数的设置才能具体实施，这个字段就是起到明确具体参数的作用。由于ERRTP头信息中资源有限，不可能把各种FEC编码方案所对应的具体参数及其规则等一一罗列，本发明的第一实施例通过用子类型的概念来指示各种备选的参数设置方案。该字段也称为FEC编码子类型字段，FEC Subtype，占9比特。该域主要表示在FECTypeLUT中定义的各大类型下面进一步细分的子类型。

数据包长度字段，用于指示错误弹性编码方案在对多媒体数据进行纠删编码后的数据节点长度，称为Data Length字段，占11比特。由于每个数据包长度应小于网络传送最大传送单元(Maximum Transport Unit，简称“MTU”)，而目前有线信道MTU<1500＝0 x 5DC字节，无线信道MTU<100字节，因此该字段11个比特足以存放数据包的长度。

数据包数目字段，用于指示该ERRTP包所承载的数据节点的数目，又称为Packet Number字段，占8比特，比如对于若干个NALU经过前向纠错码校验后，分组封装在多个ERRTP中，每个ERRTP中所承载的数据节点数。

可见有了这些字段之后，解码端或网络节点可以根据该字段给出的FEC码类型和数据包的校验类型对接收到的数据包进行校验，并恢复丢失的数据包。

值得注意的是，上面提到的子类型FEC Subtype字段共9个比特是用来编码指示各种备选的参数设置方案的，下面就给出本发明的第一实施例中如何进行编码指示的技术细节。

首先收发双方需要协商确定该字段指示关系对应表。在开始传送之前，发送端和接收端协商确定:对于各种FEC码大类型，FEC Subtype的取值与其所指示的该种FEC码的相关参数设置方案的对应关系，及各种备选方案的具体参数设置情况。

然后，发送端和接收端都根据协商结果建立对应关系表，用于根据FECType和FEC Subtype字段来查询所对应的FEC编码类型或FEC编解码处理模块；

在收发过程中，发送端调用相应纠删编码处理模块进行纠删编码，接收端调用相应纠删解码处理模块进行纠删解码。

在实际应用中，子类型的信息实际上指示两个方面:

A.FEC编码的生成规则(Generation Rule)；

B.保护强度/保护能力。

所谓生成规则就是在发送端如何将数据节点进行处理生成各个校验节点的规则或者算法(Algorithm)。当然在接收端所做的正好相反，如果在传送过程中发生了丢包，即某些节点丢失了，那么根据生成规则可以恢复或者部分恢复丢失的节点。可见生成规则是很重要的信息，根据它，通信的双方就可以基于FEC机制来工作了。在FECTypeLUT中列出的FEC类型中的每一类，都有不同的生成规则；而在每一类中，比如Tornado码，下面的子类的生成规则还要结合具体的生成参数(generation parameters)。因此具体到这里的每个子类，生成规则将和生成参数结合起来。

比如对于Tornado码，生成参数包括如下数据:数据节点总数、校验节点总数、校验节点层数、相继两层之间节点数目的递缩比例、表示相继两层之间节点关联关系的关联矩阵，如果有L层校验节点，那么这样的关联矩阵就有L个、或者等效的表示相继两层节点关联关系的二部图(Bipartite)的参数化数学表示(parametric mathematical representation)。

一般来说，在大的生成规则相同的前提下，生成参数往往决定子类型的保护强度。比如Tornado码，在上面给出的各项生成参数中，数据节点总数和检验节点总数基本上能够在很大程度上决定保护能力(当然严格来说，要完全决定保护能力，需要全部的生成参数)。在本发明中，对于每个FEC大类型，选择一些决定保护能力的主要参数(决定作用最大)作为代表性生成参数(representative generation parameters)。通过使用代表性生成参数，就可以把大类下面的子类按照保护能力从弱到强的顺序(升序)排列起来。从而建立一个LUT叫做FECSubTypeLUT。

每个大类型下面具体支持多个子类型，可以有具体的应用和通信双方的通信能力(CPU处理速度、内存、程序复杂度等因素)和需要决定。如果通信环境变化很大，网络的性能波动范围很大，那么需要支持的子类型一般来说要多，相反可以较少。这个完全可以在通信开始前通过能力协商过程，由通信双方来达成一致的约定。协商可以通过H.323或会话初始协议(SessionInitial Protocol，简称“SIP”)等目前主流的多媒体通信框架协议进行。

假定针对某个大类下面的子类，如果需要区分S个子类型(S≤2⁹-1)，代表性生成参数有k个，用p¹，p²，...，p^k表示，那么表2给出一个对应关系的例子，表中上标表示FEC大类型，下标表示具体哪个参数。

表2FEC Subtype和参数设置方案对应关系表

FEC Subtype	FEC编码子类型(参数设置)
FEC Subtype	FEC编码子类型(参数设置)	000000000	FEC子类型0(p<sup>0</sup><sub>1</sub>，p<sup>0</sup><sub>2</sub>，..，p<sup>0</sup><sub>k</sub>)
000000001	FEC子类型1(p<sup>1</sup><sub>1</sub>，p<sup>1</sup><sub>2</sub>，..，p<sup>1</sup><sub>k</sub>)	000000000
000000001		000000010	FEC子类型2(p<sup>2</sup><sub>1</sub>，p<sup>2</sup><sub>2</sub>，..，p<sup>2</sup><sub>k</sub>)
000000011	FEC子类型3(p<sup>3</sup><sub>1</sub>，p<sup>3</sup><sub>2</sub>，..，p<sup>3</sup><sub>k</sub>)	000000010
000000011		…………………	………………
S(S≤2<sup>9</sup>-1)	FEC子类型S(p<sup>S</sup><sub>1</sub>，p<sup>S</sup><sub>2</sub>，..，p<sup>S</sup><sub>k</sub>)	…………………	………………

比如，对于Tornado码，可以设置对应关系是:000000010-(24，20)(数据节点总数＝20，校验节点总数＝4)，000000011-(30，20)，...，111111111-其它。

针对某种特性的FEC编码的子类型，一组给定的生成规则结合相应的生成参数对应唯一的一个编码方案，即唯一决定了如何由数据节点生成校验节点，以及如何恢复丢失的节点。可以建立一个数据库，来存储每种大类型和子类型对应的生成参数。而生成规则本身用硬件或者软件模块来实现。因此，每种大类型在发送端对应一个FEC处理模块，负责生成校验节点；在接收端同样对应一个FEC处理模块，负责恢复节点。但是，对应每种大类型的模块，需要从上述生成参数数据库中读取具体的每种子类型的生成参数，从而来进行处理。因此，通信双方都是根据FEC Type和FEC Subtype两个信息域的信息来决定调用哪个FEC处理模块和读取哪些生成参数。

由于目前多媒体通信技术的发展，H.264视频编码标准已逐渐成为主流媒体编码格式，因此本发明的第二实施例在第一实施例的基础上，给出了用ERRTP对H.264的NALU数据流进行FEC编解码的具体步骤，其流程如下所述。

发送端将多个(假设为S个)H.264 NALU合并为一组统一进行编码传送，先把S个NALU重新划分为等长的块，假设为M个，这M个就是数据节点。

在该步中，将H.264的S个NALU分为一组；然后将S个NALU首尾相接(concatenated)，连接形成一个大块，然后将该大块等分为M个数据块，其中每个数据块的长度为K个字节。这里如果该大块的总的字节数(设为TB)不能被M整除，那么应该进行取整运算，使得每个数据块的长度为Ceiling(TB/M)字节，Ceiling函数表示取整，即Ceiling(x)等于不小于x的最小整数，x为任意实数。那么在某些数据块中的后面可能要采用填充零串(zeropadding)的操作，使得字节数凑齐到Ceiling(TB/M))。

接着，对M个数据节点其进行FEC编码，得到N个校验节点。对M个数据块使用FEC码编码生成N个校验块，生成过程采用前面描述过的方法，根据FEC Type和FEC Subtype信息，确定调用具体哪个FEC处理模块进行校验块的生成。

然后，发送端将所有数据节点和校验节点分组封装在ERRTP包中进行发送。在此例中各个字段应该按如下设置:

类型字段FEC Type＝0010，表示使用Tornado码；

子类型字段则由发送端具体根据实际情况选择，比如取值为FECSubtype＝000000010，表示使用Tornado(24，20)码，其中数据节点20个，校验节点4个，信道编码冗余度为16.7％；该纠删码在丢包率小于等于3％时，可以完全恢复丢失的数据包；

数据包长度Data-Length＝K Bytes；

数据包数目Packet Number＝(M+N)/P，表示一个ERRTP载荷中承载的数据节点个数。

接收端在接收到这些ERRTP包后，解封装得到数据节点和校验节点。接收端以P个数据包为周期，每接收到一组P个数据包就开始进行一次解码恢复。一组多少个数据包由双方协商确定。

接收端根据校验节点对数据节点进行错误弹性解码。每次在收到数据包P+1后开始检测前面收到的P个数据包中是否有数据包丢失，如果有就采用前面描述的方法，根据FEC Type和FEC Subtype信息，确定调用具体哪个FEC处理模块进行解码和恢复或者部分丢失的数据。

最后在得到完整的数据节点后，重新合并就得到一个大块，采用与发送端相同的方式，划分得到S个NALU。

在实际应用中发现，上例采用基于ERRTP的抗数据包丢失算法，可以在增加不到17％码字的情况下，大大提高视频码流的抗数据包丢失能力。而与RTP载荷头结构相比，仅仅增加了4字节，可见对传送效率基本没有影响，取得了显著的实际效果。

在前面已经提到关于本发明的另外一个关键技术点就是不等保护的实现。主要体现在两个方面，一个是根据不同重要等级的多媒体数据来选择合适的编码方案或者参数，即确定前述FEC编码类型与子类型，另一个就是根据不同时刻的网络状况来选择。对应这两个方面，分别称为混合和交替使用各种FEC编码方案。所谓混合(Hybrid)，是指在同一时间内同时使用多种FEC子类型，主要用于保护不同重要性的数据；而所谓交替(Alternation)，是指在不同时间(不同的网络状况下)使用不同的FEC子类型。

因此对于H.264 NALU数据流，前面提到，其头字节体现了数据的重要程度，因此发送端根据NALU的头信息中的NRI字段或Type字段可以评估QoS等级，进而选择错误弹性编码方案，即确定FEC Type字段和FEC Subtype字段。而对于网络状况，一般的网络传送都有相应的网络状况监测机制，发送端可以根据这些机制获知接收端反馈的传送报告，以此评价网络传送状况，进而选择错误弹性编码方案，即确定FEC Type字段和FEC Subtype字段。

H.264码流是基于NALU进行传送或存储，NALU由NAL头信息和NAL载荷组成。在H.264的NALU中，不同NALU类型对解码恢复图像的影响不同。例如，NRI取0表示NALU中存放非参考图象的一个Slice或Slice数据条带，不会影响后续解码；而NRI取非0表明NALU中存放一个序列/图像参数集或者是参考图像的一个Slice或Slice数据条带，会严重影响后续解码。

因此，在对H.264的码流进行数据包保护时，可以根据NRI或Nal_unit_type的取值将H.264的数据分为两类:一类为相对重要的图像数据(例如Nal_ref_idc等于1)；另一类为次要的图像数据(例如Nal_ref_idc等于0)。然后，对重要的图像数据使用冗余度较大、抗丢包能力强的FEC1码进行保护；而次要的图像数据可以使用冗余度较小、抗丢包能力较弱的FEC2码进行保护。

通过这种不等保护算法，保证了各类重要信息在高数据包丢失环境下的正确恢复，而对FEC2码仍然未能恢复的图像信息采用错误掩盖和防止误码扩散等技术。FEC1，FEC2这里只是一般的表示方法，表示任意两种子类型。这两种子类型可以属于同一大类型，也可以属于不同大类型。

很显然，上述方法可以推广到更加一般的情形，把数据按照NAL_unit-type的取值分成更多类，比如五类:最重要数据、次重要数据、一般重要数据、较不重要数据、最不重要数据；也可以分成7类或者更多，那么，可以用相同数量的FEC子类型来保护，每类数据对应一种不同的子类型。只要保护能力从弱到强就可以了，这些子类型不一定属于同一个大类型。而对保护能力最强的FEC码保护后仍然未能恢复的图像信息采用错误掩盖和防止误码扩散等技术。

不等保护的另外一种情况也在本发明范围内，就是可以根据网络实时状况选择不同保护能力的的FEC。然后通过ERRTP的头信息来通知通信的双方，使得它们能够正确对数据进行解码和恢复丢失的数据。可以把网络当前受到影响传送性能下降的情况分成几个级别。比如五级:最严重、次严重、一般严重、较不严重、最不严重；也可以分成7级或者更多，那么，可以用相同数量的FEC子类型来保护，每级对应一种不同的子类型。只要保护能力从弱到强就可以了，这些子类型不一定属于同一个大类型。而对保护能力最强的FEC码保护后仍然未能恢复的图像信息采用错误掩盖和防止误码扩散等技术。感知网络状况可以通过现有的各种QoS监测方法实现。

更为复杂的应用方案也在本发明范围内，如果总共有T种FEC方案(不同类型/子类型)可以使用(通信双方终端都支持)。决定采用哪种FEC，要同时取决于数据重要性和网络的状况。那么可以采用一个二维LUT的方法，如表3所示:

表3多种FEC机制混合和交替使用的二维LUT

以上表格中，数据重要性级别和网络状况级别都按照升序排列。其中FEC的下标用二维下标表示，表中的错误弹性机制FEC(i，j)，0<i≤U，0<j≤V，可以是上述T个FEC方案中的任意一种。

需要提及的是，上述发明的实施例描述中均以FEC纠删码特别是Tornado码为例，但对于其他类似的错误弹性机制特别是除Tornado码以外的FEC编码方案都可以适用，并不影响本发明的实质和范围。

而在本发明的另外一个实施例中，专门采用了一种改进的Tornado纠删码，这种改进的Tornado纠删码对于一组数据节点仅生成一层所述校验节点，可以大大减少编码延时，满足实时通信的需求。

在实时视频通信中，使用FEC码数据包保护会引入时延，时延的大小与图像数据数据包的大小相关。将S个NALU分为一组，其中一个NALU包含一个Slice的码流数据。如果一帧图像划分为一个Slice，则编码端就会有S帧的时延，同样解码端也会有S帧的时延。NALU与数据节点个数的关系如下式所示:

Σ_{i = 0}^{s} {NalSize}_{i} = PackSize \times DataNode

式中S个NALU长度值相加等于数据节点个数乘上每个节点数据包的大小。由式(1)可以看出当S取值受限时，PackSize×DataNode的取值也会受限，另外由于IP网络传送的有效性导致PackSize取值不能太小，因此DataNode的取值受限。

IP网络上实时视频通信中，一帧图像的延时T_total计算如下:

T_total＝T_FEC+T_codec+T_trans

该式中T_FEC是加入FEC保护后引入的时延，T_codec和T_trans分别是H.264编解码器处理时延和网络传送时延。由于数字信号处理技术和IP网络的迅速发展，可以假定T_codec和T_trans都能够满足实时性要求:

T_codec<＝T_th，T_trans<＝T_th，其中T_th＝1/F_target

式中F_target是解码目标帧率(可取值10Hz，30Hz等)，且设一帧图像划分为一个Slice，这时式(2)可改为:

T_total<＝S*T_th+2*T_th＝(S+2)*T_th

由上两式可知，一帧图像的延时T_total的延时基本由S的取值确定，而DataNode又大大影响S的取值。因此，要在能够保证视频通信抗数据包丢失能力的前提下，尽量减少FEC引入的时延，进一步保证实时视频通信的QoS。

本发明在DataNode受限的情况下，采用改进的Tornado码保护算法。该改进的Tornado方法，不采用多级偶图的编码方式，而是只使用一层校验节点的编码方式。与原来的Tornado编码方式相比，改进后的编码方法大大提高了算法的灵活性，数据节点和校验节点的个数可以任意设置，也降低了编解码算法的复杂度，可用于实时视频通信的抗数据包丢失。另外，在数据节点受限的情况下，改进Tornado码的抗数据包丢失性能基本没有下降。该改进的Tornado编码方法具体原理及详细步骤，在后文将详细阐述。

注意到上例ERRTP对于NALU的封装中并没有提到NALU的信息头怎么处理，在本发明的第三实施例在第二实施例的基础上，ERRTP将同类NALU一起处理并将头信息综合到ERRTP头信息中。与RTP最基本的不同点在于，在ERRTP封装过程中，将具有相同头信息的NALU包的头信息综合入ERRTP的头信息中。

前面已经提到过NALU头信息结构，这里再次强调一下，NALU信息依次包含:

占1比特的F字段，用于指示所述NALU是否出错；

占2比特的NRI字段，用于指示所述NALU的重要性；

占5比特的Type字段，用于指示所述NALU的类型。

收发双方的执行步骤如下所述。发送端按ERRTP封装格式将头信息相同的多个NALU数据节点或者校验节点封装在同一个ERRTP包中。根据实际工程经验，在一般情况下，因为H.264比特流总是存在相邻的部分其对应的NALU类型相同这个属性，这个假设总是可以满足的。即使在某些情况下无法满足，也可以有几种对策可以处理这样的情况:第一种可以将现同类型的NALU累积，直到满足一定的数目后在封装到ERRTP中，另一种如果相同类型的NALU的数目达不到一定的数目的话，采用RTP填充的方法，虽然浪费一点带宽，但这微不足道，还有一种方法是如果类型不同的NALU非常多，则可以采用RTP封装，反正在接收端能够根据ERRTP标识来识别，进行对应的处理。

上面提到的在所述ERRTP封装格式中，将其所承载的NALU所具有的相同头信息综合在该ERRTP包的头信息中，并将所承载的NALU去掉其头信息再按照前面提到的流程处理，进行划分、编码和封装，填充入该ERRTP包的净荷中。那么如何将NALU头综合到ERRTP头中呢？下面将具体给出两套方案以解决这个几个问题。

在ERRTP封装格式中，NALU头信息中的NRI字段和Type字段填充在ERRTP包头信息的PT字段中，前面已经叙述，该PT字段位于ERRTP包头信息的第2个字节的后7比特。在图7中已经给出这样一个ERRTP头的格式，其中与RTP不同的地方已经用粗体部分表示，另外图中有些地方在后面还会解释。

另外两个要点是:第一，将ERRTP包头中的V字段作为ERRTP标识，前面已提到；第二，NALU头信息中的F字段填充在ERRTP包头信息的M字段中，该M字段位于ERRTP包头信息的第2个字节的前1比特，在接收端则根据ERRTP包的M字段判断其所承载的NALU是否出错，也就实现了F字段的禁止比特功能。可见该方案通过版本的区别，可以告诉RTP数据包的接收方，该RTP协议是ERRTP，从而在后面的处理，就要按照针对ERRTP协议的处理流程进行。

在该方案中，将NALU头信息字节(8个比特)替换原RTP头信息中的标识M字段1个比特和PT字段7个比特共8个比特。具体的替换顺序比如可以是这样:

F比特替换M比特；

NRI 2个比特替换PT 7个比特中的最高2个比特；

Type 5个比特替换PT 7个比特中的最低5个比特；

实际上，这样的替换方案是有其合理性的。PT 7个比特本来就是可以自由使用的，前面已经提到。M字段的用途在RTP(RFC 3550)中规定如下:某种具体的层面(Profile)可以规定不使用M比特，而是把它并入PT，这样PT最多可以有8个比特，区别256种不同的类型。因此，用F比特替换M比特完全是符合RTP规定的，不会引起ERRTP和传统RTP之间互通的问题。

容易看出本发明ERRTP的封装格式具有明显的三个优点:第一，额外开销少，尤其是一个RTP中有多个NALU时，明显节省传送比特数；第二，不用对RTP数据包中的H.264 NALU数据解码就可以判别这些NALU的相对重要性；第三，不用对RTP数据包中的H.264 NALU数据解码就可识别由于其它的比特丢失而是否会造成该RTP包能否正确解码。

为了进一步详细描述本发明的技术细节，下面给出一个ERRTP封装和去封装的过程描述。在进行上述处理后，在同一个ERRTP数据包中的多个H.264 NALU类型完全相同，即它们的头信息字节都相同，那么在他们划分、编码、封装到ERRTP数据包中的时候，可以剥离掉原来的头信息字节，这样如果有N个NALU，可以减少N个字节。去封装时，就是把NALU从ERRTP数据包中提取解码、重新划分还原为原来的形式，即将这N个NALU从他们所在的ERRTP数据包中提取解码出来，然后把ERRTP头信息中的PT的7个比特拷贝到一个字节H(8比特)中的最低7个比特中去，而H的最高比特作为F比特，设置为0。然后把生成的H字节附加到每个提取出来的NALU的最前面，这样就还原了每个NALU。当然如果说ERRTP包头中的F字段为1的话，说明该ERRTP包中的NALU出错，因此直接丢弃即可，也节省的处理时间。

下面给出第二种解决方案，该方案与第一个有一点是相同的，即也是将NALU头中的NRI和Type字段填充到ERRTP头的PT字段的7个比特中。不同的地方有两点:采用M字段标识ERRTP，这样带来的一个问题就是F字段没有地方填充了，该实施例中将F是否置位的两类NALU分别对待，对于F置位的出错NALU还是采用原先的RTP传送，而对于正常的则采用ERRTP传，但忽略该F比特。具体细节如下所述。

将M字段取值为1来标识ERRTP包，该M字段位于所述ERRTP包头信息的第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字段可以保留，用于未来的扩展携带更多信息，这里就是用于标识ERRTP包。这样做的好处是，不需要对于版本信息V＝2进行修改，ERRTP还是用原来版本V取值2。这也是节约了目前仅有的RTP版本信息资源。

然而不可避免的是，在实际应用中可能出现需要使用F比特的小概率情况，比如NALU语法错的时候，本发明对于这种情况做如下处理:在ERRTP封装格式中，忽略所述NALU头信息中的F字段；但在发送端，对于F字段有效的出错NALU，仍旧采用RTP包封装，仅对正常的NALU采用ERRTP包装；在接收端则判断该包为ERRTP还是RTP包后按相应封装格式处理该包。也就是说，当F比特在某些特殊情况下，要用于原来H.264定义的目的，即要用于表示可能存在的H.264NALU语法错误的情况，如果一个中间设备比如网关在对于视频按照H.264协议进行视频编码的时候，发现某个NALU存在语法错误，那么就要对于该NALU单独进行封装处理。

归纳上述ERRTP和RTP交替处理的方法流程如下:

发送端首先判断至少一个NALU的头信息中的F字段是否有效，据此将其分为正常NALU和出错NALU；

然后按ERRTP封装格式将正常NALU封装成ERRTP包，并设ERRTP标识；按RTP封装格式将出错NALU封装成RTP包；

接收端首先判断接收到的包的头信息是否设ERRTP标识，将其分为ERRTP包和RTP包；

然后根据ERRTP封装格式处理ERRTP包，根据RTP包封装格式处理RTP包。

可见，网关对于正常的NALU，按照前面描述的方法，对于类型相同的H.264 NALU按照一定的规则(由具体应用决定，主要规定每个ERRTP数据包中封装多少个同类的NALU)进行ERRTP封装，一旦发现某个NALU存在语法错误，那么就要对于该NALU采用常规RTP封装。这个时候常规的RTP数据包中也许就只含有一个H.264 NALU。

最后还需要说明的一点是，注意到前文提到的表1中给出的NALU的类型及其对应Type字段的取值，可以发现现有的类型不足16种，也就是说Type的5个比特完全可以缩减为4个，这不影响现有的H.264传送，因此在ERRTP封装格式中，当NALU的所有类型少于16种时，仅用Type字段的低4比特表征，而Type的最高比特作为扩展保留比特，称作C字段。将该C比特留待以后使用，继续进行功能扩展。将比特C进行保留后，表1中给出的NALU类型要做相应修改:共16个值，取值0-12与表1相同，取值13-15为保留。

当然虽然目前H.264的NALU类型只有13种，但是H.264后续会发展，可能会产生更多的NALU类型，如果未来NALU类型增加到16种以上，那么还是需要用PT7个比特中的最低4个比特加上C比特作为类型指示。

需要提及的是这里将NALU头信息综合到ERRTP包头信息中的最大好处也就是，多媒体传送设备可以根据ERRTP头信息直接获知其所承载的NALU的相关信息，并据此实施H.264多媒体数据实时传送的QoS策略。这一点在现有的RTP是无法实现的，因为对于RTP层来说，NALU层信息是不关心的，也就无法获知净荷中的每个NALU的头信息的，从而无法实现QoS策略。

在ERRTP的基础之上，为了实现接收端的反馈，采用SEI承载QoS报告的增强技术，从前文描述可见，RTCP承担了QoS报告机制，但它其实是一种通用的报告方法，可以用于报告QoS，也可以用于报告其它信息。对于特定的视频通信应用，用RTCP来报告却不一定是最合适的。在某些时候，如果QoS信息的发送方和接收方都能使用更高层的协议比如H.264来通信，则完全可以考虑用H.264来承载报告的内容。本发明就是基于这个出发点，直接采用H.264来承载QoS报告信息，可以避免使用额外的信道，实现了一种“带内”报告机制。

由H.264高层协议来传送QoS报告的另一个依据是，在目前的视频通信应用中，对于网络传送的适应措施，主要基于终端来实现，而不是网络中间设备比如路由器，交换机或者网关来实现。因此QoS报告的封装提取并不依赖于底层协议，只需终端能够理解提取H.264中承载的QoS报告信息就能实现QoS监测，因此可以不依赖于底层的RTCP等协议。当然，通过采用H.264的“带内”报告机制，并不意味着排斥RTCP报告机制的应用，两种机制可以选择使用，也可以共存，H.264的使用反而能够降低RTCP的报告流量。另外，如果采用H.264“带内”报告方式，则H.264的数据包可以采取多种保护措施，并且对于承载QoS报告的H.264数据包，可以认为是重要的数据，根据不等保护(Unequal Protection，简称“UEP”)的原则，可以对其采用高强度的保护措施。从而可以保证报告数据的正确到达，提高QoS监测的可靠性。

本发明的第四实施例在第三实施例的基础上，基于H.264的扩展消息机制来承载QoS报告的，大致分为以下三个基本步骤

首先，各个多媒体通信终端统计生成H.264多媒体通信的QoS报告，这些报告的内容可以与RTCP的SR、RR报告内容相同，当然也可以不同，但是所描述的有关H.264媒体通信的服务质量及网络状态等信息是一致的；

然后，终端用H.264扩展消息承载这些QoS报告，发给其他通信终端，H.264扩展消息机制前面已提及，典型的有SEI等，本发明所采用的基本上就是SEI消息，当然随着以后H.264的扩展也可以使用其它扩展消息承载；

在发送QoS报告的同时终端也接收到其它终端发来的QoS报告，事实上每个终端都将根据这些QoS报告执行QoS策略。

本发明以SEI消息承载QoS报告的，以现有的RTCP的QoS报告为例，可以直接将RTCP的SR、RR报告的主要内容，作为H.264 SEI消息的载荷，从而用扩展SEI消息来承载这些信息。

基于这种思想，在本发明的第四实施例中，定义具体的SEI扩展消息专门用于承载QoS报告。H.264规定，SEI信息存放在一类NALU中，如前所述其Type＝6。本发明在SEI域中存放类似RTCP的SR和RR报告消息，既保证了传送效率，又能有效地反馈信道状态及解码信息，便于编码端和解码端交互式抗数据包丢失。具体结构如图8所示，其中除了头信息按照SEI消息结构来安排以外，其它QoS报告内容都借鉴RTCP的SR、RR报告的格式。

用于承载QoS报告的SEI消息的头信息包含以下字段:

第1个字节(字节0)为载荷类型字段(SEI Type)，用于指示载荷为对应QoS报告，本实施例中，SEI Type＝200表示存放在SEI域中的是类似RTCP中的发送报告(SR)，而SEI Type＝201表示其为接收报告(RR)；

第2、3个字节(字节1、2)为载荷长度字段(SEI Packet-Length)，用于指示对应QoS报告长度，这个长度与RTCP的QoS报告中的长度字段采用相同的定义；

第4个字节及以后为SEI消息的载荷，也即用于填充对应QoS报告。

QoS报告也分为发送方报告和接收方报告，由载荷类型字段指示区分，即SEI Type取值不同，QoS报告的具体内容可以与RTCP的SR、RR报告相同，比如图2中所示:

版本信息字段(V)，占2比特，本例取值为二进制11即V＝3，表示与以前版本的区别；

填充字段(P)，占1比特，用于指示是否有填充内容，与RTCP相同；

接收报告数字段(RC)，占5比特，用于指示该QoS报告中所报告接收报告块数目；

发送方SSRC字段，占32比特，用于标识该服务质量报告的发送方；

对于发送方报告，这里还包含发送方信息块，用于描述该报告的发送方的相关信息；

之后包含多块接收报告块，用于描述来自不同源的多媒体统计信息，每块包含源的标识符和多媒体流的相关统计指标，前面RTCP中已经描述了各种指标的意义；

最后包含特定层面扩展，用于特定层面的保留功能扩展。

可见，图8中给出的QoS报告内容与RTCP基本相同。RTCP的基本内容RR和SR写入SEI域后，可以不需要专门的逻辑信道传递RTCP信息，节省了部分带宽开销。事实上，本发明的精髓在于用SEI消息进行带内承载，至于QoS报告的如何统计生成，只要能实现QoS监测的发明目的，都不影响本发明的实质和范围。

在实现QoS报告之后，即可在此基础上进行多种QoS策略，比如利用RTCP的累计数据包丢失字段，它们在双向视频通信(终端既有编码器又有解码器)中可用于反馈解码信息，便于交互式抗数据包丢失。

另外，在QoS报告中有到达时延抖动和发送方字节计数等字段，它们都可用于感知网络状态。其中，速率控制算法可根据到达时延抖动字段中的信息，进一步保证编码端速率接近恒定；发送方字节计数字段可以估算载荷的平均速率，便于发送端根据网络状态重新设定编码器参数，包括调整目标帧率、恢复图像质量和原始图像的分辨率等等。

为了改进RTCP传送的可靠性不足，在采用H.264“带内”报告方式后，H.264的数据包可以采取多种保护措施，并且对于承载QoS报告的H.264数据包，可以认为是重要的数据，根据不等保护的原则，可以对其采用高强度的保护措施。从而可以保证报告数据的正确到达。比如用于承载QoS报告的SEI应该进一步由NALU承载，而如前所述NALU是有一个头信息可以设置该内容的重要程度的，因此通信终端可以根据QoS报告传送的可靠性要求来设置该NALU的nal_ref_idc字段，可以设为1，2，3等，在错误弹性编码中即会根据这一字段的等级不同而采取不同强度的保护措施。

通信终端还可以根据当前网络状态和高层应用需求来动态调整基于SEI消息的QoS报告的发送周期。缺省情况下，将RTCP信息写入SEI域的时间间隔(即报告周期)与RFC 3550中建议RTCP传送间隔一致。当然，根据特定应用的需要(特定的保护方法等)，可能报告周期不一定和RFC 3550规定的完全一样，而是可以调整。报告周期根据特定应用的需要确定。比如，报告数据的一个重要用途是动态估计网络的性能:丢包率，延迟，抖动等。如果需要频繁检测这些数据，则报告周期要短，否则报告周期可以长。在网络状况良好的时候，可以停止报告。另外，用SEI消息不仅可以传送H.264视频的QoS报告，还可以混合承载多种媒体流的QoS报告，只需在QoS报告后面加入各种媒体流相应的接收报告块即可。比如音频流等，只要在SR报告中增加其源的SSRC具体的报告块内容。前面也提到，除了采用SEI进行带内监测之后，通信终端还可以选择现有的RTCP传送，也可以同时使用H.264扩展消息、RTCP中的一种或两种来传送承载QoS报告。

在给出了采用SEI实现从接收端反馈网络状况相关的QoS报告之后，在此基础上就容易实现自适应的保护策略调整，包括多级保护和不等保护。根据现有技术对于网络通信状况无法自适应调整的问题，本发明的第五实施例给出一种统计当前通信状况并自适应调整保护策略的自适应保护的视频传送方法。首先按照保护方法性能影响，给出不同参数配置，设置保护能力不同的多等级保护策略，用于在不同通信状况下被选用于进行高效可靠的保护；其次，在接收端根据通信情况统计网络状况、通信质量，并将其发回给发送端；最后由发送端根据发回的通信质量统计信息进行调整，选择最合适的保护策略等级。

该方案的关键还在于统计通信质量的方法及发回统计信息的渠道。利用H.264 NALU的序号丢失情况可以统计丢包率及其位置等信息，并通过定义NALU中净荷部分的扩展SEI消息结构，用于承载该统计信息，从接收端传送统计数据到发送端。这样的反馈机制虽然与QoS报告的SR/RR格式不尽相同，但熟悉本领域的技术人员可以理解，两种方式的根本原理是相同的，只是用SEI承载的内容不同，因此下面的描述不再专门提出SEI承载网络丢包率的方案与QoS报告的方案的区别。

以Tornado纠删码为例，即根据前述Tornado纠删码的编码解码方法来对视频流数据进行保护。Tornado纠删码需要设定参数有:数据节点数目、校验节点数目、递缩比率、校验节点层数、用于计算校验节点的各级二部图。在视频流通信过程中，发送端将视频流数据分割为数据节点，然后按照Tornado编码方法产生校验节点，一起发送给接收端；接收端则按照Tornado解码方法进行纠错，获得视频流数据。

由于实际IP网络带宽等因素是经常变化而不稳定的，因此固定的保护策略将带来低效率或者高误码率等问题，因此本实施例预先设定了保护力度不同等级的保护策略系列，分别用于在不同通信质量等级情况下保护视频流数据。可见，不同等级的保护策略可以适应网络通信质量的变化，不但能够满足信道劣化情况下的保护力度要求，而且能够在信号改善情况下适当调低保护力度，以减少系统开销，节约处理、带宽资源。

为了给定不同等级保护策略，需要设定不同参数的Tornado纠删码。根据前述影响Tornado纠删码保护性能的参数主要有数据节点数目、校验节点数目及二部图两侧节点度向量的随机分布，为简单起见，不同能力的Tornado码，一般不会有统一的二部图的，采用不同的数据节点数目和校验节点数目来给出不同保护力度的Tornado纠删码保护策略。根据Tornado纠删码原理，不同数据节点数目和校验节点数目即能确定不同码率或冗余率的Tornado纠删码，从而给出不同的保护力度和系统开销。

接收端接收数据并进行Tornado纠删码解码得到视频流数据，同时根据数据丢失情况进行统计，得到统计信息表征通信质量。

发送端需要根据通信质量状况来进行保护策略调整，因此需要对传送情况进行统计，接收端根据H.264视频流程数据的NALU的序列号来统计传送情况。在基于H.264双向视频通信中，通信系统的各个终端都既有编码器、又有解码器。而NALU是序列编号的，即所有发送端发送出去的NALU具有统一的序列编号，因此，接收端可以根据收到NALU的序号，判断是否有NALU丢失。如果有NALU序号不连续就说明存在NALU丢失，中断的NALU序号就是丢失NALU的序号，其个数就是丢失的NALU数目。经过一段时间的累计，即可计算得到该段时间内丢失的NALU的总数目，再对该时间段内所有NALU数目进行归一化，即可得到累计丢包率(Accumulated Lost SliceRate，简称＂ALSR＂)。当然，接收端也可以将丢包信息直接发回给发送端，由发送端进行统计。采用NALU序号来进行统计，不但能保证统计信息精确无误，而且直接利用现有数据信息，不需要额外的承载开销。

接收端将统计信息以及其他数据丢失信息通过扩展SEI消息发回发送端。在接收端统计得到关于传送情况的统计信息后，需要发回给发送端，本实施例定义了扩展SEI消息结构，专门用于承载从接收端发回的传送情况统计信息。接收端在完成统计后，将该信息写入专门定义的扩展SEI消息体中，然后写入该终端发回的编码码流的SEI域中，发回发送端。发送端收到该SEI消息后，即可直接得知统计信息，或者统计得到ALSR，从而建立发送端对于网络丢包率的真实感知机制。

如前所述SEI消息也由H.264码流的基本单位NALU所承载，每个SEI域包含一个或多个SEI消息，而SEI消息又由SEI头信息和SEI有效载荷组成。SEI头信息包括两个码字:载荷类型和载荷大小。其中载荷类型的长度不一定，比如类型在0到255之间时用一个字节表示，当类型在256到511之间时用两个字节0xFF00到0xFFFE表示，依次类推，这样用户可以自定义任意多种载荷类型。在现有H.264标准中，类型0到类型18标准中已定义为特定的信息，如缓存周期、图像定时等。由此可见H.264中定义的SEI域可根据需求存放足够多的用户自定义信息。在本发明的第一实施例中，在预留的SEI载荷类型中定义一种用于承载统计信息的扩展SEI消息。

最后发送端根据发回的统计信息进行Tornado纠删码的调整，使用更加合适当前传送情况的保护策略。最后发送端将要根据统计信息来调整保护策略，即选择合适等级的保护策略。这里发送端还要预先设定对应于不同保护等级的判断阈值系列，设定进入各个级别的阈值，然后根据ALSR所落在阈值选择其相应的等级。由此建立的传送情况的统计、反馈、调整机制能够准确、及时地适应网络传送需求，提高保护能力。

对不同重要性的数据采用了不同的保护策略系列。考虑到关键数据和非关键数据的保护力度要求不同，为了进一步提高适应度，设定了两个不同的保护策略系列，分别用于保护关键数据和非关键数据。这样，两种不同通信需求的数据，即可独立处理，按适合各自需求的保护力度选择保护策略，提高系统效率。

例如，用不同等级的Tornado码作为保护方案系列，其保护能力等级用参数n、1表征，其中n表示数据节点数，1表示校验节点数。用TN(n+1，n)表示由参数n、l确定的Tornado码保护方案。因此对应于关键数据的保护方案系列为:TN_K(n₀+l₀，n₀)，TN_K(n₁+l₁，n₁)，........，TN_K(n_L-1+l_L-1，n_L-1)；同样的对于非关键数据的保护方案系列为:TN_NK(n₀+l₀，n₀)，TN_NK(n₁+l₁，n₁)，........，TN_NK(n_L-1+l_L-1，n_L-1)。设定阈值系列0<G₁，G₂，......，G_L-1<1，即用于判断选择保护等级。发送端在调整保护策略时，根据ALSR和阈值G₁，G₂，......，G_L-1的关系，进行如下操作:

如果0<AlSR<G1，则采用TN_K(n₀+l₀，n₀)对于关键数据进行保护，采用TN_NK(n₀+l₀，n₀)对于非关键数据进行保护；

如果G_i<AlSR<G_i+1，i＝1，2，.....，L-2，则采用T_NK(n_i+l_i，n_i)对于关键数据进行保护，采用TN_NK(n_i+l_i，n_i)对于非关键数据进行保护；

如果G_L-1<AlSR<1，则采用TN_K(n_L-1+l_L-1，n_L-1)对于关键数据进行保护，采用TN_NK(n_L-1+l_L-1，n_L-1)对于非关键数据进行保护。

此外，发送端还根据接收端发回的丢失数据信息，重新发送这些信息。接收端在统计丢失的NALU信息时，同时获得丢失的NALU所对应包含的图像帧的定位信息，该信息包含所在帧的序号及帧中的位置。接收端将定位信息发回给发送端，发送端即可定位到对应的视频流数据，并重新发送。在实时视频通信中，延时太长的视频流数据已经失去了价值，但在某些业务需求情况下或者某种机制下，具有一定延时的数据仍然具有价值，比如在缓冲范围较大的视频通信中，只要延时的视频流数据仍然落在缓冲区内，这些数据就可以用于避免视频流播放的中断。可见重发机制对于提高视频流通信的可靠性和服务质量具有重要价值的。

除了采用错误弹性保护策略以外，本发明的第六实施例在第五实施例的基础上，从错误掩盖和误码扩散消除两个方面出发，结合接收端错误掩盖策略和发送端的误码扩散消除策略，以实现既能尽量减少误码带来的视频质量损失又能避免误码引起扩散的目的。对于错误掩盖，采用简单替代方案即可达到以尽量低的复杂度实现补偿误码损失的效果；对于误码扩散消除，通过H.264已有通道建立误码信息反馈机制，根据反馈实施帧内编码，以达到扩散消除效果，且不增加额外网络负担，确保视频码流对误码问题的鲁棒性，也因此避免因错误掩盖引起的误码扩散。

该方案的基本思路是，在接收端通过对NALU序号的统计，发现丢失数据信息，如Slice的位置等，一方面采用高效算法对丢失数据进行简单替代以掩盖误码损失，另一方面将误码信息反馈给发送端。通过H.264的扩展SEI消息，建立从接收端到发送端的误码信息反馈通道。发送端获知误码信息后，立即采取分段逐次进行帧内编码的策略，将误码Slice分段刷新，以防止误码扩散。

H.264视频通信过程中，发送端对待发送视频流数据进行编码，得到视频码流，然后封装NALU并通过分组报文传送给接收端。接收端接收报文并进行解码，此时接收端需要判断视频流数据是否有丢失，以进行后续的误码消除操作。误码消除流程大致分为掩盖、反馈、扩散消除三个大步骤。

首先，接收端根据NALU序号中断情况来判断是否丢失数据，并统计丢失数据的信息，即误码信息。如前所述，NALU是H.264视频流数据传送的基本单位，每个NALU都有唯一连续的序号。因此，接收端根据接收到NALU序号是否有中断，获知哪些NALU丢失了。从而可以实施针对丢失数据的错误掩盖策略。采用NALU序号来进行统计，不但能保证统计信息精确无误，而且直接利用现有数据信息，不需要额外的承载开销。

首先接收端通过识别接收到的NALU头信息获知序号，由序号的不连续检测误码发生，通过前面NALU得知中间缺失的NALU应该承载的视频数据，对误码引起的数据丢失进行定位，比如丢失NALU的前一个NALU承载的是第N帧的第1个Slice，则按传送顺序可以推断丢失NALU所承载的Slice的位置，应该是本帧的后一个Slice。

接着接收端需要进行视频信息的重同步，由于H.264视频码流连续传送过程中，接收端与数据流需要同步，然后才能正确接收，一旦数据流有中断之后，接收端需要重新进行同步，通过找到中断处之后的下一个NALU头信息来完成解码器的重同步。这一过程，接收端也需要通过下一个NALU的序号来判断中间丢失的NALU个数及其定位信息。

之后，接收端需要进行错误掩盖，丢失数据的NALU被整个丢弃，因此该NALU所承载整个Slice丢失，错误掩盖策略就是通过简单替代，用时间域或者空间域相邻的数据代替丢失的数据，比如采用丢失数据所在帧的前一帧对应位置的Slice恢复图像数据进行掩盖。

接收端在获得误码信息后，将其反馈给发送端。反馈误码信息需要一条反馈通道，为了减少网络负担、简化实现机制，本发明的第一实施例中采用现有的H.264通信机制，定义扩展SEI消息，用于承载误码信息建立反馈，以便发送端结合误码信息防止误码扩散。事实上，结合误码信息反馈机制和发送端的误码扩散消除策略，才能避免因前面接收端实施的错误掩盖策略导致的误码扩散。

在前面的实施例中，利用H.264的扩展SEI消息提供一种从接收端到发送端的信息反馈机制，使得发送端可以及时了解哪些NALU丢失了，这样可以及时进行有效的误码扩散消除，防止因这些丢失的数据引起以后的误码扩散。

在H.264体系内部建立信息反馈机制的好处在于节约网络带宽开销、节省系统处理资源、且不影响互通性。下面介绍如何定义扩展SEI消息。如前所述SEI消息也由H.264码流的基本单位NALU所承载，每个SEI域包含一个或多个SEI消息，而SEI消息又由SEI头信息和SEI有效载荷组成。SEI头信息包括两个码字:载荷类型和载荷大小。其中载荷类型的长度不一定，比如类型在0到255之间时用一个字节表示，当类型在256到511之间时用两个字节0xFF00到0xFFFE表示，依次类推，这样用户可以自定义任意多种载荷类型。在现有H.264标准中，类型0到类型18标准中已定义为特定的信息，如缓存周期、图像定时等。由此可见H.264中定义的SEI域可根据需求存放足够多的用户自定义信息

然后，发送端即开始根据反馈的误码信息进行误码扩散消除。联合误码信息的误码扩散消除方法，其效果要比现有的无反馈的误码扩散消除好。利用误码信息，比如丢失Slice的位置，发送端可以有目的的针对所丢失Slice采取防止措施，比如在以后的编码中避免以丢失Slice作为参考帧，这样可以尽量缩短接收端解码时对该Slice的依赖。

由于H.264编码是基于Slice的，即前后帧的同一Slice的数据是具有参考关联的，后续帧的同一Slice数据是通过前面帧的Slice预测编码的，因此误码扩散也将限定在同一Slice内部。本发明的第二实施例中，采用分段逐次进行帧内编码的策略，即在发送误码之后，对以后帧的该Slice区域分段分割为新的Slice，比如划分处P个宏块作为一个新Slice，然后对其采用帧内编码，以消除该Slice对前面丢失的Slice的参考或依赖。由于H.264视频实时传送系统为了保证传送质量，采用数据率控制方案来限制每帧数据的波动，使得每帧数据量均衡，提高视频传送的稳定性。因此，在每帧中一次进行帧内编码的数据量即宏块数目不能太多，否则将会超过H.264数据率控制范围。

图9示出了分段逐次帧内编码的误码扩散消除的原理。当接收端出现无法恢复的丢包错误后，检测并反馈误码信息给发送端，即丢失数据的Slice所在帧及帧内定位信息通过扩展的SEI消息发回给发送端。发送端从SEI消息中提取丢失的slice定位信息，比如图9中的每帧划分为三个Slice，即Slice#0、Slice#1、Slice#2，而第n帧的Slice#1在传送中丢失，之后需要执行分段逐次帧内编码。

首先，在第n帧中，编码端对Slice#1按宏块扫描顺序，从起始位置开始分割P个宏块组成新的Slice#3，剩余宏块仍然为Slice#1，此时有四个Slice，其中对新的Slice#3进行帧内编码。

接着，在第n+1帧中，上一步中分割新组成的Slice#3在帧内编码之后，作为Slice#3发送出去，而其他Slice仍然按照常规编码。

此后，需要判断Slice#1中是否还剩余宏块，如果还有没有分割的，则返回第一步在下一帧中继续将Slice#1剩余宏块分段组成新的帧，实施帧内编码并发送，直到所有宏块处理完毕。

上面每次划分的宏块个数P应该满足以下条件，尽量大，以避免分割次数、减少处理时延、缩短影响范围，但是需要满足前述H.264数据率控制范围。每次划分的宏块个数可以不一样，但最后一次划分的宏块数将使得丢失Slice中的所有宏块都处理完毕。

比如说视频流数据的一帧由240个宏块组成，初始划分每80个宏块为一个Slice，即1-80宏块为Slice#0，81-160宏块为Slice#1，161-240宏块为Slice#2。而根据数据率计算确定合适分段数值P为12个宏块一段。则第n帧中丢失Slice#1后，Slice#1的80个宏块应该进行分段逐次帧内编码，首先在第n+1帧中选前12个宏块进行帧内编码组成为Slice#3，这样在第n+2帧中Slice#3即可采用常规预测编码，而接着的12个宏块再进行帧内编码组成Slice#4，依次直到第n+7帧时最后剩余为8个宏块进行帧内编码组成Slice#9，才完成分段逐次帧内编码的误码扩散方法流程。

根据实验结果发现采用本发明的错误掩盖和误码扩散消除联合的方法后，得到的视频图像效果非常好。

在最后还要提出一种改进的Tornado编码方案，该方案在本发明的第七实施例中使用这种Tornado编码方案作为错误弹性保护策略。下面简单指出该种Tornado编码方案与传统的编码方案的主要区别。

在采用Tornado码进行数据传送保护的过程中，设置多层的Tornado码校验节点层会在一定程度上增强数据传送保护能力，但是，设置多层的Tornado码校验节点层也会使Tornado码的运算量大，从而使数据在进行传送保护过程中付出了时间延迟长的代价。如果能够在确保数据传送保护能力没有显著下降的情况下，减少校验节点层的层数，就能够有效减少Tornado码的运算量，大大减小数据传送过程中的时间延迟，从而寻求到更高的数据传送保护性能-代价比。因此，本发明的第七实施例是:设置仅具有一层校验节点层的纠删码，根据所述纠删码进行数据传送保护。

该Tornado纠删码方案仅具有一层校验节点层，去掉了Tornado码的中间校验节点层，同样，也去掉了Tornado码中按照Reed-Solomon编码产生最后一层校验节点的固有要求，这样，本发明的纠删码如附图10所示，仅具有一层数据节点层和一层校验节点层，可以说本发明的纠删码是一种结构简化的Tornado码，是一种改进的Tornado码。

本发明改进的Tornado码的数据节点大小L1、数据节点层中数据节点的个数n、校验节点层中校验节点个数L可根据实际需求来确定。如根据数据传送速率、数据类型如音频数据/视频数据等、数据保护能力要求、能够接收的最大网络延迟等因素确定数据节点层中数据节点大小L1、数据节点层中包含的数据节点个数n、校验节点层中包含的校验节点个数L。

如果设定现有技术中Tornado码具有m层中间校验节点层，且从数据节点层至第m个中间层，相邻两层之间的节点数目的等比递缩因子为

最后层与第m层之间的节点数目的等比递缩因子为则现有技术中Tornado码的总节点数Total_Node为:

由于Total_Node＝n+L，因此，L的设置是有限制的，

L不能够任意设定。由于需要保证Tornado码中每层节点的节点个数都是整数，因此需要以及

都是整数，这个条件叫做隐含整数节点数条件。根据该条件，如果给定Tornado码中的m和就可以计算出n需要满足的条件，如当m＝3，

则可以计算出n＝16k，其中k为任意自然数。由此可知，n能够取得的最小值为16，且现有技术中Tornado码的码率r为:

而冗余率1-r为:

本发明改进的Tornado码由于不存在中间校验节点层，使改进的Tornado码不再需要上述隐含整数节点数目的条件，本发明改进的Tornado码的校验节点层的校验节点个数L为:本发明的改进的Tornado码的数据节点层与校验节点层的节点数目的等比递缩因子

可以任意设置，在给定数据节点个数n的条件下，L可以灵活设定。

本发明改进的Tornado码的码率r为:

本发明改进的Tornado码的冗余率1-r为:

本发明改进的Tornado码可表示为TN(n+L，n)，如TN(30，20)，表示数据节点层中数据节点数目n＝20、校验节点层中校验节点数目L＝10。此时，本发明改进的Tornado码的

而码率r＝2/3＝66.7％。

综上所述，本发明在综合上述六种增强技术的基础上，将整个H.264/ERRTP传送架构模块化实现，并且相互结合在一个协议栈上，不仅能够实现各自的优点，而且经过相互增强之后能够体现更好的可靠性和服务质量。

熟悉本领域的技术人员可以理解，上述七个实施例的描述中，涉及到各种具体实现细节和参数选择等，都是可以根据具体应用另外确定，并不影响本发明的实质和范围。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims

1.一种多媒体通信方法，其特征在于，其通信过程包含以下步骤，

A 发送端根据基于实时传送协议的错误弹性保护策略对多媒体数据进行保护，并将其发送给接收端，所述错误弹性保护策略的相关信息携带在封装所述多媒体数据的错误弹性实时传送协议包中，其中，所述错误弹性实时传送协议包为同时包含有多媒体数据和对该多媒体数据进行保护的错误弹性保护策略的相关信息的一种数据包；

2.根据权利要求1所述的多媒体通信方法，其特征在于，其通信过程还包含以下步骤，

3.根据权利要求2所述的多媒体通信方法，其特征在于，其通信过程还包含以下步骤，

D 所述接收端统计传送错误信息，并且实施错误掩盖策略；

4.根据权利要求3所述的多媒体通信方法，其特征在于，所述步骤A包含以下子步骤:

所述步骤B包含以下子步骤:

5.根据权利要求4所述的多媒体通信方法，其特征在于，所述前向纠错编码后的多媒体数据分为数据节点和校验节点两类。

6.根据权利要求5所述的多媒体通信方法，其特征在于，在所述步骤A1中，所述发送端至少根据以下因素之一选择所述前向纠错编码方案:

7.根据权利要求6所述的多媒体通信方法，其特征在于，所述错误弹性实时传送协议包头信息中包含:

8.根据权利要求7所述的多媒体通信方法，其特征在于，在所述步骤A1中，所述发送端将至少一个H.264网络抽象层单元划分为等长的至少一个数据节点，然后对其进行前向纠错编码，得到至少一个校验节点；

9.根据权利要求8所述的多媒体通信方法，其特征在于，在开始传送之前，还包含步骤，

10.根据权利要求9所述的多媒体通信方法，其特征在于，所述发送端和所述接收端都根据所述前向纠错编码子类型字段指示的对应关系建立对应关系表，用于根据所述前向纠错编码类型字段和所述前向纠错编码子类型字段查询所对应的前向纠错编码或前向纠错解码处理模块；

11.根据权利要求10所述的多媒体通信方法，其特征在于，在所述步骤A1中，所述发送端根据所述H.264网络抽象层单元的头信息中的网络抽象层参考标识字段和网络抽象层单元类型字段中的任意一者或两者的组合，以及任何其他可以事先定义的规则来评估对应数据的相对重要性，从而确定所述服务质量等级，进而选择所述前向纠错编码方案，确定所述前向纠错编码类型字段和前向纠错编码子类型字段。

12.根据权利要求10所述的多媒体通信方法，其特征在于，在所述步骤A中，所述发送端根据所述接收端反馈的传送报告评价所述网络传送状况，进而选择所述前向纠错编码方案，确定所述前向纠错编码类型字段和前向纠错编码子类型字段。

13.根据权利要求12所述的多媒体通信方法，其特征在于，所述错误弹性实时传送协议包头信息中的版本信息字段取值为二进制值“11”或十进制值“3”，以区别于实时传送协议；

14.根据权利要求8所述的多媒体通信方法，其特征在于，所述步骤A中，所述发送端将头信息相同的至少一个网络抽象层单元去掉其头信息后再一起进行划分、编码和封装入所述错误弹性实时传送协议包，并将该网络抽象层单元所具有的相同头信息综合在该错误弹性实时传送协议包的头信息中；

15.根据权利要求14所述的多媒体通信方法，其特征在于，在所述错误弹性实时传送协议头信息中，所述网络抽象层单元头信息中的网络抽象层参考标识字段和类型字段填充在所述错误弹性实时传送协议包头信息的净荷类型字段中，该净荷类型字段位于所述错误弹性实时传送协议包头信息的第2个字节的后7比特。

16.根据权利要求15所述的多媒体通信方法，其特征在于，所述错误弹性实时传送协议标识字段为所述错误弹性实时传送协议包头信息的版本信息字段，该版本信息字段位于所述错误弹性实时传送协议包头信息的第1个字节的前2比特。

17.根据权利要求16所述的多媒体通信方法，其特征在于，在所述错误弹性实时传送协议封装格式中，所述网络抽象层单元头信息中的禁止比特字段填充在所述错误弹性实时传送协议包头信息的标记字段中，该标记字段位于所述错误弹性实时传送协议包头信息的第2个字节的前1比特；

18.根据权利要求15所述的多媒体通信方法，其特征在于，在所述步骤A、B中，所述错误弹性实时传送协议标识为所述错误弹性实时传送协议包头信息的标记字段取值，该标记字段位于所述错误弹性实时传送协议包头信息的第2个字节的前1比特。

19.根据权利要求18所述的多媒体通信方法，其特征在于，所述步骤A包含以下子步骤:

所述步骤B包含以下子步骤:

20.根据权利要求8所述的多媒体通信方法，其特征在于，所述步骤C以下子步骤，

C1所述接收端统计生成所述服务质量报告；

C2所述接收端用补充增强信息承载所述服务质量报告，发给所述发送端。

21.根据权利要求20所述的多媒体通信方法，其特征在于，

所述服务质量报告在所述补充增强信息中的封装格式如下:

第4个字节及以后为载荷，用于填充对应服务质量报告。

22.根据权利要求21所述的多媒体通信方法，其特征在于，所述服务质量报告分为发送方报告和接收方报告，由所述载荷类型字段指示区分；

版本信息字段，占2比特；

填充字段，占1比特，用于指示是否有填充内容；

包含特定层面扩展，用于特定层面的保留功能扩展。

23.根据权利要求21所述的多媒体通信方法，其特征在于，用于承载所述服务质量报告的所述补充增强信息进一步由抽象网络层单元承载；

24.根据权利要求21所述的多媒体通信方法，其特征在于，所述通信终端根据当前网络状态和高层应用需求来动态调整所述服务质量报告的统计生成及发送的周期。

25.根据权利要求21所述的多媒体通信方法，其特征在于，当所述通信终端用所述补充增强消息混合承载至少一种媒体流的服务质量报告时，

26.根据权利要求20所述的多媒体通信方法，其特征在于，所述步骤C中，所述接收端根据接收到的所述视频流数据的网络抽象层单元序号，统计丢失的所述网络抽象层单元数目，生成所述服务质量报告，发回给所述发送端；

27.根据权利要求26所述的多媒体通信方法，其特征在于，所述接收端根据接收到的服务质量报告，分析计算网络状况参数；所述参数包括端到端的瞬时带宽、延时和抖动。

28.根据权利要求27所述的多媒体通信方法，其特征在于，所述发送端设置不同等级的错误弹性保护策略系列，在所述步骤A中根据所述服务质量报告选择使用相应等级的所述错误弹性保护策略。

29.根据权利要求28所述的多媒体通信方法，其特征在于，所述步骤C中，所述接收端根据接收到的所述视频流数据的网络抽象层单元序号，统计得到丢失视频流数据的定位信息，并将其发回给所述发送端；

30.根据权利要求8所述的多媒体通信方法，其特征在于，在所述步骤E中，所述发送端根据所述传送错误信息获得所述丢失条带的定位信息，通过对该丢失条带进行分段逐次帧内编码，以实现所述误码扩散消除策略。

31.根据权利要求30所述的多媒体通信方法，其特征在于，所述分段逐次帧内编码包含以下步骤，

E1从所述丢失条带中分割一组连续的宏块，组成新条带，剩余的所述宏块仍属于所述丢失条带，进入步骤E2；

E2对所述新条带进行帧内编码，在下一帧时发送，在此之后该新条带做常规编码，进入步骤E3；

E3在下一帧编码时，判断所述丢失条带是否还包含未处理的宏块，如果是，则返回步骤E1，否则结束帧内编码。

32.根据权利要求31所述的多媒体通信方法，其特征在于，在所述步骤E1中，每次分隔的所述一组连续宏块的大小满足:该组连续宏块进行帧内编码后，本帧的数据率在H.264数据率控制范围内。

33.根据权利要求8所述的多媒体通信方法，其特征在于，所述步骤D包含以下子步骤，

D1所述接收端检测传送错误，并统计传送错误信息；

D2所述接收端在发生传送错误后，进行视频信息重同步；

D3所述接收端根据所述传送错误信息实施所述错误掩盖策略。

34.根据权利要求33所述的多媒体通信方法，其特征在于，所述步骤D1中，所述接收端根据网络抽象层单元序号的不连续情况来检测并统计传送错误信息。

35.根据权利要求34所述的多媒体通信方法，其特征在于，在所述步骤D1中，所述接收端根据所述网络抽象层单元序号的中断情况获得丢失条带的定位信息，该定位信息包含所述丢失条带所在的帧号和所述丢失条带在该帧的位置。

36.根据权利要求35所述的多媒体通信方法，其特征在于，所述错误掩盖策略包含步骤:所述接收端用所述丢失条带所在帧的前一帧的相应条带，来替代该丢失条带。

37.根据权利要求8至36中任意一项所述的多媒体通信方法，其特征在于，所述错误弹性编码方案包含改进的“Tornado”纠删码；

38.根据权利要求2至36中任一项所述的多媒体通信方法，其特征在于，所述步骤B中的传送错误包含数据包丢失、或随机比特错误。

39.一种多媒体通信终端，包含用于实现多媒体通信的基本功能模块，其中包含用于实现多媒体编解码功能的编解码模块，其特征在于，还包含以下模块:

错误弹性实时传送控制协议模块，用于将通过所述编解码模块编码后的多媒体数据进行错误弹性保护后再在网络侧传送，对来自网络侧的所述多媒体数据进行纠错后再传给所述编解码模块进行解码，所述错误弹性保护策略的相关信息携带在封装所述多媒体数据的错误弹性实时传送协议包中，其中，所述错误弹性实时传送协议包为同时包含有多媒体数据和对该多媒体数据进行保护的错误弹性保护策略的相关信息的一种数据包。

40.根据权利要求39所述的多媒体通信终端，其特征在于，还包含以下模块:

41.根据权利要求40所述的多媒体通信终端，其特征在于，还包含

错误掩盖模块，用于实现错误掩盖功能；

所述编解码模块用于实现H.264编解码标准的编解码，还用于误码扩散消除功能；

42.根据权利要求41所述的多媒体通信终端，其特征在于，还包含

43.根据权利要求42所述的多媒体通信终端，其特征在于，其传送层基于所述错误弹性实时传送协议/实时传送控制协议，用于实现支持错误弹性的多媒体传送功能；

44.根据权利要求39至43中任一项所述的多媒体通信终端，其特征在于，所述用于实现多媒体通信的基本功能模块包含以下之一或其任意组合:

主控模块，用于负责整个终端的控制；

业务模块，用于实现高层业务；

通信过程控制模块，用于控制通信过程；

应用协议模块，用于实现应用协议功能；

实时传送控制协议模块，用于实现实时传送控制协议功能；

网络抽象层模块，用于实现网络抽象层功能；

音频编解码模块，用于实现音频编解码功能。