CN118633292A - 用于媒体容器文件和流传输清单中的画中画的信令 - Google Patents

Abstract

本公开涉及媒体容器文件和流传输媒体清单中画中画(PiP)的信令。一方面，公开了容器文件中的PiP体验的信令，其中PiP体验由两个或更多个媒体轨道组成。媒体轨道组用于定义画中画体验，其中定义了一个或多个主媒体轨道和替代/覆盖媒体轨道。用角色方案标识PiP体验。可以独立地解码PiP中的媒体轨道，或者如果编码方案支持，则替代已编码流可以以合并模式替换主画面流中的对应区域，对于该合并模式，还发信号通知替代画面的重要性顺序和主画面的特定区域。在另一方面，画中画体验可在流传输清单中发信号通知。这种信令可以包括用画中画描述符来标识自适应集以及使用角色描述符来标识PiP体验，以及进一步在清单中注释子画面，其中一个或多个子画面被标识为用于替代的一个或多个区域。

Description

用于媒体容器文件和流传输清单中的画中画的信令

引用并入

本申请基于并要求于2023年6月26日提交的美国非临时申请第18/341,471号的优先权，该美国非临时申请基于并要求于2022年7月12日提交的美国临时申请第63/388,555号和于2022年10月18日提交的美国临时申请第63/417,103号的优先权，其通过引用整体并入本文。

技术领域

本公开涉及媒体容器文件和流传输媒体清单中画中画(PiP)的信令。

背景技术

媒体内容可以被组织在具有预定格式的容器文件中。此类媒体内容可以包括诸如图像或视频的视觉信息。例如，可以以画中画(PiP)模式同时显示不同组的视觉信息。媒体容器文件可以被下载用于本地回放，或者可以从服务器流传输。下载的或流传输的媒体都可以调用PiP模式。与PiP使用的媒体内容相关的信息和配置可能需要在媒体容器文件或码流中，以及在媒体清单中发信号通知。所述媒体清单由流传输应用使用以执行自适应流传输。

发明内容

本公开涉及媒体容器文件和流媒体清单中画中画(PiP)的信令

一方面，公开了容器文件中PiP体验的信令，其中PiP体验由两个或多个媒体轨道组成。媒体轨道组用于定义画中画体验，其中定义了主媒体轨道和替代/覆盖媒体轨道。PiP经验与角色方案相一致。PiP中的媒体轨道可以独立解码，或者如果编码方案支持，替代编码流可以在合并模式下替换主画面流中的相应区域，为此还用信号通知了替代画面和主画面特定区域的重要性顺序。

另一方面，可以在流式清单中用信号通知画中画体验。这种信令可以包括用画中画描述符标识自适应集，以及使用角色描述符来标识PiP体验，并在清单中进一步注释子画面，其中一个或多个子画面被标识为一个或更多个替换区域。

在一些示例实施方式中，公开了一种获得(画中画)PiP信息的方法。该方法可以包括：检索以ISO基本媒体文件格式(ISOBMFF)构造的媒体容器文件，其中媒体容器文件包括主媒体轨道和将以PiP模式呈现的至少一个子媒体轨道；解析所述媒体容器文件，以通过用于媒体轨道组定义的预选轨道组输入(Prse)框语法元素来标识用于PiP体验的媒体轨道组；解析媒体容器文件，以通过媒体容器文件中的多个媒体轨道定义内的预选组(Pres)框语法元素来识别属于媒体轨道组的主媒体轨道和至少一个子媒体轨道；解析所述媒体容器文件以确定合并模式，所述合并模式指示在被解码之前，根据所述主媒体轨道或所述至少一个子媒体轨道的所述Pres框语法元素的组分内的样本标志合并语法元素的存在或值，是否将所述至少一个子媒体轨道的编码数据单元与所述主媒体轨道的解码数据单元合并；以及根据所述合并模式，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道。

在上述示例实施方式中，所述Prse框语法元素属于所述媒体容器文件中配置为定义媒体轨道组的第一预定义类型的语法元素

在上述任一个示例实施方式中，所述第一预定义类型的语法元素各自包括媒体轨道组类型标签元素；且所述媒体轨道组类型标签元素使用一组预定义的目的关键字来指示对应媒体轨道组的预期体验，包括所述PiP体验。

在上述任一个示例实施方式中，所述第一预定义类型的语法元素各自包括媒体轨道组类型描述符；并且所述媒体轨道组类型描述符被配置为使用具有预定义角色的角色方案来指定对应媒体轨道组的预期体验，包括所述PiP体验。

在上述任一个示例实施方式中，所述媒体容器文件中的所述第一预定义类型的语法元素中的每一个包括对应媒体轨道组的多个轨道。

在上述任一个示例实施方式中，所述Pres框语法元素属于媒体轨道定义内的第二预定义类型的语法元素，所述媒体轨道定义被配置为使用对应的媒体轨道组标识符来指定所述媒体轨道与一媒体轨道组的关联。

在上述任一个示例实施方式中，所述第二预定义类型的语法元素中的每一个包括媒体轨道组处理描述符(prsp)，用于指定关于所述媒体轨道组的所述媒体轨道的PiP处理。

在上述任一个示例实施方式中，所述媒体轨道组处理描述符包括优先级参数以指示所述媒体轨道相对于所述媒体轨道组中的其它媒体轨道的优先级顺序。

在上述任一个示例实施方式中，所述PiP体验的所述主媒体轨道的所述优先级参数包括用于PiP处理的最高优先级值。

在上述任一个示例实施方式中，所述PiP体验的所述至少一个子媒体轨道的所述优先级参数包括用于PIP处理的较低优先级值。

在上述任一个示例实施方式中，所述样本标志合并语法元素属于第三预定义类型的语法元素，所述第三预定义类型的语法元素被对应地包括在与主媒体轨道相关联的所述媒体轨道组处理描述符中。

在上述任一个示例实施方式中，与所述主媒体轨道相关联的所述第三预定义类型的语法元素具有指示在被解码之前所述主媒体轨道与所述子媒体轨道合并的一预定义值。

在上述任一个示例实施方式中，当与所述主媒体轨道相关联的所述第三预定义类型的语法元素具有所述预定义值时，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道包括：将所述主媒体轨道的所述已编码数据单元和所述至少一个子媒体轨道的所述已编码数据单元合并以进行单个解码。

在上述任一个示例实施方式中，所述媒体轨道组处理描述符包括一区域标识参数，所述区域标识参数用于指示在解码之前，要与其它媒体轨道的已编码流合并的相应媒体轨道的已编码流中的区域列表。

在上述任一个示例实施方式中，当与所述主媒体轨道相关联的所述第三预定义类型的语法元素具有所述预定义值时，与所述主媒体轨道相关联的所述区域标识参数为非空。

在上述任一个示例实施方式中，当所述媒体轨道的所述优先级顺序不是最高时，即使所述媒体轨道的所述区域标识参数存在，也忽略所述区域标识参数。

在上述任一个示例实施方式中，当所述媒体轨道的所述区域标识参数为非空时，所述媒体轨道的所述优先级顺序相应地为最高。

在上述任一个示例实施方式中，当与所述主媒体轨道相关联的所述第三预定义类型的语法元素不具有所述预定义值时，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道包括：通过分开的独立解码来处理所述主媒体轨道和所述至少一个子媒体轨道。

在上述任一个示例实施方式中，所述主媒体轨道和所述至少一个子媒体轨道属于由所述媒体容器文件中的另一Prse框语法元素指示的另一媒体轨道组。

在一些其他示例实施方式中，公开了一种从流媒体清单中获得画中画(PiP)信令信息的方法。该方法可以包括从流传输服务器检索流传输媒体清单；解析所述流传输媒体清单以识别与一组流传输媒体内容相关联的一组PiP信令信息项；根据所述PiP信令信息项构建对所述一组流传输媒体内容的自适应请求；接收所述一组流传输媒体内容；以及根据PiP信令信息项对所述一组流传输媒体内容进行解码和显示。

在上述示例实施方式中，PiP信令信息项可以从流传输媒体清单中的多个自适应集中提取。

在上述任一个示例实施方式中，多个自适应集形成一PiP组。

在上述任一个示例实施方式中，所述多个自适应集中的每一个包括用于指定相应自适应集的角色的补充描述符。

在上述任一个示例实施方式中，所述补充描述符包括角色值和标识符。

在上述任一个示例实施方式中，所述角色值是预定义角色方案中定义的一组角色值中的一个。

在上述任一个示例实施方式中，所述预定义角色方案使用预定义角色方案的通用资源名称(URN)在多个自适应集中指示。

在上述任一个示例实施方式中，所述角色值指示相应的自适应集用于PiP；并且所述标识符对于所述PiP组的多个自适应集是相同的，并且被分配用于从包括其他PiP自适应组的其他自适应组中识别所述PiP组。

在上述任一个示例实施方式中，所述角色值还指示所述PiP组中相应自适应集的角色，或者所述角色包括PiP组之间的主自适应或子自适应中的一个。

在上述任一个示例实施方式中，多个自适应集合中最多有一个与所述PiP组中的主自适应集的角色相关联。

在上述任一个示例实施方式中，当所述多个自适应集的一个自适应集是所述主自适应集并且可与所述PiP组中的子自适应集合并时，所述主自适应集的内容组件描述符还包括所述主自适应集的已编码子组件的列表，所述已编码子组件用于在解码之前由所述PIP组的已编码子自适应集替换。

