CN117597937A - 用于用信号传输预选的方法、装置和系统 - Google Patents

Abstract

描述了一种处理媒体流的方法。方法包括：接收根据预定义传输格式分组的媒体流，其中，分组的媒体流包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联，并且其中，多个盒包括引用指示媒体流的媒体组件的相应轨道的一个或多个5轨道盒；确定媒体流是否包括指示预选的预定义类型的预选相关盒，其中，预选与对用户的媒体呈现相对应；以及如果确定媒体流包括预选相关盒，则：分析与预选0相关盒相对应的元数据信息，元数据信息指示预选的特性；基于元数据信息标识分组的媒体流中贡献于预选的一个或多个轨道；以及根据给定的预选提供一个或多个轨道用于下游处理。

Description

用于用信号传输预选的方法、装置和系统

相关申请的交叉引用

本申请要求以下优先申请的优先权：于2021年6月29日提交的美国临时申请63/216,029(参考号：D21064USP1)和于2022年1月7日提交的美国临时申请63/297,473(参考号：D21064USP2)，上述美国临时申请通过援引并入本文。

技术领域

本公开涉及音频和/或视频编解码(编码/解码)的一般领域，并且更具体地涉及用于用信号传输与对用户的媒体呈现相对应的预选及其处理的方法、装置和系统。

背景技术

一般来说，随着下一代音频(NGA)或类似视频技术的出现，整体音频体验不再作为预先生成的单一实例媒体组件进行传输。相反，单独的语义对象可以各自单独地进行提供，以为最终用户提供根据其偏好定制内容的高效方式。

例如，可以以多种语言提供对话，因为附加的可选音频组件和语言选择可以通过组合不同的音频组件或通过组件之间的不同平衡来实施。

从广义上讲，出于不同的原因，包括为那些不需要媒体资产的某些部分的用户节省传输带宽的可能性，现代视频压缩方案通常可以利用将总体可用媒体数据分布在多个流上的可能性。

如技术人员可以理解和认识到的，在任何情况下，媒体播放器通常将依赖于附带的元数据来指导如何渲染组件以产生预定义的用户体验。

对于传输，可以将这些内容组件(或简称CC)中的多个内容组件多路复用到单个基本流中，或者可以将这些组件分布于多个基本流上。

通常，不是所有可用组件都应同时呈现，相反仅这些组件的某些组合就可以提供期望的用户体验。

各种多路复用和传输层中的元数据为客户端(或最终用户)提供了关于所有可用组件的所需知识。另外，在一些情况下，还可能需要数据来决定要下载和解码哪些基本流。

国际标准化组织(ISO)包括并指定了通常称为ISOBMFF的基本媒体文件格式。特别地，ISOBMFF由ISO通过ISO/IEC 14496-12MPEG-4第12部分来指定。一般来说，其定义了如视频和/或音频等基于时间的多媒体文件的通用结构。虽然大多数现有的多路复用格式可能已经提供了用文件内的组件的相应性质来注释组件的手段，但ISO基本媒体文件格式(ISOBMFF)多路复用似乎在某种程度上缺乏用信号传输由内容组件的组合构成的整体体验的能力。简言之，与似乎引入了预选概念的一些其他标准(例如，MPEG-DASH(ISO/IEC23009-1))相比，似乎存在差距。

鉴于此，一般来说、更特别地是在ISOBMFF的上下文中，似乎需要用信号传输向用户指示这种预选的信息(可能还有，指示如何处理这种预选的信息)的技术。

发明内容

鉴于以上所述，本公开总体上提供了具有相应独立权利要求的特征的处理媒体流的方法、媒体流处理装置、程序以及计算机可读存储介质。

根据本公开的第一方面，提供了一种处理媒体流的方法。媒体流可以是音频流、视频流或其组合。方法可以在用户侧执行或者在一些情况下在用户(解码)侧环境中执行，根据各种实施方式，环境可以包括但不限于TV、条形音箱、网络浏览器、媒体播放、插件等。

特别地，方法可以包括接收根据预定义传输格式分组的媒体流。预定义传输格式可以是由ISO通过ISO/IEC 14496-12MPEG-4第12部分指定的基本媒体文件格式(ISOBMFF)或者呈任何其他合适的(传输)格式。分组的媒体流可以包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联。值得注意的是，如本文所使用的，在一些可能的情况下，术语“盒”通常可以用于指由唯一(盒)类型标识符(以及可能还有，相应长度)定义的面向对象构建块，例如如ISO 14496-12中所述。当然，贯穿本公开使用的术语“盒”不应被理解为仅限于这样的规范。相反，术语“盒”通常应理解为可以用作媒体数据或分组的媒体流的其他数据的占位符的任何合适的数据结构。此外，如技术人员还将理解和认识到的，这种“盒”可以通过使用任何其他合适的术语来指代。示例可以是：在一些可能的规范中(包括MP4的第一定义)，在某些情况下“盒”可以替代性地被称为“原子”。进一步地，如所指示的(“分层”)，根据各种实施方式和/或要求，多个盒可以具有相同或不同的级别(或位置)、可以是嵌套的(子盒(child/sub box)与父盒)等，如技术人员将理解和认识到的。更特别地，除了其他可能性之外，多个盒可以包括引用(或者换句话说，指示)指示媒体流的媒体(内容)组件的相应轨道的一个或多个轨道盒。从广义上讲，媒体(内容)组件通常可以指媒体内容的单个/单独连续组件(并且通常还可以与对应的(例如，分配的)媒体内容组件类型相关联，媒体内容组件类型可以包括但不限于音频、视频、文本等)。用于理解“媒体(内容)组件”的概念的示例可以如例如在MPEG-DASH(ISO/IEC 23009-1)中定义/描述的那样找到。

方法可以进一步包括确定媒体流是否包括指示预选的预定义类型的预选相关盒，其中，预选可以与对用户的媒体呈现相对应。更具体地说，如本文所使用的，术语/短语“预选”通常用于指代(媒体流的)旨在(例如，由用户侧设备)共同使用并且更特别是通常表示可以由最终用户选择用于同时解码和/或呈现的媒体呈现的一个版本的一组媒体内容组件。用于理解“预选”概念的示例可以如在例如MPEG-DASH(ISO/IEC 23009-1)中描述的那样找到。当然，如技术人员将理解和认识到的，在一些其他可能的技术上下文中，术语“预选”也可以通过使用任何其他合适的(相当的)术语而被已知(或被提及)，如(但不限于)如在例如ETSI TS103190-2中所描述的“呈现”或如在例如ISO/IEC 23008-3等中所描述的“预设”。因此，预选相关盒可以是媒体流中的多个盒当中具有特定预定义(或预定)类型的特定盒。如技术人员将理解和认识到的，这种指示预选的特定类型可以通过使用任何合适的手段预先预定义(或预定)，这将在下面更详细地描述。

如果确定媒体流包括预选相关盒，则方法还可以进一步包括：分析与预选相关盒相对应的元数据信息，元数据信息指示预选的特性；基于元数据信息标识分组的媒体流中贡献于预选的一个或多个轨道；以及根据给定的预选提供一个或多个轨道用于下游处理。如技术人员将理解和认识到的，根据各种实施方式，以上说明的元数据信息可以(直接)包括在媒体流(或者更具体地，(分组的)媒体流的多个盒)中或者可以通过使用任何合适的手段(间接)从媒体流中得到。例如，元数据信息可以被包括或包含在头盒(或另一个盒的子盒)中，头盒可以与预选相关盒相关联或链接至预选相关盒(例如，作为其子盒)。如上所述，预选通常是指一组媒体内容组件旨在例如由一个或多个合适的下游设备(例如，媒体解码器、媒体播放器等)共同使用的情况。在一些可能的情况下，下游设备还可以简称为“汇点(sink)”。因此，根据各种实施方式和/或要求，下游处理可以包括但当然不限于对那些有贡献的轨道进行多路复用(或在一些可能的情况下，再多路复用)、排序、合并、解码或渲染，如将在下文中更详细地描述的。

如以上所述的那样配置，所提出的方法通常可以提供一种高效而灵活的方式来确定/标识媒体流内被配置为贡献于特定预选的轨道，并随后用信号传输轨道，从而使得能够(例如，由一个或多个合适的下游设备)对这种有贡献的轨道进行进一步合适的下游处理。因此，从广义上讲，所提出的方法可以被视为提供以统一的方式在传输层文件(例如，ISOBMFF)中用信号传输指示预选(以及可能还有，对预选的处理)的信息的可能性和能力，这在各种用例或场景中可以被认为是有益的。例如，预选的这种统一表示(或者换言之，格式/类型无关)可以用于实施媒体播放应用程序编程接口(API)的统一数据结构(例如，将由应用程序使用或者用作网络浏览器的插件)，使得不需要媒体播放器中的格式特定实施方式，从而减少了实施和/或测试的工作量，同时提高了可靠性。作为另一个示例，预选的这种统一表示也可以实现清单(例如，MPEG基于HTTP的动态自适应流式传输(DASH)格式文件或HTTP实时流(HLS)格式文件)生成器中预选数据处理的格式无关实施方式，从而避免对二进制数据的计算上更昂贵的操作的需要，并且再次减少了实施工作量并提高了可靠性。如本文所使用的，术语“格式/类型无关”通常可以意指所提出的表示对于所有数据类型(格式)是通用的。

在一些示例实施方式中，媒体流可以进一步包括处理信息，处理信息指示将如何(例如，由(多个)下游设备)处理贡献于预选的轨道。类似于如上所述的元数据信息，根据各种实施方式，处理信息也可以(直接)包括在媒体流(或者更特别地，(分组的)媒体流的多个盒)中或者可以通过使用任何合适的手段(间接)从媒体流中得到。例如，处理信息也可以包括在一个(例如，特定(预定义)类型的)特定盒中，特定盒可以与预选或预选相关盒相关联或链接至预选或预选相关盒(例如，作为其子盒)。

在一些示例实施方式中，处理信息可以包括排序信息，排序信息指示用于处理(例如，解码、合并等)一个或多个轨道的轨道顺序。例如，在一些可能的情况下，轨道顺序可以指示将以何种顺序向下游设备(例如，解码设备)提供轨道。类似于上述，这种排序信息可以被实施为包括在与处理信息相关联或有关的(子)盒中。

在一些示例实施方式中，处理信息可以包括合并信息，合并信息指示一个或多个轨道是否要与一个或多个其他轨道合并以用于联合(下游)处理。也就是说，根据这种合并信息的实施方式，在一些情况下，某个(一些)轨道可以与某个(一些)其他轨道合并以用于下游处理；而在一些其他情况下，某个(一些)轨道可以被单独地处理(例如，被路由到单独的解码实例)。值得注意的是，在一些可能的情况下，这种合并也可以被称为多路复用或任何其他合适的术语。如技术人员将理解和认识到的，轨道的合并(多路复用)可以通过使用任何合适的手段(例如，通过将后续轨道附加到先前轨道的末端)来实现。

在一些示例实施方式中，方法可以进一步包括根据合并信息和排序信息来合并一个或多个轨道。

在一些示例实施方式中，对于贡献于预选的每个轨道，排序信息可以包括用于定义轨道的轨道顺序的相应轨道顺序值。如技术人员将理解和认识到的，可以通过使用相应轨道顺序值来确定用于定义轨道的轨道顺序的各种合适的规则。如上所述，在一些可能的情况下，轨道顺序可以指示将以何种顺序向下游设备(例如，解码设备)提供轨道。在这种情况下，可能的示例性实施方式(但不是任何类型的限制)可以是：具有较小轨道顺序值(例如，1)的轨道将比具有较大轨道顺序值(例如，3)的另一轨道更早地被提供给解码设备。在一些情况下，如果多个轨道具有相同的值顺序值，则这些轨道的排序可能不再相关或重要。进一步地，以类似的方式，合并信息可以包括用于贡献于预选的每个轨道的相应合并标志。特别地，合并标志的第一设置值(例如，‘1’)可以指示相应轨道将以轨道顺序与相邻轨道(例如，前一轨道或后一轨道，这取决于这种合并标志的各种实施方式)合并(或多路复用)，并且合并标志的第二设置值(例如，‘0’)可以对应地指示相应轨道将被单独地处理(例如，被馈送或路由到单独的下游解码设备中)。因此，根据合并信息和排序信息来合并一个或多个轨道可以包括根据轨道顺序相继地(或顺序地)扫描轨道；以及根据相应合并标志来合并轨道。例如，在一些可能的情况下，如果轨道i的合并标志标志[i]被设置为‘1’，则轨道i的每个样本可以被附加到具有下一个更低(或更高)轨道顺序值的轨道(例如，轨道i-1或i+1)的(多个)样本；而另一方面，如果轨道的合并标志被设置为‘0’，则轨道i可以被提供给单独的解码器实例。作为另一个可能的示例，在轨道的所有合并标志都被设置为‘0’的极端情况下，应用上面的概念，则所有轨道将被分布到若干个(单独的)下游设备(汇点)。

在一些示例实施方式中，方法可以进一步包括根据由预选指示的媒体呈现来解码一个或多个轨道以用于回放媒体流。

在一些示例实施方式中，一个或多个轨道可以由下游设备(例如，媒体播放器、TV、条形音箱、插件等)解码。

在一些示例实施方式中，合并一个或多个轨道和解码一个或多个轨道可以由单个设备来执行。换句话说，可能存在合并和解码协同工作的用例。更具体地说，这种用例的示例(但不限于此)可以是某个JavaScript API希望仅使用单一合并流、而不使用多个流进行工作的情况。在这种情况下，一个实体通常可以获取多个传入流，并如上文所说明的那样将它们合并/多路复用，并且随后将它们作为一个合并流通过单流API发送，以在API的另一侧进行解码。在一些可能的情况下，单流格式可以是通用媒体应用程序格式(CMAF)字节流格式。当然，如技术人员将理解和认识到的，在一些其他情况下，轨道的合并和解码可以由不同的(单独的)设备执行。作为说明性示例(但不限于此)，TV可能正在实施如上所说明的流的合并，但是将合并的流发送到单独的下游设备(如条形音箱)以用于后续解码。

在一些示例实施方式中，媒体流可以包括预定义类型的多个(而不是仅一个)预选相关盒。因此，方法可以进一步包括在多个预选相关盒当中选择(或确定)预选相关盒。如技术人员将理解和认识到的，可以以任何合适的方式执行对多个预选相关盒当中的一个特定预选相关盒的这种选择(或确定)。

