一种基于实时传输协议的多媒体数据传输控制方法

摘要

一种基于实时传输协议的多媒体数据传输控制方法，包含如下步骤：步骤A：发送端完成一个AU组的编码后，在该AU组包含的AU头信息中写入该AU在所属AU组内的相对位置信息；并将该AU组包含的AU发送至接收端；步骤B：接收端根据AU头信息中包含的该AU在所属AU组内的相对位置信息和该AU的AU索引或索引差信息，以解码顺序将其保存在一个可用的AU组缓存的缓存单元中。本发明针对各种不同的音频视频数据格式都可以通过在RTP包的AU头信息中加入参考数据块的相对位置信息，并在发送端和接收端的处理流程上进行相应的改进，使得接收端能够以更为高效的方式对多媒体数据流进行处理。

说明书

技术领域

本发明涉及一种分组包交换网络中的多媒体数据传输控制方法，尤其涉及一种基于RTP(Real-time Transport Protocol，实时传输协议)的多媒体数据传输控制方法。

背景技术

随着网络技术的迅猛发展和全球信息化程度的加深，多媒体实时通信已成为网络通信中的一个非常重要的业务，这些业务主要包括视频点播、可视电话、会议电视、远程教育、流媒体等，这些应用中的关键技术是数字视频的实时采集和传输。

实时传输协议是在多媒体实时通信领域被广泛采用的一种传输协议。RTP被定义在一对一或一对多的传输情况下工作。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议下工作。RFC(Requestfor Comments，请求注解)标准集对不同视频压缩格式定义了不同的数据包并设计了相应的传输控制方法。

对于H.263格式视频数据的RTP传输，RFC 2190中在RTP头信息中定义的负载(paylaod)信息，包括解码需要的编码数据类型，编码特性和数据包前后关系，发出的时间信息以及数据包分割方法。

对于H.263+格式视频数据的RTP传输，RFC 2429中定义了视频流的开始、结束，以及各种帧数据的同步帧数据关系，可以用于指导解码前如何进行组包。

对于H.264格式视频数据的RTP传输，RFC 3984中利用MIME(Multipurpose Internet Mail Extensions，多用途网际邮件扩充协议)来控制初始顺序，最大到达时间差异等，有利于组包的灵活控制。RFC 3640中定义了音频视频数据码流的负载格式。此外RFC 3640中还允许数据包以交叠(Interleave)方式传输，增大了网络传输的容错能力。

但是，上述各种与RTP传输相关的协议都没有从数据封装格式方面为接收端提供预见数据到达的能力；并且，由于经过包交换网络传输的数据会产生乱序、丢失等问题，接收端在收到经过网络发送的数据包后，还需要对其进行重新排序，数据包的存储也通常需要以链表形式进行保存，加重了接收端的处理负荷，降低了接收端的处理能力。

发明内容

本发明要解决的技术问题是，克服现有技术中基于RTP的多媒体数据传输控制方法的不足，提出一种从数据封装格式方面为接收端提供预见数据到达的能力，并使接收端能够以实时组包、零拷贝的方式对音频视频数据流进行处理的多媒体数据传输控制方法。

为了解决上述问题，本发明提供一种基于实时传输协议的多媒体数据传输控制方法，包含如下步骤：

步骤A：发送端完成一个AU组的编码后，在该AU组包含的AU头信息中写入该AU在所属AU组内的相对位置信息；并将该AU组包含的AU发送至接收端；

步骤B：接收端根据AU头信息中包含的该AU在所属AU组内的相对位置信息和该AU的AU索引或索引差信息，以解码顺序将其保存在一个可用的AU组缓存的缓存单元中。

此外，所述AU在所属AU组内的相对位置信息为该AU所属AU组内的其它AU相对于该AU的偏移值。

此外，所述AU在所属AU组内的相对位置信息还可以是该AU相对于所属AU组内特定AU的偏移值。

此外，在所述步骤A之前还包含如下步骤：

发送端和接收端对AU组参数进行协商和确定。

此外，在所述步骤B之后还包含如下步骤：

步骤C：接收端的接收模块完成一个AU组数据的接收后，通知相应的AU处理程序进行处理，同时标记该AU组对应缓存单元的状态为不可用；

步骤D：AU处理程序完成对AU组数据的处理后通知接收模块，接收模块标记相应的缓存单元的状态为可用。

此外，AU组中包含多于一个的可有效解码的数据单元。

