【技术实现步骤摘要】
【国外来华专利技术】
概括地说，本专利技术涉及在网络上分层媒体的传输。更具体地，本专利技术涉及在分层多 播传输处理中解码顺序信息的有效恢复。技术背景这个部分旨在提供在权利要求书中列举的本专利技术的背景或环境。这里的说明可包 括能够遵循的概念，但不必是先前已经构想或遵循的那些概念。因此，除非这里另外指出， 在这个部分所描述的内容并非是本申请中的说明书和权利要求书的现有技术，并且不可以 通过包括在这个部分中而承认其是现有技术。多媒体应用包括例如本地端播放的服务、流传输或按需服务、会话和广播/多播 服务。在多媒体应用中涉及的技术包括媒体编码、存储和传输。对于不同技术指定不同标 准。具体地，在具有波动带宽需求的视频通信系统中，分层编码的使用是有益的。例如，在会 话的生存期间可处理连接速度改变的视频使能的移动电话中，这个特征特别有益。例如，由 于从无线局域网(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-a...
【技术保护点】
一种将媒体流封包成传输分组的方法，包括：确定应用数据单元是否要在多个传输会话中传递；以及在确定所述应用数据单元要在所述多个传输会话中传递时，在第一传输会话传输分组中包括第一解码顺序指示，以及在第二传输会话传输分组中包括第二解码顺序指示，其中所述第一解码顺序指示和所述第二解码顺序指示包括至少一个值，其表示在所述媒体流中所述应用数据单元的解码顺序，以及其中在缺少包含所述第二传输会话传输分组的第二传输会话时，将所述第一解码顺序指示指定为不必要。
【技术特征摘要】
【国外来华专利技术】US 2007-9-24 60/974,777书中列举的本发明的背景或环境。这里的说明可包 括能够遵循的概念，但不必是先前已经构想或遵循的那些概念。因此，除非这里另外指出， 在这个部分所描述的内容并非是本申请中的说明书和权利要求书的现有技术，并且不可以 通过包括在这个部分中而承认其是现有技术。多媒体应用包括例如本地端播放的服务、流传输或按需服务、会话和广播/多播 服务。在多媒体应用中涉及的技术包括媒体编码、存储和传输。对于不同技术指定不同标 准。具体地，在具有波动带宽需求的视频通信系统中，分层编码的使用是有益的。例如，在会 话的生存期间可处理连接速度改变的视频使能的移动电话中，这个特征特别有益。例如，由 于从无线局域网(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模式。应注意，在使用中，...
【专利技术属性】
技术研发人员：王业奎，M汉努卡塞拉，
申请(专利权)人：诺基亚公司，
类型：发明
国别省市：FI[芬兰]
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。