在一些示例实施方式中，预选相关盒可以由应用程序(例如，控制媒体播放器/解码器的应用程序)选择(或确定)。例如，在一些可能的情况下，应用程序可以被配置(例如，基于预定义算法)为(自动)选择(或确定)例如对应于(例如，解码或呈现环境的)特定设置的预选相关盒。

在一些示例实施方式中，媒体流可以包括一个或多个标签盒(一个或多个标签盒可以以某种方式与相应的预选或相应的预选相关盒相关联或链接至相应的预选或相应的预选相关盒)，一个或多个标签盒各自包括与相应的预选相对应的对用户的相应媒体呈现的描述性信息。因此，在这种情况下，可以基于用户的输入来执行预选相关盒的选择(或确定)。作为示例(但不限于此)，标签盒可以包括指示各种语言(例如，英语、德语、中文等)的可选字幕的描述性信息，每种语言都可以被视为相应的预选(呈现)，使得(例如，控制应用程序的)用户可以适当地选择(例如，通过点击鼠标或键盘)对应的语言设置。

在一些示例实施方式中，预选相关盒可以被认为是与用于在被分组之前对媒体流进行编码的媒体编解码器无关的。换言之，一般来说，预选相关盒可以仅包括用于相应预选的必要信息，而不包括可以与媒体编解码器相关的信息(即，编解码器特定信息)。换句话说，在(多个)预选相关盒中，通常不存在与媒体流如何被编码(例如，由特定媒体编码器)和/或应如何解码(例如，由特定媒体解码器)这样的媒体流相关的信息。

在一些示例实施方式中，与预选相关盒相对应的元数据信息可以包括指示一个或多个轨道标识符的轨道标识信息，一个或多个轨道标识符各自与相应的轨道相关联，其中，与元数据信息中的一个或多个轨道标识符相关联的轨道可以与媒体呈现相关。如技术人员将理解和认识到的，指示一个或多个轨道标识符的这种轨道标识信息可以以任何合适的方式来实施，方式例如像阵列一样简单，其中，阵列中的每个元素(唯一地)指示相应的轨道标识符(其本身可以通过使用整数值或任何其他合适的形式来表示)。在这种情况下，在一些可能的情况下，与预选相关盒相对应的元数据信息可以可选地进一步包括计数器(例如，整数值)，计数器指示预选所需(或贡献于预选)的轨道的数量。

在一些示例实施方式中，与预选相关盒相对应的元数据信息可以包括预选标识信息，预选标识信息指示用于标识预选的预选标识符。也就是说，与预选相关盒相对应的元数据信息可以包括必要的信息(例如，通过使用整数来表示)，必要的信息使得预选能够对于外部(例如，下游)应用程序和/或设备(唯一地)可标识，例如用于相应地辅助对相应预选的选择/确定。

在一些示例实施方式中，与预选相关盒相对应的元数据信息可以包括用于配置下游设备(例如，下游媒体播放器/解码器)以根据预选对轨道进行解码的唯一预选特定数据。根据各种实施方式和/或要求，这种预选特定数据可以包括任何合适的信息(例如，在一些情况下，编解码器特定信息)，并且可以以任何合适的方式(例如，整数、阵列、字符串等)来实施(表示)。

根据本公开的第二方面，提供了一种处理媒体流的方法。媒体流可以是音频流、视频流或其组合。方法可以在用户侧执行或者在一些情况下在用户(解码)侧环境中执行，根据各种实施方式，环境可以包括但不限于TV、条形音箱、网络浏览器、媒体播放、插件等。

特别地，方法可以包括接收根据预定义传输格式分组的媒体流。类似于前面的第一方面，预定义传输格式可以是由ISO通过ISO/IEC 14496-12MPEG-4第12部分指定的基本媒体文件格式(ISOBMFF)或者呈任何其他合适的(传输)格式。分组的媒体流可以包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联。如上所述，根据各种实施方式和/或要求，多个盒(或通过使用任何其他合适的术语来指代)可以具有相同或不同的级别(或位置)、可以是嵌套的(子盒与父盒)等，如技术人员将理解和认识到的。更特别地，除了其他可能性之外，多个盒可以包括引用(或者换句话说，指示)指示媒体流的媒体(内容)组件的相应轨道的一个或多个轨道盒。另外，多个盒还可以包括一个或多个轨道组盒(或通过使用任何其他合适的术语/名称来指代)，一个或多个轨道组盒各自与联合地标识媒体流内的相应轨道组的由轨道组标识符和轨道组类型构成的相应对相关联。也就是说，具有相同轨道组标识符和相同轨道组类型(例如，由相同轨道组标识符和相同轨道组类型标识或与其相关联)的轨道可以被认为属于相同轨道组。每个这样的轨道组通常可以确定与对用户的相应媒体呈现相对应的相应预选。如已经在上文所说明的，术语/短语预选(或通过使用任何其他合适的术语/名称来指代)通常用于指代(媒体流的)旨在(例如，由用户侧设备)共同使用并且更特别是通常表示可以由最终用户选择用于同时解码/呈现的媒体呈现的一个版本的一组媒体内容组件。

方法可以进一步包括检查(例如，访问、循环遍历等)媒体流中的轨道盒，以确定媒体流中存在的预选的完全(或完整/总)集合。特别地，预选的完全集合的确定可以包括：确定一组唯一的轨道组标识符和轨道组类型对；以及通过相应的轨道组标识符来对预选进行寻址。如上所述，每个预选与相应的轨道组相关联，相应的轨道组本身又由相应的对应轨道组标识符和对应轨道组类型对来标识。因此，预选可以通过与其相关联/链接的相应轨道组标识符来寻址(或标识)。

方法还可以进一步包括在预选的完全集合当中选择预选。特别地，预选可以基于包括在具有相同轨道组标识符的轨道组盒中的相应预选的属性(例如，表示为元数据或任何其他合适形式)来选择。

方法还可以包括确定(例如，标识)贡献于所选择的预选的一组一个或多个轨道盒。特别地，贡献于(相同)预选的一组一个或多个轨道盒可以通过具有相同轨道组标识符的(相应)轨道组盒的存在来确定(标识)。

此外，方法可以进一步包括将如以上所确定的一组一个或多个轨道盒的每个成员(元素)中引用的轨道确定为贡献于预选的一个或多个轨道。

最后，方法可以包括根据预选提供一个或多个轨道用于下游处理。如上所述，预选通常是指旨在例如由如媒体解码器、媒体播放器等一个或多个合适的下游设备(或者在一些可能的情况下，称为汇点)共同使用的一组媒体内容组件。因此，根据各种实施方式和/或要求，下游处理可以包括但不限于对那些有贡献的轨道进行多路复用(或在一些可能的情况下，再多路复用)、排序、合并、解码或渲染，如将在下文中更详细地描述的。

如以上所述的那样配置，所提出的方法通常可以提供一种高效而灵活的方式来确定/标识媒体流内被配置为贡献于特定预选的轨道，并随后用信号传输轨道，从而使得能够(例如，由一个或多个下游设备)对这种有贡献的轨道进行进一步合适的下游处理。特别地，要注意的是，如以上在第一方面中提出的方法通常寻求在预选相关盒中提供被配置为贡献于特定预选的(所有)轨道的相关信息，从而使得能够对所有有贡献的轨道进行索引(或标识)。在这个意义上，如第一方面中所描述的对轨道的这种索引可以被视为某种正向(直接)索引。相比之下，在本第二方面提出的方法中，贡献于特定预选的轨道可以由轨道组类型和轨道组标识符所构成的对联合确定。更具体地，具有(例如，包含)带有特定(例如，预定义或预定)轨道组类型的轨道组盒的轨道通常可以指示轨道贡献于预选。进一步地，具有相同轨道组标识符的轨道通常可以指示那些轨道属于(贡献于)相同预选。在这个意义上，与第一方面中提出的相反，这里描述的对轨道的这种索引可以被视为某种反向索引。在任何情况下，类似于第一方面，在第二方面中提出的方法也可以提供以统一的方式在传输层文件(例如，ISOBMFF)中用信号传输指示预选(以及可能还有，对预选的处理)的信息的可能性和能力，这在各种用例或场景中可以被认为是有益的。例如，预选的这种统一表示(或者换言之，格式无关)可以用于实施媒体播放API的统一数据结构(例如，将由应用程序使用或者用作网络浏览器的插件)，使得不需要媒体播放器中的格式特定实施方式，从而减少了实施和/或测试的工作量，同时提高了可靠性。作为另一个示例，预选的这种统一表示也可以实现清单(例如，MPEG基于HTTP的动态自适应流式传输DASH格式文件或HTTP实时流HLS格式文件)生成器中预选数据处理的格式无关实施方式，从而避免对二进制数据的计算上更昂贵的操作的需要，并且再次减少了实施工作量并提高了可靠性。

在一些示例实施方式中，每个预选可以与预定义类型的相应预选相关盒相关联。特别地，预选相关盒可以实例化(例如，固有的、扩展等)具有与预选相关的预定义轨道组类型的轨道组盒。如技术人员将理解和认识到的，这种与预选相关的预定义轨道组类型可以通过使用任何合适的手段来实施，如特定(预定义)字符串(例如，‘预选’或‘pres’)、特定(预定义)值(例如，‘3’)等。一般来说，在第二方面中提出的方法中，每个预选和每个对应于(贡献于)预选的轨道通常会存在一个这样的预选相关盒。作为比较，在前述第一方面中提出的方法中，每次预选通常会存在一个这样的预选相关盒。

在一些示例实施方式中，预选相关盒可以与预选处理盒相关联，预选处理盒包括指示将如何处理贡献于预选的轨道的处理信息。根据各种实施方式，处理信息可以(直接)包括在媒体流(或者更特别地，(分组的)媒体流的多个盒)中或者可以通过使用任何合适的手段(间接)从媒体流中得到。例如，处理信息也可以包括在(例如，特定(预定义)类型的)特定盒中，特定盒可以与预选或预选相关盒相关联或链接至预选或预选相关盒(例如，作为其子盒)。

在一些示例实施方式中，预选相关盒可以与预选信息盒相关联，预选信息盒包括指示预选的语义(或描述性)信息(例如，属性、特性等)。

在一些示例实施方式中，处理信息可以包括用于配置下游设备(例如，下游媒体播放器/解码器)以根据预选对轨道进行解码的唯一预选特定数据。根据各种实施方式和/或要求，这种预选特定数据可以包括任何合适的信息(例如，在一些情况下，编解码器特定信息)，并且可以以任何合适的方式(例如，整数、阵列、字符串等)来实施(表示)。

在一些示例实施方式中，处理信息可以包括排序信息，排序信息指示用于对轨道进行排序以进行进一步下游处理(例如，解码、合并等)的轨道顺序。例如，在一些可能的情况下，轨道顺序可以指示将以何种顺序向下游设备(例如，解码设备)提供轨道。类似于上述，这种排序信息可以被实施为包括在与处理信息相关联或有关的(子)盒中。

在一些示例实施方式中，处理信息可以包括合并信息，合并信息指示一个或多个轨道是否要与一个或多个其他轨道合并以例如用于联合(下游)处理。也就是说，根据这种合并信息的实施方式，在一些情况下，某个(一些)轨道可以与某个(一些)其他轨道合并以用于下游处理；而在一些其他情况下，某个(一些)轨道可以被单独地处理(例如，被路由到单独的解码实例)。值得注意的是，在一些可能的情况下，这种合并也可以被称为多路复用或任何其他合适的术语。如技术人员将理解和认识到的，轨道的合并(多路复用)可以通过使用任何合适的手段(例如，通过将后续轨道附加到先前轨道的末端)来实现。

在一些示例实施方式中，方法可以进一步包括根据合并信息和排序信息来合并一个或多个轨道。

在一些示例实施方式中，对于贡献于预选的每个轨道，排序信息可以包括用于定义轨道的轨道顺序的相应轨道顺序值。如技术人员将理解和认识到的，可以通过使用相应轨道顺序值来确定用于定义轨道的轨道顺序的各种合适的规则。如上所述，在一些可能的情况下，轨道顺序可以指示将以何种顺序向下游设备(例如，解码设备)提供轨道。在这种情况下，可能的示例实施方式(但不是任何类型的限制)可以是：具有较小轨道顺序值(例如，1)的轨道将比具有较大轨道顺序值(例如，3)的另一轨道更早地被提供给解码设备。在一些情况下，如果多个轨道具有相同的值顺序值，则这种轨道的排序可能不再相关或重要。进一步地，以类似的方式，合并信息可以包括用于贡献于预选的每个轨道的相应合并标志。特别地，合并标志的第一设置值(例如，‘1’)可以指示相应轨道将以轨道顺序与相邻轨道(例如，前一轨道或后一轨道，这取决于这种合并标志的各种实施方式)合并(或多路复用)，并且合并标志的第二设置值(例如，‘0’)可以对应地指示相应轨道将被单独地处理(例如，被馈送/路由到单独的下游解码设备中)。因此，根据合并信息和排序信息来合并一个或多个轨道可以包括根据轨道顺序相继地(或顺序地)扫描轨道；以及根据相应合并标志来合并轨道。例如，在一些可能的情况下，如果轨道i的合并标志标志[i]被设置为‘1’，则轨道i的每个样本可以被附加到具有下一个更低(或更高)轨道顺序值的轨道(例如，轨道i-1或i+1)的(多个)样本；而另一方面，如果轨道的合并标志被设置为‘0’，则轨道i可以被提供给单独的解码器实例。作为另一个可能的示例，在轨道的所有合并标志都被设置为‘0’的极端情况下，应用上面的概念，则所有轨道将被分布到若干个(单独的)下游设备(例如，汇点)。

在一些示例实施方式中，方法可以进一步包括根据由预选指示的媒体呈现来解码一个或多个轨道以用于回放媒体流。

在一些示例实施方式中，一个或多个轨道可以由下游设备(例如，媒体播放器、TV、插件等)解码。

在一些示例实施方式中，合并一个或多个轨道和解码一个或多个轨道可以由单个设备来执行。换句话说，可能存在合并和解码协同工作的用例。更具体地说，这种用例的示例(但不限于此)可以是某个JavaScript API希望仅使用单一合并流、而不使用多个流进行工作的情况。在这种情况下，一个实体通常可以获取多个传入流，并如上文所说明的那样将它们合并/多路复用，并且随后将它们作为一个合并流通过单流API发送，以在API的另一侧进行解码。在一些可能的情况下，单流格式可以是通用媒体应用程序格式(CMAF)字节流格式。当然，如技术人员将理解和认识到的，在一些其他情况下，轨道的合并和解码可以由不同的(单独的)设备执行。作为说明性示例(但不限于此)，TV可能正在实施如上所说明的流的合并，但是将合并的流发送到单独的下游设备(如条形音箱)以用于后续解码。