在上述任一个示例实施方式中，所述PiP组中的所述多个自适应集中的至少一个包括第二补充描述符，所述第二补充描述符指示所述多个自适应集中的所述至少一个也属于第二PiP组。

本公开的各方面还提供了一种媒体流设备或装置，其包括电路，所述电路被配置为执行上述方法实施方式中的任何一个。

本公开的各方面还提供了存储指令的非易失性计算机可读介质，当由媒体流设备执行时，这些指令被配置为使所述媒体流设备能够执行上述方法实施方式中的任何一个。

附图说明

从以下详细描述和附图中，所公开的主题的其它特征、性质以及各种优点将更加明显，其中：

图1图示了根据本公开的实施例的内容分发系统。

图2图示了根据本公开的实施例的基于HTTP的动态自适应流传输(DASH)系统。

图3图示了根据本公开的实施例的DASH客户端架构。

图4图示了示例画中画应用。

图5图示了媒体容器文件中的示例信令方案。

图6示出了用于图5的信令方案的示例数据和逻辑流程。

图7示出了示例数据和逻辑流程。

图8示出了根据本公开的示例实施例的计算机系统的示意图。

具体实施方式

基于超文本传输协议(HTTP)的流传输

图1图示了示例内容分发系统100，其中远程信息处理装置120被配置为通过通信网络130从一个或多个集中式或分布式内容服务器110请求内容。特别地，信息处理装置120可以包括专用硬件组件、在通用硬件上运行的软件组件或其组合，该信息处理装置120用作内容消费应用。内容消费应用可以生成指定所请求的内容和所请求的内容的特征的一个或多个请求。每个请求可以基于网络协议栈来构建，并通过通信网络130传送到内容服务器110。作为响应，内容服务器可以根据请求生成码流，使用网络协议栈来打包码流，并将该码流包传送到内容消费应用。

在一些示例实施方式中，可以立即请求内容。换句话说，内容消费应用可以请求、接收并本地存储整个媒体内容。本地存储的内容可由例如媒体播放器根据需要来进行处理和消费(例如，提取、解码和回放)，该媒体播放器是内容消费应用的一部分或与内容消费应用分开。这种过程可以称为下载。

在一些其它实施方式中，内容可以在被消费时被流传输，而不是被下载以供稍后消费。在此类实施方式中，所请求的内容的整体可能不需要被存储在内容消费应用中。相反，只有有限量的内容在滚动的基础上被连续地从内容服务器110接收，并由用于内容处理和回放的输入-输出本地缓冲器管理。此类实施方式可以被称为流传输。虽然诸如倒带、快进和搜寻的一些媒体回放功能可能涉及复杂的媒体码流控制和缓冲，但是媒体流传输通常更通用并且更适合于包含未被重复消费的定时媒体序列的内容的分发。

在下面的公开中，术语“内容”和“媒体”可以互换使用。所请求的内容可以包括该内容消费所需的各种信息项，包括但不限于内容本身和各种元数据。内容本身还可以包括各种媒体组件，诸如不同的轨道，包括但不限于视频组件/轨道、音频组件/轨道、字幕等。用于描述媒体内容或提供附加处理信息的元数据可被视为一个或多个单独的轨道。这种具有其元数据的内容可以由内容服务器120生成为码流，该码流可以根据内容消费应用已知的一组协议或规则来解析和解码。单数形式的术语“内容服务器”用于表示布置在中心位置或分布在各种地理位置上的单个服务器或多个服务器。此类内容服务器可以被实施为专用计算机器，或者替代地，可以被构建为虚拟机器，和/或被虚拟地隐藏在云计算环境中。此外，在下面的公开中，术语“信息处理装置”(参考图1的120)和“内容消费应用”可以互换使用。这些术语也可被替代地称为“客户端”、“客户端设备/装置”、“回放设备/装置/客户端”等。虽然在图1中仅示出了单个信息处理装置120，但是可以存在多个独立的信息处理装置。换句话说，一组内容服务器110可以被配置为同时且独立地向多个内容消费应用提供流传输服务。

在一些示例实施方式中，可以对内容服务器110为分发而生成的内容进行分段以便于其流传输。例如，诸如电影的媒体内容的定时序列可以被分成时间段，每个时间段包含多个媒体帧。每个媒体段可以是自包含的，使得其包括例如解析、解码和回放的处理不需要其它媒体段的信息。媒体内容可以被预先分段。因此，媒体内容可以由内容服务器120逐段地存储和管理。替代地，当在流传输过程期间请求连续存储的媒体内容时，可以从连续存储的媒体内容实时生成媒体段。在一些进一步的实施方式中，媒体的段可以是分级的，包含多级段。

在用于流传输的一些特定实施方式中，关于从内容服务器110请求哪些媒体段或媒体段的哪些部分的决定可以由内容消费应用实时地确定，如由通过用户应用接口的用户回放指令所控制的。以这种方式，内容服务器可以被配置为响应于请求，并且根据该请求用它们的元数据生成或检索内容的段或段的部分，并且通过网络130将段或段的部分递送到请求内容消费应用。

在一些示例实施方式中，媒体内容的相同媒体轨道可以被准备为不同的版本。例如，可以以不同的分辨率和/或帧速率准备相同的电影轨道。对于另一示例，可以以不同的比特率准备相同的电影轨道。对于另一示例，可以用不同的声音质量和/或不同数量的声音通道(例如，5通道声音或7通道声音)准备相同的音频电影。因此，内容消费应用可以确定媒体轨道的哪个版本要流传输，并且在该内容消费应用对媒体内容的请求中包括这种选择。内容消费应用可以基于多个示例因素中的一个或多个做出这种决定，该多个示例因素包括但不限于信息处理装置120的回放能力(例如，显示分辨率、解码速度、处理能力、缓冲器大小等)、网络带宽和吞吐量等。这样，可以根据它们的设备能力在不同的媒体消费应用之间适应流传输会话。如此配置的流传输架构可以被称为自适应流传输。流传输过程还可以在每个媒体消费应用内是自适应的，因为可以根据例如实时网络条件(例如带宽和吞吐量，以及网络带宽支持的比特率)在流传输会话期间的不同时间选择和请求不同版本的媒体轨道。如此配置的流传输架构还可以被称为动态自适应流传输。特别地，被配置为适应媒体内容的比特率的流传输架构可以被称为动态自适应比特率流传输。

在一些示例实施方式中，在动态自适应流传输中由内容消费应用对媒体内容的段或段的部分的特定版本的请求可以基于根据流传输会话的进展的媒体清单来构建。术语“清单”可用于表示描述媒体内容的信息项的任何集合，包括段、版本、网络位置以及任何内容消费应用确定在流传输会话期间在不同时间如何请求以及请求什么所需的任何其它信息。清单通常可被称为“媒体呈现描述(MPD)”。

这种清单可以在创建或生成特定媒体内容时在内容服务器侧准备。这种清单可以由内容消费应用请求并在流传输会话开始时从内容服务器接收。内容消费应用还可以在流传输会话期间请求清单的任何更新。这种清单可以被内容消费设备用作蓝图，用于在流传输会话期间构建媒体内容的段或段的部分的特定版本的后续请求。

在一些示例实施方式中，媒体服务器可以被配置为从外部应用的立场来看，类似于web服务器的功能。这样，内容消费应用可以基于例如超文本传输协议(HTTP)做出对媒体清单和/或媒体段或媒体段的部分的请求。这样，可以将请求构建为URL，并且可以将所请求的内容作为对来自内容服务器的HTTP请求的响应来递送。

清单被指定、内容被分段、组织和版本化，以及HTTP请求被构建的方式的细节可以取决于特定的自适应流传输协议，诸如基于HTTP的动态自适应流传输(DASH)、HTTP直播流传输(HLS)、平滑流传输协议(SSTP)等。下面的各种附加示例实施方式可以在DASH的上下文中描述。然而，基本原理可应用于任何类型的基于HTTP的自适应流传输。此外，基本原理可应用于基于除了HTTP之外的网络协议的媒体内容请求机制。

基于HTTP的动态自适应流传输(DASH)

用于实施自适应媒体流传输的一个示例协议包括基于超文本传输协议(DASH)的动态自适应流传输。如上所述，DASH表示自适应比特率流传输实施方式中的一种，其使得能够使用基于超文本传输协议(HTTP)基础设施的内容递送网络(CDN)来流传输媒体内容，该基础设施包括被配置为具有各种代理和高速缓存等的web服务器的内容服务器。此类内容服务器可以被称为DASH服务器。因此，上述内容消费应用可以被称为DASH客户端。

DASH支持从DASH服务器到DASH客户端的直播流传输，并且允许DASH客户端控制流传输会话，使得DASH服务器在大规模部署中不需要应付流自适应管理的附加负载。如上所述，DASH还允许DASH客户端选择来自各种DASH服务器的流传输，从而实现网络的进一步负载平衡以受益于DASH客户端。DASH还例如通过改变比特率来提供媒体轨道的不同媒体版本之间的动态切换，以适应DASH客户端的网络条件和处理能力。

