用于多媒体流中速率适配的缓冲器水平信令

摘要

在多媒体流传输网络中，客户端具有接收器缓冲器存储从服务器接收到的分组以补偿服务器的数据传输量和客户端的数据使用量之间的差值，服务器应该能够基于接收器缓冲器的状态来适配数据传输率。为了速率适配的目的，服务器基于由客户端提供的信息在接收器缓冲器内重构分组的列表。被发送到服务器的信息表示将要被解码的下一个单元以及将要被解码的下一个单元所属于的分组的序列号、或在客户端将要被解码的下一个分组、下一个NAL的DON号或携带将要被解码的下一个NAL的分组的序列号以及表示下一个NAL单元的解码顺序的DON。

说明书

技术领域

本发明一般地涉及多媒体流，并且更特别地，涉及多媒体流服务中服务器和客户端之间的速率适配。

背景技术

在多媒体流服务中，包括三个参与方：流服务器、流客户端和传输信道或基础网络。就吞吐量和可靠性(即，如果没有采取吞吐量比特率保证)而言，通常传输信道是该项业务的瓶颈，但吞吐量限制也可发生在客户端和/或服务器处。

在实时的流传输系统中，由于信道、客户端和服务器的动态改变吞吐量特性，流递送需要是自适应的以便为用户维持实时回放的体验。服务器应该将传输速率适配到系统变化的吞吐量。这种速率适配系统的示例可在Haskell等人的专利(美国专利No.5,565.924，“Encoder/Decoder Buffer Control for variable Channel”)中找到。

流客户端提供用于在将进入的数据传递到媒体解码器以便播放之前将其存储的接收器缓冲。接收器缓冲器用于对源编码速率(也称为采样速率)和传输速率之间的差值进行补偿(预解码器缓冲)。它还用于对信道上分组传输延迟变化进行补偿(抖动缓冲)。一般地，假定这两个功能合并在单个的接收器缓冲器中。然而，它们也可以用接收器内的两个分离的缓冲器来实现，尽管从延迟的观点看这样的实施不是最适宜的。接收器缓冲还可消除适配不精确性(即，如果系统吞吐量没有与服务器输出恰好匹配)。

如果接收器缓冲器变为空(即，缓冲器下溢)，这意味着解码器用光了解码的数据，客户端在重新开始之前需要中止播放并且再次缓冲进入的数据。另一方面，如果进入的数据率快于播放的速率，则接收器缓冲器的空间将被耗尽(即，缓冲器溢出)，这将导致从缓冲器丢弃分组以便为新进入的分组腾出空间。当分组被丢弃时，视频质量被恶化。为了确保平滑和无瑕疵的播放，客户端的接收器缓冲器应该被保持在某个充满度范围内。为了确保接收器缓冲器不会下溢或溢出，在服务器处的传输和采样的以及在客户端处的传输和采样的比特率必须被适当地控制。

如在3GPP TS26.234中定义的3GPP速率适配信令是基于以RTCP APP(应用定义的实时控制协议)分组的形式从接收器发送到发送方的反馈。该分组包括接收器缓冲器内最旧的分组的序列号(SN)。该序列号被称为OBSN(最旧缓冲的序列号)。

OBSN的信令允许发送方执行必需的适配。然而，如果解码顺序和显示顺序是不同的，则发送方可能无法导出缓冲器的状态并且信令的目的受挫。利用在版本5中支持的PSS(分组交换流媒体服务)视频编解码器，因为它们的分组传输顺序等于解码顺序，所以这将不是问题。

在版本6中，H.264(也即已知的MPEG-4 AVC)将被添加到PSS编解码器的列表中。利用H.264，因为在有效载荷级(在IETF H.264RTP有效载荷格式草案中规定)的交错分组化，传输顺序和解码顺序可以不同。

相同的属性还存在于许多的音频和语音编解码器的帧交错传输，例如AMR-NB、AMR-WB、AMR-WB+、AAC和AAC加(对于后者，在RFC 3640中定义的交错方法被使用)。

以下示出的问题假设服务器传输一系列的分组，其RTP序列号被表示为x、x+1、x+2、x+3、......。让我们进一步假设这些RTP中的每一个携带两个单元。从使用的编解码器和有效载荷格式，这些单元中的每一个被映射到解码顺序y。解码顺序y定义如下：如果分组具有解码顺序y，其为要解码的第一个分组。即，当当前分组具有解码顺序y时，这还意味着在当前分组被提供给解码器的时刻，(y-1)分组已经被解码。例如，在H.264的情况下，由H.264 RTP有效载荷格式所定义的DON(解码顺序号)可用于导出在每个分组内接收到的NAL单元的解码顺序。

