在分层多播中的编码应用数据单元顺序恢复的制作方法

专利名称:在分层多播中的编码应用数据单元顺序恢复的制作方法
技术领域：
概括地说，本发明涉及在网络上分层媒体的传输。更具体地，本发明涉及在分层多 播传输处理中解码顺序信息的有效恢复。
技术背景
这个部分旨在提供在权利要求
书中列举的本发明的背景或环境。这里的说明可包 括能够遵循的概念，但不必是先前已经构想或遵循的那些概念。因此，除非这里另外指出， 在这个部分所描述的内容并非是本申请中的说明书和权利要求
书的现有技术，并且不可以 通过包括在这个部分中而承认其是现有技术。
多媒体应用包括例如本地端播放的服务、流传输或按需服务、会话和广播/多播 服务。在多媒体应用中涉及的技术包括媒体编码、存储和传输。对于不同技术指定不同标 准。具体地，在具有波动带宽需求的视频通信系统中，分层编码的使用是有益的。例如，在会 话的生存期间可处理连接速度改变的视频使能的移动电话中，这个特征特别有益。例如，由 于从无线局域网(WLAN)到第三代(3G)网络或从3G网络到全球移动通信系统(GSM)网络 的后退，这样的改变可能是必要的。在分层编码中，选择基层以甚至可在最慢链路上传递。 通过增加使用更快接入技术传递的额外视频“增强”层，能够增加视频质量。
与视频标准相关的最近的工作是具有分层编码概念的ITU-T推荐H. 264的扩展。 这个工作通常已知为“可扩展视频编码(Scalable VideoCoding) ”或SVC。SVC标准的最新 草案在2007年6月-7月、第24届JVT会议、日内瓦、瑞士的JVT-X201" Joint Draft 11 of SVC Amendment^ l^ifffi^, ^TbTAA ftp3. itu. ch/av-arch/ivt-site/2007 06 Geneva/ TVT-201. zip获得，并H.其全部内容通i寸引用合并干此。
在分层编码设置中，通常可观察层级。对于给定的高层，典型地存在高层所依赖的 至少一个低层。当来自低层的数据丢失时，高层的数据变得相当没有意义，在某些情形下完 全没有用。因此，如果需要丢弃层或属于某些层的分组，则清楚的是首先丢弃高层或属于高 层的分组，或至少在丢弃低层或属于低层的分组之前执行这样的丢弃。
这样的分层概念还可扩展成多视点视频编码(MVC)，其中每个视点可看作层，并且 每个视点可通过多个可扩展层表示。在多视点视频编码中，将从均对应于视点的不同相机 输出的视频序列编码成一个位流。在编码之后，为了显示某个视点，显示属于该视点的解码 图片。MVC标准的最新草案在2007年6月-7月、日内瓦、瑞士的JVT-X209" Joint Draft 4.0 onMultiview Video Coding” 中有所描沭，这可从 ftp3. itu. ch/av-arch/ivt-site/2007 06 Geneva/TVT-209. zip获得，并且其全部内容通过引用合并于此。
分层多播是用于可扩展编码位流(例如SVC或MVC位流)的传输技术。用于因特网 协议(IP)网络上的媒体传输的通用技术已知为实时传输协议(RTP)。在使用RTP的分层多 播中，可扩展位流的层或层的子集在其自身的RTP会话中被传输，其中每个RTP会话属于多 播组。接收器可加入或订阅期望的RTP会话或多播组以接收某些层的位流。传统的RTP和 分层多播例如在 2003 年 7 月的 H. Schulzrinne, S. Casner, S.，R. Frederick 和 V. Jacobson,"RTP :A Transport Protocol for Real-Time Applications”，IETF STD 64,RFC 3550 中有 所描述，这可从 http://www. ietf. org/rfc/rfc3550. txt 获得，以及在 1996 年 8 月的 Proc. of ACM SIGCOMM' 96 白勺 M. Vetterli "Receiver-driven layered multicast", pp. 117-130, Standford, CA中有所描述。
H. 264/AVC RTP有效载荷格式在RFC 3984中被指定，后者可从http //www, ietf. orR/rfc/rfc3984. txt获得。RFC 3984指定了三个封包模式单网络提取层(NAL)单元封包 模式；非交织封包模式；和交织封包模式。在交织封包模式下，包括在分组中的每个NAL单 元关联于有关解码序号(DON)的字段，从而可导出NAL单元解码顺序。备选地，当使用单NAL 单元封包模式或非交织封包模式时，有关DON的字段均不可用。SVC RTP有效载荷的格式的 最新草案可从 http://www. ietf. org/internet-drafts/draft-ietf-avt-rtp-svc-02. txt 获得。在这个最新草案中，除了其他类型信息之外，有效载荷内容可扩展信息(PACSI)NAL 单元被指定为包含可扩展信息，用于包括在RTP分组中的NAL单元。
在分层多播中，订阅多于一个RTP会话的接收器从不同RTP会话恢复接收的NAL 单元的解码顺序，然后将他们发送至解码器。然而，由于在不同RTP会话之间的会话发起不 同，在一个或多个RTP会话中使用RFC 3984中指定的交织封包模式，会引起NAL单元解码 顺序恢复复杂化，并且NAL单元解码顺序不同于输出或显示顺序。
SVC RTP有效载荷格式的最新草案尝试确保通过需要使用所有RTP会话的交织封 包模式为每个NAL单元可导出在整个SVC位流上的DON (称为跨层D0N(CL_D0N))。此外，最 新草案还需要基于CL-D0N导出有关DON的字段。然而，一些当前现有的RFC 3984型接收 器不具有在其中实施的交织封包模式。因此，这些接收器不能够加入分层多播和接收服务。

