专利名称：一种基于实时传输协议的多媒体数据传输控制方法
技术领域：
本发明涉及一种分组包交换网络中的多媒体数据传输控制方法，尤其涉及一种基于RTP (Real-time Transport Protocol,实时传输协议)的多媒体数 据传输控制方法。
背景技术：
随着网络技术的迅猛发展和全球信息化程度的加深，多媒体实时通信已 成为网络通信中的一个非常重要的业务，这些业务主要包括视频点播、可视电话、会议电视、远程教育、流媒体等，这些应用中的关键技术是数字视频 的实时采集和传输。实时传输协议是在多媒体实时通信领域被广泛采用的一种传输协议。 RTP被定义在一对一或一对多的传输情况下工作。RTP通常使用UDP来 传送数据，但RTP也可以在TCP或ATM等其他协议下工作。RFC( Request for Comments,请求注解)标准集对不同视频压缩格式定义了不同的数据包 并设计了相应的传输控制方法。对于H.263格式视频数据的RTP传输，RFC 2190中在RTP头信息中定 义的负载(paylaod)信息，包括解码需要的编码数据类型，编码特性和数 据包前后关系，发出的时间信息以及数据包分割方法。对于11.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是RFC3640定义的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是RFC3640定义的AU头信息的基本结构示意图。如图3所示，AU头信息中包含AU的大小、AU索引或索引差、CTS 标志、CTS差值、DTS标志、DTS差值、RAP标志和流状态。各字段在 RFC 3640文档中都有详细的定义。为了使接收端在接收到RTP包以及其中包含的AU时，能够将其直接 以正确的解码顺序存^t，可将AU进行分组，并在AU头信息中加入该AU 在组内的相对位置信息。AU组中包含AU的数量由多种因素所决定。首先AU组中包舍AU的 数量需大于一次编解码有效的所有AU包/AU片断数量的总和。此外，为了 对以交叠方式传输的AU进行正确的处理，AU组包含AU的数量需大于 maxDisplacement。关于maxDisplacement的定义以及计算方法i青参见RFC 3640文档。此外，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緩存的大小-nx (AU组最大长度)；其中，n表示AU组緩存中可以存储的AU组的数量，n>l。AU组最大长度=(AU组中包含AU数量的最大值)x (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组 参数可以采用静态配置的方式在发送端和接收端分别进行配置。但是，为了 增加系统的灵活性，适应各种音频视频格式的多媒体数据的处理，上述各参数可在发送前或发送过程中进行动态配置，参数的动态配置及发送接收流程 包含如下步骤
步骤l:发送端向接收端发送控制信息； 上述控制信息中包舍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组，当这种情况频繁发 生时，系统可以重新回到接收的初始状态，发送方重新开始发送。
权利要求
1. 一种基于实时传输协议的多媒体数据传输控制方法，包含如下步骤步骤A发送端完成一个AU组的编码后，在该AU组包含的AU头信息中写入该AU在所属AU组内的相对位置信息；并将该AU组包含的AU发送至接收端；步骤B接收端根据AU头信息中包含的该AU在所属AU组内的相对位置信息和该AU的AU索引或索引差信息，以解码顺序将其保存在一个可用的AU组缓存的缓存单元中。
2、 如权利要求1所述的基于实时传输协议的多媒体数据传输控制方 法，其特征在于，所述AU在所属AU组内的相对位置信息为该AU所属 AU组内的其它AU相对于该AU的偏移值。
3、 如权利要求1所述的基于实时传输协议的多媒体数据传输控制方 法，其特征在于，所述AU在所属AU组内的相对位置信息为该AU相对于 所属AU组内特定AU的偏移值。
4、 如权利要求1所述的基于实时传输协议的多媒体数据传输控制方 法，其特征在于，在所述步骤A之前还包含如下步骤发送端和接收端对AU组参数进行协商和确定。
5、 如权利要求1所述的基于实时传输协议的多媒体数据传输控制方 法，其特征在于，在所述步骤B之后还包含如下步骤步骤C:接收端的接收模块完成一个AU组数据的接收后，通知相应的 AU处理程序进行处理，同时标记该AU组对应緩存单元的状态为不可用；步骤D: AU处理程序完成对AU组数据的处理后通知接收模块，接收 模块标记相应的緩存单元的状态为可用。
6、 如权利要求1所述的基于实时传输协议的多媒体数据传输控制方 法，其特征在于，AU组中包含多于一个的可有效解码的数据单元。
7、如权利要求1所述的基于实时传输协议的多媒体数据传输控制方法，其特征在于，所述AU头信息中包含可用于标记该AU是否为所属组内 最后一个AU的字段。
全文摘要
一种基于实时传输协议的多媒体数据传输控制方法，包含如下步骤步骤A发送端完成一个AU组的编码后，在该AU组包含的AU头信息中写入该AU在所属AU组内的相对位置信息；并将该AU组包含的AU发送至接收端；步骤B接收端根据AU头信息中包含的该AU在所属AU组内的相对位置信息和该AU的AU索引或索引差信息，以解码顺序将其保存在一个可用的AU组缓存的缓存单元中。本发明针对各种不同的音频视频数据格式都可以通过在RTP包的AU头信息中加入参考数据块的相对位置信息，并在发送端和接收端的处理流程上进行相应的改进，使得接收端能够以更为高效的方式对多媒体数据流进行处理。
文档编号H04L29/06GK101212452SQ200610156209
公开日2008年7月2日 申请日期2006年12月31日 优先权日2006年12月31日
发明者张明华, 朱佐亮, 罗宏宇 申请人:中兴通讯股份有限公司