下面的示例示出了单元的序列，其中对于每个单元赋予了其所属于的分组的序列号、其单元号(即，其为分组中的第一单元还是第二单元)以及其解码顺序。

    SN    单元号    解码顺序    x    x    x+1    x+1    x+2    x+2    x+3    x+3    x+4    x+4    x+5    x+5    x+6    x+6    ...    x+49    x+49    x+50    x+50    x+51    x+51    0    1    0    1    0    1    0    1    0    1    0    1    0    1    ...    0    1    0    1    0    1    y    y+1    y+2    y+3    y+4    y+5    y+6    y+7    y+100    y+8    y+9    y+10    y+11    y+12    ...    y+97    y+98    y+99    y+101    y+102    y+103

在上面给出的示例中，对于从具有从x到x+3的SN的分组接收到的每个单元，解码顺序以1递增。然而，对于分组x+4该规则被打破。例如，分组x+4的第一单元属于将仅在未来被解码的帧。

另外，由H.26L有效载荷格式所定义的DON(解码顺序号)将序列号映射到解码顺序y。然而，尽管y值是从DON值导出的，这两个值不总是相同的。

现在让我们观察接收器缓冲器的进展并且假设在某个时刻，接收器已经接收到分组x、x+1、x+2、x+3。在这种情况下，在缓冲器中最旧的序列号(OBSN)是x，在RTCP RR报告中发送的最高接收序列号(HSN)是x+3。随着时间的推进，SN x的分组已经被解码并且SN x+4的分组已经被接收。因此，服务器将OBSN＝x+1(缓冲器内新的“最旧”序列号)和HSN＝x+4(接收到的新的“最近”SN)通过信号发送到客户端。

随着时间的进一步推进，例如分组x+1、x+2和x+3的单元已经被播放并且x+5、x+6和x+7已经被接收。在此，缓冲器的状态是x+4、x+5、x+6和x+7。因此，客户端将OBSN＝x+4和HSN＝x+7通过信号发送到服务器。大约在此刻将出现问题，因为在x+5之后，对于下面的分组x+6、x+7等的解码顺序号小于分组x+4的第一单元的解码顺序号。因此，当前的速率适配信令OBSN将保持在x+4直到该单元被播放并且分组x+50被接收，在此时刻OBSN将被更新。因为OBSN没有被根据解码更新并且从接收器缓冲器除去了分组，所以服务器将失去接收器缓冲器状态的跟踪。

另一个限制来源于这样的事实，即由于多个单元可以用单个的分组发送，例如当接收器将关于OBSN是x+2通过信号发送到发送方时，发送方无法确定该分组的第一单元是否仍在缓冲器中或是否仅该分组的第二单元在缓冲器内。

对于AMR-NB和AMR-WB，RFC 3267定义如何能够使用交错。对于AMR-WB+，针对AMR-WB应用定义了相同的交错规则。存在发送到有效载荷报头内部的两个相关参数：ILL和ILP。此外，每AMR分组的帧的数目固定于某个数(例如为N)。这三个值定义了数学上确定的方法，该方法用于定义将要在存在于AMR RTP分组内部的RTP有效载荷内存在的帧的顺序。

可以看出如同在H.26L中，在AMR中不存在硬编码(hard-coded)的DON的概念，因为基于发送到RTP有效载荷报头内的ILL、ILP和N值，每个帧具有确定性的解码顺序。由客户端和服务器通过使用发送到RTSP PLAY响应内的第一RTP序列号并利用(ILL，ILP，N)三元组，AMR-方式的DON被解译。对于AMR-NB，AMR-WB和AMR-WB+的交错流，针对H.26L情况所提到的相同问题陈述是有效的。

总之，速率适配信令的现有技术的方法是基于当前接收器播放缓冲器内的最旧分组，允许发送方来估计接收器缓冲器内的字节数以及播放缓冲器的持续时间。该信息由发送方使用以执行适配从而避免接收器下溢(播放中断)或接收器溢出(分组丢失)。然而，因为在某些场合下，解码顺序和传输顺序是不相同的并且多个单元可位于同一个分组内，所以发送方可能丢失接收器缓冲器的跟踪。

图1中示出了典型的RTP分组。RTP分组包括MTAP16类型的多时间集合分组以及两个多时间集合单元。图2示出了位于分组第一行中的RTP报头。如图2中所示，在RTP报头的第一行内示出分组的序列号(SN)。如图1所示，聚集型分组将多个网络抽取层(NAL)单元聚集到单个的RTP有效载荷中。特别地，在MTAP16中，NAL单元有效载荷包括16比特的无符号解码顺序号(DON)基数，或DONB(参见分组的第二行)。DONB包含第一NAL单元的DON的值，从而所有其它的NAL的DON的值可以以DOND表达，或某个NAL中的DON的值与DONB之间的差值。