在一些示例实施方式中，预选可以由应用程序(例如，控制媒体播放器/解码器的应用程序)选择(或确定)。例如，在一些可能的情况下，应用程序可以被配置(例如，基于预定义算法)为(自动)选择(或确定)例如对应于(例如，解码或呈现环境的)特定设置的预选。

在一些示例实施方式中，媒体流可以包括一个或多个标签盒(一个或多个标签盒可以与相应的预选或预选相关盒相关联或链接至相应的预选或预选相关盒)，一个或多个标签盒各自包括与相应的预选相对应的对用户的相应媒体呈现的描述性信息。因此，在这种情况下，可以基于用户的输入来执行预选的选择(或确定)。作为示例(但不限于此)，标签盒可以包括指示各种语言(例如，英语、德语、中文等)的可选字幕的描述性信息，每种语言都可以被视为相应的预选(呈现)，使得(例如，控制应用程序的)用户可以适当地选择(例如，通过点击鼠标或键盘)对应的语言设置。当然，如技术人员将理解和认识到的，预选的选择(或确定)也可以以任何其他合适的方式执行。

在一些示例实施方式中，如上所述，媒体流可以包括音频流或视频流(或其组合)中的至少一者。具体地，可以应用本公开中提出的方法的一些可能的场景(或用例)可以是例如多人视频会议(其中，观看者可以具有选择一个或多个视频流的能力)；或者是具有画中画能力的TV(例如，其中，一个画面具有较高的比特率/分辨率并且另一画面具有较低的比特率/分辨率)。

根据本公开的第三方面，提供了一种处理媒体流的方法。媒体流可以是音频流、视频流或其组合。方法可以在编码侧环境(例如，媒体编码器)上执行。在一些场景(或用例)中，这种编码器也可以被称为(媒体)打包器(即，被配置为对媒体输入进行打包/分组)。

特别地，方法可以包括根据预定义传输格式封装一个或多个基本流以生成分组的媒体流，其中，分组的媒体流包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联。类似于上述，预定义传输格式可以是由ISO通过ISO/IEC 14496-12MPEG-4第12部分指定的基本媒体文件格式(ISOBMFF)或者呈任何其他合适的(传输)格式。从广义上讲，如技术人员可以理解和认识到的，基本流可以被视为形成从单个媒体编码器流动到媒体解码器的(媒体)数据(音频或视频)的压缩二进制表示。当被多路复用(或分组)成预定义传输格式(例如，ISOBMFF)时，这些基本流可以被称为“轨道”，其中，“轨道盒”在文件头中描述每个轨道的性质(或属性)。进一步地，如也已经在上文所描述的，根据各种实施方式和/或要求，多个盒(或通过使用任何其他合适的术语来指代)可以具有相同或不同的级别(或位置)、可以是嵌套的(子盒与父盒)等，如技术人员将理解和认识到的。

更具体地，封装一个或多个基本流可以包括：根据传输格式对一个或多个基本流的媒体数据进行分组，以生成引用(或指示)一个或多个基本流的相应轨道的一个或多个轨道盒；以及基于一个或多个基本流的头信息生成预定义类型的一个或多个预选相关盒，其中，一个或多个预选相关盒中的每个预选相关盒指示与对用户的媒体呈现相对应的相应预选。

如以上所述的那样配置，所提出的方法通常可以提供用于根据预定义传输格式(例如，ISOBMFF)对媒体输入(例如，基本流)进行分组的高效而灵活的方式。更特别地，通过在分组的媒体流旁边生成并包括一个或多个预选相关盒(每个预选相关盒指示相应的预选)，所提出的方法还可以使得能够以与编解码器无关的统一方式来表示预选，从而进一步使得能够对贡献于对应预选的轨道进行适当的下游处理(例如，根据前面第一方面和第二方面中提出的方法)。另外，如上所述，预选的这种统一表示也可以实现清单(例如，MPEG基于HTTP的动态自适应流式传输DASH格式文件或HTTP实时流HLS格式文件)生成器中预选数据处理的格式无关实施方式，从而避免对二进制数据的计算上更昂贵的操作的需要，并且同时减少了实施工作量并提高了可靠性。

在一些示例实施方式中，一个或多个预选相关盒中的每个预选相关盒可以包括指示相应预选的特性的元数据信息。更特别地，元数据信息可以包括指示媒体流中贡献于相应预选的一个或多个轨道的信息。如技术人员将理解和认识到的，根据各种实施方式，以上说明的元数据信息可以(直接)包括在媒体流(或者更特别地，(分组的)媒体流的多个盒)中或者可以通过使用任何合适的手段(间接)从媒体流中得到。例如，元数据信息可以被包括或包含在头(或类似物)盒中，头盒可以以某种方式与预选相关盒相关联或链接至预选相关盒(例如，作为其子盒)。

在一些示例实施方式中，与相应预选相关盒相对应的元数据信息可以进一步包括以下各项中的至少一项：指示用于标识相应预选的预选标识符的预选标识信息；或用于根据预选对轨道进行解码的唯一预选特定数据(例如，用于配置如下游媒体解码器等下游设备)。

在一些示例实施方式中，封装基本媒体流可以进一步包括生成一个或多个轨道组盒，一个或多个轨道组盒各自与联合地标识分组的媒体流内的相应轨道组的相应轨道组标识符和相应轨道组类型(由它们构成的对)相关联。特别地，具有相同轨道组标识符和相同轨道组类型的轨道可以被认为属于相同轨道组。进一步地，生成一个或多个预选相关盒可以包括：向每个预选分配第一唯一标识符；以及针对贡献于相应预选的每个轨道，生成与相应预选相关联的相应预选相关盒，并且将轨道组标识符设置为第一唯一标识符，其中，预选相关盒实例化具有与预选相关的预定义轨道组类型的轨道组盒。如技术人员将理解和认识到的，这种与预选相关的预定义轨道组类型可以通过使用任何合适的手段来实施，如特定(预定义)字符串(例如，‘预选’或‘pres’)、特定(预定义)值(例如，3)等。一般来说，在本文中提出的方法中，每个预选和每个对应于(贡献于)预选的轨道通常会存在一个这样的预选相关盒。

在一些示例实施方式中，轨道组盒可以是通过基于贡献于一个预选的轨道的相应媒体类型对轨道进行分组来生成的。

在一些示例实施方式中，媒体类型可以包括以下各项中的至少一项：音频、视频和字幕。当然，如技术人员将理解和认识到的，也可以使用任何其他合适的媒体类型。

在一些示例实施方式中，生成一个或多个预选相关盒可以进一步包括：生成一个或多个预选处理盒，一个或多个预选处理盒包括指示将如何处理贡献于相应预选的轨道的处理信息。根据各种实施方式，处理信息可以(直接)包括在媒体流(或者更特别地，(分组的)媒体流的多个盒)中或者可以通过使用任何合适的手段(间接)从媒体流中得到。例如，处理信息也可以包括在(例如，特定(预定义)类型的)特定盒中，特定盒可以以某种方式与预选或预选相关盒相关联或链接至预选或预选相关盒(例如，作为其子盒)。

在一些示例实施方式中，处理信息可以包括以下各项中的至少一项：指示用于处理轨道的轨道顺序的排序信息；或指示一个或多个轨道是否要与另一个或多个轨道合并(例如，以用于联合(下游)处理)的合并信息。例如，在一些可能的情况下，轨道顺序可以指示将以何种顺序向下游设备(例如，解码设备)提供轨道。进一步地，根据合并信息的实施方式，在一些情况下，某个(一些)轨道可以与某个(一些)其他轨道合并以用于下游处理；而在一些其他情况下，某个(一些)轨道可以被单独地处理(例如，被路由到单独的解码实例)。类似于上述，排序信息以及合并信息可以被实施为包括在与处理信息相关联或有关的一个(子)盒(或多个(子)盒)中。

在一些示例实施方式中，方法可以进一步包括：接收至少一个输入媒体；以及处理(例如，编码)输入媒体以生成一个或多个基本流，其中，一个或多个基本流包括输入媒体的媒体数据和对应的头信息。例如，可以通过使用合适的媒体编码器来处理(例如，编码)输入媒体，以便适当地生成对应的基本流。

在一些示例实施方式中，方法可以进一步包括基于一个或多个预选相关盒来生成清单文件。一般来说，清单文件通常可以包括各种信息，例如，关于媒体流的信息(如媒体类型、编解码器属性、媒体特定性质等)。除了这样的信息(即，与媒体流本身有关)之外，所提出的方法还可以进一步包括与预选相关联的信息。预选相关信息可以包括但不限于元数据信息、处理信息等。与传统技术相比，所提出的用于生成清单文件的方法通常可以为预选相关数据处理提供格式无关的实施方式，从而避免计算上更昂贵的操作(例如，在传统技术中必须对二进制数据执行的操作)，减少实施和/或测试工作量并提高可靠性。

在一些示例实施方式中，如技术人员将理解和认识到的，清单文件可以是MPEG基于HTTP的动态自适应流式传输(DASH)格式文件、HTTP实时流(HLS)格式文件或任何其他合适的清单格式文件。

根据本公开的第四方面，提供了一种处理媒体流的方法。媒体流可以是音频流、视频流或其组合。例如，方法可以由清单生成器来执行。

特别地，方法可以包括接收根据预定义传输格式分组的媒体流。特别地，分组的媒体流可以包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联，其中，多个盒可以包括一个或多个轨道盒以及预定义类型的一个或多个预选相关盒，一个或多个轨道盒引用(例如，指示)指示媒体流的媒体组件的相应轨道，并且其中，每个预选相关盒指示与对用户的媒体呈现相对应的相应预选。

进一步地，方法还可以包括基于一个或多个预选相关盒来生成清单文件。

如以上所述的那样配置，所提出的方法通常可以通过还考虑预选相关信息(例如，描述性信息和/或处理相关信息)来提供用于生成清单文件的高效而灵活的方式。更特别地，除了与(多个)媒体流相关的信息之外，所提出的方法可以进一步包括与预选相关联的信息。预选相关信息可以包括但不限于元数据信息、处理信息等。与传统(清单生成)技术相比，所提出的用于生成清单文件的方法通常可以为预选相关数据处理提供格式无关的实施方式，从而避免计算上更昂贵的操作(例如，在传统技术中必须对二进制数据执行的操作)，减少实施和/或测试工作量并提高可靠性。

在一些示例实施方式中，如技术人员将理解和认识到的，清单文件可以是MPEG基于HTTP的动态自适应流式传输(DASH)格式文件、HTTP实时流(HLS)格式文件或任何其他合适的清单格式文件。

在一些示例实施方式中，对用户的媒体呈现可以由与媒体流的语言、种类和/或一个或多个媒体特定属性相关的相应配置来表征。当然，根据各种实施方式，也可以使用任何其他合适的配置。

在一些示例实施方式中，预定义传输格式可以是ISO基本媒体文件格式(ISOBMFF)或任何其他合适的传输格式。

根据本发明的第五方面，提供了一种媒体流处理装置，媒体流处理装置包括处理器和耦接到处理器的存储器。处理器可以适于使媒体流处理装置执行根据前述方面中描述的示例方法中的任一种方法的所有步骤。

根据本发明的第六方面，提供了一种计算机程序。计算机程序可以包括指令，指令当由处理器执行时使处理器执行在整个公开中描述的方法的所有步骤。

根据本发明的第七方面，提供了一种计算机可读存储介质。计算机可读存储介质可以存储前述计算机程序。

将理解，装置特征和方法步骤可以以多种方式互换。特别地，(多种)所公开方法的细节可以由对应装置(或系统)实现，并且反之亦然，如技术人员将认识到的。此外，关于(多种)方法进行的以上陈述中的任何陈述被理解为同样地适用于对应装置(或系统)，并且反之亦然。

附图说明

下文参考附图解释本公开的示例实施例，其中，相同的附图标记指示相同或相似的元素，并且其中，

图1A是示出了媒体播放应用程序编程接口(API)的示例性实施方式的示意图，

图1B是示出了根据本公开的实施例的媒体播放API的示例性实施方式的示意图，

图2是示出了根据本公开的实施例的处理媒体流的系统的示例性实施方式的示意图，

图3A是示出了打包器的示例实施方式的示意图，

图3B是示出了根据本公开的实施例的打包器的示例实施方式的示意图，

图4A是示出了清单生成器的示例实施方式的示意图，

图4B是示出了根据本公开的实施例的清单生成器的示例实施方式的示意图，

图5是图示了根据本公开的实施例的处理媒体流的方法的示例的示意性流程图，

图6是图示了根据本公开的实施例的处理媒体流的方法的另一示例的示意性流程图，

图7是图示了根据本公开的实施例的处理媒体流的方法的又一示例的示意性流程图，

图8是图示了根据本公开的实施例的处理媒体流的方法的又另一示例的示意性流程图，以及

图9是用于执行根据本公开的实施例的方法的示例装置的示意性框图。

具体实施方式

如上文所指示的，除非另有指示，否则本公开中相同或相似的附图标记可以指示相同或相似的元素，使得为简洁起见，可以省略对其的重复描述。

特别地，附图和以下描述仅作为说明与优选实施例相关。应当注意的是，根据下面的讨论，本文所公开的结构和方法的替代实施例将容易地被公认为在不脱离所要求保护的原理的情况下可以采用的可行替代方案。

现在将详细参考若干实施例，在附图中图示了这些实施例的示例。需要注意的是，在可行的情况下，可以在附图中使用可行的类似或相似的附图标记，并且附图标记可以指示类似或相似的功能。附图仅出于说明目的描绘所公开系统(或方法)的实施例。本领域技术人员将容易从以下描述中认识到，在不脱离本文描述的原理的情况下，可以采用本文所图示的结构和方法的替代实施例。

此外，在连接元素(如实线或虚线或箭头)用于图示两个或更多个其他示意性元素之间或当中的连接、关系或关联性的附图中，缺乏任何这样的连接元素并不意味着暗示可以不存在连接、关系或关联性。换句话说，未在附图中示出元素之间的一些连接、关系或关联性，以免模糊本发明。另外，为了便于图示，使用单个连接元素来表示元素之间的多个连接、关系或关联性。例如，在连接元素表示信号、数据或指令的通信的情况下，本领域的技术人员应理解，这样的元素表示为了影响通信而可能需要的一条或多条信号路径。