此外，所述AU头信息中包含可用于标记该AU是否为所属组内最后一个AU的字段。

本发明针对各种不同的音频视频数据格式都可以通过在RTP包的AU头信息中加入参考数据块的相对位置信息，并在发送端和接收端的处理流程上进行相应的改进，使得接收端能够以更为高效的方式对多媒体数据流进行接收和存放，并使接收端的接收程序与上层应用程序使用相同的数据存储区对多媒体数据流同步进行处理。

附图说明

图1是RFC 3640定义的RTP包的负载格式；

图2是RFC 3640定义的RTP包中的AU头部分的结构示意图；

图3是RFC 3640定义的AU头信息的基本结构示意图；

图4是本发明增加了AU在组内的相对位置信息的AU头信息的结构示意图。

具体实施方式

本发明的基本思路是，通过在RTP包的AU头信息中加入各参考数据块的相对位置信息，接收端根据该相对位置信息及AU索引信息将该AU以正确的解码位置放入缓存中。

下面将结合附图，并以RFC 3640的RTP封装格式为例对本发明进行详细的说明。

AU(Access Unit，访问单元)作为最小的解码有效单元，通常是发送端和接收端编码、解码和传输控制的基本单位，如何对AU进行传输控制、存储和读取是发送端和接收端快速高效地进行多媒体通讯的关键因素。

图1是RFC 3640定义的RTP包的负载格式。

图2是RFC 3640定义的RTP包中的AU头部分的结构示意图。

如图1和图2所示，RTP包头包含RTP头、AU头部分、附加数据部分和AU数据部分。由于一个RTP包中可包含多个AU，所以RTP包的AU头部分包含AU头长度和多个AU头。

图3是RFC 3640定义的AU头信息的基本结构示意图。

如图3所示，AU头信息中包含AU的大小、AU索引或索引差、CTS标志、CTS差值、DTS标志、DTS差值、RAP标志和流状态。各字段在RFC 3640文档中都有详细的定义。

为了使接收端在接收到RTP包以及其中包含的AU时，能够将其直接以正确的解码顺序存放，可将AU进行分组，并在AU头信息中加入该AU在组内的相对位置信息。

AU组中包含AU的数量由多种因素所决定。首先AU组中包含AU的数量需大于一次编解码有效的所有AU包/AU片断数量的总和。此外，为了对以交叠方式传输的AU进行正确的处理，AU组包含AU的数量需大于maxDisplacement。关于maxDisplacement的定义以及计算方法请参见RFC3640文档。

此外，AU组中包含AU的数量需要考虑到接收端上层应用的处理能力以及视频/音频数据显示/播放的视觉/听觉平滑效果；此外AU组中包含AU的数量还与发送端和接收端能够提供的缓存大小等因素直接相关。AU组中包含AU的数量还受到发送方编码器产生数据速度限制。

图4是本发明增加了AU在组内的相对位置信息的AU头信息的结构示意图。如图4所示，“前面第x个AU的偏移值”表示本AU的前面第x个AU的第一个字节相对于本AU的第一个字节的偏移值，以字节表示。“后面第y个AU的偏移值”表示本AU的后面第y个AU的第一个字节相对于本AU的第一个字节的偏移值，以字节表示。上述偏移值由发送端完成对AU的编码后，在发送前分别进行设置。

图4中的“忽略标志”可表示该AU是否可忽略，也可作其它用途。

当然，AU在组内的相对位置信息也可以其它方式表示，例如在AU头信息中包含该AU相对于组内第一个AU的偏移值。

在接收端，在接收到RTP数据包后，需要将RTP数据包中包含的各AU的AU数据部分根据其所在的AU组和在组内的相对位置信息存储在相应的AU组缓存中。

上述AU组缓存的大小可通过如下方式确定：

AU缓存的大小＝n×(AU组最大长度)；

其中，n表示AU组缓存中可以存储的AU组的数量，n＞1。

AU组最大长度＝(AU组中包含AU数量的最大值)×(AU最大长度)。

上述“AU组中包含AU数量的最大值”和“AU最大长度”可采用如下方式进行估算：

当选定了一种编解码格式后，根据数据处理能力，发送方和接收方根据所采用的平台建立一个参考测试环境，通过系统一般情况下和系统CPU和其它资源竞争紧张情况下数据的接收能力来确定。此外，估算还需参考如下因素：网卡的处理速度，TCP/IP的数据吞吐量，编码器和解码器的处理速度，在多任务情况下缓冲队列处理和数据搬移速度等。另外发送方和接收方在有多个传输通路并行处理时还需要考虑每个通路的平均数据处理速度。