H.264编解码器的RTP有效载荷格式可以在IETF音频可视化传输工作组因特网草案draft-ietf-avt-rtp-h264-05(2004年4月)中找到。

发明内容

本发明提供了一种机制，由于多媒体流传输网络中的服务器设备，该服务器发送流数据分组到客户端以在客户端设备中播放并重构存储在接收器缓冲器内的数据分组列表。基于该重构，服务器设备调整提供给客户端设备的流数据量，从而控制接收器缓冲器的水平(level of receiver buffer)。

本发明的第一方面提供一种用于在多媒体流传输网络中控制客户端中的接收器缓冲器的水平的方法，该流传输网络包括用于向该客户端提供多个分组中的流数据的服务器，其中该至少一些数据分组存储在接收器缓冲器内以补偿服务器的数据传输量与客户端的数据使用量之间的差值，并且其中以基于与在客户端中的播放顺序关联的多个解码顺序值的解码顺序将分组解码。该方法包括：

基于解码顺序值在客户端中确定在接收器缓冲器的分组之中的将要被解码的下一个分组；以及

向服务器发送表示将要被解码的所述下一个分组的信息，从而允许客户端基于该信息调整提供给客户端的流数据量。

根据本发明，分组与包括将要被解码的下一个单元的多个单元关联，并且其中将要被解码的下一个分组是将要被解码的下一个单元所属于的分组。单元中的每一个具有单元号并且数据分组中的每一个具有对于客户端和服务器都是已知的序列号，并且发送到服务器的信息表示将要被解码的所述下一个单元的单元号以及所述下一个单元所属于的分组的序列号。

根据本发明，服务器保留已经被发送的单元的列表以及单元号和发送单元所属于的分组的序列号以及所述序列号和单元号之间到解码顺序的映射的记录，以便基于所述映射确定在接收器缓冲器内的数据单元，从而基于所述确定在服务器中调整提供给客户端的流数据量。

根据本发明，发送到服务器的信息另外表示了将要被解码的所述下一个单元的安排的播放时间与所述下一个单元的解码时间之间的差值。

根据本发明，发送到服务器的信息另外表示了由客户端接收到的最高序列号从而允许服务器确定接收器缓冲器内的数据分组。

根据本发明，每个单元具有时间戳并且每个数据分组具有对于客户端和服务器都已知的序列号，并且发送到服务器的信息表示将要被解码的所述下一个单元的时间戳以及所述下一个单元所属于的分组的序列号。

本发明的第二方面提供一种多媒体流传输网络，包括：

至少一个客户端；以及

用于向客户端提供在多个分组内的流数据的服务器，其中客户端包括：

接收器缓冲器，用于存储将要被解码的至少一些数据分组以便补偿服务器的数据传输量和客户端的数据使用量之间的差值，并且其中以基于与在客户端内的播放顺序关联的多个解码值的解码顺序将分组解码，以及

一种机制，用于基于解码顺序值向服务器发送表示在缓冲器的分组之中的将要被解码的下一个分组的信息以便允许服务器调整提供给客户端的流数据的速率。

根据本发明，分组与包括将要被解码的下一个单元的多个单元关联，并且其中将要被解码的下一个分组是将要被解码的下一个单元所属于的分组。每个单元具有单元号并且每个数据分组具有对于客户端和服务器都已知的序列号，并且发送到服务器的信息表示将要被解码的所述下一个单元的单元号以及所述下一个单元所属于的分组的序列号。

根据本发明，服务器保留已经被发送的单元的列表以及单元号和发送单元所属于的分组的序列号以及所述序列号和单元号之间到解码顺序的映射的记录，以便基于所述映射确定在接收器缓冲器内的数据单元，从而基于所述确定在服务器中调整提供给客户端的流数据量。

根据本发明的第三方面，提供了一种多媒体流传输网络中的客户端设备，该流传输网络包括用于向客户端设备提供多个分组内的流数据的服务器设备，其中以基于与客户端设备中的播放顺序关联的多个解码值的解码顺序将分组解码。该客户端设备包括：

接收器缓冲器，用于存储将要被解码的至少一些数据分组以便补偿服务器设备的数据传输量和客户端设备的数据使用量之间的差值；以及

一种机制，用于基于解码顺序值向服务器设备发送表示在接收器缓冲器的分组之中的将要被解码的下一个分组的信息以便允许服务器设备调整提供给客户端设备的流数据。

根据本发明，分组与包括将要被解码的下一个单元的多个单元关联，并且其中将要被解码的下一个分组是将要被解码的下一个单元所属于的分组。每个单元具有单元号并且每个数据分组具有对于客户端设备和服务器设备都已知的序列号，并且发送到服务器设备的信息表示将要被解码的所述下一个单元的单元号以及所述下一个单元所属于的分组的序列号。