发明内容
各个实施例提供了在分组结构中包括每个分组中的应用数据单元(ADU)的解码 顺序的指示。例如，当PACSI NAL单元包括在单时间聚集分组类型A(STAP-A)分组中(其 中STAP-A分组在RFC 3984中被指定)时，在PACSI NAL单元中包括CL-D0N字段。使用 STAP-A分组指示非交织封包模式在使用中用于特定RTP会话。如果接收器仅被订阅使用非 交织封包模式的单RTP会话，则可忽略CL-D0N指示。然而，如果接收器加入了包括使用非 交织封包模式的至少一个RTP会话的多RTP会话，则可利用在使用非交织封包模式的RTP 会话中对于每个RTP分组的CL-D0N指示以及在其他RTP会话(使用交织分组模式)的分 组中的DON字段，以确定在所有RTP会话中传递的NAL单元的解码顺序并适当地重新排序 NAL单元。因此，根据SVC RTP有效载荷格式和根据各个实施例实现的接收器能够恢复在不 同RTP会话中传递的NAL单元的解码顺序，即使在基层RTP会话没有使用交织封包模式时， 而仅订阅基层RTP会话的RFC 3984接收器可忽略PACSI NAL单元。
通过结合附图来详细描述，本发明的这些和其他优点和特点及其组织和运行方式 将变得显而易见，其中贯穿下面描述的附图，类似的元素具有类似的编号。