在DASH中，上面描述的媒体清单可以特别地称为MPD(即使术语MPD通常可以用于指自适应流传输系统中除基于DASH的那些之外的任何类型的清单)。例如，DASH中的MPD可以被构建为文件，该文件可以全部或部分地由DASH客户端下载，并且提供由DASH客户端使用的信息项，以通过从DASH服务器选择性地和自适应地请求流传输媒体段来流传输媒体内容。

MPD可以以各种格式构建。例如，MPD可以以可扩展标记语言(XML)文档或文件的形式来构建。可以请求MPD文件并将该文件递送到DASH客户端。MPD文件可以经由例如HTTPGET请求由HTTP请求。MPD文件可以完全在流传输会话开始时递送。替代地，MPD文件可以被分段并部分地传递。这样，MPD文件的部分可以在流传输的开始之前被请求和递送，并且MPD文件的其它部分可以在稍后被请求和递送，以减少会话启动延迟(使得流传输可以以较早的媒体段开始，而不必等待与媒体的稍后段有关的信息项)。还可以在流传输会话期间更新MPD文件(例如，用需要但尚未检索的段信息)。

在一些示例实施方式中，MPD文件描述媒体内容的段、段的组织以及段的可用版本。MPD可以支持内容可访问性特征、评级、相机视图、元数据等的表达。DASH还可以支持多视图和可缩放已编码内容的递送。

在一些示例实施方式中，MPD文件可以包含沿着媒体消费时间线(例如，视频内容的播放时间)的一个或多个时段的描述序列。一个或多个时段中的每一个可由例如MPD文件中的“时段”信息元素标签来定义。媒体内容可以由MPD文件指示为组织在多个连续时间段中。MPD文件可以标识回放时间线中的时段中的每一个的开始时间。开始时间可以被定义为从媒体内容开始的绝对开始时间，或者被定义为从回放时间线中其它参考点的相对偏移。

在一些示例实施方式中，对于每个媒体时段，MPD文件该可以指定一个或多个自适应集。可以指定不同的自适应集来捕获一个或多个媒体组件的不同组合(或子集)。例如，视频和音频可以是不同的自适应集。不同版本的音频(立体音频或多通道音频)可以是不同的自适应集。不同语言的音频可以是不同的自适应集。在一个特定示例中，MPD文件可以指定每个时段包含一个视频自适应集、多个音频自适应集，每个自适应集用于所支持语言中的每一个。自适应集还可以包含字幕或任意元数据。

在一些示例实施方式中，特定时段的自适应集可被分配给由MPD文件中的组属性指示的组。同一组中的自适应集通常被认为是彼此的替代。例如，可以将特定时段的视频数据的每个自适应集分配给相同的组，使得可以为对应时段的多媒体内容的视频数据选择任何自适应集。一个时段内的媒体内容可以来自一个自适应集或自适应集的组合，其中每个组贡献至多一个自适应集。

在一些示例实施方式中，每个自适应集可由MPD文件指定为包含对应时段的相同媒体组件的一个或多个表示。例如，表示可以是音频或视频数据的多个可选已编码版本中的一个。该表示可因编码类型而不同，例如，因用于视频数据的比特率、分辨率和/或编解码器以及用于音频数据的比特率和/或编解码器而不同。术语表示可用于指对应于多媒体内容的特定周期且以特定方式编码以实现特定范围的平均比特率的已编码媒体数据的区段。在一些示例实施方式中，对于自适应集中的每个表示，MPD文件可以指定表示的属性，包括但不限于视频/音频类型、视频/音频编解码器、以像素为单位的视频帧宽度、以像素为单位的视频帧高度、视频/音频帧速率和带宽(表示平均已编码比特率)。

自适应集的每个表示还可以包括取决于包括在自适应集中的媒体组件的组合的一个或多个媒体组件。表示中的每个媒体组件可以对应于一个单独媒体类型的已编码版本，诸如音频、视频或定时文本(例如，用于闭路字幕)。媒体组件可以是时间连续的，跨一个表示内的连续媒体段的边界。

在一些示例实施方式中，表示可以包括一个或多个段。每个表示可以包括初始化段，或者表示的每个段可以是自初始化的。当存在时，初始化段可以包含用于访问该表示的初始化信息。在某些情况下，初始化段不包含媒体数据。包含媒体数据的段可以表示时间分段的内容。不同表示之间的段可以在时间上对齐。对于每个媒体段，MPD文件可以包括唯一标识符。当与基础URL、基础URN或基础统一资源标识符(URI)组合时，这种标识符可以形成表示媒体段的网络位置的唯一URL、URN或URI，该唯一URL、URN或URI可以被包括在对该媒体段的HTTP请求中，并且由内容服务器用来定位所请求的段以用于递送。

例如，用于请求媒体段的URL可以被定义为<绝对-URI>，具有固定方案“http”或“https”，如果范围属性与URL一起提供，则可能进一步由字节范围补充。字节范围可被表示为标识段中的连续字节范围。

在一些进一步的示例实施方式中，子表示可以在MPD文件中被指定和描述为例如使用子表示元素/指示符嵌入(或包含)在规则表示中。子表示元素可用于描述嵌入在表示中的一个或几个媒体内容组件的特性。例如，子表示元素可用于描述嵌入式音频组件(例如，编解码器、采样率等)、嵌入式字幕(例如，编解码器)的特性，或者子表示元素可用于描述一些嵌入式较低质量视频层(例如，一些较低帧速率等)。子表示和表示元素可以共享一些公共属性和元素。

在一些示例实施方式中，DASH客户端可以被配置为从DASH服务器访问、下载和请求MPD文件的全部或一部分。也就是说，DASH客户端可以检索MPD文件以用于发起直播流传输会话。基于MPD文件和表示的选择，DASH客户端可以做出若干进一步的决定，包括确定服务器上可用的最新段是什么、确定下一段和可能的未来段的段可用性开始时间、确定何时开始段的回放，以及确定何时获取/取得/请求新的MPD文件。

在一些示例实施方式中，MPD还可以包括关于DASH事件的信息，以便向DASH客户端或DASH应用发信号通知非周期性信息。事件可以被定时，从具有持续时间的特定媒体呈现时间开始。附加地或替代地，事件信息可以包括与媒体呈现的回放期间的特定时间相关联的媒体播放器的控制消息，诸如广告插入提示。可以在流传输期间插入的媒体可以由诸如广告服务器的单独服务器提供。除了通过MPD与媒体表示分开地发信号通知事件之外，事件还可以仅在一个或几个所选择的自适应集中的所选择的媒体表示中或在所有表示中被带内多路复用。

图2图示了示例性DASH系统200。DASH系统200可以包括通过网络250连接的一个或多个集中式或分布式内容服务器210和信息处理装置230。DASH系统(200)还可以包括一个或多个补充内容服务器，诸如一个或多个广告服务器220。

内容服务器210可向信息处理装置230提供主要内容(例如，主程序)和用于内容的MPD。清单文件可以由MPD生成器214生成。主要内容和清单文件可以由相同的服务器或不同的服务器提供。

信息处理装置230可以包括直接与内容服务器210通信的DASH客户端232。由信息处理装置230的DASH应用234控制的DASH客户端232可以请求和/或接收MPD，并且可以基于MPD从内容服务器210的HTTP服务器212请求和获取主要内容。MPD可以由DASH客户端232处理。此外，DASH客户端232可以根据DASH事件从广告服务器220获取广告内容，或者从一个或多个补充内容服务器获取其它内容(例如，交互式内容)。主内容和广告内容可以由DASH客户端232和DASH应用234处理并输出以在信息处理装置230的显示设备236上显示。显示设备236可以与信息处理装置230集成在一起或者在信息处理装置230的外部。此外，DASH客户端232可以从一个或多个定时元数据轨道中提取其它事件信息，并且将所提取的事件信息发送到DASH应用234用于进一步处理。DASH应用234可以被配置为例如基于事件信息显示补充内容。

在图3中图示了DASH客户端232的示例。如图3所示，示例DASH客户端232可以包括DASH访问引擎304、选择逻辑302以及媒体引擎306和308。例如，DASH访问引擎302可以被配置为与内容服务器通信，用于检索流传输媒体的MPD的一部分或整体，以及用于请求和检索动态请求的流传输媒体的段数据，以及用于根据MPD DASH事件请求补充媒体(广告)。选择逻辑304可被配置为确定请求的下一个或多个段，包括自适应集和表示的选择。这种决定例如可以由用户指令以及诸如网络带宽和吞吐量的其它实时信息来确定。媒体引擎306可以被配置为根据媒体段的格式(例如，MPEG)和媒体段的定时来处理由DASH访问引擎302接收的段数据，以生成主媒体输出。媒体引擎308可以被配置为处理与来自DASH访问引擎302的定时DASH事件相关联的媒体内容，以生成补充媒体输出(诸如广告)，该补充媒体输出例如可以被插入到主媒体输出中。

媒体容器文件

媒体内容可以存储在具有各种预定义格式的文件中。包含文件的媒体可以用于定义包含基于时间的多媒体数据(诸如视频、音频和与视频和音频相关联的其它数据)的文件的一般结构。ISO基本媒体文件格式(ISOBMFF)是多媒体容器文件的一个示例。它被设计为一种灵活且可扩展的格式，便于多媒体的交换、管理、编辑和呈现。在下面的公开中，虽然术语“ISOBMFF”指特定的容器文件格式，但是它在下面也用于表示任何媒体容器文件格式，下面的基本原理适用于该媒体容器文件格式。