根据本发明，客户端设备进一步包括具有可执行代码的软件程序以确定：

基于解码顺序值的接收器缓冲器中的数据分组的解码顺序，以及

基于解码顺序值的接收器缓冲器内的数据分组之中的将要被解码的下一个分组。

本发明的第四个方面提供了一种服务器设备，该设备用于在多媒体流传输网络中提供流数据，该多媒体流传输网络包括至少一个客户端设备，用于接收多个数据分组中的流数据以及以基于与播放顺序关联的多个解码顺序值的解码顺序将数据分组解码，其中客户端设备具有接收器缓冲器，用于存储至少一些数据分组，以补偿服务器设备的数据传输量和客户端设备的数据使用量之间的差值。该服务器设备包括：

一种机制，用于基于客户端设备中的解码顺序值从客户端设备接收表示在接收器缓冲器的分组之中的将要被解码的下一个分组的信息；以及

一种软件程序，用于基于该信息确定接收器缓冲器中的分组，以调整提供给客户端设备的流数据量以便控制接收器缓冲器的水平。

根据本发明，分组与包括将要被解码的下一个单元的多个单元关联，并且其中将要被解码的下一个分组是将要被解码的下一个单元所属于的分组。每个单元具有单元号并且每个数据分组具有对于客户端设备和服务器设备都已知的序列号，并且发送到服务器设备的信息表示将要被解码的所述下一个单元的单元号以及所述下一个单元所属于的分组的序列号。

本发明的第五方面另外提供了一种软件产品，该产品嵌入到计算机可读介质中以便在多媒体流传输网络的客户端设备中使用，该流传输网络包括用于向客户端设备提供多个分组中的流数据的服务器设备，其中以基于与客户端设备内的播放顺序关联的多个解码值的解码顺序将分组解码，并且其中客户端设备包括接收器缓冲器，用于存储将要被解码的至少一些数据分组，以补偿数据传输之间的差值。该软件产品包括：

一种代码，用于基于解码顺序值确定接收器缓冲器中数据分组的解码顺序；以及

一种代码，用于基于该解码顺序值确定接收器缓冲器数据中的数据分组之中的将要被解码的下一个分组，从而向服务器设备提供表示将要被解码的所述下一个分组的信息，允许服务器设备基于该信息调整提供给客户端设备的流数据量以控制接收器缓冲器的水平。

根据本发明，分组与包括将要被解码的下一个单元的多个单元关联，并且其中将要被解码的下一个分组是将要被解码的下一个单元所属于的分组。每个单元具有单元号并且每个数据分组具有对于客户端设备和服务器设备都已知的序列号，并且发送到服务器设备的信息表示将要被解码的所述下一个单元的单元号以及所述下一个单元所属于的分组的序列号。

本发明的第六方面，提供了一种软件产品，该产品嵌入到计算机可读介质中以便在多媒体流传输网络中提供流数据的服务器设备中使用，多媒体网络至少包括客户端设备，用于接收多个数据分组中的流数据并且以基于与播放顺序关联的多个解码顺序值的解码顺序将数据分组解码，其中客户端设备具有接收器缓冲器，用于存储至少一些数据分组以补偿服务器设备的传输量与客户端设备的数据使用量之间的差值。该软件产品包括：

一种代码，用于将解码顺序与已经被发送到客户端设备的数据分组的序列号联系；以及

一种代码，用于基于所述联系和由客户端设备提供的表示在客户端设备中将要被解码的下一个分组的信息，确定接收器缓冲器中的数据分组，从而允许服务器设备调整提供给客户端设备的流数据量以控制接收器缓冲器的水平。

附图说明

图1是表示典型的RTP分组的框图；

图2是表示典型的RTP报头的框图；

图3是表示具有可根据本发明执行速率适配方法的服务器设备和客户端设备的多媒体流系统的框图。

具体实施方式

本发明提供缓冲器水平信令(buffer level signaling)的方法以便允许多媒体流传输网络中的服务器在H.264的编解码器中执行速率配适，对于编解码器分组传输顺序不同于解码顺序。根据本发明的缓冲器水平信令方法是基于有关将要被解码的下一个单元的信息。将要被解码的下一个单元所属于的分组的序列号(SN)在这里称为NDSN。

在根据本发明的缓冲器水平信令的方法中，接收器向发送方报告将要被解码的下一个单元的信息。该单元是可在RTP有效载荷格式中定义的可识别解码单元。更特别地，可识别单元可由分组内的NDSN和单元号(NDU)标识。在音频编解码器的情况下，可识别编码单元通常是帧。在H.264编解码器的情况下，可识别解码单元是NAL(网络抽取层)单元。例如，将要被传递到解码器的下一个NAL单元是在具有SN＝100的分组中发现的第三个NAL，则接收器将值100和2发送到发送方。