图1示出根据各个实施例的PACSI NAL单元的结构的表示；
图2示出根据各个实施例执行的方法的流程图；[0015]图3示出各个实施例所使用的多媒体通信系统；
图4是可用在本发明方案中的移动电话的透视图；以及
图5是图4的移动电话的电话电路的示意性表示。
具体实施方式
各个实施例提供了这样的系统和方法，其在无需交织封包模式方案的情况下支持 现有RFC 3984接收器，以加入分层多播和接收由基层提供的服务。更具体地，在PACSI NAL 单元头部中可包括CL-D0N字段。因此，各个实施例实现用于在RTP分组(例如STAP-A分 组)中包括的NAL单元的CL-D0N信息的存在，其可用于非交织封包模式，其中STAP-A聚集 NAL单元与同一 NAL单元时间。因此，即使在基层RTP会话没有使用交织封包模式时，根据 SVC RTP有效载荷格式和根据各个实施例实现的接收器也能够恢复在不同RTP会话中传递 的NAL单元的解码顺序，而仅订阅基层RTP会话的RFC 3984接收器可忽略PACSI NAL单元。
如上所述，CL-D0N指的是跨层解码序号，其可包括例如在SVC RTP有效载荷结构 中的字段，或指示在用于传输SVC位流的所有RTP会话中传输的所有NAL单元上的NAL单 元解码顺序的导出变量。应注意，在使用RTP的SVC技术的环境中提出了这里所述的各个 实施例。然而，只要是利用分层多播，各个实施例的系统和方法可应用于使用任意适合传输 协议的任意分层或可扩展编解码器。还应注意，代替分层多播，各个实施例的系统和方法可 应用于在其中通过单独逻辑信道或分组流发送可扩展媒体位流的层的任意传输机制。
如果确定如在分层多播中那样，在多于一个RTP会话中传输SVC位流的不同层，则 需要使用交织封包模式的RTP会话中的所有NAL单元的DON值指示CL-D0N值。此外，当在 多于一个RTP会话中传输SVC位流的不同层，并且在任意RTP会话中呈现至少一个STAP-A 分组时，某些条件适用。
首先，在每个STAP-A分组中存在PACSI NAL单元。此外，在每个STAP-A分组中包 括的PACSI NAL单元中存在CL-D0N字段。此外，对于每个STAP-A分组中的NAL单元的DON 值指示CL-D0N值，并且如下导出。在PACSI NAL单元中的CL-D0N字段指定用于以传输顺 序的STAP-A中的第一 NAL单元的DON的值。对于在STAP-A中以呈现顺序的每个连续NAL 单元，DON的值等于(在STAP-A中的先前NAL单元的DON的值+1) % 65536，其中“ ％ ”指 的是取模运算。
如上所述，根据各个实施例实现NAL单元类型(其被称为PACSI NAL单元)。PACSI NAL单元如果存在，则为聚集分组中的第一 NAL单元，并且在其他分组类型中不存在。PACSI NAL单元指示对于聚集分组的有效载荷中的所有剩余NAL单元通用的可扩展信息和其他特 征。此外，PACSI NAL单元可包括CL-D0N字段，并且包含0个或多个补充增强信息(SEI)NAL 单元。因此，PACSI NAL单元使媒体更容易知晓网络单元(MANE)，以决定是否转发/处理/ 丢弃包含PACSI NAL单元的聚集分组。例如，发送者可创建PACSI NAL单元，但是接收器可 忽略他们。备选地，接收器可将PACSI NAL单元用作支持有效聚集分组处理的提示。应注 意，可以在SVC标准和RFC 3984中未指定的那些值中选择用于PACSI NAL单元的NAL单元 类型。
当聚集分组的第一聚集单元包含PACSI NAL单元时，在相同分组中存在至少一个 额外聚集单元。因此，根据在聚集分组中的剩余NAL单元设置聚集分组的RTP头部和有效载
8荷头部字段。当在多时间聚集分组(MTAP)中包括PACSI NAL单元时，设置用于PACSI NAL 单元的DON，以指示PACSI NAL单元具有等同于在聚集分组的剩余NAL单元之间的解码顺序 的第一 NAL单元的DON。
图1示出PACSI NAL单元的结构的表示。前4个八位字节0、1、2和3与包括传统 4字节SVC NAL单元头部的前4个八位字节相同。在他们之后是2个始终存在的八位字节、 2个可选八位字节、和0或多个SEINAL单元，在其每个之前是16位无符号大小字段(以网 络字节顺序)，其指示字节中随后的NAL单元的大小(不包括这两个八位字节，但是包括SEI NAL单元的NAL单元类型八位字节)。图1示出包含例如2个SEINAL单元的PACSI NAL单 元结构。
如果包含PACSI NAL单元的聚集分组是STAP-A分组，则CL-D0N字段是可选的和存 在的。当存在时，CL-D0N字段表示用于以传输顺序的STAP-A中的第一 NAL单元的CL-D0N。 还应注意，当包含PACSI NAL单元的聚集分组不是STAP-A分组时，CL-D0N字段不需要存在。 根据最新SVC RTP有效载荷格式草案，设置在图1中所示的PACSI NAL单元中的其他字段 的值。
除了在RFC 3984中指定的用于单NAL单元封包模式的通用封包模式之外的某些 封包规则，非交织封包模式、和交织封包模式也适用于各个实施例的编码和/或解码方面。
当在多于一个RTP会话中传输SVC位流的层时，交织封包模式应用于所有RTP会 话。然而，如果RTP会话未使用交织封包模式，则使用非交织封包模式，即使用STAP-A分组， 并且未使用任意其他类型的分组。此外，每个STAP-A包含PACSI NAL单元和CL-D0N字段， 其存在于PACSI NAL单元中。因此，可允许将非交织封包模式用于传递兼容H.264/AVC的 (全)基层的会话，从而其中未实现交织封包模式的RFC 3984接收器可订阅(全)基层会 话。
在另一实施例中，每当RTP会话未使用交织封包模式时，就使用非交织封包模式。 然而，允许任意分组类型，即STAP-A、分段单元类型A (FU-A)或单NAL单元分组。在FU-A或 单NAL单元分组不包含CL-D0N字段时，从以传输顺序为先前NAL单元导出的CL-D0N值计 算在FU-A或单NAL单元分组中包含的用于NAL单元的CL-D0N的值，例如通过对以传输顺 序将用于先前NAL单元的CL-D0N值加1 (使用65536取模运算)。在另一实施例中，STAP-A 不需要包含CL-D0N字段。相反，导出在STAP-A中的PACSI NAL单元(如果存在)之后的 用于第一 NAL单元的CL-D0N值，作为用于上述FU-A或单NAL单元分组的CL-D0N。
此外，非VCL-NAL单元可在与其关联的VCL NAL单元相同的会话中传递。为了实 现这个特征，包含在可扩展嵌套SEI消息中并适用于多于一个会话的SEI消息可被分开，并 包含在多个可扩展嵌套SEI消息中。因此，CL-D0N值表示这样的值，如果所有这些SEI消 息在单独可扩展嵌套SEI消息中并且如最新SVC标准草案传统指示的那样包含在相应接入 单元的开始中，则可产生该值。
根据各个实施例的编码和/或解码方面，也适用除了在RFC 3984中指定的共同解 分组(de-packetization)规则之外的解分组处理。应注意，对于单RTP会话，在RFC 3984 中指示的通用解分组处理(具有某些改变)一般也适用。为了接收传递可扩展位流的多于 一个RTP会话，以下描述解分组处理的适当方案的实例，例如，用于在多RTP会话中传递的 NAL单元的解分组处理。与单RTP会话情形一样，用于多RTP会话的解分组导致从传输顺序到NAL单元解码顺序的NAL单元重排序，其中“RTP会话”指的是对于NAL单元解分组的 RTP会话。
接收器包括接收器缓冲器，其用于补偿不同会话发起时间，传输延迟抖动，和用于 从传输顺序到NAL单元解码顺序的NAL单元重排序。应注意，在以下的假设情况下描述接 收器操作所有RTP会话同时发起，并且不存在传输延迟抖动。然而，接收器还可适应在不 同会话发起时间和传输延迟抖动都存在时的情形。例如，接收器可保留单独的缓冲器用于 会话发起改变缓冲、传输延迟抖动缓冲、和去会话复用缓冲，和/或可使用针对所有上述目 的的接收器缓冲器。此外，接收器可在缓冲操作中例如通过在开始解码和播放之前执行的 额外初始缓冲来考虑会话发起改变和传输延迟抖动。
如上所述，当使用多于一个RTP会话来传递SVC位流时，可为每个NAL单元导出 CL-D0N值。这样能够在无需用于每个RTP会话的单独去交织处理的情况下实现NAL单元解 码顺序恢复处理，而不管RTP会话是否使用交织封包模式。除会话发起改变缓冲器和传输 延迟抖动缓冲器之外，接收器缓冲器可称为去会话复用缓冲器。在字节数目方面，可将去会 话复用缓冲器的大小设置为等于或大于RTP会话的sprop-deint-buf-req媒体类型参数的 值(与去交织缓冲器关联)，其传递解码需要在所有其他RTP会话中传递的SVC层存在所针 对的SVC层。这样的RTP会话可称为最大RTP会话。应注意，可向接收器提供要发送的流 的属性的参数称为“sprop”参数。
应注意，在接收器中存在两个缓冲状态，例如“初始缓冲，，和“播放时缓冲”。初始 缓冲可发生在RTP会话被初始化时。在初始缓冲之后，开始解码和播放，并且可利用播放时 缓冲模式。不管缓冲状态，接收器可按接收顺序在去会话复用缓冲器中存储进入的NAL单 元。换句话说，将聚集分组的NAL单元分别存储在去会话复用缓冲器中，其中为每个NAL单 元计算和存储DON的值(即在这个情况下为CL-D0N)。然而，应注意，可将CL-D0N设置为具 有与DON不同的值。例如，如果存在3个层，则每个层仅包含1个NAL单元。在该情况下， 随后，用于3个NAL单元的CL-D0N值可以是{0，1，2}或{3，10，18}...，只要顺序正确，同时 在任意2个NAL单元之间的间隙可以是灵活的。
这里还描述了接收器操作，其中初始缓冲继续，直到实现以下条件中的至少一个 在去会话复用缓冲器中存在N个或更多个VCL NAL单元，其中常数N指的是最高RTP会话加 1的OPTIONAL (可选的)sprop-interleaving-depth媒体类型参数的值；如果最大RTP会话 白勺 sprop-max-don-diff 存在，贝U don_diff (m,n)大于最大 RTP 会i舌白勺 sprop-max-don-diff 的值，其中n对应于在接收NAL单元中具有AbsD0N(以下定义)的最大值的NAL单元，m对 应于在接收NAL单元中具有AbsDON的最小值的NAL单元；以及对于等于或大于最大RTP会 话的OPTIONAL sprop-init-buf-time媒体类型参数的值的时间段，初始缓冲继续。
应注意，don_diff是如下定义的函数
使得DON⑴为NAL单元i的解码序号。
<formula>formula see original document page 10</formula>[0042]If (DON (m) < DON (n) and DON (n)-DON (m) >= 32768)，
don_diff (m, n) =If (DON (m) > DON (n) and DON (m)-DON (n) < 32768)，
don_diff (m, n) =此外，可如下确定要从去会话复用缓冲器去除的NAL单元。如果去会话复用缓 冲器包含至少N个VCL NAL单元，则将NAL单元从去会话复用缓冲器去除，并按以下指 定的顺序传递至解码器，直到缓冲器包含N-1个VCL NAL单元。如果最大RTP会话的 sprop-max-don-diff存在，则从去会话复用缓冲器去除don_difT (m，n)大于最大RTP会话 的sprop-max-don-diff所针对的所有NAL单元，并按以下指定的顺序将其传递至解码器。 这里，n对应于在去会话复用缓冲器中的NAL单元之间具有AbsDON的最大值的NAL单元。
如下指定将NAL单元传递至解码器的顺序。对于与DON的值关联的每个NAL单元， 将PD0N设置为在RTP会话的开始被初始化为0的变量，计算DON距离。如果NAL单元的DON 的值大于PD0N的值，则DON距离等于D0N-PD0N。否则，DON距离等于65535-PD0N+D0N+1。 按DON距离的升序将NAL单元传递至解码器。如果几个NAL单元共享DON距离的相同值， 则可按任意顺序将他们传递至解码器。当向解码器传递了期望数目的NAL单元时，针对传 递至解码器的最后NAL单元，将PD0N的值设置为DON的值。
此外，可使用有效载荷来选择有效载荷的可选特征和位流的某些特征。在这里，这 些参数可指定为用于SVC编解码器的媒体类型登记的一部分。还可为使用SDP的应用提供 在RFC4566中指定的这些参数到会话描述协议(SDP)标准的映射。然而，应注意，可定义等 同的参数与不使用SDP的控制协议一起来使用。
如下定义上述或相关的媒体类型参数。封包模式指的是信号传输RTP分组流的属 性或接收器方案的能力的参数。应注意，可仅指示单配置点，因此当声明支持多于一个封包 模式的能力时，必须使用多个配置点(RTP有效载荷类型)。
当封包模式的值等于0或封包模式不存在时，必须使用在RFC 3984中定义的单 NAL模式。应注意，在使用中，这个模式用在使用ITU-R推荐H.241[H.241](在RFC 3984中 所述)的标准中。当封包模式的值等于1时，必须使用在RFC 3984中定义的非交织模式。 当封包模式的值等于2时，必须使用在RFC 3984中定义的交织模式。还应注意，封包模式 的值必须是0至2的范围内的整数，包括0和2。
sprop-interleaving-depth是在当前RTP会话不取决于任意其他RTP会 话并且封包模式不存在时不必存在的参数。此外，如果封包模式的值等于0或1， sprop-interleaving-depth参数不必存在。在当前RTP会话取决于任意其他RTP会话或封 包模式的值等于2时，这个参数必须存在。此外，sprop-interleaving-d印th参数信号传 输NAL单元流的属性。其指定按传输顺序在NAL单元流中的任意VCL NAL单元之前，以及 按解码顺序在VCLNAL单元之后的VCL NAL单元的最大数目。因此，其确保当用于NAL单元 解码顺序恢复的缓冲器大小至少为sprop-interleaving-d印th+1的值(就VCL NAL单元 而言)时，接收器必须重构NAL单元解码顺序。这里，NAL单元流指的是包括在当前RTP会 话中传递的所有NAL单元以及在其他RTP会话(如果存在，当前RTP会话所依赖)中传递 的所有NAL单元的NAL单元流。此外，sprop-interleaving-d印th的值必须是0至32767 范围内的整数，包括0和32767。[0052]sprop-deint-buf-req是在当前RTP会话不取决于任意其他RTP会话并且封包模 式不存在，或封包模式的至等于0或1时不必存在的参数。在当前RTP会话取决于任意其 他RTP会话或封包模式的值等于2时，这个参数必须存在。此外，sprop-deint-buf-req用 于信号传输NAL单元流的区交织缓冲器的所需大小。sprop-deint-buf-req必须大于或等 于在这种去交织缓冲器(上述)中所需的最大缓冲器占用(以字节为单位)。当去交织缓 冲器大小就字节而言至少为sprop-deint-buf-req的值时，其确保接收器可执行交织NAL 单元到NAL单元解码顺序的去交织。这里，NAL单元流指的是包括在当前RTP会话中传递 的所有NAL单元以及在其他RTP会话(如果存在，当前RTP会话所依赖)中传递的所有NAL 单元的NAL单元流。sprop-deint-buf-req的值必须是0至4294967295范围内的整数，包 括0和4294967295。应注意，sprop-deint-buf-req参数仅指示去交织缓冲器的所需大小。 在能发生网络抖动时，还提供适当大小的抖动缓冲器。当在多于一个RTP会话中传递可扩 展位流，并且会话同时发起时，还可通过适当大小的缓冲器补偿会话发起改变。
sprop-init-buf-time是可用于信号传输NAL单元流的属性的参数。这里，NAL单 元流指的是包括在当前RTP会话中传递的所有NAL单元以及在(如果存在，当前RTP会话所 依赖的)其他RTP会话中传递的所有NAL单元的NAL单元流。在开始从传输顺序恢复NAL 单元解码顺序之前，这个参数信号传输用于接收器的初始缓冲时间。假设是可靠和即时传 输，该参数是用于传输和解码的相同时间轴的最大值(NAL单元的传输时间-NAL单元的解 码时间)，以及在第一分组到达时解码开始。指定sprop-init-buf-time的值的实例如下。
按以下交织顺序发送NAL单元流，其中该值对应于解码时间，并且传输顺序是从 左至右
02135468 7 …
假设NAL单元的稳定传输速率，则传输时间为
01234567 8 …
从传输时间列向地减去解码时间得到以下序列
0-110-110-11...
因此，就NAL单元传输时间而言，在该实例中的sprop-init-buf-time的值为1。
将sprop-init-buf-time参数编码为在90kHz时钟的时钟节拍中的非负10进 制整数表示。如果参数不存在，则未限定初始缓冲时间值。否则，sprop-init-buf-time 必须是0至4294967295范围内的整数，包括0和4294967295。除了信号传输的 sprop-init-buf-time之外，接收器应考虑传输延迟抖动缓冲，包括用于混合器、解译器、网 关、代理、业务整形器、和其他网络元件引起的延迟抖动的缓冲。接收器应考虑的另一方面 是当在多于一个会话中传递可扩展位流时的会话发起改变，包括缓冲改变。
sprop-max-don-diff参数可用于信号传输NAL单元流的属性。然而，其并不用于 信号传输发送器或接收器或编解码器能力。sprop-max-don-diff参数是在0至32767范围 内的整数，包括0和32767。如果sprop-max-don-diff不存在，则未指定参数的值。这里同 样，NAL单元流指的是包括在当前RTP会话中传递的所有NAL单元以及在(如果存在，当前 RTP会话所依赖的)其他RTP会话中传递的所有NAL单元的NAL单元流。sprop-max-don-diff 参数 计算如 下sprop-max-don-diff = max {AbsDON(i)-AbsDON(j)}，其中i为任意，j为> 1的任意值。应注意，i和j指示按传输顺序的NAL单元的索引，并且AbsDON指示在65535之后不绕回到0的NAL单元的解码序号。换句话说，如下计算AbsDON:将m和η设置为按传输顺序的连续NAL单元。对于传输 顺序中的每个第一 NAL单元(其索引为0)，AbsDON(O) = DON(O)0对于其他NAL单元，如 下计算AbsDON
<formula>formula see original document page 13</formula>
其中D0N(i)是具有传输顺序中的索引i的NAL单元的解码序号。应注意，接收器 可使用sprop-max-don-diff来触发将接收器缓冲器中的哪些NAL单元传递至解码器。
图2是示出根据实现如下方法的各个实施例执行的处理的流程图，所述方法为封 包和将媒体流解分组成传输分组，以用于发送/编码和接收/解码可扩展编码位流。在200， 在每个分组中的分组结构中包括对于应用数据单元(ADU)的解码顺序的指示。即，如上所 述，当例如在STAP-A分组中包括PACSI NAL单元时，在PACSI NAL单元中包括CL-DON字段。 如果接收器仅被订阅使用非交织封包模式的单RTP会话，则在210，可通过与非交织封包模 式结合的第一解分组处理忽略CL-DON指示。第一解分组处理例如可识别在STAP-A中包含 的每个ADU，从STAP-A解封装他们，并按他们的传输顺序传递ADU用于解码。然而，如果接 收器被订阅/加入了多RTP会话，则可利用在使用非交织封包模式的RTP会话中对于每个 RTP分组的CL-DON指示以及在其他RTP会话(其使用交织封包模式)的分组中的DON字 段，以确定在所有RTP会话中传递的NAL单元的解码顺序并适当地重新排序NAL单元。
图3示出本发明所使用的一般多媒体通信系统。如图3所示，数据源300提供模拟 格式、未压缩数字格式、或压缩数字格式或这些格式的任意组合的源信号。编码器310将源 信号编码成编码的媒体位流。编码器310能够编码多于一种媒体类型(例如音频和视频)， 或可需要多于一个编码器310对不同媒体类型的源信号进行编码。编码器310还可接收通 过合成生成的输入(例如图形和文本)，或其能够生成合成媒体的编码的位流。在下文中， 仅考虑一个媒体类型的一个编码的媒体位流的处理，以简化说明。然而，应注意，典型的实 时广播服务包括几个流(典型地至少一个音频、视频和文本字幕流)。还应注意，系统可包 括许多编码器，但是在下文中，仅考虑一个编码器310，以在不失一般性的情况下简化说明。
应理解，尽管这里包含的文本和实例可特别地描述编码处理，但是本领域普通技 术人员容易理解，相同概念和原理也应用于相应解码处理，反之亦然。
将编码的媒体位流传送至存储器320。存储器320可包括任意类型大容量存储器 以存储编码的媒体位流。存储器320中的编码的媒体位流的格式可以是基本的自包含位流 格式，或者可将一个或多个编码的媒体位流封装到容器文件中。一些系统“现场”运行，即 省略存储器，并将编码的位流从编码器310直接传送到发送器330。然后，根据需要，将编码的媒体位流传送到发送器330，其也称为服务器。在传输中使用的格式可以是基本的自包含 位流格式、分组流格式，或者可将一个或多个编码媒体位流封装到容器文件中。编码器310、 存储器320、和发送器330可驻留在相同物理设备中，或者他们可包括在分离的设备中。编 码器310和发送器330可通过现场实时内容来运行，在这种情况下典型地不永久存储编码 的媒体位流，但是在内容编码器310中和/或发送器330中短时间缓冲，以平滑处理延迟、 传输延迟、和编码的媒体比特率的变化。
发送器330通过使用通信协议栈发送编码的媒体位流。所述栈包括但不限于，实 时传输协议(RTP)、用户数据报协议(UDP)、和因特网协议(IP)。当通信协议栈是面向分组 的时，发送器330将编码的媒体位流封装到分组中。例如，当使用RTP时，发送器330根据 RTP有效载荷格式将编码的媒体位流封装到RTP分组中。典型地，每个媒体类型具有专用 RTP有效载荷格式。还应注意，系统可包含多于一个发送器330，但是为了简单，以下描述仅 考虑一个发送器130。
发送器330可通过通信网络连接至网关340，也可以不连接至网关340。网关340 可执行不同类型的功能，例如，根据一个通信协议栈到另一通信协议栈对分组流进行转译、 数据流的合并和分离、以及根据下行链路和/或接收机功能对数据流进行操作(如根据主 要下行链路网络条件控制被转发流的比特率)。网关340的实例包括多点会议控制单元 (MCU)、电路交换和分组交换视频电话之间的网关、无线一键通(PoC)服务器、在数字视频 广播-手持(DVB-H)系统中的IP封装器、或向家庭无线网络本地转发广播传输的机顶盒。 当使用RTP时，网关340称为RTP混合器或RTP解译器，并典型地用作RTP连接的端点。
系统包括一个或多个接收器350，其典型地能够接收所发送的信令，并将其解调 制、和解封装成编码的媒体位流。典型地，通过解码器360进一步处理编解码器媒体位流， 解码器360的输出是一个或多个未压缩的媒体流。最后，绘制器370可通过例如扬声器或 显示器再现未压缩的媒体流。接收器350、解码器360、和呈现器370可驻留在相同物理设 备中，或者他们可包含在分离的设备中。
应注意，可从虚拟地位于任意类型网络中的远程设备接收要解码的位流。此外，可 从本地硬件或软件接收位流。
在位率、解码复杂性、和图片大小方面的可扩展性是用于异构和易错环境的期望 属性。该属性是期望的，以抵抗限制，例如关于接收设备中的位率、显示分辨率、网络吞吐 量、和计算功率的限制。
本发明的通信设备可使用各种传输技术来通信，包括但不限于，码分多址(CDMA)、 全球移动通信系统(GSM)、通用移动通信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、 传输控制协议/互联网协议(TCP/IP)、短消息服务(SMS)、多媒体消息服务(MMS)、电子邮 件、即时消息服务(IMS)、蓝牙、IEEE 802. 11等。通信设备可通过使用各种介质通信，包括 但不限于，无线电、红外、激光、电缆连接等。
图4和5示出其中可实现本发明的一个代表性电子设备12。然而，应理解，本发明 不限于一个特定类型的电子设备12或其他电子设备。图4和5中所示的某些或所有特征 可结合在图1中代表的任意或所有设备中。
图4和5的电子设备12包括外壳30、液晶显示器形式的显示器32、键板34、麦 克风36、听筒38、电池40、红外端口 42、天线44、根据本发明一个实施例的UICC形式的智能卡46、读卡器48、射频电路52、编解码器电路54、控制器56、存储器58和电池80。各个电路和部件都是本领域公知的类型，例如在移动电话的Nokia领域中。
权利要求
一种将媒体流封包成传输分组的方法，包括确定应用数据单元是否要在多个传输会话中传递；以及在确定所述应用数据单元要在所述多个传输会话中传递时，在第一传输会话传输分组中包括第一解码顺序指示，以及在第二传输会话传输分组中包括第二解码顺序指示，其中所述第一解码顺序指示和所述第二解码顺序指示包括至少一个值，其表示在所述媒体流中所述应用数据单元的解码顺序，以及其中在缺少包含所述第二传输会话传输分组的第二传输会话时，将所述第一解码顺序指示指定为不必要。
2.如权利要求
1所述的方法，其中所述媒体流是可扩展视频位流。
3.如权利要求
1所述的方法，其中根据实时传输协议形成所述传输分组。
4.如权利要求
1所述的方法，其中在所述至少一个传输分组的有效载荷内容可扩展性 信息网络提取层单元中包括所述解码顺序指示。
5.如权利要求
4所述的方法，其中所述有效载荷内容可扩展性信息网络提取层单元是 所述至少一个传输分组中的第一网络提取层单元，所述至少一个传输分组包括聚集分组。
6.如权利要求
1所述的方法，其中所述应用数据单元至少部分地包括网络提取层单兀。
7.如权利要求
1所述的方法，其中所述媒体流通过接收器接收，所述接收器订阅所述 多个传输会话的单传输会话之一，以及其中所述接收器忽略所述解码顺序指示。
8.如权利要求
1所述的方法，其中所述多个传输会话中的每个利用非交织封包模式和 交织封包模式之一。
9.一种计算机程序产品，其在计算机可读介质上实现，包括被配置为执行权利要求
1 的处理的计算机代码。
10.一种装置，包括处理器；以及存储器单元，其通信地连接至所述处理器，以及包括被配置为确定应用数据单元是否要在多个传输会话中传递的计算机代码；以及被配置为在确定所述应用数据单元要在所述多个传输会话中传递时，在第一传输会话 传输分组中包括第一解码顺序指示，以及在第二传输会话传输分组中包括第二解码顺序指 示以用于封包媒体流的计算机代码，其中所述第一解码顺序指示和所述第二解码顺序指示 包括至少一个值，其表示在所述媒体流中所述应用数据单元的解码顺序，以及其中在缺少 包含所述第二传输会话传输分组的第二传输会话时，将所述第一解码顺序指示指定为不必 要。
11.如权利要求
10所述的装置，其中所述媒体流是可扩展视频位流。
12.如权利要求
10所述的装置，其中所述存储器单元还包括被配置为根据实时传输 协议形成所述传输分组的计算机代码。
13.如权利要求
10所述的装置，其中所述存储器单元还包括被配置为在所述至少一 个传输分组的有效载荷内容可扩展性信息网络提取层单元中包括所述解码顺序指示的计 算机代码。
14.如权利要求
13所述的装置，其中所述有效载荷内容可扩展性信息网络提取层单 元是所述至少一个传输分组中的第一网络提取层单元，所述至少一个传输分组包括聚集分组。
15.如权利要求
10所述的装置，其中所述应用数据单元至少部分地包括网络提取层单元。
16.如权利要求
10所述的装置，其中所述媒体流通过接收器接收，所述接收器订阅所 述多个传输会话的单传输会话之一，以及其中所述接收器忽略所述解码顺序指示。
17.如权利要求
10所述的装置，其中所述多个传输会话中的每个利用非交织封包模式 和交织封包模式之一。
18.一种装置，包括用于确定应用数据单元是否要在多个传输会话中传递的装置；以及 用于在确定所述应用数据单元要在所述多个传输会话中传递时，在第一传输会话传输 分组中包括第一解码顺序指示，以及在第二传输会话传输分组中包括第二解码顺序指示以 用于封包媒体流的装置，其中所述解码顺序指示包括至少一个值，其表示在所述媒体流中 所述应用数据单元的解码顺序，以及其中在缺少包含所述第二传输会话传输分组的第二传 输会话时，将所述第一解码顺序指示指定为不必要。
19.如权利要求
18所述的装置，其中所述媒体流是可扩展视频位流。
20.一种将传输分组解分组成媒体流的方法，包括接收包括第一解码顺序指示的第一传输会话传输分组和包括第二解码顺序指示的第 二传输会话传输分组；当确定已传递所述第一传输会话传输分组的应用数据单元而没有包含所述第二传输 会话传输分组的第二传输会话时，通过第一解分组处理忽略所述解码顺序指示；以及当确定已传递所述第一传输分组的所述应用数据单元而具有包含所述第二传输会话 传输分组的第二传输会话时，在第二解分组处理中使用所述解码顺序指示以进一步确定在 所述媒体流中传输的所述应用数据单元的解码顺序。
21.如权利要求
20所述的方法，其中所述媒体流是可扩展视频位流。
22.如权利要求
20所述的方法，其中根据实时传输协议形成所述传输分组。
23.如权利要求
20所述的方法，其中在所述至少一个传输分组的有效载荷内容可扩展 性信息网络提取层单元中包括所述解码顺序指示。
24.如权利要求
23所述的方法，其中所述有效载荷内容可扩展性信息网络提取层单 元是所述至少一个传输分组中的第一网络提取层单元，所述至少一个传输分组包括聚集分 组。
25.如权利要求
20所述的方法，其中所述应用数据单元至少部分地包括网络提取层单元。
26.如权利要求
20所述的方法，其中所述媒体流通过接收器接收，所述接收器订阅所 述多个传输会话的单传输会话之一，以及其中所述接收器忽略所述解码顺序指示。
27.如权利要求
20所述的方法，其中所述多个传输会话利用非交织封包模式和交织封 包模式。
28.如权利要求
27所述的方法，其中所述第一解分组处理包括结合所述非交织封包模 式使用的解分组处理。
29.如权利要求
27所述的方法，其中所述第二解分组处理包括结合所述交织封包模式使用的解分组处理。
30.一种计算机程序产品，其在计算机可读介质上实现，包括被配置为执行权利要求
20的处理的计算机代码。
31.一种装置，包括 处理器；以及存储器单元，其通信地连接至所述处理器，以及包括被配置为接收包括第一解码顺序指示的第一传输会话传输分组和包括第二解码顺序 指示的第二传输会话传输分组的计算机代码；被配置为当确定已传递所述第一传输会话传输分组的应用数据单元而没有包含所述 第二传输会话传输分组的第二传输会话时，通过第一解分组处理忽略所述解码顺序指示的 计算机代码；以及被配置为当确定已传递所述第一传输分组的应用数据单元而具有包含所述第二传输 会话传输分组的第二传输会话时，在第二解分组处理中使用所述解码顺序指示以进一步确 定在所述媒体流中传输的应用数据单元的解码顺序的计算机代码。
32.如权利要求
31所述的装置，其中所述媒体流是可扩展视频位流。
33.如权利要求
31所述的装置，其中所述存储器单元还包括被配置为根据实时传输 协议形成所述传输分组的计算机代码。
34.如权利要求
31所述的装置，其中所述存储器单元还包括被配置为在所述至少一 个传输分组的有效载荷内容可扩展性信息网络提取层单元中包括所述解码顺序指示的计 算机代码。
35.如权利要求
34所述的装置，其中所述有效载荷内容可扩展性信息网络提取层单 元是所述至少一个传输分组中的第一网络提取层单元，所述至少一个传输分组包括聚集分组。
36.如权利要求
31所述的装置，其中所述应用数据单元至少部分地包括网络提取层单元。
37.如权利要求
31所述的装置，其中所述媒体流通过接收器接收，所述接收器订阅所 述多个传输会话的单传输会话之一，以及其中所述接收器忽略所述解码顺序指示。
38.如权利要求
31所述的装置，其中所述多个传输会话利用非交织封包模式和交织封 包模式之一。
39.如权利要求
38所述的装置，其中所述第一解分组处理包括结合所述非交织封包模 式使用的解分组处理。
40.如权利要求
38所述的装置，其中所述第二解分组处理包括结合所述交织封包模式 使用的解分组处理。
41.一种装置，包括用于接收包括第一解码顺序指示的第一传输会话传输分组和包括第二解码顺序指示 的第二传输会话传输分组的装置；用于当确定已传递所述第一传输会话传输分组的应用数据单元而没有包含所述第二 传输会话传输分组的第二传输会话时，通过第一解分组处理忽略所述解码顺序指示的装 置；以及用于当确定已传递所述第一传输分组的应用数据单元而具有包含所述第二传输会话 传输分组的第二传输会话时，在第二解分组处理中使用所述解码顺序指示以进一步确定在 所述媒体流中传输的应用数据单元的解码顺序的装置。
42.如权利要求
41所述的装置，其中所述媒体流是可扩展视频位流。
专利摘要
提供了这样的系统和方法，其允许接收器恢复在不同的实时协议(RTP)会话中传递的网络提取层(NAL)单元的解码顺序。当PACSI NAL单元是单时间聚集分组类型A(STAP-A)分组并且PACSI NAL单元是聚集分组中的第一NAL时(例如当接收器被订阅传递NAL单元的不同RTP会话时)，在PACSI NAL单元的分组结构中包括每个分组中的应用数据单元(ADU)的解码顺序的指示。如果接收器仅被订阅基层RTP会话，则可忽略CL-DON指示。
文档编号H04L29/06GKCN101809967SQ200880108437
公开日2010年8月18日 申请日期2008年9月23日
发明者M·汉努卡塞拉, 王业奎 申请人:诺基亚公司导出引文BiBTeX, EndNote, RefMan