ISOBMFF可以包括用于媒体数据的定时序列的定时、结构和媒体信息，诸如视听呈现。文件结构可以被设计为面向对象的。例如，可以以简单的方式将ISOBMFF文件分解成基本对象。对象的结构可以从其定义的类型中隐含和派生出来。

符合ISOBMFF的文件可形成为一系列对象，称为“框”。所有数据可包含在框中。这些框可以以分级方式级联。文件内可以没有其它数据。呈现(例如，运动序列)可包含在若干文件中。所有定时和成帧信息可以包括在ISOBMFF文件中，并且辅助文件基本上可以使用任何格式。

例如，文件类型框(“ftyp”)可置于ISOBMFF文件的开头。在文件类型框内，可以指定一般信息，包括但不限于所使用的编码类型、每种编码的数据如何存储、应用于文件的约束和扩展、兼容性和/或文件的预期用途。对于另一示例，文件类型框之后可以是电影框，该电影框中包含定义各种内容轨道的级联框。

ISOBMFF可以支持媒体数据通过网络的流传输以及本地回放。支持流传输的ISOBMFF文件可以包括关于要流传输的数据单元的信息(例如，文件中的基本流传输数据应如何通过流传输协议来服务)。

在一些示例实施方式中，容器文件可用于描述对应于流传输清单中的特定表示的媒体内容。在此类实施方式中，在清单中描述的每个表示可以与媒体容器文件相关联。

画中画

在一些示例实施方式中，视觉媒体内容可以以画中画(PiP)模式叠加。在图4中示出了画中画用例。如图4所示，PiP视图包含主画面和PiP。主画面拍摄整个屏幕，而覆盖画面拍摄屏幕的一部分，覆盖主画面的想应区域。PiP的坐标由x、y、高度和宽度指示，其中这些参数相应地定义PiP相对于主画面坐标的位置(例如左上角像素坐标)和大小。

在流传输媒体的情况下，主视频和PiP视频可以作为两个单独的流来传递。如果它们是独立的流，则可以由单独的解码器进行解码，然后组合在一起用于渲染。在一些示例实施方式中，如果视频编解码器支持合并流，则可以将PiP视频流与主视频流组合，可能用PiP视频替换表示主视频的覆盖区域的流，然后可以将单个流发送到解码器以进行解码然后进行渲染。

因此，为了提供有效的PiP处理，各种信令信息可包括在媒体容器文件中以指定各种媒体内容在PiP体验中的可能角色和关系。这种信令然后将由回放设备解释以获得预期的PiP体验。同样地，这种信令也可以被包括在用于流传输的清单(例如DASH MPD)中，以便向流传输客户端指示各种PiP可能性。然后流传输客户端将能够解析清单并确定何时以及如何使用PiP并向用户提供PiP体验。例如，流传输清单中的这种PiP信令可以从与流传输媒体相关联的基本媒体容器文件中的PiP信令导出。

例如，一般的PiP信令解决方案应能够指示如何将两个或更多个轨道用于PiP体验，即，轨道的已解码画面可以覆盖在其它轨道的已解码画面的区域上。可以直接发信号通知或至少可以从该信号中导出的示例信息可以包括但不限于：

·可以创建PiP体验的媒体内容(例如，轨道)的可能组合。

·标识PiP体验中的主要和叠加内容或轨道。

·PiP体验中指示叠加内容或轨道的位置。

下面的示例实施方式提供了一些现有ISOBMFF和DASH清单框架的修改/扩展，以支持PiP信令，从而提高全面灵活的PiP体验。

例如，所公开的方案使用轨道组的概念来定义和发信号通知作为组的媒体轨道以提供PiP体验。示例方案允许唯一标识的多个不同的PiP媒体轨道分组。PiP体验轨道组中的媒体轨道可以独立解码，或者可以合并在一起进行解码。示例方案相应地包括指示每个PiP体验轨道组内的这种合并能力的信令。

对于另一示例，画中画体验可在流传输清单中发信号通知。这种信令可以包括用画中画描述符来标识自适应集以及使用角色描述符来标识PiP体验，以及进一步在清单中注释子画面，其中一个或多个子画面被标识为一个或多个替换区域。

媒体容器文件中的示例PiP信令

在一些示例实施方式中，轨道预选组可用于指定PiP体验。如图5的501所示，例如ISOBMFF中的媒体容器文件可以包含在图5的502中被称为“moov”的元数据框。示例“moov”框5020可包含媒体容器文件中包括的媒体内容的一般信息。“moov”框可以在其中包括电影标题框，在图5的504中称为“mvhd”，包含诸如与“moov”框相关联的呈现的创建和修改时间等信息。

“moov”框502还可以包含轨道组描述框，在图5的506中称为“tkgd”。“tkgd”框可以在其下指定用于各种媒体体验的轨道组的一个或多个描述。每个轨道组的说明或描述可以包括在预选轨道组输入框中，在图5的508中称为“prse”。这些预选组中的每一个可以被标识为共同实现特定媒体体验的媒体轨道的集合。在图5的示例中，指定了两个轨道组，对应于两个单独的“prse”框。

每个预选轨道组输入“prse”框可以包括一“track_group_id”元素，用于指定相应预选轨道组的唯一标识。图5中指定的两个示例轨道组对应于track_group_id＝1和2。每个预选轨道组输入“prse”框还可以包括一“num_tracks”元素，该元素用于指定预选轨道组中的轨道数目。每个“prse”框可以可选地包括一个或多个“preselection_tag”元素，该元素可以是回放系统可以向解码器提供的编解码器特定值，以唯一地标识媒体中的若干预选中的一个，以了解预选体验的性质。在图5的示例中，预选轨道组1由其“preselection_tag”标识为用于PiP体验的预选。使用“preselection tag”元素的“pip”值用于发信号通知PiP仅仅是一种选择。如下所述，可使用“prse”框中(例如，下文所述的“kind”框中)的其它替代元素来发信号通知PiP体验。例如，在图5的示例中，具有“track_group_id”＝2的预选组也是PIP预选组。在那里，PIP的指示可能不需要提供“preselection tag”，而是可以在“kind”框中提供。在一些示例实施方式中，可以提供两种信令选项，并且每个“prse”框(或每个预选组)可以使用不同的选项来发信号通知PiP体验。

每个预选轨道组输入“prse”还可以包括“kind”框，该框可替代地用于指定相应预选轨道组的角色。例如，可以为轨道组预选定义预定义的角色方案。预定义的角色方案可以为策略(tack)组预选指定一组角色。由“prse”指定的特定预选组的“kind”框可以包括指示预定义角色之一的数据项。例如，“kind”框可以发信号通知画中画体验为预定义角色中的一个，其中主画面的一个或多个区域可以覆盖一个或多个替代画面。预定义的角色方案例如可以由DASH角色方案IdURI指定，如下面进一步详细描述的那样，并且预定义的角色值中的一个可以是“pip”，用于指示PiP体验。可以使用其它替代的角色方案。

在“moov”框中，各个媒体轨道可分别由轨道框来描述，在图5的510中称为“trak”。如图5所示，可以在媒体容器文件中描述/定义多个媒体轨道。相应地，在容器文件中可以包括多个“trak”框510。图5示出了由它们的唯一标识符trak_id＝1、2和3标识的三个这种示例。

每个“trak”框提供相应媒体轨道的基本信息。例如，可以指定媒体轨道标识符(“trak_id”)。每个“trak”框还可以包含一个可选的轨道组框，在图5的512中称为“trgr”。每个媒体轨道的轨道组“trgr”框指定媒体轨道所属的一个或多个预选轨道组。媒体轨道所属的一个或多个轨道组中的每一个都可以由一个预选框指定，在图5的514中称为“pres”。因此，用于媒体轨道的轨道组“trgr”框可以包括一个或多个预选框“pres”，这取决于该特定媒体轨道与多少预选组(如上述“tkgd”框506的“prse”框508中所定义的)相关联。

一个或多个预选“pres”框514中的每一个可以通过预选组ID来标识对应轨道组，如图5的516所示，并且作为示例，还可以通过预选处理框(在图5的518中称为“prsp”)进一步可选地指定如何将该特定媒体轨道与预选轨道组中的其它媒体轨道相关联地用于相应的体验。“prsp”框对于轨道的特定组预选可以是可选的，并且可以根据需要被包括在内。例如，在图5中，具有trak_id＝1、2和3的每个媒体轨道可以与由上面的“tkgd”框506内的两个“prse”框508定义的两个示例预选轨道组中的一个或两个相关联或属于这两个示例预选轨道组中的一个或两个，其中包括“prsp”框。

相对于具有track_group_id的特定预选组，具有trak_id＝1的媒体轨道的示例预选处理“prsp”框518可指定轨道顺序参数，在图5的520或521中称为“track_order”。轨道顺序参数可用于指定预选组内的媒体轨道之间的优先级顺序。例如，轨道顺序参数的较低值可指示较高优先级。特别是对于示例PiP预选组，可以将作为PiP体验的主画面的一部分的轨道设置为track_order＝0，如520所示的track_id＝1的轨道。用于画中画体验的PiP预选组的旨在用作主画面(称为替代画面)的一个或多个区域的覆盖或替代的任何其它媒体轨道可被设置为高于0的track_order值，如521所示的track_id＝1和2的轨道。在预选组的替代轨道内，较低的track_order值指示媒体轨道的替代画面相对于其它媒体轨道的优先级。