接收器基于最小的y值向发送方报告将要解码的下一个单元的信息。基于接收到的NDSN和NDU，服务器可识别下一个将被解码的单元。如此，发送方可导出接收器缓冲器的正确状态。利用在背景部分给出的一组x和y值，该实施可如下示出：

当分组x+4、x+5、x+6和x+7已被接收时，在这些分组中携带的单元的解码顺序是y+100、y+8、y+9、y+10、y+11、y+12、y+13和y+14。因此，分组x+4的第二单元具有y+8的最小解码顺序值。因此，将要被解码的下一个单元可被明确地通过属于的分组的SN(x+4)和相应的单元号(NDU＝1)发送到发送方。接收器还总是设置HSN＝x+7，因为这是最晚接收到的序列号。上面讨论的情况在表1中示出：

  解码顺序值  接收器缓冲器的分组  NDSN  HSN    NDU    ...    ...    ...    y+5    y+6    y+7    y+8    y+9    y+10    y+11    ...    ...    ...  ...  ...  ...  x+2、x+3、x+4  x+3、x+4、x+5  x+3、x+4、x+5  x+4、x+5、x+6  x+4、x+5、x+6  x+4、x+5、x+6、x+7  x+4、x+6、x+7、x+8  ...  ...  ...  ...  ...  ...  x+2  x+3  x+3  x+4  x+5  x+5  x+6  ...  ...  ...  ...  ...  ...  x+4  x+5  x+5  x+6  x+6  x+7  x+8  ...  ...  ...    .    .    .    1    0    1    1    0    1    0    .    .    .

表1

注：当解码顺序值＝y+6时，NDSN＝x+3并且NDU＝0；当解码顺序值＝y+7时，NDSN＝x+3并且NDU＝1。

注：接收器缓冲器中的分组的一些数据单元可被解码并且从缓冲器中移去。然而，缓冲器中的每一个分组具有保留在缓冲器中的至少一个数据单元。

基于接收到的NDSN和NDU，发送方可获得关于哪些分组存在于接收器缓冲器中的精确估计，并且对于接收器缓冲器中的每个分组，哪些数据单元位于接收器缓冲器内。

在接收器侧：

-计算当前位于缓冲器中的编码单元的解码顺序(y值)；

-找到将要被解码的下一个单元(具有最小y值的单元)；以及

-发送将要被解码的下一个单元的单元号(NDU)和该单元所属于的下一个分组的序列号(称其为NDSN)。

在发送方侧：

-保留已被发送的单元列表(L)。对于每个单元保留其中单元被发送的分组的序列号(SN)、指示分组中单元的顺序的单元号以及单元号和顺序号到解码顺序号(即其y值)的映射的记录。

-在RTCP RR或SR报告中查找由接收器发送的NDU、NDSN和HSN；

-通过在L中查找其记录信息符合下面要求的所有单元，在接收器缓冲器中重构单元列表：

1)列表中的解码号高于映射到发送的NDSN和NDU的解码顺序，以及

2)序列号小于接收到的最高序列号(HSN)。

应该注意到当比较解码号和序列号时应当考虑到回绕。例如，由于RTP序列号在信令中是利用16比特表示的，被发送的最大值是65535。接着下一个值0实际上表示65536的序列号。

可选地，特定值也可用于NDU字段(例如如果字段是两个字节，则为0xFFFF)以便提供没有单元信息的信号。在这种情况下，仅单元所属于的分组的序列号被提供。服务器将不能精确地估计当前哪些单元位于接收器缓冲器内。

下面描述几个其它的实施：

实施1：

接收器基于最小的y值向发送方报告将要解码的下一个分组的信息。基于接收到的NDSN，服务器可识别将下一个被解码的分组。如此，发送方可导出接收器缓冲器的正确状态。利用在背景部分给出的一组x和y值，该实施可如下示出：

当分组x+4、x+5、x+6和x+7已被接收时，它们相应的解码顺序是y+100、y+101、y+4和y+5。因此，x+6具有y+4的最小解码顺序值。因此，将要被解码的下一个分组和相应的NDSN是x+6。接收器还总是设置HSN＝x+7，因为这是最晚接收到的序列号。上面讨论的情况在表2中示出：

解码顺序值 接收器缓冲器的分组NDSN HSN未解码的最小SN    ...    ...    ...    y+2    y+3    y+4    y+5    ...    ... ... ... ... x+2，x+3，x+4，x+5 x+3，x+4，x+5，x+6 x+4，x+5，x+6，x+7 x+4，x+5，x+7，x+8 ... ... ... ... ... x+2 x+3 x+6 x+7 ... ...  ...  ...  ...  x+5  x+6  x+7  x+8  ...  ...  .  .  .  x+2  x+3  x+4  x+4  .  .