上述AU组缓存中可以存储的AU组的数量n的取值受到上层应用程序对数据的处理速度的制约，通常n取为大于3的整数。允许同时接收多个AU时，上层可以至少处理一个AU组。由于网络发送的延迟到达和数据包到达顺序有可能与解码顺序不一致，因此可以允许有至少两个AU组同时在接收。

上述AU组缓存可分为n个缓存单元，其中，每个缓存单元保存一个AU组，缓存单元大小等于AU组最大长度。此外，AU组缓存还可采用链表和环形数组等方式。

由于AU组的接收和对AU组数据的处理可由接收端的接收模块和上层应用程序同时进行，所以需对AU组缓存的使用进行同步处理。同步处理可采用全局变量、信号量、系统消息等方式实现。例如，当AU组接收模块完成对一个AU组的接收时，发送系统消息给上层应用程序，系统消息中包含保存该AU组的缓存单元的编号及起始地址和数据长度等信息，同时将对应的AU组缓存单元设置为不可用状态；当上层应用程序对该AU组的数据处理完毕后，发送系统消息给接收模块，接收模块将对应的AU组缓存单元设置为可用状态，将接收到的下一个AU组的数据保存在状态为可用的AU组缓存单元中。

上述“AU组中包含AU数量的最大值”和“AU最大长度”等AU组参数可以采用静态配置的方式在发送端和接收端分别进行配置。但是，为了增加系统的灵活性，适应各种音频视频格式的多媒体数据的处理，上述各参数可在发送前或发送过程中进行动态配置，参数的动态配置及发送接收流程包含如下步骤：

步骤1：发送端向接收端发送控制信息；

上述控制信息中包含AU最大长度等信息；

上述控制信息可采用MIME/SDP格式进行定义和解析。

步骤2：接收端根据发送端发送的控制信息及接收端对数据的处理能力计算AU组中包含AU数量的最大值，并将此信息发送至发送端；

步骤3：发送端根据自身的处理能力和数据缓冲的大小，修改并确定AU组中包含AU数量的最大值，并将该值发送至接收端；同时建立发送队列及相应资源；

步骤4：接收端根据最终确定的AU组中包含AU数量的最大值、AU最大长度等信息分配用于保存AU组数据的AU组缓存；

步骤5：发送端开始编码并将编码后的AU数据保存至发送队列中；

步骤6：发送端完成一个AU组的编码后，将各AU在AU组内的相对位置信息写入AU头信息中，将AU组发送至接收端；

步骤7：接收端根据AU头信息中包含的AU在所属AU组内的相对位置信息和AU索引或索引差信息，以解码顺序将各AU保存在一个可用的AU组缓存区中；

步骤8：接收端接收到完整的AU组数据时，将保存该AU组数据的AU组缓存区的地址、长度等信息通知上层应用程序进行处理；

步骤9：上层应用程序对该AU组处理完毕，通知接收端，接收端标志相应AU组缓存区为可用。

此外，当AU组发送延迟过大时，发送端可在当前AU组尚未发送完成时，将组内的待发AU封装成下一个AU组的AU进行发送，同时在该待发AU的AU头信息的忽略标志中，写入该AU在先前所属的AU组中的序号。接收端对AU头信息的忽略标志进行判断，当忽略标志大于0时，根据该AU的AU索引和忽略标志中的该AU在先前所属的AU组中的序号获知该AU先前所属的AU组，并停止该先前所属AU组的后续AU的接收，当该AU先前所属AU组中AU索引值小于该AU的组内AU接收完毕时，标记该AU组接收完毕，通知上层应用程序对该AU组进行处理。

此外，由于AU组中包含的AU数不一定每次相同，AU头信息的忽略标志可用于表示当前AU为组内最后一个AU。

此外，在AU组的接收过程中可以根据上述maxDisplacement值对当前的网络的稳定性进行监测，即出现当前接收到的AU的AU时间戳和最早应该出现但是没有出现的AU的AU时间戳的差值大于maxDisplacement时，可以认为网络条件不稳定，即应该接收到的数据没有到达。此时系统应进行如下处理：

如果相应的标准中规定了对没有到达的非关键AU不可以忽略，则告知上层应用程序，由上层应用程序决定是否丢弃该AU组，当这种情况频繁发生时，系统可以重新回到接收的初始状态，发送方重新开始发送。