如上文所指示的，从广义上讲，本文件通常试图提出在ISOBMFF文件的上下文中实现预选概念的技术，从而能够完成MPEG-DASH和各种其他媒体压缩格式的可用性。

因此，本文描述的示例实施例可以涉及针对“预选”的各种用例的方法、装置和过程。

在详细描述示例实施例之前，为了便于理解，可能仍然值得描述可以在整个本公开中使用的一些可能的术语，即使其中一些术语可能已经在上面(简要地)讨论过。

特别地，出于本文件的目的，就“预选”而言，这种术语通常意指同时解码/呈现的一组一个或多个媒体(内容)组件，如在例如MPEG-DASH(ISO/IEC 23009-1)中。如技术人员将理解和认识到的，在一些其他可能的技术上下文中，“预选”也可以通过使用任何其他合适的(相当的)术语而被已知(或被提及)，如(但不限于)如在例如ETSI TS103190-2中所描述的“呈现”或如在例如ISO/IEC 23008-3等中所描述的“预设”。

关于“适配集(AdaptationSet)”，这种术语通常应如MPEG-DASH(ISO/IEC 23009-1)中的类似描述进行定义，并且与上述类似，也可以被称作(称为)其他术语，如通用媒体应用程序格式(CMAF)中定义的“切换集(SwitchingSet)”。

关于“呈现”，这种术语通常应如MPEG-DASH(ISO/IEC 23009-1)中的描述进行定义，并且也可以称为“音频轨道(AudioTrack)”(例如，如通过W3C API定义)或“轨道列表(Tracklist)”或“轨道(Track)”(例如，如通过ISOBMFF定义)。

关于“媒体内容组件”，这种短语/术语通常应意指具有所分配媒体内容组件类型的媒体内容的单个连续组件，例如如MPEG-DASH(ISO/IEC 23009-1)中所述。

关于“媒体内容组件类型”，这种短语/术语通常应意指媒体内容的单一类型，例如如MPEG-DASH(ISO/IEC 23009-1)中所述。如技术人员将理解和认识到的，媒体内容组件类型的示例可以包括但不限于音频、视频、文本或任何其他合适的类型。

关于“盒(box)”，这种术语通常应意指由唯一类型标识符和长度定义的面向对象构建块，例如如ISO 14496-12中所述。与以上类似，可以注意到，在一些规范(包括MP4的第一定义)中，术语“盒”可以替代性地被称为“原子(atom)”、或任何其他合适的类似术语。

关于“容器盒”，这种短语/术语通常应意指唯一目的是容纳一组相关(子)盒并对其进行分组的盒，例如如ISO 14496-12中所述。然而，需要注意的是，容器盒通常不是从“全盒(fullbox)”得到的。

最后，关于“ISO基本媒体文件”，这种短语/术语通常应意指符合如ISO 14496-12中指定的文件格式(即，ISOBMFF)的文件。

因此，如技术人员将理解和认识到的，除非另有明确指示，否则上述术语和/或短语可以互换使用。

在进入相应示例性实施例的技术细节之前，还可能值得首先描述与预选相关的一些可能的用例(场景)，特别是从抽象和宽泛的总体角度。

参考附图，图1A是示出了媒体播放应用程序编程接口(API)的示例性实施方式的示意图。换句话说，图1A可以被视为媒体播放器中呈现(预选)选择的示例用例。更特别地，图1A的示例通常被认为是通过使用传统技术来支持预选的一种可能的实施方式。

从广义上讲，尽管一些媒体内容可以使用通常利用清单文件的如MPEG DASH等手段来传递，但一些播放器框架可能只使用ISOBMFF格式的内容。因此，基于这种架构的媒体播放器将被要求能够基于仅包含在ISOBMFF中的元数据信息来进行呈现选择，并且因此不能再依赖于来自(多个)清单文件的信令。

如图1A所示，媒体播放器1200接收输入媒体(或文件)1000，用于生成对应的媒体输出/呈现1400。输入媒体1000可以是(分组的)容器格式文件或流(例如，ISOBMFF文件或流)。媒体播放器1200由合适的应用程序1300控制。这种应用程序1300以及对应地媒体播放器1200的传统控件可以包括但不限于“播放”、“暂停”、“停止”、“前进”、“倒退”等。然而，对于下一代音频(或类似的视频技术)，媒体播放器1200可能被要求向应用程序1300呈现可用体验(或呈现)的列表，并且作为交换，从应用程序中获得期望的选择。这通常可以在媒体播放器1200与应用程序1300之间的API 1290中实施。

一般来说，传入的ISOBMFF 1000提供(包括)呈容器格式特定表示的元数据1010(例如，被实施为一个或多个盒或呈任何其他合适的形式)以及(多个)媒体基本流1020。特别地，这样的容器格式元数据1010可以被布置为字节数据，其通常可以是编解码器特定的。进一步地，基本流1020本身可以包括头信息数据(或者在一些情况下也可以称为某种元数据)1030(其通常是二进制数据的形式)以及编码(或压缩)的媒体数据1040(其类似于二进制元数据1030，通常是二进制数据的形式)。如技术人员可以理解和认识到的，从广义上讲，基本流数据1040通常可以用二进制信息(比特数据)表示，而容器数据1010通常可以利用字节数据。

此外，如图1A所示，媒体播放器1200本身可以包括用于多种不同媒体格式(或者换句话说，是格式或编解码器特定的)的多个解码器实施方式(或实例)1220，多个解码器实施方式要求媒体播放器1200对应地还提供合适的选择元素/组件(或简称为选择器)1210以从容器格式数据解包基本流并决定使用哪个媒体解码器1220。决定通常是基于如上所述的容器格式元数据1010来进行的。

如图1A中进一步所示，支持预选的解码器1220提供(例如，生成)预选相关数据1230。这样的编解码器特定数据1230必须由对应的格式转换器1240转换成编解码器无关的通用格式1250，以便经由相应的API 1290(其通常是编解码器无关的)由应用程序1300来使用。

通常，与对基本流进行解包、将编解码器/格式特定数据转换为编解码器无关的通用格式有关的操作可能会引入整个程序的(不期望的)额外工作(例如，用于实施、用于测试等)并且因此在某种程度上可能被认为是低效的。

为了解决关于图1A所讨论的部分或全部问题，图1B示意性地图示了根据本公开的实施例的媒体播放API的示例性实施方式。值得注意的是，如先前所指示的，如上文所指示的，除非另有指示，否则图1B中相同或相似的附图标记可以指示图1A中相同或相似的元素，因此为简洁起见，可以省略对其的重复描述。

特别地，与图1A相比，图1B所示的媒体播放器1201不再需要读取每个解码器1221的相应API，重新格式化其输出并以格式无关的方式提供数据。

相反，利用与传入的ISOBMFF文件或流1001内的预选(如将在下文中更详细讨论的)相关的新数据结构1051(通常为字节格式)，媒体播放器1201可以仅在其相应的API1291处将数据1051呈现给应用程序1301。主要原因是这样的预选相关数据1051是编解码器无关的。

如所提出的那样配置，这种方法通常不需要实施多个与格式相关的元数据格式转换器(例如，如图1A所示的格式转换器1240)。此外，所提出的方法还隐式地定义了可以用于在媒体播放器API 1291处呈现预选相关元数据(例如，新数据结构1051)的统一数据结构。换言之，利用新提出的数据结构，现在可以使媒体播放器能够通过适当的API显露所包含的信息，以请求应用程序选择期望的呈现(预选)。更具体地，方法以与编解码器无关的方式工作，并且提供了一种轻量级的方法，因为它避免了解析编码的媒体本质的需要。

概括地说，如技术人员将理解和认识到的，以上提出的用于媒体播放器API的用例的方法通常至少提供以下益处，即：

·在如ISOBMFF等传输数据格式中的顶层中对预选进行统一表示；

·用于媒体播放器API的统一数据结构；

·不需要媒体播放器中的格式特定实施方式；以及

·实施者的工作量减少、测试工作量减少、可靠性提高以及行业接受快。

图2是示出了根据本发明的实施例的处理媒体流的系统的示例性实施方式的示意图。特别地，可以看到图2示意性地示出了这种媒体处理系统的可能的整体工作流程。

特别地，如图2所示，与关于图1A和图1B描述的媒体播放器用例一样，(自动)清单生成器2500可能也需要访问传入的媒体数据中包含的体验(呈现)。通常，由于可能必须在这样的处理系统中处理大量使用的编解码器，因此这些设备2500将优选地在编解码器无关的元数据上操作。此外，由于数据侧路径通常对于稳健操作而言也是不期望的，因此要使用的任何元数据结构都可能需要是全面的并提供应显示在清单(或清单文件)中的所有细节。

在图2所示的示例系统工作流程中，媒体(例如，音频和/或视频)编码器2100-A、2100-B和2100-C通常生成不同格式(例如，MP3、MP4、AC-4等)的编码的媒体流2200-A、2200-B和2200-C。然后，将这些基本流2200-A–C馈送到打包器2300-A、2300-B和2300-C，以封装成统一的传输格式，如ISOBMFF。

随后，可以将这些ISOBMFF文件或流2400-A、2400-B和2400-C中的每一个分发到相应的媒体播放器(未示出)，但是也可以分发到清单生成器2500，用于生成对应的清单文件2600作为输出。这种文件(例如，MPEG DASH格式文件或HLS格式文件)通常可以用如XML(可扩展标记语言)等机器和/或人类可读的格式表示。

现在，参考图3A，提供了图示了打包器(例如，打包器2300-A–C)的可能实施方式的示例图。

特别地，如关于图3A所示，由(二进制)媒体头信息或元数据3210和(二进制)编码/压缩的(原始)媒体信息/数据3220构成的传入的媒体基本流3200(例如，图2中例示的基本流2400-A–C)随后被分组成容器格式输出文件或流(例如，ISOBMFF)3400。

更特别地，在过程中，打包器3300通常以未改变的方式将传入的流数据3200传递到对应的输出表示3420中。打包器3300的合适的内部装置(或组件)3310可以读取二进制头信息/元数据3210，以便生成用于媒体输出3400的对应描述性元数据信息(但为字节格式)3410。打包器3300的这种装置(或组件)3310可以例如是解码器特定信息(DSI)生成器或任何其他合适的组件。数据3410稍后可以由相应媒体播放器(例如，如图1A所示的媒体播放器1200)使用，以选择适当的解码器(例如，如图1A所示的解码器1220)。在ISOBMFF的示例性用例中，描述性字节数据3410可以尤其包括解码器特定信息(简称DST)，而且还可以包括关于基本流的某些通用注释。如先前所说明的，当封装在如ISOBMFF等某些文件格式中时，基本流可以被称为轨道。

与图3A的实施方式相比，图3B示意性地图示了根据本发明的实施例的打包器的可能示例实施方式。与上文类似，除非另有指示，否则图3B中相同或相似的附图标记可以指示图3A中相同或相似的元素，使得为简洁起见，可以省略对其的重复描述。

更特别地，如关于图3B所示，打包器3301现在可以包括另外的(内部)装置/组件3321(在一些可能的情况下，其可以被称为预选数据生成器)，也向装置/组件提供传入的媒体流3201的二进制头信息3211。在一些可能的情况下，装置3321的功能也可以被实施为作为现有(内部)装置3311的一部分的附加功能。然而，如图3B中清楚所示，在这种情况下，生成附加的字节格式指定的数据结构3451，并将其嵌入到输出流3400中。值得注意的是，如以上所说明的，数据结构3451通常携带(编解码器无关的)预选相关信息(例如，描述性信息和/或处理相关信息)和媒体格式无关表示。

图4A是清单生成器的示例实施方式的示意图。

特别地，如关于图4A所示，清单生成器4500通常读取输入文件或流4400(例如，ISOBMFF文件)，以生成对应的清单文件4600所需的信息。这样的所需数据可以包括关于媒体流的信息4620，如适当的媒体类型(有时也称为MIME类型)、编解码器属性以及媒体特定性质。所有信息可以独立于每个媒体文件或流、基于可从容器级元数据结构4410获得的数据来生成。

除了与这些单独的媒体文件或流相关联的信息之外，还可能需要生成预选相关信息4610。在传统技术中，所需信息可能通常需要通过例如某种带外侧数据路径(现在如图4A所示)来提供或通过解析封装的基本流的二进制头数据来提供。

特别是在后一种情况下，对应的装置/组件4510(在一些可能的情况下，其可以被称为预选数据生成器或使用任何其他合适的术语)因此不仅是编解码器格式相关的，而且需要进行计算上昂贵的二进制数据解析，并且根据所使用的媒体格式，需要关于如何从可用内容组件元数据生成对应预选的附加格式相关知识。在某些情况下，步骤附加地需要联合读取多个媒体文件或流的有效载荷，这使得过程变得困难且容易出错。在一些可能的情况下，如技术人员将理解和认识到的，清单生成器4500还可以包括可以负责执行如媒体特定信令(例如，“适配集(AdaptationSet)”)等操作的另一个(内部)装置/组件4520。

为了解决关于图4A所讨论的一些或全部问题，图4B示意性地图示了根据本公开的实施例的清单生成器的示例性实施方式。值得注意的是，如先前所指示的，如上文所指示的，除非另有指示，否则图4B中相同或相似的附图标记可以指示图4A中相同或相似的元素，使得为简洁起见，可以省略对其的重复描述。

特别地，如关于图4B所示，利用所提出的预选相关数据结构4451，不仅可以避免对编解码器特定二进制解析器的需要，而且清单生成器4501可以依赖于来自传入流4401的所提出数据结构4451的预生成信息。如技术人员可以理解和认识到的，数据结构4451已经与期望的输出数据4611对准。因此，本文提出的清单生成器4501通常只需要对将字节信息转换为清单文件的表示(例如，XML)作出响应的预选数据转换器4531，而不是图4A所示的预选数据生成器4510(它是编解码器特定的)。

概括地说，如技术人员还将理解和认识到的，以上提出的用于清单生成器的用例的方法通常至少提供以下益处，即：

·清单生成器中预选数据处理的格式无关实施方式；

·字节格式的实施方式只避免了对二进制数据进行计算上更昂贵的操作；

·由于与现有功能高度重叠，在打包器中实施预选元数据的开销较低；

·所有媒体格式的清单生成器操作相同；以及

·实施者的工作量减少、测试工作量减少、可靠性提高以及行业接受快。