表2

注：当解码顺序值＝y+3时，NDON＝由分组x+3携带的NAL单元的DON；当解码顺序值＝y+4时，NDON＝由分组x+6携带的NAL单元的DON。

基于接收到的NDSN，发送方可获得关于哪些分组位于接收器缓冲器中的精确估计，因为它能够将序列号本地的映射到它们的解码顺序-发送方保留了序列号和这些序列号被映射到解码号的方式的列表。在这个示例中，发送方知道x+4具有高于x+7的解码顺序。这就可断定x+4位于缓冲器内并且确定哪些其它分组当前位于缓冲器内。

此外，发送方可通过可选播放延迟参数的信令得到更为精确的接收器缓冲器持续时间的测量。播放延迟定义为要解码的下一个分组的安排的播放时间和该分组(即，序列号NDSN的分组)的解码时间之间的差值。

因此实施1可总结如下：

在接收器侧：

-计算当前位于缓冲器内的分组的解码顺序(y值)；

-找到将要被解码的下一个分组(具有最小y值的分组)；以及

-发送将要被解码的下一个分组的序列号(称其为NDSN)。

在发送方侧：

-保留已被发送的分组序列号列表(L)，以及从序列号到解码顺序的映射。

-在RTCP RR或SR报告中查找由接收器发送的NDSN和HSN；

-通过在L中查找其序列号满足下面要求的所有分组，在接收器缓冲器中重构分组列表：1)列表中与序列号关联的解码顺序高于映射到NDSN序列号的解码顺序，以及2)序列号小于接收到的最高序列号(HSN)。

实施2

关于实施1，如果使用MTAP(多时间聚集分组，在H.264有效载荷格式中定义)，则还能存在不确定性。聚集分组类型用于将多个NAL(网络抽取层)单元聚集到单个的RTP有效载荷中。所有的NAL单元包括八位组类型的单个NAL单元，其还联合用作该RTP有效载荷格式的有效载荷报头。在MTAP中，NAL单元有效载荷包括16比特无符号解码号顺序基数(DONB)以及一个或多个多时间聚集单元。DONB必须以在MTAP的NAL单元之中的NAL单元解码顺序包括第一NAL单元的DON的值。由于这样的事实将出现问题，即来自不同帧的NAL可被包括在同一个RTP分组中并因此具有相同的SN。随后，当报告NDSN时，哪一些分组NAL将下一个被解码不是已知的。如果属于同一个分组的不同NAL之间的可能采样时间差是有限的，则实施1可导致缓冲器估计中的某些不精确性。当发送方分组化使得在同一个分组内的NAL的采样时间之间存在高的差值时，则根据实施1的估计可完全失败。

在实施2中，通过发送要解码的下一个NAL(NDON)的DON而不是序列号来解决该不确定性。

在实施1中所描述的那些相同的发送方和接收器算法可被使用。实施2和实施1不同之处在于发送NDON而不是NDSN(见表2下的注)。因此，实施2可总结如下：

在接收器侧：

-计算当前位于缓冲器内的NAL的解码顺序(y值)；

-找到将要被解码的下一个分组(具有最小y值的分组)；以及

-发送将要被解码的下一个分组的DON(称其为NDON)。

在发送方侧：

-保留已被发送的NAL的列表(L)，对于每个NAL，保留其中NAL被发送的分组的序列号(SN)、它的DON值和从NAL到解码顺序的映射的记录；

-查找由接收器发送的NDON和HSN；以及

-通过在L中查找记录的信息符合下面要求的所有NAL，在接收器缓冲器中重构NAL列表：1)与L中的NAL关联的解码顺序高于映射到发送的NDON的解码顺序，以及2)序列号小于接收到的最高序列号(HSN)。

对于AMR(-NB，-WB和-WB+)，DON的计算执行如下：

假设：

-对于以语音帧块“n”开始的交错组，ILL＝L

-交错组的第一有效载荷分组是“s”，n的RTP序列号为“SN”

-每个有效载荷中携带的语音帧块的数目是N。

-第一AMR音频分组的序列号是“SN0”

AMR有效载荷(该交错组的第一分组)

ILL＝L，ILP＝0，

携带的帧块：n、n+(L+1)、n+2×(L+1)、...、n+(N-1)×(L+1)

有效载荷s+1(该交错组的第二分组)

ILL＝L，ILP＝1，

帧块：n+1、n+1+(L+1)、n+1+2×(L+1)、..、n+1+(N-1)×(L+1)

有效载荷s+L(该交错组的最后一个分组)