示例预选处理“prsp”框518还可以可选地指定样本合并标志，在图5的522和523中被称为“sample_merge_flag”。样本合并标志可以被指定为二进制值。例如，具有二进制值1的“sample_merge_flag”可以指示该轨道属于合并轨道组，并且能够与该轨道组中的一个或多个其它轨道合并，以进行合并解码(在解码之前合并主画面和子画面的码流)。该合并轨道组中的媒体轨道可以根据其相对于预选组(图5的520和521)指定的“轨道顺序(track_order)”值进行排序，如上所述。例如，合并组可以包括具有sample_merge_flag＝1的一个媒体轨道，随后是具有sample_merge_flag＝0或不具有sample_merge_flag的一个或多个媒体轨道(在该情况下默认为零)。例如，合并组的所有轨道可以具有相同的媒体类型，并且可以具有按时间排列的所有样本。对于PiP预选组，具有sample_merge_flag＝1的轨道可以是其它轨道可以合并到其中然后被解码为合并以形成PiP体验的主画面，并且在具有sample_merge_flag为1的主轨道的组中具有sample_merge_flag＝0的媒体轨道可以是替代画面。

在图5的示例中，track_group Id＝2的PiP组具有可合并的主轨道(track_id＝1并且其sample_merge_flag＝1，如523所示)，以及track_id＝3的子画面轨道，该子画面轨道可以合并到该PiP组的主画面(track_id＝1)中，但通过不在其“prsp”框中包括sample_merge_flag，其本身不可合并以包括其它轨道。在该示例中，如果要为组2的轨道3包含sample_merge_flag，则它将被包含为具有0值。

此外，在图5的示例中，具有track_group Id＝1的PiP组具有不可合并的主轨道(具有track_id＝1并且具有其sample_merge_flag＝0，如522所示)。这样，在解码之前不合并该PiP。相反，每个轨道将被分别解码，然后根据PiP配置进行合并以在解码之后形成组合画面。该PiP组包括作为子画面的轨道2。它的sample_merge_flag(存在或不存在)对于该PiP组是无关紧要的。

例如，对于参与PiP预选组的媒体轨道，还可以在其与PiP预选组对应的“prsp”框中可选地包括区域标识符列表，在图5的524和525中称为“region_ids”。区域ID列表可以标识该媒体轨道中的已编码视频数据单元的白色间隔区域的列表，PiP预选组中的其它媒体轨道可以覆盖这些白色间隔区域。该字段指示在对可合并轨道进行解码之前视频码流中可以发生合并的区域的位置，使得解码器可以适当地组装合并的码流以进行解码。空字符串或不存在“region_ids”可指示在已编码码流中，该对应媒体轨道的任何区域都是不可替换或不可替代的。这样，当“region_ids”不是空的时，“sample_merge_flat”应该被设置为1(在解码之前可合并)，并且sample_merge_flag＝1和非空“region_ids”的组合因此可以指示由该对应轨道的“region_ids”表示的已编码数据单元可以被track_order值大于0的的其它轨道替换。此外，在一些示例实施方式中，具有非空“region_ids”的媒体轨道还应具有“track_order”为0，指示该媒体轨道为PiP体验中的主画面。

利用上面的示例配置方案，可以构建用于在媒体容器文件中发信号通知PiP的示例方法。在这种示例方法中：

·容器文件中的预选轨道组输入框(例如，“prse”框)可用于定义被配置为提供PiP体验的轨道组。

·轨道组标识符，例如“track_group_id”，可以在预选轨道组输入框内使用，以指定与示例PiP体验相关联的示例媒体轨道组的标识符。

·整数元素，例如“Num_tracks”，可被包括在轨道组定义中的预选轨道组输入框中，以指示PiP预选组中的组件轨道的总数。

·信息框，例如“kind”框，可被包括在预选轨道组输入框内，以指定预选组在包括PiP的预定义角色集中的角色。

·预选框，例如在轨道框内的“pres”框，用于指定媒体轨道组并且用于指示该轨道是可以被配置用于提供PiP体验的组(PiP预选组)的一部分。

·在媒体轨道的预选框(“pres”)内的轨道组预选标识符，用于标识对应的轨道组，该轨道组与以上“prse”框中的轨道组的定义组合来确定该轨道组是否用于PiP体验。

·预选处理框，例如，媒体轨道的预选框(“pres”)内的“prsp”框，用于定义媒体轨道相对于PiP体验选择组的处理方式。

·优先级值，例如“track_order”，作为与媒体轨道的PiP预选组相关联的媒体轨道的预选处理框(“prsp”)的一部分，用于指示该媒体轨道是PiP体验的主画面(例如，track_order＝0)还是PiP体验的替代画面(例如，track_order＝1)。如果主PiP由多个轨道组成，则这些多个轨道将在“pres”框下包括具有相同track_group_id的“prsp”框，其中track_order为0。

·合并指示，例如“sample_merge_flag”，作为与媒体轨道的PiP预选组相关联的媒体轨道的预选处理框(“prsp”)的一部分，用于指示在解码之前PiP体验中的已编码媒体轨道是否可被该组中的其它已编码轨道合并，例如sample_merge_flag＝1可以指示该轨道是可合并的。

·区域列表，例如“region_ids”，作为与媒体轨道的PiP预选组相关联的媒体轨道的预选处理框(“prsp”)的一部分，用于指定在解码之前用于PiP体验的媒体轨道的可替换区域的标识符列表。

再次，仅作为示例和作为上述信令原理的应用示出，图5的容器文件包括两个轨道预选组，组1和组2，三个媒体轨道，轨道1、轨道2和轨道3。预选轨道组1包含媒体轨道1和轨道2，而预选轨道组2包含媒体轨道1和轨道3。两个预选轨道组都提供了一种PiP体验，如在“kind”框中指定，通过具有值“pip”的“preselection_tag”提供，或“kind”框和“preselection_tag”两者都提供(“kind”框的内容在图5中未示出，但如上所述)。

对于图5的预选轨道组2，PiP体验被定义为可用替换画面流替代主PiP画面的子画面流以进行解码。在用于该示例PiP体验选择组(track_group_id＝2)的两个媒体轨道(媒体轨道1和轨道3)中，媒体轨道1配备有一个“prsp”框，用于指示轨道1如何在PiP体验中相对于另一个媒体轨道(媒体轨道3)被使用。具体地，具有trak_id＝1的媒体轨道形成主画面(如其“track_order”为0所指示的)。作为主画面的媒体轨道1可与来自其它媒体轨道(例如，媒体轨道3)的内容合并，如其针对媒体轨道1设置为“1”的“sample_merge_flag”所指示的。此外，在单次解码之前，媒体轨道1内具有区域ID值为“1”的区域可用媒体轨道3的内容替换。

对于图5的预选轨道组1，由于与主画面轨道1相关联的sample_merge_flag被设置为0，所以通过两个独立的解码(而不是合并流的单个解码)来定义PiP体验。

下面进一步描述可以指定上述媒体容器文件中的PiP签名方案中的元素的语法的方式。

预选处理框定义：

框类型：‘prsp’

容器：PreselectionGroupBox(“pres”)

强制性：否(可选的)

数量：0或1(存在或不存在)

如上所述并且作为示例，该框位于“pres”框内，所述“pres”框位于“trgr”框内，所述“trgr”框位于用于媒体轨道的“trak”框内，该“trak”框位于“moov”框内。它可以包含关于如何处理对预选有贡献的轨道的信息。在一些示例实施方式中，媒体类型特定框可用于描述“prsp”内的进一步处理。该框存在于轨道内的预选框中或不存在于轨道内的预选框中。

预选处理框语法

下面进一步描述预选处理框的各种语法元素的语义。

预选处理框语义

·如下所述，“track_order”定义了该轨道相对于预选组中其它轨道的顺序。

·“sample_merge_flag”等于1指示此轨道在解码之前能够与另一轨道合并。

·“region_ids”指定已编码视频数据单元的白色间隔ID的列表，在解码之前，其相应的替代流可以在该预选中用其它已编码轨道替换。空字符串意味着没有区域是可替换的。例如，仅当track_order＝0时，该字段可以具有非空值。上面已描述，下面将下进一步详细描述该字段对于PiP体验的使用。

例如，对于画中画应用，作为主画面的一部分的每个轨道应具有其track_order＝0。旨在用作主画面(称为替代画面)的一个或多个区域的覆盖或替代的画中画应用中的任何轨道，其track_order应设置为具有高于0的值。较低track_order值指示替代画面的优先级。

样本输入特定规范可能要求将预选的轨道以特定顺序提供给相应的各个解码器实例。由于诸如track_id的其它方式对于该目的而言是不可靠的，所以track_order可用于在预选中相对于彼此对轨道进行排序。较低的数字指示在给定时间，在具有较高轨道序号的轨道的样本之前将对应轨道的样本提供给解码器。如果预选中的两个轨道的track_order被设置为相同的值，或者如果对于至少一个轨道不存在预选处理框，则这些轨道的顺序与预选无关，并且可以以任何顺序向解码器提供样本。