如以上和本公开的其他地方所说明的，本公开中提出的技术可以应用于音频流以及视频流(或其组合)的处理。具体地，当涉及视频处理时，为了进一步理解本发明，可能值得更详细地讨论一些潜在的用例。

一个可能的用例可以包括帧率/分辨率可缩放视频处理。更具体地说，一些可能的MPEG编解码器(例如，在如ISO/IEC 23090-3(“MPEG-I第3部分”)中定义的通用视频编解码(VCC)的上下文中，也称为ITU-T H.266等)可以提供从同一流创建多个显示帧率的选项。例如，一个流可以被解码成50Hz或者以更高的复杂性为代价，也可以被解码成100Hz。如技术人员可以理解和认识到的，将一个流解码成任一帧率的可能性可以用本公开中提出的预选概念来覆盖。在相关的用例中，一个流将仅携带50Hz预选的比特，而第二个流将提供100Hz预选的附加比特——使得为了解码成100Hz，100Hz预选将引用两个流。类似地，可以缩放图像的分辨率，而不是缩放帧率，因此以上说明也适用于多分辨率流。

另一个可设想的示例用例可以涉及联合SDR/HDR流。特定用例可以涉及高动态范围(HDR)的概念，与标准动态范围(SDR)中的传统视频相比，高动态范围提供更高的对比度并且有时还提供更宽的色域(WCG)。如提供向后兼容增强层的系统等系统可以用于创建可以被解码用于SDR显示器或具有HDR能力的显示器的流。从相同或多个流中得到不同体验的可能性可以通过与不同体验相关的预选来用信号传输。

又另一个视频相关用例可以涉及画中画(简称pip)技术。具体地，在用例中，视频组成的一部分可以由不同的内容代替(例如，通过使用VCC中的“子画面”概念或任何其他合适的方式)。示例是新闻节目，其中，部分显示被手语翻译员为听力受损受众解释内容的视频捕获所代替。这是另一个示例，其中，最终体验由不同的部分构成，其中，部分是通过预选(集体地)选择的。

在讨论了以上可能的用例后，现在参考图5至图8，其中，示意性地说明了图示根据本发明的实施例的处理媒体流的方法的示例的流程图。

特别地，从广义的角度来看，图5和图6的方法流处理方法可以被视为处理(用信号传输)与传输格式文件(例如，ISOBMFF)中的预选相关的信息的两种可能的解决方案，根据各种实施方式和/或情况，两种可能的解决方案可以一起或替代性地实施。另一方面，图7和图8的方法流处理方法可以被视为分别对应于如以上参考图3B和图4B所述的打包器和清单生成器的可能用例。

更特别地，如图5所示的方法5000可以通过接收根据预定义传输格式分组的媒体流从步骤S5100开始。如先前所说明的，媒体流可以是音频流、视频流或其组合，如由如参考图3B所述的打包器3301准备的媒体流3401。方法5000可以在用户侧执行或者换句话说，在用户(解码)侧环境中执行，根据各种实施方式，环境可以包括但不限于TV、条形音箱、网络浏览器、媒体播放、插件等。预定义传输格式可以是由ISO通过ISO/IEC 14496-12MPEG-4第12部分指定的基本媒体文件格式(ISOBMFF)或者呈任何其他合适的(传输)格式。具体地，分组的媒体流可以包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联。如上所述，贯穿本公开使用的术语“盒”不应被理解为仅限于这样的特定术语。相反，术语“盒”通常应理解为可以用作分组的媒体流中媒体数据的占位符并且因此可以通过使用其他合适的术语来指代的任何合适的数据结构。进一步地，根据各种实施方式和/或要求，多个盒可以具有相同或不同的级别(或位置)、可以是嵌套的(子盒与父盒)等，如技术人员将理解和认识到的。除了其他可能性之外，多个盒可以包括引用(或者换句话说，指示)指示媒体流的媒体(内容)组件的相应轨道的一个或多个轨道盒。从广义上讲，媒体(内容)组件通常可以指媒体内容的单个/单独连续组件(并且，通常还可以与如音频、视频、文本等对应的(分配的)媒体内容组件类型相关联)。用于理解“媒体(内容)组件”的概念的示例可以如例如在MPEG-DASH(ISO/IEC 23009-1)中定义/描述的那样找到。

随后，在步骤S5200中，方法5000可以包括确定媒体流是否包括指示预选的预定义类型的预选相关盒，其中，预选可以与对用户的媒体呈现相对应。如上所述，术语/短语“预选”通常用于指代(媒体流的)旨在(例如，由用户侧设备)共同使用并且更特别是通常表示可以由最终用户选择用于同时解码/呈现的媒体呈现的一个版本的一组媒体内容组件。当然，如技术人员将理解和认识到的，在一些其他可能的技术上下文中，术语“预选”也可以通过使用其他合适的(相当的)术语而被已知(或被提及)，如(但不限于)如在例如ETSITS103190-2中所描述的“呈现”或如在例如ISO/IEC 23008-3等中所描述的“预设”。因此，预选相关盒可以是媒体流中的多个盒当中具有特定预定义(或预定)类型的特定盒。如技术人员将理解和认识到的，这种指示预选的特定类型可以通过使用任何合适的手段预先预定义(或预定)。

如果在步骤S5300中确定媒体流包括预选相关盒，则方法5000还可以进一步包括：在步骤S5310处，分析与预选相关盒相对应的元数据信息，元数据信息指示预选的特性；在步骤S5320处，基于元数据信息标识分组的媒体流中贡献于预选的一个或多个轨道；以及最后在步骤S5330处，根据给定的预选提供一个或多个轨道用于下游处理。如技术人员将理解和认识到的，根据各种实施方式，以上说明的元数据信息可以(直接)包括在媒体流(或者更特别地，(分组的)媒体流的多个盒)中或者可以通过使用任何合适的手段(间接)从媒体流中得到。例如，元数据信息可以被包括在头盒中，头盒可以以某种方式与预选相关盒相关联或链接至预选相关盒(例如，作为其子盒)。如上所述，预选通常是指旨在例如由一个或多个合适的下游设备(例如，媒体解码器、媒体播放器等)共同使用的一组媒体内容组件。在一些可能的情况下，下游设备还可以简称为“汇点”。因此，根据各种实施方式和/或要求，下游处理可以包括但不限于对那些有贡献的轨道进行多路复用(或再多路复用)、排序、合并、解码或渲染，如以上所描述的。

如以上那样配置，所提出的方法5000通常可以提供一种高效而灵活的方式来确定/标识媒体流内被配置为贡献于特定预选的轨道，并随后用信号传输轨道，从而使得能够(例如，由一个或多个合适的下游设备)对这种有贡献的轨道进行进一步的下游处理。因此，从广义上讲，所提出的方法可以被视为提供以统一的方式在传输层文件(例如，ISOBMFF)中用信号传输指示预选(以及可能还有对预选的处理)的信息的可能性和能力，这在各种用例或场景中可以被认为是有益的，如上面参考图1A、2、3B和4B详细描述的那些。