ILL＝L，ILP＝L，

帧块：n+L、n+L+(L+1)、n+L+2×(L+1)、n+1+(N-1)×(L+1)

下一个交错组将以帧块n+×(L+1)开始

在以语音帧块n开始的交错组中，在具有ILP＝I的AMR有效载荷中，第i个AMR帧的解码顺序是：

DON(i)＝(n+j)+i×(L+1)

其中

i＝0，...，N-1并且是整数

j＝0，...，L，并且是整数

n可基于ILL、N、初始和当前AMR有效载荷的序列号如下计算：

n＝(Floor[(SN-SN0)/(L+1)])×N×(L+1)并且n是整数。

对于接收到的第一个AMR分组，第一个AMR帧的DON是零。由于客户端和服务器都知道第一个RTP序列号(服务器通过发送它，客户端通过检查RTSP PLAY响应和RTP信息报头的“seqnum”字段)，因此将直接做出这样的标记。接着，每个AMR帧的DON将通过利用ILL、ILP和N来计算。

实施3

如H.264编解器中所定义的，当发送MTAP中的DON的值时，传送顺序中第一NAL单元的DON值可以被设置成任何值。DON的值包含在0到65535的范围内。在到达最大值之后，DON的值回绕到0。因此，结合实施2，DON可以回绕，这将在服务器处造成不确定性。这是因为DON字段具有比SN字段较小的比特并且DON可以是稀少的(发送方可以由于某种原因在连续的NAL之间使用高的DON增量)

在实施3中，接收器通过其中携带的分组SN和DON值来唯一地识别下一个NAL。因此，接收器发送携带下一个NAL单元的分组的序列号和表示下一个NAL单元的解码顺序的DON号到服务器。如果分组中没有其它的NAL，则DON不需要被发送。

实施3可总结如下：

在接收器侧：

-计算当前位于缓冲器内的NAL的解码顺序(y值)；

-找到将要被解码的下一个分组(具有最小y值的分组)；以及

-发送将要被解码的下一个分组的DON(称其为NDON)以及将要被解码的下一个分组的序列号(称其为NDSN)。

在发送方侧：

-保留已被发送的NAL的列表(L)，对于每个NAL，保留其中NAL被发送的分组的序列号(SN)、它的DON值和从NAL到解码顺序的映射的记录；

-查找由接收器发送的NDON、NDSN和HSN；以及

-通过在L中查找记录信息符合下面要求的所有NAL，在接收器缓冲器中重构NAL列表：1)在L的NAL中关联的解码顺序高于映射到发送的NDON和发送的NDSN的解码顺序，以及2)序列号小于接收到的最高序列号(HSN)。

为了示出如何实施用于速率配适的缓冲器水平信令的方法，图3中示出了多媒体流系统。如图所示，多媒体流系统1具有用于从流客户端60发送缓冲器水平信令到流服务器10的装置。

流服务器10包括应用级信令引擎20、速率控制器20和服务缓冲器40。流客户端60包括应用级信令引擎70，相当于并且适合于与流服务器10中的应用级信令引擎20通信。其另外包括客户端缓冲器80，在图3示出的本发明的实施方式中，该客户端缓冲器80包括抖动缓冲器82和预解码缓冲器84，集成为单个的单元。在本发明的另一个实施方式中，流客户端60可包括分开实施的抖动缓冲器和预解码缓冲器。流客户端另外包括媒体解码器90、后解码缓冲器100、缓冲器控制器110和显示/播放设备120。

在图3中示出的系统另外表示出包括位于流服务器10和流客户端60之间的“信道缓冲器”50，表示发生在从流服务器到客户端的数据分组的传输期间的变化的传输延迟。

服务器的速率控制器30操作于将速率适配在媒体数据从流服务器发送的速率。服务器还具有用于对将要发送到客户端的分组添加时间戳的传输时钟32。其通过根据传输信道上变化的比特率调整发送数据速率来操作，考虑客户端对于传输时间偏移的请求，因此试图避免由于预编码缓冲器的下溢而导致客户端处的播放的中止或由于缓冲器溢出而导致在客户端丢弃分组。

在数据分组从流服务器通过传输信道发送到流客户端60之前，服务缓冲器40暂时地存储该数据分组。在“直播”的流传输方案中，其中数据分组被实时地采样，服务器缓冲器确实为物理的缓冲器，在此数据分组在采样时被置于其中并且在传输时被提取。在“预编码”流方案中，其中数据分组不是实时采样但存储在预编码文件中并且在传输时从该文件读取，服务器缓冲器是虚拟的缓冲器，其代表了数据分组的采样时间(当预编码文件的第一数据分组被发送时，参考在流服务器处启动的采样时钟)和传输时间之间的差值。