合并组可以被定义为根据track_order进行排序的一组轨道，其中具有sample_merge_flag设置为1的一个轨道后面跟随具有sample_merge_flag设置为0的一组连续轨道。合并组的所有轨道应具有相同的媒体类型，并且应具有按时间排列的所有样本。

如果样本输入类型与合并预选样本的编解码器特定过程相关联，则应使用该过程。

sample_merge_flag＝1和非空region_ids的组合可指示由region_ids中的ids表示的已编码数据单元可由具有track_order值大于0的其它轨道替换。区域ID的具体语义需要针对特定的编解码器进行明确规定。

在一些示例实施方式中，如果合并组中的轨道都是样本输入类型“mhm2”(MPEG-H3D音频)，则可以在例如ISO/IEC 23008-3:2019的子条款14.6中定义合并过程。

在一些示例实施方式中，合并组中的轨道可以具有不同的样本输入类型。

在一些示例实施方式中，如果样本输入类型不与合并预选样本的编解码器特定过程相关联，并且当region_ids为空时，则将使用以下过程：合并组内的合并可以通过在贡献轨道上形成具有相同时间戳的轨道样本的元组。元组内样本的排序可以通过track_order确定。这些元组可以通过样本的逐字节级联来形成，产生具有分配的相应时间戳的单个样本。如果目标是生成新轨道，则每个合并组可以产生一个单独输出轨道，该轨道符合从合并轨道的媒体类型导出的媒体类型。对于不是合并组的一部分的轨道，合并过程不特别或不受本公开的限制。

预选轨道组输入框定义

框类型：‘prse’

容器：TrackGroupDescriptionBox

强制性：否

数量：零或更多

如上所述，“prse”框可以在轨道预选组框“tkgd”内，该轨道预选组框“tkgd”在“moov”框内。它可以包含关于各种预选轨道组的定义的信息。

预选可以例如通过语言、种类或媒体特定属性如音频渲染指示、音频交互性或频道布局来限定。在预选轨道组输入框中发信号通知的属性可以优先于在贡献轨道中发信号通知的属性。

预选轨道组输入框可被配置为仅描述由等于‘prse’的track_group_type标识的轨道组。

在一些示例实施方式中，具有将track_in_movie标志设置为1的至少一个贡献轨道的所有预选可由预选轨道组输入框限定。否则，预选轨道组输入框的存在可以是可选的。

在一些示例实施方式中，唯一地限定预选的所有属性都将存在于预选的预选轨道组输入框中。

预选轨道组输入框语法

下面进一步描述预选处理框的各种语法元素的语义。

预选轨道组输入框语义

预选轨道组输入框“prse”可以包含关于选择对应预选组时可用体验的信息。适于描述预选的框包括但不限于本文定义的以下框列表：

·定义了音频元素的框：AudioElementBox

·提供音频元素选择的框：AudioElementSelectionBox

·指定扩展语言的框：ExtendedLanguageBox

·指定其它用户数据的框：UserDataBox

·指定预选类型和信息的框：KindBox

·提供标签信息的框：LabelBox

·指示音频渲染的框：AudioRenderingIndicationBox

·指定通道布局的框：ChannelLayout

在一些示例实施方式中，如果预选轨道组输入框中包含UserDataBox，则它将不携带任何上述框。

在一些示例实施方式中，num_tracks指定由该预选轨道组分组的非替代轨道的数目。

在一些示例实施方式中，由该预选轨道组分组的轨道可以是具有‘pres’轨道组的轨道，其中track_group_id等于该预选的ID。

在一些示例实施方式中，由该预选轨道组分组的非替代轨道的数目可以是以下各值的总和：

·具有alternate_group等于0并由该预选轨道组分组的轨道数目，

·由该预选轨道组分组的所有轨道中唯一非零alternate_group值的数目。

在一些示例实施方式中，num_tracks的值可以大于或等于该文件中由该预选轨道组分组的非替代轨道的数目。等于0的值可以指示由该轨道组分组的轨道的数目对于处理该轨道组是未知的或者不是必需的。

在一些示例实施方式中，当预选被分拆成多个文件时，num_tracks的值可以大于包含在该文件中具有相同track_group_id的预选组框(“pres”)的非替代轨道的数目。

在一些示例实施方式中，当播放器访问由该预选轨道组分组的非替代轨道少于num_tracks所指示的规定时，播放器可能需要省略由该预选轨道组分组的轨道。

在一些示例实施方式中，preselection_tag可以是回放系统可以向解码器提供的以唯一标识媒体中的若干预选中的一个的编解码器特定值。

在一些示例实施方式中，selection_priority可以是整数，该整数可能在没有其它区分(诸如通过媒体语言)的情况下声明预选的优先级。较低的数字指示较高的优先级。

在一些示例实施方式中，segment_order指定(如果存在的话)建议遵循的段的顺序规则，用于对预选的接收段进行排序。例如，根据ISO/IEC 23009-1:2022，第5.3.11.5款的规定，用语义指定以下值：

0：未定义

1：时序

2：完全有序

在一些示例实施方式中，可以保留其它值。如果segment_order不存在，则应推断其值等于0。

在一些示例实施方式中，不是所有对预选播放有贡献的轨道都可以在同一文件中递送。

在一些示例实施方式中，如上所述，类型框可以利用在ISO/IEC 23009-1:2022，第5.8.5.5款中定义的角色方案，因为它提供了描述预选特性的常用方案。

在一些示例实施方式中，预选轨道组输入框可以携带关于所引用轨道中预选的初始体验的信息。预选体验可以在这些轨道的回放期间改变。例如，音频语言可以在回放期间改变。这些变更不受预选轨道组输入框中呈现的信息的影响。

在一些示例实施方式中，可以使用其他的媒体类型特定框来描述预选的特性。读者可以忽略和跳过无法识别的框。

在一些示例实施方式中，如上所述，可以使用类型框来发信号通知画中画体验，其中通过使用DASH角色方案IdURI和值“pip”，主画面的一个或多个区域可以与一个或多个替代画面叠加。

预选轨道组输入框设计：优势

以上预选轨道组输入框的设计可提供以下若干优点：

·将现有预选轨道组框用于PiP信令

·允许多组PiP共享轨道。

·允许在PiP体验中使用多于1个的替代画面。

·允许主画面由若干轨道组成

·允许用替代流替换主画面子画面/区域，用于对PiP中的所有轨道进行单次解码。

流传输清单中的示例PiP信令

如上所述，除了在媒体容器文件中包括各种信令信息以指定各种媒体内容在PiP体验中的可能的角色和关系之外，这种信令还可以被包括在流传输应用的清单(例如DASHMPD)中，以便向流传输客户端指示各种PiP可能性。然后，流传输客户端将能够解析清单并通过自适应地构建其对内容服务器的媒体请求来确定何时以及如何使用PiP并向用户提供PiP体验。例如，流传输清单中的这种PiP信令可以从与流传输媒体相关联的基本媒体容器文件中的PiP信令导出，如上所述。通常，作为容器文件的媒体文件和与媒体相关联的清单可以在生成时被协调。

在一些示例实施方式中，可以通过现有角色方案来提供作为附加角色的PiP体验。此类角色可以在不同级别的流传输清单中发信号通知。例如，此类角色可以在自适应集级别上发信号通知。

在一个示例实施方式中，如urn:mpeg:dash:role:2011中指定的DASH角色方案的示例值可包括以下值，以便支持清单中的PiP信令>

表1—用于具有值“urn:mpeg:dash:role:2011”的方案的Role@value属性

值“PIP-main”和“PIP-sub”专门用于流传输清单(例如，DASH MPD)中PiP相关信息的信令。这样，在自适应级别处，指定为MPD中自适应集的“PIP-main”的Role@value将向流传输客户端发信号通知，对应自适应集可以是提供PiP体验的主画面的PiP体验的一部分，而指定为MPD中自适应集的“PIP-sub”的Role@value将向流传输客户端发信号通知，对应自适应集可以是提供PiP体验的主画面的替代画面的PiP体验的一部分。

例如，角色方案中的这种角色值可以包括在流传输清单中的画面-画面描述符中，用于发信号通知PIP内容及其配置。此类PiP描述符可以在各种级别处指定。例如，可以在流传输清单中的自适应集级别处指定此类PiP描述符。

例如，自适应集中的SupplementalProperty元素可包括@schemeIdUri属性，该属性等于指定包括PiP值的上述角色方案的预定义urn。

在示例自适应集级别处，用于SupplementalProperty描述符的相同描述符和相同@id来发信号通知的自适应集被认为旨在用于一个PiP体验。如上所述，PiP体验可以由一个或多个主呈现组成。每个主呈现的任何自适应集可以用具有@value＝‘pip-main’的角色描述符来注释。PiP体验还可以包括一个或多个替代呈现，其中一个或多个可以叠加在主呈现中的一个的上面。每个替代呈现的任何自适应集可以用SupplementalProperty描述符中的具有@value＝‘pip-sub’的角色描述符来注释。

在一些示例实施方式中，自适应集可以包括多于一个的PiP描述符，其具有不同的@id以表达多于一个的PiP体验。换句话说，自适应集可以是由自适应集内具有不同@id值的不同PiP描述符标识的多个不同PiP体验的一部分。相同的自适应集可以是多个PiP体验中的一些中的主画面(因此对应@id值的描述符具有@value为“pip-main”)，但是可以是多个PiP体验中的一些其它体验中的子画面(并且因此具有@value为“pip-sub”)。