值得注意的是，如技术人员可以理解和认识到的，国际标准化组织(ISO)和国际电子委员会(IEC)已经联合发布了用于实施某种技术的功能性文件，功能性文件的标题为：ISO/IEC 14496-12，信息技术-视听对象的编解码-第12部分：ISO基本媒体文件格式(2020年发布的最新版本并且可从https://www.iso.org/standard/74428.html获得)。文件最初由动画专家群组(MPEG)起草，指定了ISO基本媒体文件格式(或简称ISOBMFF)，其是构成其他更具体文件格式的基础的通用格式。

如已在上文说明的，ISOBMFF内的媒体信息通常是通过使用称为“盒”的构建块以分层、面向对象的方式结构化的。这些数据结构由唯一的类型标识符和长度定义并且可以嵌套或连接以形成整个文件结构。

文件格式内的单独的媒体数据(如单个视频或音频组件)可以称为“轨道”，轨道表示为由媒体编码器预先生成的基本流。

文件格式包含媒体数据的定时序列(如视听呈现)的定时、结构和媒体信息。ISO/IEC 14496-12已经包含了若干种描述媒体组件的性质的手段。此类描述性元素或专用盒被分配给电影头(‘moov’)盒内的单独的轨道和子轨道。这样的可用盒包括“扩展语言标签”(‘elng’)盒或种类(‘kind’)盒。

为了用信号传输轨道或子轨道的组合的性质，如上面参考图5详细说明的，作为一些可能的实施方式，本公开通常建议提供新的数据结构，以与例如电影头(或任何其他合适的盒)内的轨道的定义并行使用。然而，需要注意的是，虽然将这些所谓的预选中的每个预选与它们的组成(有贡献的)媒体轨道联系起来是本提案的一部分，但应尽可能重复使用现有的用于用信号传输它们相应性质的手段。

例如，在一些可能的实施方式中，可以引入两个新盒，其中，一个容器盒可以被认为形成DASH预选元素的对应物并且将所有描述性和结构性元数据作为子盒；而另一个盒可以是采用结构元数据来创建预选的(强制性)头盒。当然，如以上详细说明的，如果需要，也可以包括任何进一步合适的盒(例如，处理相关盒)。在这种情况下，可以例如通过利用每个轨道的轨道头中的唯一轨道标识符(ID)分配来实现将预选与轨道链接。由于预选通常需要由外部应用程序引用，因此应相应地分配唯一标识符。特别地，预选标识符在整个捆绑包的范围内应是唯一的，即在可用于媒体呈现的所有ISOBMFF文件中是唯一的。此外，由于编码的媒体格式可以使用不同的分配，因此可能需要相应地定义和/或设置(多个)另外的元素(例如，使用对应的标签来映射在媒体格式中使用的相应标识符等)。

鉴于此，为了实施上文关于图5所述的所提出方法，特别是为了支持ISOBMFF的上下文中的预选，在一些可能的实施方式中，总体上可以建议通过以下文本来修改(创建或替换)ISO 14496-12第8节：

3.1术语和定义

3.1.x预选

表示可以由用户选择用于同时解码/呈现的媒体呈现的一个版本的一组一个或多个媒体组件。

3.1.y捆绑包

不一定包含在单个ISOBMFF文件中的提供媒体呈现的整体可获得体验的一组多个轨道。

8.18预选结构

8.18.1引言

8.18.2向后兼容性

8.18.3预选盒

定义

盒类型：‘pres’

容器：电影盒(‘moov’)、电影片段盒(‘moof’)

强制性：否

数量：零或更多

这是用于单一预选的容器盒。预选提供了一种特定最终用户体验的描述和技术组成。媒体呈现中的每个可用预选都应有一个预选盒。

强制性预选头盒包含对构成预选的所有轨道的必要引用。附加地，盒还提供了可用于选择过程的标识符。

预选的性质应使用附加盒(如扩展语言盒或种类盒)进行指示。在多个预选共享相同公共性质的情况下，内容作者应通过标签盒提供适当的文本描述。

语法

aligned(8)class PreselectionBox extends Box(‘pres’){

}

8.18.3预选头盒

定义

盒类型：‘prhd’

容器：预选盒(‘pres’)

强制性：是

数量：正好一个

盒指定单一预选的特性。一个预选中包含正好一个预选头盒。

preselection_id和preselection_tag分别向应用程序或媒体编解码器提供预选的标识。这些可以用于选择呈现。

在没有提供其他区分的情况下，应使用selection_priority来指导任何自动选择过程。应避免评估预选元素的顺序以确定其优先级。

语法

语义

version是指定盒的版本的整数(在本说明书中为0)。

flags是具有标志的24位整数；尚未定义任何值。

preselection_id是向外部应用程序声明唯一标识符的整数。

preselection_tag是向所使用媒体编解码器声明标识符的整数。

selection_priority是声明在不可能如通过媒体语言进行其他区分的情况下预选的优先级的整数。数字越低表示优先级越高。

n_tracks是声明形成预选所需的轨道数的整数。

track_ID是唯一标识每个轨道的整数数组。对于预选，需要通过track_ID值引用的数组中所有轨道的列表。

8.18.4标签和组标签盒

定义

盒类型：‘labl’

容器：预选盒(‘pres’)和可选的其他容器

强制性：否

数量：零或更多

盒可以用于用文本描述对包含结构进行注释。描述旨在以某种形式的文本显示呈现给用户，而不是旨在用于任何自动选择过程。

多个盒可以用于提供不同语言的文本描述。

语法

语义

label_id是包含可由外部应用程序使用的标识符的整数。

language是以NULL结尾的C字符串，其包含符合RFC 4646(BCP 47)的语言标记字符串，如“en-US”、“fr-FR”或“zh-CN”。

label是以NULL结尾的C字符串，其包含文本描述。

因此，可以进一步建议通过如下所示以灰色突出显示的行来更新表1(在同一文件ISO 14496-12中)。

表1-盒类型、结构和交叉引用(信息性(Informative))

/>

附加地，可以进一步建议将新的预选头盒作为容器引入到一些已经存在的盒中。例如，可以建议修改现有的盒定义(在同一文件ISO 14496-12中)如下：

8.4.6扩展语言标签

8.4.6.1定义

盒类型：‘elng’

容器：媒体盒(‘mdia’)、预选头盒(‘prhd’)

强制性：否

数量：零或一

[…]

如已经所描述的，以上提出的修改应被理解为只是一个可能的实施示例，但肯定不是唯一的示例。尽管上面已经给出/提出了与预选有关的所提出盒的一些具体名称，但这些盒也可以用不同的名称命名。同样，如技术人员将理解和认识到的，即使以上提出的预选相关盒似乎嵌套在‘moov’盒下，但这些盒当然也可以在其他地方实施。在一个可能的示例中(但肯定不是任何类型的限制)，这些预选相关盒可以与ISOBMFF中的所谓‘EntityToGroupBox’或任何其他合适的地方相关联(例如，嵌套在其下面)。类似地，如技术人员将理解和认识到的，随着标准的进展和/或发展，上述(多个)示例表(或其中的元素)以及示例章节可能具有不同的名称和/或(分层)位置。在一些可能的情况下，上述(多个)示例性表(或其部分)和/或章节甚至可能部分或完全过时(陈旧)，使得相应的预选相关信息可能必须在其他地方定义，这在那时将被认为是合适的。

现在参考图6，其示意性地图示了根据本发明的实施例的处理媒体流的方法6000的另一可能示例的流程图。如上所述，图6的方法通常可以被视为如上所述的图5的方法的替代方案(或者在一些可能的情况下，作为附加方案)。

特别地，方法6000可以通过接收根据预定义传输格式分组的媒体流从步骤S6100开始。与上述类似，媒体流可以是音频流、视频流或其组合，如由如参考图3B所述的打包器3301准备的媒体流3401。方法6000也可以在用户侧执行或者换句话说，在用户(解码)侧环境中执行，根据各种实施方式，环境可以包括但不限于TV、条形音箱、网络浏览器、媒体播放、插件等。预定义传输格式可以是由ISO通过ISO/IEC 14496-12MPEG-4第12部分指定的基本媒体文件格式(或简称ISOBMFF)或者也可以呈任何其他合适的(传输)格式。具体地，分组的媒体流可以包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联。除了其他可能性之外，多个盒可以包括引用(或者换句话说，指示)指示媒体流的媒体(内容)组件的相应轨道的一个或多个轨道盒。

随后，在步骤S6200中，方法6000可以包括检查(例如，访问、循环遍历等)媒体流中的轨道盒，以确定媒体流中存在的预选的完全(或完整/总)集合。特别地，预选的完全集合的确定可以包括：确定一组由轨道组标识符和轨道组类型构成的唯一对；以及通过相应的轨道组标识符来对预选进行寻址。如上所述，每个预选与相应的轨道组相关联，相应的轨道组本身又由对应轨道组标识符和对应轨道组类型构成的相应对来标识。因此，预选可以通过与其相关联/链接的相应轨道组标识符来寻址(或标识)。

方法6000还可以进一步包括在步骤S6300处在预选的完全集合当中选择预选。特别地，预选可以基于包括在具有相同轨道组标识符的轨道组盒中的相应预选的属性(例如，表示为元数据或其他合适形式)来选择。

随后，在步骤S6400处，方法6000可以包括确定贡献于所选择的预选的一组一个或多个轨道盒。特别地，贡献于(相同)预选的一组一个或多个轨道盒可以通过具有相同轨道组标识符的(相应)轨道组盒的存在来标识。

另外，在步骤S6500处，方法6000可以包括将如以上所确定的一组一个或多个轨道盒的每个成员(元素)中引用的轨道确定为贡献于预选的一个或多个轨道。

最后，在步骤S6600处，方法6000可以包括根据预选提供一个或多个轨道用于下游处理。如上所述，预选通常是指旨在例如由如媒体解码器、媒体播放器等一个或多个合适的下游设备(或者在一些可能的情况下，称为汇点)共同使用的一组媒体内容组件。因此，根据各种实施方式和/或要求，下游处理可以包括但不限于对那些有贡献的轨道进行多路复用(或再多路复用)、排序、合并、解码或渲染，如将在下文中更详细地描述的。

如以上那样配置，所提出的方法6000通常可以提供一种高效而灵活的方式来确定/标识媒体流内被配置为贡献于特定预选的轨道，并随后用信号传输轨道，从而使得能够(例如，由一个或多个合适的下游设备)对这种有贡献的轨道进行进一步的下游处理。特别地，要注意的是，如以上在第一方面中提出的方法通常寻求在预选相关盒中提供被配置为贡献于特定预选的(所有)轨道的相关信息，从而使得能够高效地对所有有贡献的轨道进行索引(或标识)。在这个意义上，如图5的上述方法5000中所描述的对轨道的这种索引可以被视为某种正向(直接)索引。相比之下，在图6所示的方法6000中，贡献于特定预选的轨道可以由轨道组类型和轨道组标识符构成的对联合确定。更具体地，具有(例如，包含)带有特定(例如，预定义或预定)轨道组类型的轨道组盒的轨道通常可以指示轨道贡献于预选。进一步地，具有相同轨道组标识符的轨道通常可以指示那些轨道属于(贡献于)相同预选。在这个意义上，与图5中提出的相比，参考图6描述的对轨道的这种索引可以被视为某种反向索引。在任何情况下，类似于图5，图6中提出的方法6000也可以提供以统一的方式在传输层文件(例如，ISOBMFF)中用信号传输指示预选(以及可能还有，对预选的处理)的信息的可能性和能力，这在各种用例或场景中可以被认为是有益的，如上面参考图1A、2、3B和4B详细描述的那些。

值得注意的是，与图5类似，为了实施上文关于图6所述的所提出方法6000，特别是为了支持ISOBMFF的上下文中的预选，在一些可能的实施方式中，总体上可以建议通过以下文本来修改(创建或替换)ISO 14496-12(作为参考图5提出的文本的替代或补充)：

3.1术语和定义

3.1.x预选

表示可以由用户选择用于同时解码/呈现的媒体呈现的一个版本的一组一个或多个媒体组件。

3.1.y媒体组件

总体上可以建议通过以下加下划线的行来修改ISO 14496-12第8.3.4.3节：

track_group_type指示grouping_type并应设置为以下值之一或注册的值或衍生规范或注册中的值：

‘msrc’指示轨道属于多源呈现。在8.3.4.4.1中指定。

‘ster’指示轨道是适合在立体显示器上回放的立体象对的左视图或右视图。在02中指定。

‘pres’指示轨道贡献于预选。在8.3.4.4.3中指定。

track_group_id和track_group_type对标识文件内的轨道组。包含具有相同track_group_id和track_group_type值的特定TrackGroupTypeBox的轨道属于相同轨道组。

总体上可以建议通过以下行来修改(或创建)ISO 14496-12第8.3.4.4.3节：

8.3.4.1.3预选盒

8.3.4.1.3.1定义

track_group_type等于‘pres’的TrackGroupTypeBox指示轨道贡献于预选。

在PreselectionGroupBox内具有相同track_group_id值的轨道是同一预选的一部分。

预选可以通过语言、种类或媒体特定属性(如音频渲染指示或通道布局)进行限定。在预选盒中用信号传输的属性应优先于在有贡献的轨道中用信号传输的属性。

所有唯一限定预选的属性应存在于预选的至少一个预选盒中。如果存在于预选的多于一个预选盒中，则盒应相同。

注意：预选仅对相同媒体类型的轨道进行分组。

不包含至少一个预选所需的所有媒体组件的轨道在其轨道头盒中的track_in_movie标志应设置为‘0’。这防止不了解预选盒的播放器播放会导致不完整体验的轨道。

注意：良好的做法是将一个轨道的track_in_movie标志设置为一。这意味着轨道提供了至少一种完整的体验。

8.3.4.1.3.2语法

8.3.4.1.3.3语义

selection_priority是声明在不可能如通过媒体语言进行其他区分的情况下预选的优先级的整数。数字越低表示优先级越高。

order根据[MPEG-DASH]从以下枚举集合中指定预选内适配集中的表示的一致性规则：

0：未定义

1：按时间排序

2：完全排序

8.3.4.1.3.4预选信息盒

8.3.4.1.3.4.1定义

盒类型：‘prsi’

容器：预选盒

强制性：是

数量：正好一个

盒汇集了关于预选的所有语义信息。

8.3.4.1.3.4.2语法

8.3.4.1.3.4.3语义

8.3.4.1.3.4.5预选处理盒

8.3.4.1.3.4.5.1定义

盒类型：‘prsp’

容器：预选盒

强制性：是

数量：正好一个

盒包含关于应如何处理贡献于预选的轨道的信息。媒体类型特定盒可以用于描述进一步的处理。

8.3.4.1.3.4.5.2语法

8.3.4.1.3.4.5.3语义

preselection_tag是包含标签的标识符的整数。具有相同值的标签属于一个标签组。默认值为零指示标签不属于任何标签组。

track_order定义了应向解码器提供轨道的顺序。track_order较低的轨道应首先提供给解码器。如果多个轨道具有相同的track_order值，则顺序不相关。

sample_merge_flag：如果标志被设置为‘1’，则轨道的每个样本都应附加到具有下一个较低track_order值的轨道的样本上。如果被设置为‘0’，则轨道应提供给单独的解码器实例。

可以进一步建议创建(或修改或替换)ISO 14496-12第8.18.4节如下：

8.18.4标签和组标签盒

定义

盒类型：‘labl’

容器：轨道中的容器用户数据盒(‘udta’)、预选盒(‘pres’)

强制性：否

数量：零或更多

标签提供了对ISOBMFF文件中的数据结构进行注释的能力，以提供对标签所被分配于的元素的上下文的描述。这样的标签可以例如由回放客户端用于向用户提供选择选项。标签还可以用于另一上下文中的简单注释。

另外，可以在更高级别上添加GroupLabel元素，以便提供组中收集的标签的概要或标题。示例可以是其在菜单中使用，以便提供标签的菜单的上下文。

可以使用多个标签来提供文本描述。为了向多语言受众注释预选，可以以与预选的语言不同的语言提供注释。

如果is_group_label被设置为不同于零的值，则盒中的标签文本将指定具有相同label_id的所有标签的概要或标题。这可以用作包含标签集合的选择菜单上的标题。

语法

语义

is_group_label指定标签是否包含标签组的概要标签。

label_id是包含标签的标识符的整数。具有相同值的标签属于一个标签组。默认值为零指示标签不属于任何标签组。

language是以NULL结尾的C字符串，其包含符合RFC 4646(BCP 47)的语言标记字符串，如“en-US”、“fr-FR”或“zh-CN”，语言是标签的目标语言。

label是以NULL结尾的C字符串，其包含文本描述。

可以进一步建议创建(或修改或替换)ISO 14496-12第8.18.4节如下：

8.18.5音频渲染指示盒

定义

盒类型：‘ardi’

容器：预选盒(‘pres’)

强制性：否

数量：零或一

音频渲染指示盒包含用于优选再现通道布局的提示。

语法

语义

audio_rendering_indication包含根据表2编解码的优选再现通道布局的提示。

表1-音频渲染指示的编解码

audio_rendering_indication	描述
		0	未给出再现通道布局的偏好
1	优选的再现通道布局是立体的
		2	优选的再现通道布局是二维的(例如5.1多通道)
3	优选的再现通道布局是三维的
		4	将内容预先渲染以供耳机使用
5至255	保留以供将来使用

值得注意的是，如技术人员将理解和认识到的，基于如以上说明的新提出的预选相关盒，其可以被进一步建议到参考图5描述的上表1，使得为了简洁起见，不重复其细节。

附加地，可以进一步建议将新的预选头盒作为容器引入到一些已经存在的盒中。例如，可以建议通过以下划线或删去的形式突出显示的文本来修改现有的盒定义：

8.4.6扩展语言标签

8.4.6.1定义

盒类型：‘elng’

容器：媒体盒(‘mdia’)、预选盒(‘pres’)

强制性：否

数量：零或一

[…]

8.10.1用户数据盒

8.10.4.1定义

盒类型：‘udta’

容器：电影盒、轨道盒、电影片段盒或轨道片段盒或预选盒

强制性：否

数量：零或一

[…]

8.10.4轨道种类

8.10.4.1定义

盒类型：‘种类’

容器：轨道中的容器用户数据盒(‘udta’)或预选盒(‘pres’)

强制性：否

数量：零或一

12.2.4通道布局

8.10.4.1定义

盒类型：‘chnl’

容器：音频样本输入或预选盒

强制性：否

数量：零或一

[…]

同样，如已经所描述的，参考图6的方法描述的以上提出的修改应被理解为只是一个可能的实施示例，但肯定不是唯一的示例。尽管上面已经给出/提出了与预选有关的所提出盒的一些具体名称，但这些方盒也可以用不同的名称命名。同样，如技术人员将理解和认识到的，即使以上提出的预选相关盒似乎与某个特定盒相关联，但这些盒当然可以在其他地方实施。

现在参考图7，其示意性地图示了根据本发明的实施例的处理媒体流的方法7000的示例流程图。与上述类似，媒体流可以是音频流、视频流或其组合。值得注意的是，方法7000可以在编码侧环境(例如，媒体编码器)上执行。在一些场景(或用例)中，这种编码器也可以被称为(媒体)打包器(即，被配置为对媒体输入进行打包/分组)，如例示为图2中的2300-A–C或图3B中的3301。

特别地，方法7000可以包括在步骤S7100处根据预定义传输格式封装一个或多个基本流以生成分组的媒体流，其中，分组的媒体流包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联。类似于上述，预定义传输格式可以是由ISO通过ISO/IEC 14496-12MPEG-4第12部分指定的基本媒体文件格式(或简称ISOBMFF)或者呈任何其他合适的(传输)格式。

更具体地，封装一个或多个基本流的步骤S7100可以包括：在步骤S7110处，根据传输格式对一个或多个基本流的媒体数据进行分组，以生成引用(或指示)一个或多个基本流的相应轨道的一个或多个轨道盒；以及在步骤S7120处，基于一个或多个基本流的头信息生成预定义类型的一个或多个预选相关盒，其中，一个或多个预选相关盒中的每个预选相关盒指示与对用户的媒体呈现相对应的相应预选。

如以上所述的那样配置，所提出的方法通常可以提供用于根据预定义传输格式(例如，ISOBMFF)对媒体输入(例如，基本流)进行分组的高效而灵活的方式。更特别地，通过在分组的媒体流旁边生成并包括一个或多个预选相关盒(每个预选相关盒指示相应的预选)，所提出的方法还可以使得能够以与编解码器无关的统一方式来表示预选，从而进一步使得能够对贡献于对应预选的轨道进行适当的下游处理(例如，根据前面第一方面和第二方面中提出的方法)。另外，如上所述，预选的这种统一表示也可以实现清单(例如，MPEG基于HTTP的动态自适应流式传输DASH格式文件或HTTP实时流HLS格式文件)生成器中预选数据处理的格式无关实施方式，从而避免对二进制数据的计算上更昂贵的操作的需要，并且同时减少了实施工作量并提高了可靠性。

图8是图示了根据本发明的实施例的处理媒体流的方法8000的又另一示例的示意性流程图。媒体流可以是音频流、视频流或其组合。方法8000可以由清单生成器(例如，如例示为图2中的2500或图4B中的4501的清单生成器)执行。

特别地，方法8000可以包括在步骤S8100处接收根据预定义传输格式分组的媒体流。更特别地，分组的媒体流可以包括多个分层盒，多个分层盒各自与相应的盒类型标识符相关联，其中，多个盒可以包括一个或多个轨道盒以及预定义类型的一个或多个预选相关盒，一个或多个轨道盒引用(例如，指示)指示媒体流的媒体组件的相应轨道，并且其中，每个预选相关盒指示与对用户的媒体呈现相对应的相应预选。

进一步地，方法8000还可以包括在步骤S8200处基于一个或多个预选相关盒来生成清单文件。

如以上所述的那样配置，所提出的方法通常可以通过还考虑预选相关信息(例如，描述性信息和/或处理相关信息)来提供用于生成清单文件的高效而灵活的方式。更特别地，除了与(多个)媒体流相关的信息之外，所提出的方法可以进一步包括与预选相关联的信息。预选相关信息可以包括但不限于元数据信息、处理信息等。与传统(清单生成)技术相比，所提出的用于生成清单文件的方法通常可以为预选相关数据处理提供格式无关的实施方式，从而避免计算上更昂贵的操作(例如，在传统技术中必须对二进制数据执行的操作)，减少实施和/或测试工作量并提高可靠性。

总之，上面参考附图提出和描述的方法总体上涉及用于通过考虑“预选”来处理媒体流的技术。这样的“预选”感知技术可以实现各种潜在的用例。如上所述，一个可能的用例可以包括在若干种语言(字幕)当中进行选择。

另一个可能的示例用例可以涉及叙述重要性。具体地，为了尽可能满足听力障碍者的需求或者尽可能使音频作品适配不同的听力条件，可能需要如对话增强等技术，一般来说，技术可以用于提高对话水平与背景水平的比率。作为这种对话增强技术的扩展，已经提出了额外的措施来选择性地和逐步地从作品中删除整个音频元素，以提高对话的可懂度。在这种情况下，可以通过“仅对话”将“完整材料”的连续体映射为多个预选并使用本公开的方法。

进一步可设想的用例可以涉及受众定向。更具体地说，有时可能关注的是针对语言之外的特定受众。作为示例(但不是任何类型的限制)，可以提供分别对任何一支球队都有偏见的两名体育比赛评论员。在这种情况下，不同的预选可以包括或引用不同的体育比赛评论员。

又进一步的预选相关用例可以涉及回放环境适配。也就是说，与TV的内置扬声器或耳机版本相比，内容创作者可以生成针对不同再现环境(如家庭影院设置)的专用版本。在这种情况下，不同的预选可以涉及用于不同再现环境的不同音频。

最后，本发明同样地涉及用于执行在整个公开中描述的方法和技术的(多个)装置。图9总体上示出了这种装置9000的示例。特别地，装置9000包括处理器9100和耦接到处理器9100的存储器9200。存储器9200可以存储用于处理器9100的指令。根据各种用例和/或实施方式，处理器9100还可以尤其接收输入数据(例如，媒体输入、分组的媒体流等)。根据各种用例和/或实施方式，处理器9100可以适于执行贯穿本公开描述的方法/技术(例如，如上所述的方法5000、6000、7000和8000)并且对应地生成输出数据9400(例如，分组的媒体流、清单文件等)。例如，根据本发明的实施例，装置9000可以根据情况实施打包器，打包器被配置为执行如上面关于图7所说明的处理媒体流的方法7000；或者实施清单生成器，清单生成器被配置为执行上面关于图8所说明的处理媒体流的方法8000。

解释

实施上文描述的技术的计算设备可以具有以下示例架构。其他架构也是可能的，包括具有更多或更少组件的架构。在一些实施方式中，示例架构包括一个或多个处理器(例如，双核处理器)、一个或多个输出设备(例如，LCD)、一个或多个网络接口、一个或多个输入设备(例如，鼠标、键盘、触敏显示器)和一个或多个计算机可读介质(例如，RAM、ROM、SDRAM、硬盘、光盘、闪速存储器等)。这些组件可以经由一个或多个通信信道(例如，总线)交换通信和数据，这些通信信道可以利用各种硬件和软件来促进数据和控制信号在组件之间的传送。

术语“计算机可读介质”是指参与向处理器提供指令以用于执行的介质，包括而不限于非易失性介质(例如，光碟或磁碟)、易失性介质(例如，存储器)和传输介质。传输介质包括而不限于同轴电缆、铜线和光纤。

计算机可读介质可以进一步包括操作系统(例如，操作系统)、网络通信模块、音频接口管理器、音频处理管理器和实时内容分发器。操作系统可以是多用户、多处理、多任务、多线程、实时等。操作系统执行基本任务，包括但不限于：标识来自网络接口和/或设备的输入并向网络接口和/或设备提供输出；记录并管理计算机可读介质(例如，存储器或存储设备)上的文件和目录；控制外围设备；以及管理一个或多个通信信道上的业务。网络通信模块包括用于建立并维护网络连接的各种组件(例如，用于实施如TCP/IP、HTTP等通信协议的软件)。

架构可以在并行处理或对等基础设施中实施，或者在具有一个或多个处理器的单个设备上实施。软件可以包括多个软件组件或可以是单个代码体。

所描述的特征可以有利地在一个或多个计算机程序中实施，这些计算机程序可在包括至少一个可编程处理器的可编程系统上执行，至少一个可编程处理器被耦接以从数据存储系统、至少一个输入设备和至少一个输出设备接收数据和指令并且将数据和指令传输到数据存储系统、至少一个输入设备和至少一个输出设备。计算机程序是可以直接或间接在计算机中使用以执行某个活动或带来某个结果的一组指令。计算机程序可以用任何形式的编程语言(例如，Objective-C、Java)来编写，包括编译或解译语言，并且它可以以任何形式来部署，包括作为独立的程序或作为模块、组件、子例程、基于浏览器的网络应用程序或适于在计算环境中使用的其他单元。

举例来说，用于执行指令程序的合适处理器包括通用处理器和专用处理器两者，以及任何种类的计算机的单独处理器或者多个处理器或核之一。通常，处理器将从只读存储器或随机存取存储器或两者接收指令和数据。计算机的基本元素是用于执行指令的处理器以及用于存储指令和数据的一个或多个存储器。通常，计算机还将包括用于存储数据文件的一个或多个大容量存储设备，或者可操作地耦接成与其通信；这种设备包括磁盘，如内部硬盘和可移动盘；磁光盘；以及光盘。适合于有形地体现计算机程序指令和数据的存储设备包括所有形式的非易失性存储器，这些非易失性存储器举例来说包括半导体存储器设备，如EPROM、EEPROM和闪速存储器设备；磁盘，如内部硬盘和可移动盘；磁光盘；以及CD-ROM和DVD-ROM盘。处理器和存储器可以由ASIC(专用集成电路)补充或并入在ASIC中。

为了提供与用户的交互，特征可以在计算机上实施，计算机具有用于向用户显示信息的显示设备，如CRT(阴极射线管)或LCD(液晶显示器)监视器或视网膜显示设备。计算机可以具有触摸表面输入设备(例如，触摸屏)或键盘以及如鼠标或轨迹球等指向设备，用户可以通过这些触摸表面输入设备或键盘以及指向设备向计算机提供输入。计算机可以具有用于接收来自用户的语音命令的语音输入设备。

特征可以在计算机系统中实施，计算机系统包括后端组件，如数据服务器，或包括中间件组件，如应用程序服务器或因特网服务器，或包括前端组件，如具有图形用户界面或因特网浏览器的客户端计算机，或它们的任何组合。系统的组件可以由数字数据通信的任何形式或介质(如通信网络)连接。通信网络的示例包括例如LAN、WAN以及形成因特网的计算机和网络。

计算系统可以包括客户端和服务器。客户端和服务器通常远离彼此并且典型地通过通信网络来交互。客户端与服务器的关系是由于计算机程序在相应计算机上运行并且相对于彼此具有客户端-服务器关系而产生的。在一些实施例中，服务器将数据(例如，HTML页)传输到客户端设备(例如，为了向与客户端设备交互的用户显示数据并且接收来自用户的用户输入)。可以从服务器处的客户端设备接收在客户端设备处生成的数据(例如，用户交互的结果)。

一个或多个计算机的系统可以被配置成凭借将在操作中使系统执行动作的软件、固件、硬件或它们的组合安装在系统上来执行特定动作。一个或多个计算机程序可以被配置成凭借包括指令来执行特定动作，这些指令当由数据处理装置执行时使装置执行这些动作。

虽然本说明书包含许多特定实施细节，但这些细节不应被解释为对任何发明或可以要求的内容的范围的限制，而是相反，被视为对特定发明的特定实施例所特有的特征的描述。本说明书中在单独实施例的上下文中描述的特定特征还可以在单个实施例中以组合形式实施。相反地，在单个实施例的上下文中描述的各种特征还可以在多个实施例中单独地或以任何合适的子组合形式实施。此外，尽管特征可以在上文被描述为以特定组合起作用并且甚至最初是如此要求的，但在一些情况下可以从组合中删去来自所要求组合的一个或多个特征，并且所要求组合可以针对子组合或子组合的变体。

类似地，虽然在附图中按特定顺序描绘了操作，但这不应被理解为需要按所示出的特定顺序或按先后顺序执行这样的操作，或执行所有所图示的操作以实现期望的结果。在某些情况下，多任务和并行处理可以是有利的。

此外，上文描述的实施例中的各种系统组件的分离不应被理解为在所有实施例中需要这样的分离，并且应理解，所描述程序组件和系统通常可以一起集成在单个软件产品中或封装到多个软件产品中。

除非另外特别声明，从以下讨论中显而易见的是，应当理解，在整个发明的讨论中，利用如“处理”、“计算(computing)”、“运算(calculating)”“确定”、“分析”等术语来指代计算机或计算系统或类似的电子计算设备的将表示为物理(如电子)量的数据操纵和/或变换为类似地表示为物理量的其他数据的动作和/或过程。

在整个发明中对“一个示例实施例”、“一些示例实施例”或“示例实施例”的提及意味着结合示例实施例描述的特定特征、结构或特性包括在本发明的至少一个示例实施例中。因此，在整个发明中各处出现的短语“在一个示例实施例中”、“在一些示例实施例中”或“在示例实施例中”不一定都是指代同一个示例实施例。此外，在一个或多个示例实施例中，特定特征、结构或特性可以以任何合适的方式组合，这根据本发明对于本领域的普通技术人员而言将是显而易见的。

如本文所使用的，除非另外指定，否则使用序数形容词“第一”、“第二”、“第三”等来描述共同的对象，仅表明提及相似对象的不同实例，并且不旨在暗示所描述的对象必须在时间、空间、等级或任何其他方式上按照给定的顺序。

同样，应理解，本文中所使用的措词和术语是出于描述的目的且不应视为是限制性的。“包括(including)”、“包括(comprising)”或“具有”及其变体的使用意在涵盖其后列出的项目及其等同物以及附加项目。除非另有规定或限制，否则术语“安装”、“连接”、“支撑”和“耦接”及其变体被广泛使用并且涵盖直接和间接安装、连接、支撑和耦接。

在下文的权利要求和本文的描述中，术语包括(comprising)、包括(comprisedof)或其包括(which comprises)中的任何一个是开放术语，其意指至少包括随后的元素/特征，但不排除其他元素/特征。因此，当在权利要求中使用术语包括(comprising)时，术语不应当被解释为限于在其之后列出的器件或元素或步骤。例如，包括A和B的设备这一表述的范围不应限于仅包括元素A和B的设备。如本文所使用的，术语包括(including)或其包括(which includes)或包括(that includes)中的任何一个也是开放术语，其也意指至少包括术语之后的元素/特征，但不排除其他元素/特征。因此，包括(including)与包括(comprising)同义并且意指包括(comprising)。

应当理解，在以上对本发明的示例实施例的描述中，有时在单个示例实施例/图或其描述中将本发明的各种特征组合在一起，以便简化本发明，并且帮助理解各创造性方面中的一个或多个。然而，本发明的方法不应当被解释为反映权利要求书需要比每个权利要求中明确叙述的特征更多的特征的意图。相反，如以下权利要求所反映的，各创造性方面在于少于单个前面公开的示例实施例的所有特征。因此，在随说明书的权利要求书特此明确地并入本说明书中，其中，每个权利要求独立地作为本发明的单独的示例实施例。

此外，虽然本文描述的一些示例实施例包括其他示例实施例中所包括的一些特征而不包括其他示例实施例中所包括的其他特征，但是如本领域技术人员将理解的，不同示例实施例的特征的组合旨在处于本发明的范围内并形成不同的示例实施例。例如，在所附权利要求中，要求保护的示例实施例中的任何示例实施例都可以以任何组合来使用。

在本文提供的描述中，阐述了许多具体细节。然而，应当理解，可以在没有这些具体细节的情况下实践本发明的示例实施例。在其他实例中，未详细示出众所周知的方法、结构和技术，以便避免模糊对本说明书的理解。

因此，尽管已经描述了被认为是本发明的最佳模式的模式，但是本领域技术人员将认识到，可以在不背离本发明的精神的情况下对其做出其他和进一步的修改，并且旨在要求保护落入本发明的范围内的所有这些改变和修改。例如，上文给出的任何公式仅仅表示可以使用的程序。可以从框图中添加或删除功能，并且可以在功能块当中互换操作。可以向在本公开的范围内描述的方法添加或删除步骤。

上文已经关于用于确定对音频输入的音频质量的指示的方法和系统描述了本公开所枚举的示例实施例(“EEE”)。因此，本发明的实施例可以涉及以下枚举的示例中的一个或多个：

EEE 1.一种用于对多路复用格式中的编码的媒体比特流进行解码的方法，所述多路复用格式包括用于版本列表的预选盒，所述版本列表具有所述版本的性质，所述预选盒与编码的媒体格式无关：

从所述预选盒中确定具有选择方法的性质的所述版本列表；

基于所述选择方法对所述编码的媒体比特流进行解码，以便输出可播放的音频版本。

EEE 2.根据EEE 1所述的方法，其中，所述选择方法是显露给最终用户的UI，所述UI可视化用于执行即时选择的所述版本和性质。

EEE 3.根据EEE 1所述的方法，其中，所述选择方法是基于用户偏好设置的自动过程。

EEE 4.根据EEE 1所述的方法，其中，所述选择方法是基于关于终端设备、回放地理区域或其他数据特性的信息的自动过程。

EEE 5.根据EEE 1至4中任一项所述的方法，其中，所述多路复用格式为ISOBMFF、传输流或MXF。

EEE 6.根据EEE 5所述的方法，其中，所述媒体比特流包括加密的媒体有效载荷，并且其中，编码格式为明文。

EEE 7.根据EEE 1至4中任一项所述的方法，其中，所述解码方法用于专门的回放架构、专门类型的媒体或用于音频、视频和虚拟现实的专门预选。

EEE 8.根据EEE 1至4中任一项所述的方法，其中，所述多路复用格式包括关于预下载的用户选择的信息。

EEE 9.一种用于对编码的媒体资产进行打包以用于传输的方法，其中，传输格式涵盖列出所述资产的清单文件，所述方法包括：

对所述清单文件进行打包，其中，所述清单文件涵盖要从单流或多流资产得到的可用版本和其性质的列表，并且其中，所述列表可以在不访问编解码器特定信息的情况下从所述资产得到。

EEE 10.根据EEE 9所述的方法，其中，所述清单文件呈MPEG DASH、HLS或SDP格式。

EEE 11.一种处理媒体流的方法，所述方法包括：

接收根据预定义传输格式分组的所述媒体流，其中，分组的媒体流包括多个分层盒，所述多个分层盒各自与相应的盒类型标识符相关联，其中，所述多个盒包括一个或多个轨道盒以及一个或多个轨道组盒，所述一个或多个轨道盒引用指示所述媒体流的媒体组件的轨道，所述一个或多个轨道组盒各自与联合地标识所述媒体流内的相应轨道组的相应轨道组标识符和相应轨道组类型相关联，并且其中，具有相同轨道组标识符和相同轨道组类型的轨道属于相同轨道组；并且其中，每个这样的轨道组确定预选；

访问所述媒体流中的所有轨道盒以确定预选的总集合；

其中，所述确定是通过确定一组所有唯一的由轨道组标识符和轨道组类型构成的对并且通过轨道组标识符对所述预选进行寻址来进行的；

基于在具有相同轨道组标识符的所有轨道组盒中找到的预选的属性来选择所述预选；

确定贡献于所述预选的一组一个或多个轨道盒，所述一组一个或多个轨道盒是如通过具有相同轨道组标识符的轨道组盒的存在来标识的；以及

确定在所述一组轨道盒的每个成员中引用的有贡献的轨道。

Claims (49)

1.一种处理媒体流的方法，包括：

接收根据预定义传输格式分组的所述媒体流，其中，分组的媒体流包括多个分层盒，所述多个分层盒各自与相应的盒类型标识符相关联，并且其中，所述多个盒包括引用指示所述媒体流的媒体组件的相应轨道的一个或多个轨道盒；

确定所述媒体流是否包括指示预选的预定义类型的预选相关盒，其中，所述预选与对用户的媒体呈现相对应；以及

如果确定所述媒体流包括所述预选相关盒，则：

分析与所述预选相关盒相对应的元数据信息，所述元数据信息指示所述预选的特性；

基于所述元数据信息标识所述分组的媒体流中贡献于所述预选的一个或多个轨道；以及

根据给定的预选提供所述一个或多个轨道用于下游处理。

2.根据权利要求1所述的方法，其中，所述媒体流进一步包括处理信息，所述处理信息指示将如何处理贡献于所述预选的轨道。

3.根据权利要求2所述的方法，其中，所述处理信息包括排序信息，所述排序信息指示用于处理所述一个或多个轨道的轨道顺序。

4.根据权利要求2或3所述的方法，其中，所述处理信息包括合并信息，所述合并信息指示一个或多个轨道是否要与一个或多个其他轨道合并以用于联合处理。

5.根据权利要求4当从属于权利要求3时所述的方法，其中，所述方法进一步包括：

根据所述合并信息和所述排序信息来合并所述一个或多个轨道。

6.根据权利要求5所述的方法，其中，对于贡献于所述预选的每个轨道，所述排序信息包括用于定义所述轨道的轨道顺序的相应轨道顺序值；

其中，所述合并信息包括用于贡献于所述预选的每个轨道的相应合并标志，其中，所述合并标志的第一设置值指示所述相应轨道将以所述轨道顺序与相邻轨道合并，并且所述合并标志的第二设置值指示所述相应轨道将被单独地处理；并且

其中，根据所述合并信息和所述排序信息来合并所述一个或多个轨道包括：

根据所述轨道顺序相继地扫描所述轨道；以及

根据相应合并标志来合并轨道。

7.根据前述权利要求中任一项所述的方法，进一步包括：

根据由所述预选指示的所述媒体呈现来解码所述一个或多个轨道以用于回放所述媒体流。

8.根据权利要求7所述的方法，其中，所述一个或多个轨道由下游设备解码。

9.根据权利要求7当从属于权利要求5或6时所述的方法，其中，合并所述一个或多个轨道和解码所述一个或多个轨道由单个设备来执行。

10.根据前述权利要求中任一项所述的方法，其中，所述媒体流包括所述预定义类型的多个预选相关盒，并且其中，所述方法进一步包括在所述多个预选相关盒当中选择所述预选相关盒。

11.根据权利要求10所述的方法，其中，所述预选相关盒由应用程序选择。

12.根据权利要求10或11所述的方法，其中，所述媒体流包括一个或多个标签盒，所述一个或多个标签盒各自包括与相应预选相对应的对所述用户的相应媒体呈现的描述性信息；并且

其中，所述预选相关盒的选择是基于所述用户的输入进行的。

13.根据前述权利要求中任一项所述的方法，其中，所述预选相关盒与用于在被分组之前对所述媒体流进行编码的媒体编解码器无关。

14.根据前述权利要求中任一项所述的方法，其中，与所述预选相关盒相对应的所述元数据信息包括指示一个或多个轨道标识符的轨道标识信息，所述一个或多个轨道标识符各自与相应的轨道相关联，其中，与所述元数据信息中的所述一个或多个轨道标识符相关联的轨道与所述媒体呈现相关。

15.根据前述权利要求中任一项所述的方法，其中，与所述预选相关盒相对应的所述元数据信息包括预选标识信息，所述预选标识信息指示用于标识所述预选的预选标识符。

16.根据前述权利要求中任一项所述的方法，其中，与所述预选相关盒相对应的所述元数据信息包括用于配置下游设备以根据所述预选对所述轨道进行解码的唯一预选特定数据。

17.一种处理媒体流的方法，包括：

接收根据预定义传输格式分组的所述媒体流，其中，分组的媒体流包括多个分层盒，所述多个分层盒各自与相应的盒类型标识符相关联，其中，所述多个盒包括一个或多个轨道盒以及一个或多个轨道组盒，所述一个或多个轨道盒引用指示所述媒体流的媒体组件的相应轨道，所述一个或多个轨道组盒各自与联合地标识所述媒体流内的相应轨道组的相应的由轨道组标识符和轨道组类型构成的对相关联，其中，具有相同轨道组标识符和相同轨道组类型的轨道属于相同轨道组；并且其中，每个这样的轨道组确定与对用户的媒体呈现相对应的预选；

检查所述媒体流中的所述轨道盒以确定所述媒体流中存在的预选的完全集合，其中，所述预选的完全集合的确定包括：确定一组唯一的由轨道组标识符和轨道组类型构成的对；以及通过相应的轨道组标识符来对所述预选进行寻址；

在所述预选的完全集合当中选择预选，其中，所述预选是基于包括在具有相同轨道组标识符的轨道组盒中的相应预选的属性来选择的；

确定贡献于所选择的预选的一组一个或多个轨道盒，其中，贡献于所述预选的一组一个或多个轨道盒是通过具有相同轨道组标识符的轨道组盒的存在来标识的；

将所述一组一个或多个轨道盒的每个成员中引用的轨道确定为贡献于所述预选的一个或多个轨道；以及

根据所述预选提供所述一个或多个轨道用于下游处理。

18.根据权利要求17所述的方法，其中，每个预选与预定义类型的相应预选相关盒相关联，并且其中，所述预选相关盒实例化具有与预选相关的预定义轨道组类型的轨道组盒。

19.根据权利要求18所述的方法，其中，所述预选相关盒与预选处理盒相关联，所述预选处理盒包括指示将如何处理贡献于所述预选的轨道的处理信息。

20.根据权利要求18或19所述的方法，其中，所述预选相关盒与包括指示所述预选的语义信息的预选信息盒相关联。

21.根据权利要求19或20所述的方法，其中，所述处理信息包括用于配置下游设备以根据所述预选对所述轨道进行解码的唯一预选特定数据。

22.根据权利要求19至21中任一项所述的方法，其中，所述处理信息包括排序信息，所述排序信息指示用于对所述轨道进行排序的轨道顺序。

23.根据权利要求19至22中任一项所述的方法，其中，所述处理信息包括合并信息，所述合并信息指示所述轨道是否要与一个或多个其他轨道合并。

24.根据权利要求23当从属于权利要求22时所述的方法，其中，所述方法进一步包括：

根据所述合并信息和所述排序信息来合并所述轨道。

25.根据权利要求24所述的方法，其中，所述排序信息包括用于定义所述轨道的轨道顺序的轨道顺序值；

其中，所述合并信息包括合并标志，其中，所述合并标志的第一设置值指示所述轨道将以所述轨道顺序与相邻轨道合并，并且所述合并标志的第二设置值指示所述轨道将被单独地处理；并且

其中，根据所述合并信息和所述排序信息来合并所述一个或多个轨道包括：

根据所述轨道顺序相继地扫描所述轨道；以及

根据相应合并标志来合并轨道。

26.根据权利要求17至25中任一项所述的方法，进一步包括：

根据由所述预选指示的所述媒体呈现来解码所述轨道以用于回放所述媒体流。

27.根据权利要求26所述的方法，其中，所述一个或多个轨道由下游设备解码。

28.根据权利要求26当从属于权利要求24或25时所述的方法，其中，合并和解码所述轨道由单个设备来执行。

29.根据权利要求17至28中任一项所述的方法，其中，所述预选由应用程序确定。

30.根据权利要求17至29中任一项所述的方法，其中，所述媒体流包括一个或多个标签盒，所述一个或多个标签盒各自链接至相应预选的相应预选信息盒，并且其中，每个标签盒包括对所述用户的相应媒体呈现的描述性信息；并且

其中，所述预选的确定是基于所述用户的输入进行的。

31.根据前述权利要求中任一项所述的方法，其中，所述媒体流包括音频流或视频流中的至少一者。

32.一种处理媒体流的方法，包括：

根据预定义传输格式封装一个或多个基本流以生成分组的媒体流，

其中，所述分组的媒体流包括多个分层盒，所述多个分层盒各自与相应的盒类型标识符相关联；并且

其中，封装所述一个或多个基本流包括：

根据所述传输格式对所述一个或多个基本流的媒体数据进行分组，以生成引用所述一个或多个基本流的相应轨道的一个或多个轨道盒；以及

基于所述一个或多个基本流的头信息生成预定义类型的一个或多个预选相关盒，其中，所述一个或多个预选相关盒中的每个预选相关盒指示与对用户的媒体呈现相对应的相应预选。

33.根据权利要求32所述的方法，其中，所述一个或多个预选相关盒中的每个预选相关盒包括指示所述相应预选的特性的元数据信息；并且

其中，所述元数据信息包括指示所述媒体流中贡献于所述相应预选的一个或多个轨道的信息。

34.根据权利要求33所述的方法，其中，与所述相应预选相关盒相对应的所述元数据信息进一步包括以下各项中的至少一项：

指示用于标识所述相应预选的预选标识符的预选标识信息；或

用于根据所述预选对所述轨道进行解码的唯一预选特定。

35.根据权利要求32所述的方法，其中，封装所述基本媒体流进一步包括生成一个或多个轨道组盒，所述一个或多个轨道组盒各自与联合地标识所述分组的媒体流内的相应轨道组的相应轨道组标识符和相应轨道组类型相关联，其中，具有相同轨道组标识符和相同轨道组类型的轨道属于相同轨道组；并且

其中，生成所述一个或多个预选相关盒包括：

向每个预选分配第一唯一标识符；以及

针对贡献于相应预选的每个轨道，生成与所述相应预选相关联的相应预选相关盒，并且将所述轨道组标识符设置为所述第一唯一标识符，其中，所述预选相关盒实例化具有与预选相关的预定义轨道组类型的轨道组盒。

36.根据权利要求35所述的方法，其中，所述轨道组盒是通过基于贡献于一个预选的轨道的相应媒体类型对所述轨道进行分组来生成的。

37.根据权利要求36所述的方法，其中，所述媒体类型包括以下各项中的至少一项：音频、视频和字幕。

38.根据权利要求32至37中任一项所述的方法，其中，生成所述一个或多个预选相关盒进一步包括：生成一个或多个预选处理盒，所述一个或多个预选处理盒包括指示将如何处理贡献于相应预选的轨道的处理信息。

39.根据权利要求38所述的方法，其中，所述处理信息包括以下各项中的至少一项：

指示用于处理所述轨道的轨道顺序的排序信息；或

指示一个或多个轨道是否要与另一个或多个轨道合并的合并信息。

40.根据权利要求32至39中任一项所述的方法，进一步包括：

接收至少一个输入媒体；以及

处理所述输入媒体以生成所述一个或多个基本流，其中，所述一个或多个基本流包括所述输入媒体的媒体数据和对应的头信息。

41.根据权利要求32至40中任一项所述的方法，其中，所述方法进一步包括：

基于所述一个或多个预选相关盒来生成清单文件。

42.根据权利要求41所述的方法，其中，所述清单文件是MPEG基于HTTP的动态自适应流式传输DASH格式文件或HTTP实时流HLS格式文件。

43.一种处理媒体流的方法，包括：

接收根据预定义传输格式分组的所述媒体流，其中，分组的媒体流包括多个分层盒，所述多个分层盒各自与相应的盒类型标识符相关联，其中，所述多个盒包括一个或多个轨道盒以及预定义类型的一个或多个预选相关盒，所述一个或多个轨道盒引用指示所述媒体流的媒体组件的相应轨道，并且其中，每个预选相关盒指示与对用户的媒体呈现相对应的相应预选；以及

基于所述一个或多个预选相关盒来生成清单文件。

44.根据权利要求43所述的方法，其中，所述清单文件是MPEG基于HTTP的动态自适应流式传输DASH格式文件或HTTP实时流HLS格式文件。

45.根据前述权利要求中任一项所述的方法，其中，对所述用户的媒体呈现由与所述媒体流的语言、种类和/或一个或多个媒体特定属性相关的相应配置来表征。

46.根据前述权利要求中任一项所述的方法，其中，所述预定义传输格式是ISO基本媒体文件格式ISOBMFF。

47.一种媒体流处理装置，包括处理器和耦接到所述处理器的存储器，其中，所述处理器适于使所述媒体流处理装置执行根据前述权利要求中任一项所述的方法。

48.一种程序，包括指令，所述指令当由处理器执行时使所述处理器执行根据权利要求1至46中任一项所述的方法。

49.一种计算机可读存储介质，存储有根据权利要求48所述的程序。