在流客户端处，来自传输信道的媒体数据被接收并且被缓冲在客户端缓冲器80中。预解码缓冲器84和抖动缓冲器82的参数由缓冲器控制器110设置。参数被选择做为几个推荐的预编码缓冲参数的聚集和由客户端估计所需的额外缓冲。客户端估计需要以容许在可用的传输信道上的期望的分组传输延迟变化(即，抖动)。这样的聚集受客户端最大缓冲能力的约束。媒体解码器90从客户端缓冲器中提取媒体数据并且以合适的方式对所述媒体类型的媒体数据解码。应该理解，通常媒体数据将包括多个不同的媒体类型。例如，如果从服务器发送的媒体数据代表视频序列，其除了视频数据以外可能包括至少音频分量。因此可以理解如图1中所示出的媒体解码器90实际上可包括多于一个的解码器，例如根据特定视频编码标准实施的视频解码器和关联的音频解码器。在媒体数据由媒体解码器90解码后，其被输出到后解码缓冲器100，其在此被暂时地存储直到其安排的播放时间，在这一点上其在缓冲器控制器110的控制下从后解码缓冲器传递到显示/播放缓冲器120。

根据本发明，缓冲器控制器110适于向应用级信令引擎70提供将被解码的下一个单元的指示。接着应用级信令引擎适于将关于要被解码的下一个单元的信息发送到流服务器，如图3中的标号300所表示出的。发送的信息指示出将要被解码的下一个单元的单元号(称为NDU)和该单元所属于的分组的序列号(称为NDSN)。在H.264有效载荷的情况下，该单元是NAL。如图1中所示，流客户端60具有软件程序112，该软件程序包括用于计算当前存在于缓冲器80内的编码的单元的解码顺序(y值)以及基于最小的y值确定将要被解码的下一个单元。基于该发现，应用级信令引擎70可发送下一个单元的单元号和该下一个单元所属于的分组的序列号到流服务器10。

为了执行该实施1、2和3，缓冲器控制器110适于向应用级信令引擎70提供将要被解码的下一个分组的指示。接着应用级信令引擎适于将关于要被解码的下一个单元的信息发送到流服务器，如图3中的标号300所表示。发送的信息可指示出关于将要被解码的下一个分组的序列号。在H.264有效载荷的情况下，发送的信息指示出下一个NAL的DON。可选地，携带下一个NAL和下一个NAL的DON的分组的序列号被发送到服务器。如图1中所示，流客户端60具有软件程序112，该软件程序包括用于计算当前存在于缓冲器80内的分组的解码顺序(y值)以及基于最小的y值确定将要被解码的下一个分组。基于该发现，应用级信令引擎70可发送将要被解码的下一个分组的序列号到流服务器10。

在服务器10处，软件程序36用于从单元SN列表34确定单元的列表或分组的列表以及由客户端60提供的信息。

应该注意到在上述的实施方式中，接收器发送将要被解码的下一个单元所属于的分组的SN以及单元号。可选地，接收器可发送将要被解码的下一个单元的时间戳来代替它的单元号。只要在同一个分组中每个单元具有不同的时间戳，则发送方可从发送的时间戳和序列号明确地识别出该单元。然而，在同一个分组中一些单元可能具有相同的时间戳。在这种情况下，该信令不会允许发送方与单元号的信令同样精确地导出接收器缓冲器状态的状态，其中最大估计误差为帧的数据量。

另外，除了交错有效载荷格式以外，H.26L还将解码顺序和输出顺序解耦合。换句话说，图片的解码顺序可以与它们的输出顺序不同。在先前的编码标准中，解码顺序和输出顺序仅针对所谓的B帧允许不同，对于B帧用于中间预测的两个参考帧被使用，输出顺序中的先前帧和跟随帧(即，解码顺序中的两个先前帧)。B帧没有用于版本5编解码器的任何配置文件中。在H.26L中解码顺序和输出顺序对于任何帧可以不同。这些还对估计缓冲器具有影响。然而，本发明适用于涉及B帧的解码，并且更一般地，适用于预测通路向后前进的情况。在这些情况下，任意时间帧从未来帧预测(在采样域中)，接收器缓冲器持续时间将小于从OBSN和播放延迟信令所导出的持续时间。

至于利用RFC3640发送的AAC、AAC+和其它MPEG-4音频流，AU-Index和AU-Index-Delta参数为每一个音频接入单元或片断定义了唯一的索引号。DON完全与该索引相同。因此，本发明的实施2还适用于使用RFC3640发送的这些音频流方案。

尽管结合本发明的一个或多个实施方式对本发明进行了描述，但本领域的技术人员将理解可以做出本发明形式和详细的上述和各种其它的改变、省略和偏差而不会脱离本发明的范围。