具体地，一个示例清单主要包括以下各项：

在该示例中，有三个SupplementalProperty ID：1、2和3，每个都表示一个PiP体验。对于SupplementalProperty ID为1的第一PiP体验，自适应集1是主画面，而自适应集2和3是子画面。对于SupplementalProperty ID为2的第二PiP体验，自适应集1是主画面，而自适应集3是子画面。对于SupplementalProperty ID为3的第三PiP体验，自适应集2是主画面，而自适应集1是子画面。

以上描述符可用于自适应集级别以外的级别。这些描述符提供了灵活的方式来将各种自适应集的任意组合发信号通知给PiP体验。自适应集可用于多个PIP体验，它们可以是主画面或子画面。每个PiP体验可以具有一个主自适应集和一个或多个子自适应集。PiP体验由SupplementalProperty描述符的@id标识。

在一些进一步的示例实施方式中，“ContentComponent”元素可被定义并用于描述已编码流的各种子画面的属性，以替换主画面的一部分。

具体地，作为PiP的主呈现的自适应集可使用一个ContentComponent元素来标识要由一个或多个PIP替代呈现所替换的已编码主呈现的内容组成部分。这样，ContentComponent@tag可以包含用于替换过程的解码器的信息。例如，ContentComponent可以指示表示主视频中的目标PiP区域的已编码视频数据单元，以便在将其发送到视频解码器之前用PiP视频的对应已编码视频数据单元替换。以这种方式，可以在单个解码之前合并已编码的PiP流，并且可以避免主视频和PiP视频的单独解码。对于主视频中的特定画面，PiP视频的对应视频数据单元可以是补充视频表示中的解码时间同步样本中的所有已编码视频数据单元。在一些示例实施方式中，ContentComponent@tag的格式和语义可以由对应已编码视频规范来定义。

对于特定的示例已编码视频规范，可以用子画面id来标识用于PiP的子画面。可以使用以下用于ContentComponent@tag的示例语法：

subpic1 subpic2…。

其中：Subpic1、subpic2和…是已编码视频码流的区域的空间分离的子画面id，每个id定义一个子画面，并且id的组定义可用于画中画重叠的整个区域。

在一些示例实施方式中，ContentComponent@id可用于标识该内容组件的区域id，并且可被设置为等于在诸如上述容器文件格式的其它方案中标识的区域id。

ContentComponent的各种示例字段在下面的表2中示出。

表2—用于VVC子画面注释的ContentComponent元素的语义

以上示例ConentComponent元素可以在注释该子画面的自适应集或表示中指定。流传输客户端(例如，DASH客户端)可以向码流操纵器提供注释，以在解码之前用画中画视频流替换期望的子画面流，并且然后将操纵的码流馈送到适当的解码器。

图6示出了用于媒体容器文件中的PiP信令的示例数据和逻辑流程600。在步骤602中，接收以ISO基本媒体文件格式(ISOBMFF)构建的媒体容器文件。媒体容器文件包括要以PiP模式呈现的主媒体轨道和至少一个子媒体轨道。在步骤604中，解析媒体容器文件，以通过用于媒体轨道组定义的预选轨道组输入(Prse)框语法元素来识别用于画中画(PiP)体验的媒体轨道组。在步骤606中，进一步解析媒体容器文件，以通过媒体容器文件中的多个媒体轨道定义内的预选组(Pres)框语法元素来识别属于媒体轨道组的主媒体轨道和至少一个子媒体轨道。在步骤608中，进一步解析所述媒体容器文件以确定合并模式，该合并模式指示在被解码之前，子媒体轨道的已编码数据单元是否要与主媒体轨道的已编码数据单元合并，这取决于主媒体轨道或至少一个子媒体轨道的Pres框语法元素组分内的样本标志合并语法元素的存在或值。在步骤610中，根据合并模式，以PiP模式解码主媒体轨道和至少一个子媒体轨道。

图7示出了用于流传输媒体清单中的PiP信令的另一示例数据和逻辑流程700。在步骤702中，接收来自流传输服务器的流传输媒体清单。在步骤704中，解析流传输媒体清单以识别与一组流传输媒体内容相关联的一组PiP信令信息项。在步骤706中，根据所述PiP信令信息项为该组流传输媒体内容构建自适应请求。在步骤708中，接收所述一组流传输媒体内容。在步骤710中，根据所述PiP信令信息项解码和显示所述一组流传输媒体内容。

上述技术可以通过计算机可读指令实现为计算机软件，并且物理地存储在一个或多个计算机可读介质中。例如，图8示出了计算机系统(800)，其适于实现所公开主题的某些实施例。

所述计算机软件可通过任何合适的机器代码或计算机语言进行编码，通过汇编、编译、链接等机制创建包括指令的代码，所述指令可由一个或多个计算机中央处理单元(CPU)，图形处理单元(GPU)等直接执行或通过译码、微代码等方式执行。

所述指令可以在各种类型的计算机或其组件上执行，包括例如个人计算机、平板电脑、服务器、智能手机、游戏设备、物联网设备等。

图8所示的用于计算机系统(800)的组件本质上是示例性的，并不用于对实现本公开实施例的计算机软件的使用范围或功能进行任何限制。也不应将组件的配置解释为与计算机系统(800)的示例性实施例中所示的任一组件或其组合具有任何依赖性或要求。

计算机系统(800)可以包括某些人机界面输入设备。这种人机界面输入设备可以通过触觉输入(如：键盘输入、滑动、数据手套移动)、音频输入(如：声音、掌声)、视觉输入(如：手势)、嗅觉输入(未示出)，对一个或多个人类用户的输入做出响应。所述人机界面设备还可用于捕获某些媒体，气与人类有意识的输入不必直接相关，如音频(例如：语音、音乐、环境声音)、图像(例如：扫描图像、从静止影像相机获得的摄影图像)、视频(例如二维视频、包括立体视频的三维视频)

人机界面输入设备可包括以下中的一个或多个(仅绘出其中一个)：键盘(801)、鼠标(802)、触控板(803)、触摸屏(810)、数据手套(未示出)、操纵杆(805)、麦克风(806)、扫描仪(807)、照相机(808)。

计算机系统(800)还可以包括某些人机界面输出设备。这种人机界面输出设备可以通过例如触觉输出、声音、光和嗅觉/味觉来刺激一个或多个人类用户的感觉。这样的人机界面输出设备可包括触觉输出设备(例如通过触摸屏(810)、数据手套(未示出)或操纵杆(805)的触觉反馈，但也可以有不用作输入设备的触觉反馈设备)、音频输出设备(例如，扬声器(809)、耳机(未示出))、视觉输出设备(例如，包括阴极射线管屏幕、液晶屏幕、等离子屏幕、有机发光二极管屏的屏幕(810)，其中每一个都具有或没有触摸屏输入功能、每一个都具有或没有触觉反馈功能——其中一些可通过诸如立体画面输出的手段输出二维视觉输出或三维以上的输出；虚拟现实眼镜(未示出)、全息显示器和放烟箱(未示出))以及打印机(未示出)。

计算机系统(800)还可以包括人可访问的存储设备及其相关介质，如包括具有CD/DVD的高密度只读/可重写式光盘(CD/DVD ROM/RW)(820)或类似介质(821)的光学介质、拇指驱动器(822)、可移动硬盘驱动器或固体状态驱动器(823)，诸如磁带和软盘(未示出)的传统磁介质，诸如安全软件保护器(未示出)等的基于ROM/ASIC/PLD的专用设备，等等。

本领域技术人员还应当理解，结合所公开的主题使用的术语“计算机可读介质”不包括传输介质、载波或其它瞬时信号。

计算机系统(800)还可以包括通往一个或多个通信网络(855)的接口(854)。例如，网络可以是无线的、有线的、光学的。网络还可为局域网、广域网、城域网、车载网络和工业网络、实时网络、延迟容忍网络等等。网络还包括以太网、无线局域网、蜂窝网络(包括GSM、3G、4G、5G、LTE等)等局域网、电视有线或无线广域数字网络(包括有线电视、卫星电视、和地面广播电视)、车载和工业网络(包括CAN Bus)等等。某些网络通常需要外部网络接口适配器，用于连接到某些通用数据端口或外围总线(849)(例如，计算机系统(800)的USB端口)；其它系统通常通过连接到如下所述的系统总线集成到计算机系统(800)的核心(例如，以太网接口集成到PC计算机系统或蜂窝网络接口集成到智能电话计算机系统)。通过使用这些网络中的任何一个，计算机系统(800)可以与其它实体进行通信。所述通信可以是单向的，仅用于接收(例如，无线电视)，单向的仅用于发送(例如CAN总线到某些CAN总线设备)，或双向的，例如通过局域或广域数字网络到其它计算机系统。上述的每个网络和网络接口可使用某些协议和协议栈。

上述的人机界面设备、人可访问的存储设备以及网络接口可以连接到计算机系统(800)的核心(840)。

核心(840)可包括一个或多个中央处理单元(CPU)(841)、图形处理单元(GPU)(842)、以现场可编程门阵列(FPGA)(843)形式的专用可编程处理单元、用于特定任务的硬件加速器(844)、图形适配器(850)等。这些设备以及只读存储器(ROM)(845)、随机存取存储器(846)、内部大容量存储器(例如内部非用户可存取硬盘驱动器、固态硬盘等)(847)等可通过系统总线(848)进行连接。在某些计算机系统中，可以以一个或多个物理插头的形式访问系统总线(848)，以便可通过额外的中央处理单元、图形处理单元等进行扩展。外围装置可直接附接到核心的系统总线(848)，或通过外围总线(849)进行连接。在一个例子中，屏幕(810)可连接至图形适配器(850)。外围总线的体系结构包括外部外围组件互联PCI、通用串行总线USB等。

CPU(841)、GPU(842)、FPGA(843)和加速器(844)可以执行某些指令，这些指令组合起来可以构成上述计算机代码。该计算机代码可以存储在ROM(845)或RAM(846)中。过渡数据也可以存储在RAM(846)中，而永久数据可以存储在例如内部大容量存储器(847)中。通过使用高速缓冲存储器可实现对任何存储器设备的快速存储和检索，高速缓冲存储器可与一个或多个CPU(841)、GPU(842)、大容量存储器(847)、ROM(845)、RAM(846)等紧密关联。

所述计算机可读介质上可具有计算机代码，用于执行各种计算机实现的操作。介质和计算机代码可以是为本公开的目的而特别设计和构造的，也可以是计算机软件领域的技术人员所熟知和可用的介质和代码。

作为一非限制性实施例，具有体系结构(800)的计算机系统，特别是核心(840)，可以作为处理器(包括CPU、GPU、FPGA、加速器等)提供执行包含在一个或多个有形的计算机可读介质中的软件的功能。这种计算机可读介质可以是与上述的用户可访问的大容量存储器相关联的介质，以及具有非易失性的核心(840)的特定存储器，例如核心内部大容量存储器(847)或ROM(845)。实现本公开的各种实施例的软件可以存储在这种设备中并且由核心(840)执行。根据特定需要，计算机可读介质可包括一个或一个以上存储设备或芯片。该软件可以使得核心(840)特别是其中的处理器(包括CPU、GPU、FPGA等)执行本文所述的特定过程或特定过程的特定部分，包括定义存储在RAM(846)中的数据结构以及根据软件定义的过程来修改这种数据结构。另外或作为替代，计算机系统可以提供逻辑硬连线或以其它方式包含在电路(例如，加速器(844))中的功能，该电路可以代替软件或与软件一起运行以执行本文所述的特定过程或特定过程的特定部分。在适当的情况下，对软件的引用可以包括逻辑，反之亦然。在适当的情况下，对计算机可读介质的引用可包括存储执行软件的电路(如集成电路(IC))，包含执行逻辑的电路，或两者兼备。本公开包括任何合适的硬件和软件组合。

虽然本公开已对多个示例性实施例进行了描述，但实施例的各种变更、排列和各种等同替换均属于本公开的范围内。因此应理解，本领域技术人员能够设计多种系统和方法，所述系统和方法虽然未在本文中明确示出或描述，但其体现了本公开的原则，因此属于本公开的精神和范围之内。

Claims (20)

1.一种获得画中画(PiP)信息的方法，其特征在于，包括：

检索以ISO基本媒体文件格式(ISOBMFF)构建的媒体容器文件，其中所述媒体容器文件包括要以PiP模式呈现的主媒体轨道和至少一个子媒体轨道；

解析所述媒体容器文件，以通过用于媒体轨道组定义的预选轨道组输入(Prse)框语法元素来识别用于PiP体验的媒体轨道组；

解析所述媒体容器文件，以通过所述媒体容器文件中的多个媒体轨道定义内的预选组(Pres)框语法元素来识别属于所述媒体轨道组的所述主媒体轨道和所述至少一个子媒体轨道；

解析所述媒体容器文件以确定合并模式，所述合并模式指示在被解码之前，根据所述主媒体轨道或所述至少一个子媒体轨道的所述Pres框语法元素的组分内的样本标志合并语法元素的存在或值，是否将所述至少一个子媒体轨道的已编码数据单元与所述主媒体轨道的已编码数据单元合并；以及

根据所述合并模式，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道。

2.根据权利要求1所述的方法，其特征在于，所述Prse框语法元素属于所述媒体容器文件中配置为定义媒体轨道组的第一预定义类型的语法元素。

3.根据权利要求2所述的方法，其特征在于：

所述第一预定义类型的语法元素各自包括媒体轨道组类型标签元素；并且

所述媒体轨道组类型标签元素使用一组预定义目的关键字来指示对应媒体轨道组的预期体验，包括所述PiP体验。

4.根据权利要求2所述的方法，其特征在于：

所述第一预定义类型的语法元素各自包括媒体轨道组类型描述符；并且

所述媒体轨道组类型描述符被配置为使用具有预定义角色的角色方案来指定对应媒体轨道组的预期体验，包括所述PiP体验。

5.根据权利要求2所述的方法，其特征在于，所述媒体容器文件中的所述第一预定义类型的语法元素中的每一个包括对应媒体轨道组的多个轨道。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述Pres框语法元素属于媒体轨道定义内的第二预定义类型的语法元素，所述媒体轨道定义被配置为使用对应的媒体轨道组标识符来指定所述媒体轨道与一媒体轨道组的关联。

7.根据权利要求6所述的方法，其特征在于，所述第二预定义类型的语法元素中的每一个包括媒体轨道组处理描述符(prsp)，用于指定关于所述媒体轨道组的所述媒体轨道的PiP处理。

8.根据权利要求7所述的方法，其特征在于，所述媒体轨道组处理描述符包括优先级参数以指示所述媒体轨道相对于所述媒体轨道组中的其它媒体轨道的优先级顺序。

9.根据权利要求8所述的方法，其特征在于，所述PiP体验的所述主媒体轨道的所述优先级参数包括用于PiP处理的最高优先级值。

10.根据权利要求9所述的方法，其特征在于，所述PiP体验的所述至少一个子媒体轨道的所述优先级参数包括用于PIP处理的较低优先级值。

11.根据权利要求7所述的方法，其特征在于，所述样本标志合并语法元素属于第三预定义类型的语法元素，所述第三预定义类型的语法元素被对应地包括在与主媒体轨道相关联的所述媒体轨道组处理描述符中。

12.根据权利要求11所述的方法，其特征在于，与所述主媒体轨道相关联的所述第三预定义类型的语法元素具有指示在被解码之前所述主媒体轨道与所述子媒体轨道合并的一预定义值。

13.根据权利要求12所述的方法，其特征在于，当与所述主媒体轨道相关联的所述第三预定义类型的语法元素具有所述预定义值时，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道包括：将所述主媒体轨道的所述已编码数据单元和所述至少一个子媒体轨道的所述已编码数据单元合并以进行单个解码。

14.根据权利要求12所述的方法，其特征在于，所述媒体轨道组处理描述符包括一区域标识参数，所述区域标识参数用于指示在解码之前，要与其它媒体轨道的已编码流合并的相应媒体轨道的已编码流中的区域列表。

15.根据权利要求14所述的方法，其特征在于，当与所述主媒体轨道相关联的所述第三预定义类型的语法元素具有所述预定义值时，与所述主媒体轨道相关联的所述区域标识参数为非空。

16.根据权利要求14所述的方法，其特征在于，当所述媒体轨道的所述优先级顺序不是最高时，即使所述媒体轨道的所述区域标识参数存在，也忽略所述区域标识参数。

17.根据权利要求14所述的方法，其特征在于，当所述媒体轨道的所述区域标识参数为非空时，所述媒体轨道的所述优先级顺序相应地为最高。

18.根据权利要求12所述的方法，其特征在于，当与所述主媒体轨道相关联的所述第三预定义类型的语法元素不具有所述预定义值时，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道包括：通过分开的独立解码来处理所述主媒体轨道和所述至少一个子媒体轨道。

19.根据权利要求1至5中任一项所述的方法，其特征在于，所述主媒体轨道和所述至少一个子媒体轨道属于由所述媒体容器文件中的另一Prse框语法元素指示的另一媒体轨道组。

20.一种媒体处理设备，其特征在于，包括用于存储指令的存储器和用于执行所述指令的处理器，以：

检索以ISO基本媒体文件格式(ISOBMFF)构建的媒体容器文件，其中所述媒体容器文件包括要以PiP模式呈现的主媒体轨道和至少一个子媒体轨道；

解析所述媒体容器文件，以通过用于媒体轨道组定义的预选轨道组输入(Prse)框语法元素来识别用于画中画(PiP)体验的媒体轨道组；

解析所述媒体容器文件，以通过所述媒体容器文件中的多个媒体轨道定义内的预选组(Pres)框语法元素的语法元素来识别属于所述媒体轨道组的所述主媒体轨道和至少一个子媒体轨道；

解析所述媒体容器文件以确定合并模式，所述合并模式指示在被解码之前，根据所述主媒体轨道或所述至少一个子媒体轨道的所述Pres框语法元素的组分内的样本标志合并语法元素的存在或值，是否将所述至少一个子媒体轨道的已编码数据单元与所述主媒体轨道的已编码数据单元合并；以及

根据所述合并模式，以所述PiP模式解码所述主媒体轨道和所述至少一个子媒体轨道。