阅读说明：本技术 用于虚拟现实的方法、装置和计算机程序产品 (Method, apparatus and computer program product for virtual reality ) 是由 K·卡马施斯里达 I·库尔西奥 M·汉努卡塞拉 S·S·马特 A·埃姆雷 于 2019-12-13 设计创作，主要内容包括：用于虚拟现实的方法、装置和计算机程序产品。本发明涉及一种解决方案,其中生成定义呈现的比特流,该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；在比特流中指示与第一视觉媒体分量相关联的第一呈现时间线；在比特流中指示与第二视觉媒体分量相关联的第二呈现时间线；在比特流中指示到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及在比特流中指示该切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。(Methods, apparatuses, and computer program products for virtual reality. The invention relates to a solution wherein a bitstream is generated defining a presentation comprising omnidirectional visual media content and a first visual media component and a second visual media component; indicating in the bitstream a first presentation timeline associated with the first visual media component; indicating in the bitstream a second presentation timeline associated with a second visual media component; indicating in the bitstream a switching pattern to a second presentation timeline associated with a second visual media component; and indicating in the bitstream whether the switching pattern is with respect to the first presentation timeline or with respect to the second presentation timeline.)

用于虚拟现实的方法、装置和计算机程序产品

技术领域

本解决方案通常涉及虚拟现实。

背景技术

自从照相术和电影摄影术开始以来，最普通类型的图像和视频内容已通过具有相对较窄视场的相机捕获，并在平面显示器上显示为矩形场景。在本申请中，这样的内容被称为“平面内容”或“平面图像”或“平面视频”。相机主要是定向的，因此它们仅捕获有限的角度视场(它们指向的视场)。

最近，有新的图像和视频捕获设备可用。这些设备能够捕获周围的所有视觉和音频内容，即它们可以捕获整个角度视场(有时也称为360度视场)。更准确地说，它们可以捕获球形视场(即，在所有空间方向上均为360度)。此外，已经发明并生产了新型的输出技术，例如头戴式显示器。这些设备使一个人可以看到他/她周围的视觉内容，给人一种“沉浸”在360度相机捕获的场景中的感觉。新的捕获和显示范式(其中视场为球形)通常称为虚拟现实(VR)，并且被认为是人们将来体验媒体内容的常用方式。

发明内容

现在已经发明了用于编码和解码的改进方法和实现该方法的技术设备。本发明的各个方面包括一种方法、一种装置以及一种包括存储在其中的计算机程序的计算机可读介质，特征在于独立权利要求中所陈述的内容。本发明的各种实施例在从属权利要求中予以公开。

根据第一方面，提供了一种方法，该方法包括：生成定义呈现的比特流，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；在比特流中指示与第一视觉媒体分量相关联的第一呈现时间线；在比特流中指示与第二视觉媒体分量相关联的第二呈现时间线；在比特流中指示到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及在比特流中指示切换模式是关于第一呈现时间线或者是关于第二呈现时间线的。

根据第二方面，提供了一种装置，该装置包括处理器、存储器以及驻留在该存储器中的计算机程序代码，其中，当由处理器执行时该计算机代码被配置为使该装置：生成定义呈现的比特流，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；在比特流中指示与第一视觉媒体分量相关联的第一呈现时间线；在比特流中指示与第二视觉媒体分量相关联的第二呈现时间线；在比特流中指示到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及在比特流中指示切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

根据第三方面，提供了一种方法，该方法包括：从比特流确定呈现，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；从比特流解码与第一视觉媒体分量相关联的第一呈现时间线；从比特流解码与第二视觉媒体分量相关联的第二呈现时间线；从比特流解码到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及从比特流解码切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

根据第四方面，提供了一种装置，该装置包括处理器、存储器以及驻留在该存储器中的计算机程序代码，其中，当由处理器执行时该计算机代码被配置为使该装置：从比特流确定呈现，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；从比特流解码与第一视觉媒体分量相关联的第一呈现时间线；从比特流解码与第二视觉媒体分量相关联的第二呈现时间线；从比特流解码到与第二视觉媒体分量相关的第二呈现时间线的切换模式；以及从比特流解码切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

根据第五方面，提供了一种体现在计算机可读介质上的包括计算机程序代码的计算机程序产品，该计算机程序代码被配置为当在至少一个处理器上执行时使装置或系统：生成定义呈现的比特流，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；在比特流中指示与第一视觉媒体分量相关联的第一呈现时间线；在比特流中指示与第二视觉媒体分量相关联的第二呈现时间线；在比特流中指示到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及在比特流中指示切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

根据第六方面，提供了一种体现在计算机可读介质上的包括计算机程序代码的计算机程序产品，该计算机程序代码被配置为当在至少一个处理器上执行时使装置或系统：从比特流确定呈现，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；从比特流解码与第一视觉媒体分量相关联的第一呈现时间线；从比特流解码与第二视觉媒体分量相关联的第二呈现时间线；从比特流解码到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及从比特流解码切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

根据一个实施例，在比特流中指示/从比特流解码主呈现时间线或用以创建播放器呈现时间线的指示；以及在比特流中指示/从比特流解码切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的或者是关于主呈现时间线或播放器呈现时间线的。

根据一个实施例，在比特流中指示/从比特流解码第二视觉媒体分量的检索机制。

根据一个实施例，在容器(container)格式中包括关于切换模式的信息。

根据一个实施例，在非暂时性计算机可读介质上体现计算机程序产品。

附图说明

在下文中，将参考附图更详细地描述本发明的各种实施例，其中

图1示出了球坐标与方位角和仰角与X、Y和Z坐标轴的关系的示例；

图2示出了将球形图片转换为打包图片的示例；

图3示出了OMAF视频处理步骤的示例；

图4示出了无缝切换的示例；

图5示出了切换到零时间的示例；

图6示出了切换到偏移时间的示例；

图7是示出根据实施例的方法的流程图；

图8是示出根据另一实施例的方法的流程图；以及

图9示出了根据实施例的装置。

具体实施方式

在下文中，将在例如全向内容的沉浸式多媒体(即虚拟现实)的上下文中描述本发明的几个实施例。与2D内容的消费相比，最终用户对全向内容的消费更为复杂。这是由于最终用户可以使用的自由度更高。这种自由还导致更多的不确定性。当例如在覆盖(overlay)的情况下渲染内容的层时，情况变得更加复杂。

可用的媒体文件格式标准包括国际标准组织(ISO)基本媒体文件格式(ISO/IEC14496-12，其可以缩写为ISOBMFF)、运动图像专家组(MPEG)-4文件格式(ISO/IEC 14496-14，也称为MP4格式)、NAL(网络抽象层)单元结构视频的文件格式(ISO/IEC 14496-15)和高效视频编码标准(HEVC或H.265/HEVC)。

下面描述ISOBMFF的一些概念、结构和规范作为容器文件格式的示例，基于其可以实现实施例。本发明的各方面不限于ISOBMFF，而是描述给出了一种可能的基础的，在此基础上可以部分或完全地实现本发明。

采用ISO基本媒体文件格式的基本构建块称为盒子(box)。每个盒子都有报头和有效载荷。盒子报头指示盒子的类型和以字节为单位的盒子的大小。盒子类型可以由无符号的32比特整数(被解释为四字符代码(4CC))来标识。盒子可以包围(enclose)其他盒子，ISO文件格式指定在某种类型的盒子中允许哪些盒子类型。此外，每个文件中某些盒子的存在可能是强制性的，而其他盒子的存在可能是可选的。另外，对于某些盒子类型，可能允许一个文件中包含多个盒子。因此，可以考虑使用ISO基本媒体文件格式来指定盒子的层次结构。

根据ISO基本媒体文件格式，文件包括封装进盒子中的媒体数据和元数据。

在符合ISO基本媒体文件格式的文件中，可以在MediaDataBox(“mdat”)的一个或多个实例中提供媒体数据，而MovieBox(“moov”)可以用于包含针对定时媒体的元数据。在某些情况下，为了使文件可操作，可能需要同时存在“mdat”和“moov”盒子。“moov”盒子可以包括一个或多个轨道，每个轨道可以驻留在一个对应的TrackBox(“trak”)中。每个轨道都与由四字符代码标识的指定轨道类型的处理程序(handler)相关联。视频、音频和图像序列轨道可以统称为媒体轨道，并且它们包含初级媒体流(elementary media stream)。其他轨道类型包括提示轨道和定时元数据轨道。

轨道包括样本，例如音频或视频帧。对于视频轨道，媒体样本可以对应于编码图片或访问单元。

媒体轨道是指根据媒体压缩格式(及其对ISO基本媒体文件格式的封装)格式化的样本(也可以称为媒体样本)。提示轨道是指提示样本，包含用于构建通过所指示的通信协议传输的分组的指南(cookbook)指令。定时元数据轨道可以指描述所指的媒体和/或提示样本的样本。

“trak”盒子在其盒子的层次结构中包括SampleDescriptionBox，其提供有关所使用的编码类型的详细信息以及该编码所需的任何初始化信息。SampleDescriptionBox包含条目计数和多达条目计数指示数量的示例条目。样本条目的格式是特定于轨道类型的，但是是从通用类(例如VisualSampleEntry、AudioSampleEntry)派生的。哪种类型的样本输入形式被用于派生该轨道类型特定的样本输入格式，是由轨道的媒体处理程序确定的。

可以例如在将内容记录到ISO文件时使用电影分段，例如以避免在记录应用程序崩溃、内存空间不足或发生其他意外时丢失数据。没有电影分段，可能发生数据丢失，因为文件格式可能要求将所有元数据(例如电影盒子)写入文件的一个连续区域中。此外，当记录文件时，可能没有足够的存储空间(例如随机存取存储器(RAM))来针对可用存储大小缓冲电影盒子，并且在电影结束时重新计算电影盒子的内容可能太慢。此外，电影分段可以使得能够使用常规的ISO文件解析器同时记录和回放文件。此外，渐进式下载(例如在使用电影分段时同时接收和回放文件)可能需要更短的初始缓冲持续时间，并且与具有相同媒体内容且在没有电影分段的情况下被结构化的文件相比，初始电影盒子更小。

电影分段特征可以使得能够将原本可能驻留在电影盒子中的元数据拆分为多条。每条可以对应于轨道的特定时间段。换句话说，电影分段特征可以使得能够对文件元数据和媒体数据进行交织。因此，电影盒子的尺寸可以是有限的，并且可以实现上述用例。

在一些示例中，电影分段的媒体样本可以驻留在mdat盒子中。但是，对于电影分段的元数据，可以提供moof盒子。moof盒子可以包括针对一定回放时间持续时间的先前在moov盒子中已经存在的信息。moov盒子仍旧可以自己表示有效电影，但除此之外，它还可以包括mvex盒子，指示在同一文件中将随有电影分段。电影分段可以及时扩展与moov盒子相关联的呈现。

在电影分段内可以存在轨道分段集，包括每轨道的从零到多个的任何位置。轨道分段又可以包括从零到多个轨道运行的任意位置，每个轨道文档都是对于该轨道的连续样本运行(因此类似于块(chunk))。在这些结构内，许多字段是可选的，并且可以是默认的。可以包括在moof盒子中的元数据可以限于可以包括在moov盒子中并且在某些情况下可以被不同地编码的元数据的子集。可以从ISOBMFF规范中找到有关可以包括在moof盒子中的盒子的细节。可以将自包含的(self-contained)电影分段定义为以文件顺序连续的moof盒子和mdat盒子组成，并且mdat盒子包含电影分段的样本(moof盒子为其提供元数据)，并且不包含任何其他电影分段的样本(即任何其他的momo盒子)。

媒体分段可以包括一个或多个自包含的电影分段。媒体分段可以用于例如MPEG-DASH中的传送(例如流式传送)。

ISO基本媒体文件格式包含三种针对可与特定样本相关联的定时元数据的机制：样本组、定时元数据轨道和样本辅助信息。派生的规范可以通过这三种机制中的一种或多种提供类似的功能。

基于分组标准，可以将以ISO基本媒体文件格式及其衍生形式进行的样本分组定义为基于分组条件，将轨道中每个样本分配为一个样本组的成员。样本分组中的样本组不限于紧邻的样本，并且可以包含不相邻的样本。由于对于轨道中的样本可能有多个样本分组，因此每个样本分组都可以具有类型字段来指示分组的类型。样本分组可以由两个链接的数据结构表示：(1)SampleToGroupBox(sbgp盒子)表示将样本分配到样本组；以及(2)SampleGroupDescriptionBox(sgpd盒子)包含用于每个样本组的描述该组的属性的样本组条目。基于不同的分组标准，可以存在SampleToGroupBox和SampleGroupDescriptionBox的多个实例。这些可以通过用于指示分组类型的类型字段来区分。SampleToGroupBox可以包括grouping_type_parameter字段，该字段可用于例如指示分组的子类型。可以在SampleGroupDescriptionBox中提供默认的样本组条目，适用于未映射在同一样本分组的任何SampleToGroupBox中的所有样本。

在ISOMBFF中，编辑列表提供了呈现时间线和媒体时间线之间的映射。尤其是，编辑列表提供了轨道中样本的呈现的线性偏移，提供了空闲时间的指示，并提供了将要滞留特定时间段的特定样本。呈现时间线可以被相应地修改以提供循环，例如用于场景的各个区域的循环视频。下面提供了包括编辑列表的盒子的一个示例，即EditListBox：

在ISOBMFF中，EditListBox可以包含在EditBox中，而EditBox包含在TrackBox(“trak”)中。

在编辑列表盒子的此示例中，标志指定了编辑列表的重复。举例来说，将盒子flags(最低有效位，即ANSI-C表示法中的flags&1，其中&指示按比特的与运算)内的特定比特设置为0表示不重复编辑列表，而将特定比特(即ANSI-C表示法中的flags&1)设置为1表示重复编辑列表。可以将大于1的盒子标志的值定义为保留以供将来扩展。这样，当编辑列表盒子指示播放零个或一个样本时，(flags&1)应等于零。当重复编辑列表时，在时间0由该编辑列表产生的媒体紧随具有由该编辑列表产生的最大时间的媒体，从而无缝地重复该编辑列表。

在ISOBMFF中，“轨道”组可以基于某些特征对轨道进行分组，或者组中的轨道具有特定的关系。但是，轨道分组不允许组中有任何图像项目。

ISOBMFF中TrackGroupBox的语法如下：

aligned(8)class TrackGroupBox extends Box('trgr'){

}

aligned(8)class TrackGroupTypeBox(unsigned int(32)track_group_type)

extends FullBox(track_group_type,version＝0,flags＝0)

{

unsigned int(32)track_group_id；

//可以针对特定track_group_type规定剩余数据

}

track_group_type指示grouping_type，并且应被设置为以下值之一、或已注册的值、或来自派生规范或注册的值：

“msrc”指示该轨道属于多源呈现。

在track_group_type'msrc'的TrackGroupTypeBox内，具有相同track_group_id值的轨道被映射为源自同一来源。例如，视频电话呼叫的记录可能同时具有两个参与者的音频和视频，并且与一个参与者的音频轨道和视频轨道相关联的track_group_id的值不同于与另一参与者的轨道相关联的track_group_id的值。

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

实体(Entity)分组与轨道分组相似，但是使得能够对相同组中的轨道和图像项目两者进行分组。

ISOBMFF中EntityToGroupBox的语法如下。

group_id是分配给特定分组的非负整数，该非负整数不得等于任何其他EntityToGroupBox的任何group_id值、包含GroupsListBox的层次结构级别(文件、电影或轨道)的任何item_ID值或任何track_ID值(当GroupsListBox包含在文件级别时)。

num_entities_in_group指定映射到该实体组的entity_id值的数量。

当在包含GroupsListBox的层次结构级别(文件、电影或轨道)中存在item_ID等于entity_id的项目时，则将entity_id解析为项目；当track_ID等于entity_id的轨道存在并且GroupsListBox包含在文件级别中时，将entity_id解析为轨道。

符合ISOBMFF的文件可以在meta盒子(四字符代码：“meta”)中包含任何非定时对象(称为项目、元项目或元数据项目)。尽管元盒子的名称指元数据，但项目通常可以包含元数据或媒体数据。元盒子可以位于文件的顶级、位于电影盒子(四字符代码：“moov”)内、以及位于轨道盒子(四字符代码：“trak”)内，但最多只能有一个元盒子可以在文件级别、电影级别或轨道级别的每个级别处发生。可以要求元盒子包含指示“元”盒子内容的结构或格式的“hdlr”盒子。元盒子可以列出并表征可以引用的任何数量的项目，并且每个项目都可以与文件名相关联，并由作为整数值的项目标识符(item_id)被文件唯一地识别。元数据项可以例如存储在元盒子的“idat”盒子中或在“mdat”盒子中或驻留在单独的文件中。如果元数据位于文件外部，则其位置可以由DataInformationBox(四字符代码：“dinf”)声明。在使用XML语法格式化元数据并要求将其直接存储在MetaBox中的特定情况下，可以将元数据封装到XMLBox(四字符代码：“xml”)或BinaryXMLBox(四字符代码：'bxml')中。项目可以存储为连续的字节范围，也可以存储为多个区段(extent)，每个区段都是连续的字节范围。换句话说，可以将项目分段地存储到区段中，例如以使得能够进行交织。区段是资源的连续字节子集；可以通过级联区段来形成资源。

ItemPropertiesBox使得任何项目能够与有序项目属性集相关联。项目属性可以视为小数据记录。ItemPropertiesBox由两部分组成：包含项目属性的隐式索引列表的ItemPropertyContainerBox；以及将项目与项目属性相关联的一个或多个ItemPropertyAssociationBox。

高效图像文件格式(HEIF)是由运动图像专家组(MPEG)开发的用于存储图像和图像序列的标准。尤其是，该标准促进了根据高效视频编码(HEVC)标准编码的数据的文件封装。HEIF包括在使用的ISO基本媒体文件格式(ISOBMFF)之上的特征构建。

在HEIF的设计中，很大程度上使用了ISOBMFF结构和特征。HEIF的基本设计包括将静止图像存储为项目，将图像序列存储为轨道。

在HEIF的上下文中，以下盒子可以包含在根级别的“元”盒子中，并且可以按以下说明使用。在HEIF中，“元”盒子的处理程序盒子的处理程序值为“pict”。包含编码媒体数据的资源(无论是在同一文件内还是在由统一资源标识符标识的外部文件中)通过“数据信息”(“dinf”)盒子解析，而“项目位置”(“iloc”)盒子存储引用文件中每个项目的位置和大小。“项目引用”('iref')盒子使用类型化引用记录了项目之间的关系。如果项目集合中有项目以某种方式被认为是与其他项目相比最重要的项目，则该项目由“主项目”(“pitm”)盒子发信号通知。除了此处提到的盒子外，“元”盒子也很灵活，以包括描述项目所必需的其他盒子。

同一文件中可以包括任意数量的图像项目。给定使用“元”盒子方法存储的集合图像，有时必须限定图像之间的某些关系。这样的关系的示例包括指示用于集合的封面图像、为集合中的一些或所有图像提供缩略图、以及将集合中的一些或所有图像与诸如阿尔法平面的辅助图像相关联。使用“pitm”盒子指示图像集合中的封面图像。缩略图或辅助图像分别使用类型为'thmb'或'auxl'的项目引用链接到主图像项目。

实体可以被定义为轨道或项目的统称。实体组是项目的分组，也可以对轨道进行分组。当分组的实体没有明确的依赖关系或方向引用关系时，可以使用实体组代替项目引用。实体组中的实体共享特定的特征或具有特定的关系，如分组类型所示。

实体组是项目的分组，也可以对轨道进行分组。实体组中的实体共享特定的特征或具有特定的关系，如分组类型所示。

实体组在GroupsListBox中指示。在文件级MetaBox的GroupsListBox中指定的实体组是指轨道或文件级项目。电影级MetaBox的GroupsListBox中指定的实体组是指电影级项目。在轨道级MetaBox的GroupsListBox中指定的实体组是指该轨道的轨道级项目。

GroupsListBox包含EntityToGroupBoxes，每个指定一个实体组。EntityToGroupBox的语法规定如下：

当在包含GroupsListBox的层次结构级别(文件、电影或轨道)中存在item_ID等于entity_id的项目时，将entity_id解析为项目；当track_ID等于entity_id的轨道存在并且GroupsListBox包含在文件级别中时，将entity_id解析为轨道。

Trackbox中包含的TrackGroupBox使得能够指示轨道组，其中每个组共享特定的特征，或者组内的轨道具有特定的关系。该盒子包含零个或多个盒子，并且特定特征或关系由所包含盒子的盒子类型指示。包含的盒子包括标识符，该标识符可用于推测属于同一轨道组的轨道。包含与在TrackGroupBox中包含的相同类型盒子并且在这些包含的盒子内具有相同标识符值的轨道属于同一轨道组。通过TrackGroupTypeBox定义包含的盒子的语法如下：

Matroska文件格式能够(但不限于)将视频、音频、图片或字幕轨道中的任何一个存储在一个文件中。Matroska可用作所导出的文件格式(例如WebM)的基础格式。Matroska使用可扩展二进制元语言(EBML)作为基础。EBML受XML原理的启发，规定了二进制和八位字节(字节)对齐的格式。EBML本身是二进制标记技术的概括描述。Matroska文件由构成EBML“文档”的“元素(Elements)”组成。元素包含元素ID、元素大小的描述符和二进制数据本身。元素可以嵌套。Matroska的分段元素是用于其他顶级(级别1)元素的容器。Matroska文件可以包括一个分段(但不限于由其组成)。Matroska文件中的多媒体数据按集群(Cluster)(或集群元素)进行组织，其中每个都可以包含几秒钟的多媒体数据。集群包括BlockGroup元素，而BlockGroup元素又包括块元素(Block Elements)。提示元素(Cues Element)包括可以辅助随机访问或查找的元数据，并且可以包括用于查找点的文件指针或相应的时间戳。

统一资源标识符(URI)可以被定义为用于标识资源名称的字符串。这样的标识使得能够使用特定协议通过网络与资源的表示进行交互。URI是通过一种方案定义的，该方案指定了URI的具体语法和相关联协议。统一资源定位符(URL)和统一资源名称(URN)是URI的形式。URL可以被定义为URI，URI标识Web资源并指定对资源表示进行操作或获得资源表示的手段，指定其主访问机制和网络位置。URN可以被定义为通过特定名称空间中的名称标识资源的URI。URN可以用于标识资源，而不暗示其位置或访问方式。

超文本传输协议(HTTP)已被广泛用于通过互联网(例如视频流应用)传递实时多媒体内容。已经推出了几种用于HTTP上的自适应流式传送(例如SmoothStreaming、Adaptive HTTP Live Streaming和Dynamic Streaming)的商业解决方案，并且已经执行了标准化项目。自适应HTTP流(AHS)首先在第三代合作伙伴计划(3GPP)分组交换流(PSS)服务的版本9(3GPP TS 26.234版本9：“透明的端到端分组交换流服务(PSS)”；协议和编解码器”)中进行了标准化。MPEG以3GPP AHS版本9作为MPEG DASH标准的起点(ISO/IEC 23009-1：“HTTP上的动态自适应流(DASH)-第1部分：媒体呈现描述和分段格式”，国际标准，第二版，2014)。MPEG DASH和3GP-DASH在技术上彼此接近，因此可以统称为DASH。

下面描述DASH的一些概念、结构和规范作为容器文件格式的示例，基于其可以实施实施例。本发明的各方面不限于DASH，而是给出了一种可能的基础的描述，在此基础上可以部分或完全地实现本发明。

在DASH中，多媒体内容可以存储在HTTP服务器上，也可以使用HTTP进行传递。内容可以分为两部分存储在服务器上：媒体呈现描述(MPD)，其描述可用内容的清单、其各种替代方案、它们的URL地址和其他特征；以及分段，其以块的形式在单个或多个文件中包含实际多媒体比特流。MDP为客户端提供必要的信息，以通过HTTP建立动态自适应流式传输。MPD包含描述媒体呈现的信息(例如每个分段的HTTP统一资源定位符(URL))，以进行GET分段请求。为了播放内容，DASH客户端可以例如通过使用HTTP、电子邮件、拇指驱动器、广播或其他传输方法获得MPD。通过解析MPD，DASH客户端可以了解程序定时、媒体内容可用性、媒体类型、分辨率、最小和最大带宽、以及多媒体分量的各种编码替代方案、可访问性特征和所需的数字版权管理(DRM)的存在、网络上的媒体分量位置以及其他内容特征。使用该信息，DASH客户端可以选择适当的编码替代方案，并通过使用例如HTTP GET请求获取分段来开始流式传输内容。在进行适当的缓冲以允许网络吞吐量变化之后，客户端可以继续获取后续分段，并且还监控网络带宽波动。客户端可以通过获取不同替代方案(具有较低或较高比特率)的分段来决定如何适应可用带宽，以维持足够的缓冲区。

在DASH的上下文中，可以使用以下定义：媒体内容组件或媒体分量可以被定义为媒体内容的具有所分配的媒体分量类型的一个连续组件，其可以被单独编码为媒体流。媒体内容可以被定义为一个媒体内容时段或媒体内容时段的连续序列。媒体内容组件类型可以被定义为诸如音频、视频或文本之类的媒体内容的单一类型。媒体流可以被定义为媒体内容组件的编码版本。

在DASH中，分层数据模型被用于构造如下所示的媒体呈现。媒体呈现由一个或多个周期(Period)系列组成，每个周期包含一个或多个组，每个组包含一个或多个适应集(Adaptation Sets)，每个适应集包含一个或多个表示(Representation)，每个表示由一个或多个分段组成。组(Group)可以被定义为不希望同时呈现的适应集的集合。适应集可以被定义为一个或几个媒体内容组件的可互换编码版本的集合。表示是媒体内容或其子集的替代选择之一，其可以不同在于编码选择，例如比特率、分辨率、语言、编解码器等。分段包含某些持续时间的媒体数据，以及用于解码和呈现所包括媒体内容的元数据。分段由URI标识，并且可以由HTTP GET请求来请求。分段可以被定义为与HTTP-URL相关联的数据单位，并且可选地定位为由MPD指定的字节范围。

DASH MPD符合可扩展标记语言(XML)，并且因此如XML中定义的那样通过元素和属性指定。可以使用以下约定来指定MPD：XML文档中的元素可以由大写的首字母标识，并且可以以粗体显示为Element。为了表示元素Element1被包含在另一个元素Element2中，可以编写Element2.Element1。如果元素的名称由两个或两个以上的组合词组成，则可以使用骆驼式大小写格式(camel-casing)，例如ImportantElement。元素可以只出现一次，也可以通过<minOccurs>...<maxOccurs>定义最小和最大出现次数。XML文档中的属性可以由小写的首字母标识，也可以在其前加上“@”符号，例如@attribute。为了指向元素Element中包含的特定属性@attribute，可以编写[email protected]。如果属性的名称由两个或两个以上的组合词组成，则可以在第一个词之后使用骆驼式大小写格式，例如@veryImportantAttribute。属性可以在XML中已分配了状态为强制(M)、可选(O)、可选带有默认值(OD)和有条件强制(CM)。

在DASH中，所有描述符元素都可以以相同的方式构造，即它们包含@schemeIdUri属性(其提供用于标识方案的URI)、可选属性@value和可选属性@id。元素的语义特定于所采用的方案。标识方案的URI可以是URN或URL。在MPEG-DASH(ISO/IEC 23009-1)中指定了一些描述符，而在其他规范中可以附加或替代地指定描述符。当在MPEG-DASH以外的规范中指定时，MPD不提供有关如何使用描述符元素的任何特定信息。使用适当的方案信息实例化描述元素取决于采用DASH格式的应用程序或规范。使用这些元素之一的应用程序或规范以URI形式定义方案标识符(Scheme Identifier)，以及使用该方案标识符时用于该元素的值空间。方案标识符出现在@schemeIdUri属性中。在要求简单的枚举值集的情况下，可以为每个值定义文本字符串，并且该字符串可以包括在@value属性中。如果要求结构化数据，则可以在单独的名称空间中定义任何扩展元素或属性。@id值可用于指代唯一描述符或一组描述符。在后一种情况下，可以要求对于属性@id具有相同值的描述符是同义的，即，具有对于@id的相同值的描述符之一的处理就足够了。如果元素名称、@schemeIdUri的值和@value属性的值是等效的，则DescriptorType类型的两个元素是等效的。如果@schemeIdUri是URN，则等效性可以指RFC2141第5条中定义的词汇等效性(lexical equivalence)。如果@schemeIdUri是URL，则等效性可以指代RFC3986的条款6.2.1中定义的逐字符基础的相等性。如果@value属性不存在，则等效性可以只由@schemeIdUri的等效性确定。扩展名称空间中的属性和元素可能不会用于确定等效性。在等效性确定时，可以忽略@id属性。

MPEG-DASH指定描述符EssentialProperty和SupplementalProperty。对于元素EssentialProperty，媒体呈现作者表示，描述符的成功处理对于正确使用包含此描述符的父元素中的信息至关重要，除非该元素与另一个EssentialProperty元素共享相同的@id。如果EssentialProperty元素共享相同的@id，则处理具有相同@id值的EssentialProperty元素之一就足够了。每个不同的@id值至少应有一个EssentialProperty元素将被处理。如果未识别该方案或EssentialProperty描述符的值，则DASH客户端应忽略包含该描述符的父元素。MPD中可以存在具有相同的@id值和具有不同的@id值的多个EssentialProperty元素。

对于元素SupplementalProperty，媒体呈现作者表示描述符包含补充信息，DASH客户端可以使用该补充信息进行优化处理。如果未识别针对SupplementalProperty描述符的方案或值，则DASH客户端应忽略该描述符。MPD中可以存在多个SupplementalProperty元素。

MPEG-DASH指定视点(Viewpoint)元素，其被格式化为属性描述符。视点元素的@schemeIdUri属性用于标识所采用的视点方案。包含非等效视点元素值的适应集包含不同的媒体内容组件。视点元素可以等同地应用于非视频的媒体内容类型。具有等同视点元素值的适应集旨在一起呈现。对于已识别和未识别的@schemeIdUri值，应等同地应用此处理。

SRD(空间关系描述)在MPEG-DASH的规范性附录H中指定。以下包含SRD规范的一些摘录。

SRD方案允许媒体呈现描述(Media Presentation Description)作者表达空间对象(Spatial Objects)之间的空间关系。空间对象由或者适应集或者子表示(SubRepresentation)来表示。举例来说，空间关系可以表示视频代表另一个全帧视频的空间部分(例如感兴趣的区域或图块(tile))。

@schemeIdUri等于“urn:mpeg:dash:srd:2014”的SupplementalProperty和/或EssentialProperty描述符用于提供与包含的空间对象相关联的空间关系信息。SRD应仅包含在这两个MPD元素(适应集和子表示)中。

子表示级别SRD可用于表示一种表示(例如HEVC图块流)的空间对象。在这种情况下，SRD描述符可以出现在适应集以及子表示级别。

使用SRD方案的SupplementalProperty或EssentialProperty元素的@value是逗号分隔的SRD参数值列表。需要存在SRD参数source_id、object_x、object_y、object_width和object_height，并且有条件地或可选地存在SRD参数total_width、total_height和space_set_id。

source_id是十进制表示的非负整数，提供内容来源的标识符。source_id参数在周期内为内容的源提供唯一的标识符。它隐式定义了与此源相关联的坐标系。该坐标系使用任意原点(0；0)；x轴从左到右，y轴从上到下。共享相同source_id值的所有SRD具有相同的原点和轴方向。未定义使用带有不同source_id值的SRD的空间对象的空间关系。

对于给定的source_id值，定义参考空间，该参考空间对应于包含整个源内容的矩形区域，该区域的左上角位于坐标系的原点。SRD中的total_width和total_height值提供以任意单位表示的此参考空间的大小。total_width是十进制表示的非负整数，以任意单位表示参考空间的宽度。total_height是十进制表示的非负整数，以任意单位表示参考空间的高度。允许MPD中没有覆盖全部内容源的空间对象，例如当整个源内容由两个单独的视频表示时。

object_x是十进制表示的非负整数，以任意单位表示空间对象左上角的水平位置。object_y是十进制表示的非负整数，以任意单位表示空间对象左上角的垂直位置。object_width是十进制表示的非负整数，以任意单位表示空间对象的宽度。object_height是十进制表示的非负整数，以任意单位表示空间对象的高度。object_x和object_y参数(分别为object_width和object_height)表示相关联的空间对象在与源相关联的坐标系中的2D位置(分别为2D大小)。如上定义，object_x、object_y、object_width和object_height参数的值是相对于total_width和total_height参数的值。共享相同source_id值的SRD的位置(object_x，object_y)和大小(object_width，object_height)可以在考虑参考空间的大小之后进行比较，即，将object_x和object_width值除以total_width值并且object_y和object_height值除以它们各自描述符的total_height值。可以在不同的描述符中使用不同的total_width和total_height值，以为同一参考空间提供不同单位的位置和尺寸信息。

spatial_set_id是十进制表示的非负整数，为一组空间对象提供标识符。如果不存在，则与此描述符关联的空间对象不属于任何空间集，并且不提供任何空间集信息。MPD作者可以使用spatial_set_id参数表示给定source_id内的某些空间对象具有特定的空间关系。例如，MPD作者可以将与图块对应的所有适应集以相同的分辨率级别分组。这样，DASH客户端可以使用spatial_set_id参数来快速选择与空间相关的空间对象。

初始化分段可以被定义为包含用于呈现封装在媒体分段中的媒体流所必需的元数据的分段。在基于ISOBMFF的分段格式中，初始化分段可以包括电影盒子(“moov”)，该电影盒子可以不包括任何样本的元数据，即，样本的任何元数据在“moof”盒子中提供。

媒体分段包含某些持续时间的媒体数据用于以正常速度回放，这样的持续时间称为媒体分段持续时间或分段持续时间。内容生产者或服务提供者可以根据服务的期望特征来选择分段持续时间。例如，可以在实时服务中使用相对较短的分段持续时间，以实现较短的端到端延迟。原因是分段持续时间可以是DASH客户端感知的端到端延迟的下限，因为分段是生成用于DASH的媒体数据的离散单位。可以通过使整个媒体数据分段可用于服务器的方式来完成内容生成。此外，许多客户端实现使用分段作为GET请求的单位。因此，在直播服务的布置中，仅当整个持续时间的媒体分段可用且已编码并封装到分段中时，DASH客户端才能请求分段。对于按需服务，可以使用选择分段持续时间的不同策略。

分段可以进一步划分为子分段，例如以便可以将分段下载为多个部分。可以要求分段包含完整的访问单元。子分段可以由分段索引(Segment Index)盒子进行索引，该盒子包含用于映射每个子分段的呈现时间范围和字节范围的信息。分段索引盒子还可以通过发信号通知子分段和流访问点的持续时间和字节偏移，来描述分段中的子分段和流访问点。DASH客户端可以使用从分段索引盒子获得的信息，来使用字节范围HTTP请求进行针对特定子分段的HTTP GET请求。如果使用了相对较长的分段持续时间，则可以使用子分段来保持HTTP响应的大小合理和灵活，以适应比特率。分段的索引信息可以放在该分段的开头的单个盒子中，也可以散布在该分段的许多索引盒子中。可以有不同的散布方法，例如分层、菊花链(daisy chain)和混合。此技术可以避免在分段的开头添加大盒子，并且因此可以防止可能的初始下载延迟。

子表示嵌入常规表示中，并由子表示元素进行描述。子表示元素包含在表示元素中。子表示元素描述了嵌入在表示中的一个或几个媒体内容组件的特性。例如，它可以描述嵌入式音频组件(例如编解码器、采样率等)、嵌入式字幕(例如编解码器)的确切特性，或者它可以描述一些嵌入式质量较低的视频层(例如一些较低的帧速率或其他)。子表示和表示共享一些共同的属性和元素。如果子表示元素中存在@level属性，则适用以下：

子表示提供了访问包含它们的表示的较低质量版本的能力。在这种情况下，子表示例如允许提取在多路复用的表示中的音频轨道，或者如果提供了较低的帧速率，则可以允许有效的快进或快退操作；

初始化分段和/或媒体分段和/或索引分段应提供足够的信息，以便可以通过HTTP部分GET请求轻松访问数据。提供此类信息的细节由使用的媒体格式定义。

当使用ISOBMFF分段时，适用以下：

初始化分段包含级别分配(Level Assignment)盒子。

针对每个子分段均存在“子分段索引”盒子(“ssix”)。

属性@level指定子分段索引中与所描述的子表示相关联的级别。

表示、子表示和级别分配(“leva”)盒子中的信息包含有关将媒体数据分配给级别的信息。

媒体数据应具有顺序从而使得每个级别都提供相比于低级别的增强。

如果@level属性不存在，则子表示元素仅用于为嵌入在表示中的媒体流提供更详细的描述。

ISOBMFF包括用于指定文件子集的所谓的级别机制。级别遵循依赖性层次结构，从而使得映射到级别n的样本可以取决于级别m的任何样本，其中m<＝n，并且不取决于级别p的任何样本，其中p>n。例如，可以根据时间子层(例如HEVC的TemporalId)指定级别。可以在电影扩展(Movie Extends)(“mvex”)盒子中包含的级别分配(“leva”)盒子中宣布级别。无法为初始电影指定级别。在存在级别分配盒子时，则该盒子应用于初始电影之后的所有电影分段。对于级别分配盒子的上下文，分段(fraction)被定义为由一个或多个电影分段盒子和关联的媒体数据盒子组成，可以仅包括最后媒体数据盒子的初始部分。在分段中，每个级别的数据连续出现。分段内的级别的数据按级别值的升序出现。分段中的所有数据都被分配级别。级别分配盒子提供了从特征(例如可伸缩性层或时间子层)到级别的映射。可以通过轨道、轨道内的子轨道或轨道的样本分组来指定特征。例如，时间级别样本分组可以用于指示图片到时间级别的映射，时间级别相当于HEVC中的时间子层。也就是说，可以使用时间级别样本分组将特定TemporalId值的HEVC图片映射到具体时间级别(并且可以对所有TemporalId值重复相同的操作)。然后，级别分配盒子可以指代所指示的到级别的映射中的时间级别样本分组。

子分段索引盒子(“ssix”)提供了已索引子分段的从级别(由级别分配盒子指定)到字节范围的映射。换句话说，该盒子提供针对如何根据部分子分段中的级别将子分段中的数据排序的紧凑索引。它通过下载子分段中的数据范围，使客户端能够容易地访问针对部分子分段的数据。在存在子分段索引盒子时，则子分段中的每个字节都被分配级别。如果范围未与级别分配中的任何信息相关联，则可以使用未包括在级别分配中的任何级别。仅索引叶分段(即仅索引子分段而没有分段索引)的每个分段索引盒子都存在0或1个分段索引盒子。子分段索引盒子(如果有)是相关联的分段索引盒子之后的下一个盒子。子分段索引盒子记录了在紧接在前的分段索引盒子中指示的子分段。每个级别可以被精确地分配给一个部分子分段，即，一个级别的字节范围是连续的。通过增加子分段内的数字来分配部分子分段的级别，即，部分子分段的样本可以取决于同一子分段中前部分子分段的任何样本，但不是相反。例如，每个部分子分段包含具有相同的时间子层的样本，并且部分子分段以增加的时间子层顺序出现在子分段内。当以这种方式访问部分子分段时，最终的媒体数据盒子可以不完整，也就是说，访问的数据少于媒体数据盒子的长度指示所指示呈现的。媒体数据盒子的长度可能需要调整，或者可以使用填充。级别分配盒子中的padding_flag指示是否可以将该丢失的数据替换为零。如果不，则分配到未访问级别的样本的样本数据不被呈现，并且应格外小心。

MPEG-DASH为ISOBMFF和MPEG-2传输流定义了分段容器格式。其他规范可以基于其他容器格式指定分段格式。例如，已经提出了基于Matroska容器文件格式的分段格式，并且可以总结如下。当Matroska文件作为DASH分段或类似文件承载时，DASH单位和Matroska单位的关联可以指定如下。(DASH的)子分段可以被定义为Matroska封装的内容的一个或多个连续的集群。可以要求DASH的初始化分段包括EBML报头、(Matroska的)分段报头、(Matroska的)分段信息和轨道，并且可以可选地包括其他level1元素和填充。DASH的分段索引可以包括Matroska的提示元素。

全向媒体格式(OMAF)(正式称为ISO/IEC 23090-2)是由运动图像专家组(MPEG)开发的标准，正式称为ISO/IEC JTC1/SC29/WG11。OMAF的第一版本(以下称为OMAF v1)已于2017年底在技术上完成。在撰写本公开内容时，OMAF v2的修订工作已经启动。在本节中描述了OMAF的一些关键定义和概念作为示例，其中可以实现实施例。本发明的各方面不限于OMAF或其扩展，而是出于一种可能的基础给出了描述，在此基础上可以部分或完全实现本发明。

OMAF通过扩展ISOBMFF、HEIF和DASH来定义媒体格式，以启用专注于360度内容(例如视频、图像、音频、文本)的全向媒体应用。OMAF与单个3DoF内容的全向流有关，其中观看者位于单位球体的中心，并具有三个自由度(偏航角-俯仰角-翻滚角(Yaw-Pitch-Roll))。下一阶段的标准化(MPEG-1阶段1b)可以实现多个3DoF和3DoF+内容消费，以及与用户交互的覆盖支持。

OMAF指定了一个坐标系，该坐标系由一个单位球体和三个坐标轴组成，即X(从后到前)轴、Y(从侧面、左侧到右侧)轴和Z(垂直、向上)轴，其中三个轴在球体的中心交叉。

点在单位球体上的位置由一对球坐标方位角(φ)和仰角(θ)标识。图1示出了球坐标方位角(φ)和仰角(θ)与X、Y和Z坐标轴的关系。方位角的值范围是-180.0度(含)到180.0度(不含)。仰角的值范围是-90.0度到90.0(含)度。

全局坐标轴可以例如根据如上所述的坐标系被定义为与表示相同采集位置相关联并打算一起渲染的音频、视频和图像的坐标轴。全局坐标轴的原点通常与用于全向音频/视频采集的设备或装置的中心点以及音频和视频轨道所在的三维空间中观察者头部的位置相同。

360度全景或全向三自由度(3DoF)内容(即图像和视频)在成像设备的拍摄位置周围水平地覆盖了整个360度视场。垂直视场可以有所不同，并且可以是例如180度。可以通过球体来表示覆盖水平360度视场和垂直180度视场的全景图像，该球体已经使用等矩形投影(ERP)映射到二维图像平面。在这种情况下，在不应用任何变换或缩放的情况下，可以将水平坐标视为等同于经度，将垂直坐标视为等同于纬度。在某些情况下，水平视场360度但垂直视场小于180度的全景内容可以被认为是等矩形投影的特殊情况，其中球体的极地区域(polar areas)尚未映射到二维图像平面。在某些情况下，全景内容可以具有小于360度的水平视场和高达180度的垂直视场，而其他情况下则具有等矩形投影格式的特征。

在立方体图投影格式中，球形视频被投影到立方体的六个面(又称侧面)上。可以例如首先从具有以表示每个立方体面的90度视锥体定义的视图的视点渲染球形场景六次，来生成立方体图。立方体侧面可以被帧打包到同一帧中，或者每个立方体侧面可以被单独地处理(例如在编码中)。将立方体侧面放置在帧上的可能顺序有很多，和/或立方体侧面可以旋转或镜像。可以选择用于帧打包的帧宽度和高度，以例如以3x2立方体侧网格“紧密地”适合立方体侧面，或者可以例如以4x3立方体侧网格包括未使用的构成帧。

等矩形投影可以被定义为将(等矩形投影格式的)投影图片内的任何样本位置转换为坐标系的角坐标的过程。可以相对于pictureWidth和pictureHeight来定义投影图片内的样本位置，pictureWidth和pictureHeight分别是样本中等矩形全景图片的宽度和高度。在下文中，将沿着水平和垂直轴的样本位置的中心点分别标示为i和j。样本位置的以度为单位的角坐标(φ,θ)，由以下等矩形映射方程式给出：φ＝(0.5-i÷pictureWidth)*360,θ＝(0.5-j÷pictureHeight)*180。

通常，可以将360度内容映射到不同类型的实体几何结构上，例如多面体(即包含平坦多边形面、直边和尖角或顶点的三维实体对象，例如立方体或金字塔)、圆柱体(通过将球面图像投影到圆柱体上，如上文所述通过等矩形投影)、圆柱体(直接而不首先投影到球体上)、圆锥体等，然后被展开为二维图像平面。二维图像平面也可以被视为几何结构。换句话说，可以将360度内容映射到第一几何结构上并进一步展开为第二几何结构。但是，可以从原始360度内容或从其他宽视野视觉内容直接获取到第二几何结构的变换。通常，全向投影格式可以被定义为在二维图像平面上表示(最多)360度内容的格式。全向投影格式的示例包括等矩形投影格式和立方体图投影格式。

在某些情况下，水平视场360度但垂直视场小于180度的全景内容可以被认为是等矩形投影的特殊情况，其中球体的极地区域尚未映射到二维图像平面。在某些情况下，全景图像可以具有小于360度的水平视场和高达180度的垂直视场，而其他情况下具有等矩形投影格式的特征。

图2示出了可以在内容创作中使用的从球形图片210到打包图片240的转换，以及可以在OMAF播放器中使用的从打包图片到要渲染的球形图片的相应转换。图2中示出的示例是针对出现在投影全向视频轨道中的打包图片进行描述的。可以针对图像项得出类似的描述。图2示出了与全局坐标轴对齐的单位球体210和与局部坐标轴对齐的单位球体220。另外，图2示出了投影图像230，在其上指定了用于区域打包的区域。

OMAF视频处理步骤的示例如图3所示。

投影结构(例如球体)可以相对于全局坐标轴旋转。可以执行旋转，以例如基于内容在某些球形部分处的空间和时间活动来实现更好的压缩性能。替代地或附加地，可以执行旋转以调整已经编码的内容的渲染取向。例如，如果编码内容的水平线不是水平的，则可以随后通过指示相对于全局坐标轴旋转投影结构来对其进行调整。投影取向可以被指示为定义投影结构的取向的偏航角、俯仰角和翻滚角或相对于全局坐标轴的局部坐标轴。投影取向可以被包括在例如用于全向视频的ISOBMFF轨道的样本条目中的盒子中。

按区域打包信息可以被编码为比特流中或沿比特流的元数据。例如，打包信息可以包括从预定义或指示的源格式到打包帧格式(例如从投影图片到打包图片，如前所述)的按区域的映射。

接下来描述矩形的按区域打包元数据。对于每个区域，元数据定义投影图片中的一个矩形、打包图片中的相应矩形、以及旋转90度、180度或270度的可选变换和/或水平和/或垂直镜像。矩形可以例如由左上角和右下角的位置指示。该映射可以包括重采样。由于在投影和打包的图片中各个矩形的大小可以不同，因此该机制可以推测按区域的重采样。

OMAF定义了用于关联各种DASH元素的MPEG-DASH元素。具有@schemeIdUri属性等于“urn:mpeg:mpegI:omaf:2018:assoc”的SupplementalProperty元素被称为关联描述符。一个或多个关联描述符可以出现在适应集级别、表示级别、预选择级别。包括在适应集/表示/预选择元素内的关联描述符指示该元素的描述符的父元素(即适应集/表示/预选择元素)与omaf2中XPath查询所指示的MPD中的一个或多个元素相关联：由omaf2:@associationKindList发信号通知的关联元素和关联类型。

在OMAF DASH MPD中，具有@schemeIdUri属性等于“urn:mpeg:mpegI:omaf:2018:vwpt”的视点元素被称为视点信息(VWPT)描述符。

在适应集级别上最多可以存在一个VWPT描述符，而在任何其他级别上都不应存在VWPT描述符。当媒体呈现中没有适应集包含VWPT描述符时，媒体呈现被推测为仅包含一个视点。

@value指定视点的视点ID。ViewPointInfo是容器元素，其子元素和属性提供有关视点的信息。[email protected]属性指定一个字符串，该字符串提供针对该视点的人类可读的标签。该元素的ViewPointInfo.Position属性指定针对视点的位置信息。

在MPEG 123中，VR-IF发布了一份包括以下要求的联络声明：

·应该可以将交互式VR应用程序构建为一组VR 360流以及它们之间的导航关系和条件。简而言之，VR内容包括足够的信息来描述交互式体验的所有故事线路径，而交互逻辑留给VR应用程序。

·应该可以构建一个交互式VR应用，其中VR内容的特定部分将循环直到用户具有进一步导航到交互式VR内容的故事线所需的正确交互。

·应该可以通过在VR 360内容之上使用媒体内容的覆盖(可以带有透明元素)，并允许用户与此类覆盖的媒体进行交互，来构建交互式VR应用。

·由于定义了附加在内容中特定位置的传感器，因此应使得能够进行用户交互。传感器定义是在VR内容中完成的，并且可以包括诸如传感器位置、大小和形状之类的信息。用户对这种传感器的触发的响应也应在传感器本身中描述。这包括诸如切换到新VR流、切换到新覆盖媒体或更改覆盖媒体的位置之类的动作。

基于这些要求，需要定义当用户从一个视觉媒体实体切换到另一视觉媒体实体时的定时信息；以及主时间线，基于该主时间线呈现视觉媒体实体并在它们之间相对切换。

在该说明书中，术语“随机访问”是指解码器在流的起始点以外的点开始解码流并恢复准确的或近似的重构媒体信号(例如解码图片的表示)的能力。可以使用随机访问点和恢复点来表征随机访问操作。可以将随机访问点定义为在媒体流中可以启动解码的位置(例如视频比特流内的访问单元或编码图片)。可以将恢复点定义为媒体流中或重构信号内的第一位置，其特征在于当解码已从相应的随机访问点开始时，按输出顺序在恢复点处或恢复点之后所有媒体(诸如解码图片)的内容都是正确的或近似正确的。如果随机访问点与恢复点相同，则随机访问操作是瞬时的；否则，它可以是渐进的。

随机访问点使得能够进行例如在本地存储的媒体流以及媒体流式传输中的查找、快进播放和快退播放操作。在涉及点播流式传输的上下文中，服务器可以通过发送从最接近(以及在许多情况下，先于)查找操作的所请求目的地的随机访问点开始的数据来响应查找请求，并且/或者解码器可以从最接近(以及在许多情况下，先于)查找操作的所请求目的地的随机访问点开始解码。在不同比特率的编码流之间切换是一种在单播流式传输中常用的方法，用于将传输的比特率与预期的网络吞吐量匹配，并避免网络拥塞。在随机访问点有可能切换到另一个流。此外，随机访问点使得能够调谐到广播或多播。另外，可以将随机访问点编码为对源序列中的场景剪切的响应或对图片内更新请求的响应。

视口(viewport)可以被定义为适合于用户显示和观看的全向图像或视频的区域。当前视口(有时可以简称为视口)可以被定义为当前显示并因此能由用户观看的球形视频的一部分。在任何时间点，由应用在头戴式显示器(HMD)上渲染的视频都会渲染360度视频的一部分(其被称为视口)。类似地，当在常规显示器上观看360度内容的空间部分时，当前显示的空间部分是视口。视口是通过渲染显示器显示的在全向视频中表示的360度世界上的窗口。视口的特征在于水平视场(VHFoV)和垂直视场(VVFoV)。在下文中，视口的水平视场将被缩写为HFoV，而相应地视口的垂直视场将被缩写为VFoV。

球体区域可以被定义为球体上的区域，该区域可以由四个大圆或两个方位角圆和两个仰角圆以及另外的平铺角指定，该平铺角指示沿着源自于球体原点并通过球体区域的中心点的轴的旋转。大圆可以被定义为球体与穿过球体中心点的平面的交叉。大圆也称为矫正圆(orthodrome)或黎曼圆。方位角圆可以被定义为球体上连接所有具有相同方位角值的点的圆。仰角圆可以被定义为球体上连接所有具有相同仰角值的点的圆。

OMAF为球体区域指定了通用的定时元数据语法。定时元数据轨道的目的由轨道样本条目类型指示。指定的球体区域的所有元数据轨道的样本格式均以公共部分开头，并且可以其后紧随特定于元数据轨道的样本条目的扩展部分。每个样本都指定一个球体区域。

在OMAF中指定的特定球体区域定时元数据轨道之一被称为推荐视口定时元数据轨道，它指示当用户没有视线方向控制或已经释放视线方向控制时应显示的视口。推荐的视口定时元数据轨道可以用于基于“导演的剪辑(director's cut)”或基于观看统计的测量来指示推荐视口。可以在示例条目中提供所推荐视口的文字描述。所推荐视口的类型可以在示例条目中指示，并且可以在以下各项中：

根据导演剪辑的所推荐视口，例如根据内容作者或内容提供者的创作意图建议的视口。

视点或观察点是用户观看场景的点；它通常对应于相机位置。轻微的头部运动并不意味着会有其他视点。

如本文所使用的，术语“观察点或视点”是指三维空间中用于虚拟现实音频/视频获取或回放的量。视点是围绕用于全向音频/视频采集的设备或装置的中心点的轨迹(例如圆、区域或体积)，以及观察者的头部在音频和视频轨道所位于的三维空间中的位置。在某些情况下，跟踪观察者的头部位置，并除头部旋转之外还针对头部运动调整渲染，然后视点可以被理解为观察者头部的初始或参考位置。在利用DASH(HTTP上的动态自适应流式传输)的实现中，每个观察点可以由视点特性描述符定义为视点。该定义可以以ISOBMFF或OMAF类型的文件格式存储。除了DASH之外，传递还可以是HLS(HTTP实时流式传输)、RTSP/RTP(实时流式传输协议/实时传输协议)流式传输。

如本文所使用的，术语“视点组”是指在空间上相关或逻辑上相关的一个或多个视点。可以基于针对组的指定原点为每个视点定义的相对位置，来定义视点组中的视点。每个视点组还可以包括默认视点，该默认视点反映了当用户开始消费视点组中的视听内容而不选择视点进行播放时的默认播放起点。默认视点可以与指定原点相同。在一些实施例中，一个视点可以被包括在多个视点组中。

如本文所使用的，术语“空间上相关的视点组”是指具有在它们之间具有空间关系的内容的视点。例如，由VR相机在同一篮球场中不同位置捕获的内容，或从舞台上不同位置捕获的音乐演唱会。

如本文所使用的，术语“逻辑上相关的视点组”是指没有明确的空间关系但是在逻辑上相关的相关视点。逻辑上相关的视点的相对位置是基于创作意图来描述的。例如，作为逻辑上相关的视点组的成员的两个视点可以对应于来自表演区和更衣室的内容。另一个示例可以是来自两个竞争团队的更衣室中的两个视点，这些视点形成了逻辑上相关的视点组，以允许用户在两个团队之间穿行以观看选手的反应。

如本文所用，术语“静态视点”是指在一个虚拟现实音频/视频获取和回放会话期间保持静止的视点。例如，静态视点可以对应于由固定相机执行的虚拟现实音频/视频获取。

如本文所使用的，术语“动态视点”是指在一个虚拟现实音频/视频获取和回放会话期间不保持静止的视点。例如，动态视点可以对应于由在轨道上的移动相机或在飞行的无人机上的移动相机执行的虚拟现实音频/视频获取。

如本文所使用的，术语“观看设置”是指一个或多个视点和观看取向的设置。在只有一个视点可用的呈现的上下文中，无需为视点设置明确指示或总结视点。如果呈现具有多个可用的视点，则将基于一个或多个视点组来设置视点，并且将在视图设置中指示每个视点组中视点之间的空间或逻辑关系。

覆盖是指在360度视频内容上渲染视觉媒体的术语。视频和/或图像可以覆盖在全向视频和/或图像上。编码的覆盖视频可以是当前渲染的360度视频/图像的单独流或部分比特流。全向流式传输系统可以将视频/图像覆盖在正被渲染的全向视频/图像之上。被覆盖的二维视频/图像可以具有矩形网格或非矩形网格。覆盖过程可以覆盖该被覆盖视频/图像或视频/图像的一部分，或者可以存在一定级别的透明度/不透明度或不止一个级别的透明度/不透明度，其中被覆盖视频/图像可以在覆盖视频/图像下方看到但亮度较低。换句话说，可以存在与前景覆盖中的视频/图像和背景中的视频/图像(VR场景的视频/图像)相对应的相关联透明度级别。术语不透明度和透明度可以互换使用。

被覆盖区域可以具有一个或多个级别的透明度。例如，被覆盖区域可以具有具有不同透明度的不同部分。根据实施例，可以将透明度级别定义为在一定范围内，例如从0到1，以使得该值越小则透明度越小，反之亦然。

附加地，内容提供商可以选择将相同的全向视频的一部分覆盖在用户的当前视口上。内容提供商可以希望基于用户的观看条件来覆盖视频。例如，如果用户的视口与内容提供商的推荐视口不匹配，则可以执行覆盖。在这种情况下，客户端播放器逻辑会将内容提供商的推荐视口(作为预览窗口)覆盖在用户的当前视口的顶部。如果用户的当前视口不匹配，也可以覆盖推荐的视口，从而使覆盖视频的位置基于用户观看的方向。例如，如果推荐的视口位于用户的当前视口的左侧，则将推荐视口覆盖在显示器的左侧。也可以覆盖整个360度视频。又一个示例是使用覆盖视觉信息作为引导机制来将用户引导至推荐的视口，例如引导听力受损的人。

可以存在关于何时以及如何显示可视覆盖的一个或多个条件。因此，渲染设备可能需要接收信息，该设备可以使用该信息来执行如由发信号通知的信息所指示的覆盖。

可以在单个视觉媒体轨道或单个图像项中承载一个或多个覆盖。当在单个轨道或图像项中承载一个以上的覆盖时，或者利用其他媒体(例如背景)承载覆盖时，可以例如在OverlayStruct中或与之相关联地提供从轨道或图像项的样本到覆盖元数据的区域映射。

当几个轨道或图像项共同地承载一个或多个覆盖和/或背景视觉媒体时，可以在容器文件中指示一组轨道和图像项。例如，ISOBMFF的实体组可用于此目的。

覆盖可以落在用户的视场(FOV)之外，也就是说，用户的视口将不与该覆盖重叠。取决于特定情况，可以希望在用户不观看覆盖时继续或暂停覆盖的播放。例如，可以希望暂停覆盖播放的时间线，直到覆盖再次与用户的视口重叠。即使覆盖位于用户的视口之外，也可以希望继续播放覆盖。因此，需要一种支持多个回放时间线的机制，该机制又使得能够进行独立于基本内容的定制覆盖回放/暂停。因此，根据示例实施例提供了一种方法、装置和计算机程序产品，以便使得能够进行在具有覆盖的全向媒体内容的回放中的多个时间线支持，这又使得能够进行取决于覆盖是否与用户的视口重叠的定制的覆盖回放行为。

当前，用户可以通过使用客户端播放器提供的任何切换机制从一个覆盖视觉实体切换到另一覆盖视觉实体。当用户从一个覆盖切换到另一个覆盖时，可以发生以下情况：

-当覆盖切换需要是无缝时(无缝切换是指直到某个时间t的解码数据的呈现，以及从时间t开始的另一表示的解码数据的呈现)

-当覆盖切换要求从其起始样本“切换到”覆盖的回放时；

-当覆盖切换需要从某个时间偏移“切换到”覆盖的回放时。

当用户从一个视点切换到另一视点时，以上所有情况均有效。本实施例针对这些方面。

如参考图2所讨论的，已经从球形图片转换的打包图片可以用于内容创作中，以及可以从打包图片到要渲染的可以在OMAF播放器中使用的球形图片的对应转换。

根据本实施例，内容创作可以包括以下内容：

-在比特流、容器文件和/或清单中指示；与第一媒体分量相关联的第一呈现时间线；

-在比特流、容器文件和/或清单中指示；与第二媒体分量相关联的第二呈现时间线；

-在比特流、容器文件和/或清单中指示；到与第二媒体分量相关联的第二呈现时间线的切换模式

-在比特流、容器文件和/或清单中指示；切换模式是关于与第一媒体分量相关联的第一呈现时间线的或者是关于与第二媒体分量相关联的第二呈现时间线的。

在另一个实施例中，内容创作还可以包括以下内容：

-在比特流、容器文件和/或清单中指示；要使用的主/全局呈现时间线；

-在没有主/全局呈现时间线的情况下，内容作者可以在比特流、容器文件和/或清单中指示；将要使用的播放器呈现时间线的创建；其中

-在比特流、容器文件和/或清单中指示；切换模式是关于与第一媒体分量相关联的第一呈现时间线的或者是关于与第二媒体分量相关联的第二呈现时间线的或者是关于主/全局呈现时间线的或者是关于播放器呈现时间线的。

根据本实施例，播放器处的内容消费步骤可以包括以下内容：

-从比特流、容器文件和/或清单解析；与第一媒体分量相关联的第一呈现时间线；

-从比特流、容器文件和/或清单解析；与第二媒体分量相关联的第二呈现时间线；

-从比特流、容器文件和/或清单解析；到与第二媒体分量相关联的第二呈现时间线的切换模式

-从比特流、容器文件和/或清单解析；切换模式是关于与第一媒体分量相关联的第一呈现时间线的或者是关于与第二媒体分量相关联的第二呈现时间线的或者是关于主/全局呈现时间线的或者是关于播放器呈现时间线的。在既没有主/全局呈现时间线又没有用以创建播放器呈现时间线的指示的情况下，播放器仍可以创建并维持其自己的呈现时间线，并且所有切换模式都将关于播放器呈现时间线的。

根据另一个实施例，播放器处的内容消费步骤还可以包括以下内容：

-从比特流、容器文件和/或清单解析；要使用的主/全局呈现时间线；

-在没有主/全局呈现时间线的情况下；从比特流、容器文件和/或清单解析：要使用的播放器呈现时间线的创建；在既没有主/全局呈现时间线又没有创建播放器呈现时间线的指示的情况下(如先前实施例的情况)，播放器仍可以创建并维持其自己的呈现时间线，其中

-从比特流、容器文件和/或清单解析；切换模式是关于与第一媒体分量相关联的第一呈现时间线的或者是关于与第二媒体分量相关联的第二呈现时间线的或者是关于主/全局呈现时间线的或者是关于播放器呈现时间线的。在既没有主/全局呈现时间线又没有用以创建播放器呈现时间线的指示的情况下(如先前实施例的情况)，播放器仍可以创建并维持其自己的呈现时间线，并且所有切换模式将关于播放器呈现时间线。

本实施例提出了一种用于在用户从可以是第一覆盖的第一媒体分量切换到可以是第二覆盖的第二媒体分量时发信号通知切换模式的方法。在一个实施例中，可以有两个以上的媒体分量用于消费，并且可以在比特流、容器文件和/或清单中指示彼此之间的切换模式。

在以下示例中，将通过两个媒体分量来说明切换模式：第一媒体分量，在此称为切换自媒体分量(switched-from media component)，用户从其切换到第二媒体分量；以及第二媒体分量，在此称为切换到媒体分量(switched-to media component)。

时间线切换模式可以是以下之一：

ο无缝切换；

ο切换到零时间；

ο切换到偏移时间；

ο切换到最近的随机访问点。

图4示出了切换模式的第一示例，即无缝切换。无缝切换是指切换自媒体分量的解码数据的呈现直到一定时间t，以及切换到媒体分量的解码数据的呈现从时间t开始。图4示出了“切换自”媒体分量405和“切换到”媒体分量400，其时间线分别用附图标记415和410示出。虚线箭头450指示用户执行媒体分量的切换的时间。

图5示出了切换模式的第二示例，即切换到零时间。切换到零时间是指切换自媒体分量的解码数据的呈现直到一定时间t，以及切换到媒体分量的解码数据的呈现从时间零开始。图5示出了“切换自”媒体分量505和“切换到”媒体分量500，其时间线分别用附图标记515和510示出。虚线箭头550指示用户执行媒体分量的切换的时间。

图6示出了切换模式的第三示例，即切换到偏移时间。切换到偏移时间是指切换自媒体分量的解码数据的呈现直到一定时间t，以及切换到媒体分量的解码数据的呈现从时间t_offset开始。t_offset可以大于或小于时间t。图6示出了“切换自”媒体分量605和“切换到”媒体分量600，其时间线分别用附图标记615和610示出。虚线箭头650指示用户执行媒体分量的切换的时间。

第四示例涉及切换到最近的随机访问点(图中未示出)，其是指切换自媒体分量的解码数据的呈现直到一定时间t，以及切换到媒体分量的呈现从切换到媒体分量中的最近的随机访问点开始。“最近”在时间维度上是指可以晚于或早于时间t的时间点。

根据实施例，默认切换模式的指示可以被编码为当从切换自媒体分量向切换到媒体分量切换时将要使用的比特流、容器文件和/或清单。默认的切换模式可以稍后在呈现时间线中被其他切换模式覆盖。此外，切换模式可以随着时间保持变化，并且可以在比特流、容器文件(例如在ISOBMFF的定时元数据轨道中)和/或清单中指示切换模式的改变。在与OMAF有关的实施例中，时间线切换可以是覆盖的属性，或者可以包括在覆盖的定时元数据轨道中(样本条目和样本)，类似于用于视点切换。组中的一组视点可以随时间展示不同的切换行为。另外，可以存在用于在视点之间切换的对应结构。在任何给定的时间点，可以有一个或多个用于在视点之间切换的配置。

根据本发明的其他实施例，可以存在附加的信令以指示用于播放器应用的切换到媒体分量的检索机制。

-仅在呈现时间线中一定时间逝去后才激活切换模式；

-检索较低质量/分辨率/帧速率内容；

-检索空间上的部分内容；

-检索切换到媒体分量的中间表示，该中间表示由从切换自媒体分量预测的帧组成。

在本发明的另一实施例中，切换到媒体分量针对给定的切换自媒体分量的对应于>1个候选视点，这些候选视点可以位于不同的空间位置。从这个意义上讲，这实现了一对多视点切换，其中>1个切换到视点的时间实例都相同(同步切换)。

下面结合ISOBMFF描述一些示例实施例。需要理解的是，示例实施例被提供为示例，并且实施例不限于ISOBMFF。

在示例实施例中，切换模式信息可以由任何其他容器盒子承载，该容器盒子与已经声明了切换模式的媒体分量相关联。下面示出了用于信令通知切换模式的示例数据结构。

num_entities_in_group指定映射到该实体组的entity_id值的数量。

ref_id[i]被解析为实体，该实体可以是与覆盖或视点或者通常媒体分量相关联的轨道或图像项，内容提供者使得能够在它们之间进行切换，而消费内容的用户很可能在它们之间进行切换。

在另一示例实施例中，ref_id[i]可被解析为指示覆盖或视点或通常媒体分量的ID的item_ID，内容提供者使得能够在它们之间进行切换，而消费内容的用户很可能在它们之间进行切换。

timeline_switching_mode指定在此组中的媒体分量之间切换时要使用的时间线。

toffset指定切换时要使用的时间偏移。

媒体分量之间的切换模式可以用值指示，其中，例如值“0”代表无缝切换，值“1”代表切换到第零个样本，值“2”代表切换到偏移时间t_offset，值“3”代表切换到最近的随机访问点。应当理解，可以替代地使用任何其他值。

根据实施例，ISOBMFF的TrackGroupBox或EntityToGroupBox可以用作用于包含在不同媒体分量之间的切换模式的容器。用EntityToGroupBox发信号通知交换模式一个示例针对分组覆盖进行的，所述覆盖旨在被呈现为针对同一实体组中另一个覆盖的用户可切换替代方案。

grouping_type等于'oval'的EntityToGroupBox指定包含覆盖的轨道和图像项，这些覆盖旨在被呈现为针对同一实体组中另一个覆盖的用户可切换替代方案。

ref_overlay_id[i]指定来自第i个entity_id标识的轨道或图像项中overlay_id，它是该组中的可切换覆盖。第i个参考轨道或图像项应具有等于存在的ref_overlay_id[i]的overlay_id。如果由该实体组的entity_id值标识的每个轨道和图像项都恰好包含一个覆盖，则ref_layer_id[i]语法元素可以存在也可以不存在。否则，应存在ref_layer_id[i]语法元素。

timeline_switching_mode和toffset的语义如上所述。

类似的实施例适用于可以在彼此之间切换的一组视点。具有一组视点的一个示例实施例旨在被呈现为针对另一视点的用户可切换替代方案。

grouping_type等于'visw'的EntityToGroupBox指定包含视点的轨道和图像项，这些视点旨在被呈现为针对同一实体组中的另一视点的用户可切换替代方案。

ref_viewpoint_id[i]指定来自由第i个entity_id标识的轨迹或图像项的viewpoint-id，它是该组中的可切换视点。第i个参考轨道或图像项应具有等于存在的ref_viewpoint_id[i]的view_id。如果由该实体组的entity_id值标识的每个轨道和图像项都恰好包含一个视点，则ref_viewpoint_id[i]语法元素可以存在也可以不存在。否则，应存在ref_layer_id[i]语法元素。

在另一个示例实施例中，视点之间的切换模式可以是ViewpointGroupStruct()的一部分

ViewpointGroupStruct()提供视点组信息。

vwpt_group_id指示视点组的标识符。视点组中的所有视点共享公共的参考坐标系。

可以理解，当两个视点具有不同的vwpt_group_id值时，它们的位置坐标是不可比较的，因为视点属于不同的坐标系。

vwpt_group_description是一个以空值终止的UTF-8字符串，它指示视点组的描述。允许使用空字符串。

应当理解，期望OMAF播放器从初始视点定时元数据开始。随后，如果用户希望切换到视点组并且不存在初始视点信息，则期望OMAF播放器切换到在视点组中具有视点标识符的最小值的视点。

num_viewpoints_in_group指示可以从当前视点切换到的组中的视点数。

ref_viewpoint_id[i]指定组中的这样的视点的pointing_id，可以从当前视点切换到该视点并且对应切换模式是针对该视点定义的。

timeline_switching_mode和toffset的语义如上所述。

在另一示例实施例中，可以在具有样本条目“vpts”的被称为视点时间线切换定时元数据轨道的定时元数据轨道中发信号通知视点之间的切换模式。

样本条目语法

class vptsSampleEntry()extends MetaDataSampleEntry('vpts'){

unsigned int(32)num_viewpoint_timeline_collections；

}

样本语法

num_viewpoint_timeline_collections指示在应用了此样本条目的样本中发信号通知时间线切换模式的视点时间线集合的数量。

num_viewpoints_in_this_collection[i]指示第i个视点时间线集合中的视点数。当用户在给定视点时间线集合中的任何视点之间切换时，则期望播放器遵循该集合指示的timeline_switching_mode。

viewpoint_id[i][j]表示第i个视点时间线集合中第j个视点的视点ID。

在ISOBMFF中指示主时间线

在一个示例实施例中，呈现的主时间线可以作为PresentationTimelineBox的一部分被发信号通知。

ISOBMFF的EditBox是用于包含从轨道的媒体时间线到呈现时间线(在轨道之间共享)的映射的容器盒子。EditBox可用作将呈现时间线与轨道相关联的容器。下面提供了一个示例EditBox：

盒子类型：“prtl”

容器：EditBox

强制：否

数量：零或一

如果存在，则EditBox会向由盒子中提供的时间线标识符标识的特定呈现时间线分配轨道。当不存在EditBox时，会向具有等于0的时间线标识符的呈现时间线隐式地分配轨道。

在全向媒体内容的播放期间，与同一呈现时间线相关联的轨道将同步播放。具有不同时间线标识符的呈现时间线可以不同步地调整节奏并且可以具有不同的回放状态(例如一个可以被暂停，而另一个可以处于常规回放模式)。

在一些实施例中，示例PresentationTimelineBox指定呈现时间线，但是不指示如何控制呈现时间线。下面提供了示例PresentationTimelineBox：

(flags&1)等于1指定当轨道变为活动状态(例如可见)时，其呈现时间被设置为master_timeline_id标识的时间线的当前呈现时间。保留特定的timeline_id值(例如)用于指示整个呈现的时间线。因此，等于0的master_timeline_id指定轨道已同步到整个呈现的时间线。

(flags&2)等于2指定该轨道的呈现时间在其处于非活动状态时暂停，并在其处于活动状态时恢复。

(flags&4)等于4指定当轨道变为活动状态(例如可见)时，轨道的呈现时间从0开始。

(flags&8)等于8指定当轨道变为活动状态(例如可见)时，轨道的呈现时间从EditListBox中第一非空条目的开头开始。

该实施例不仅可以用于覆盖的切换，而且可以用于视点的切换。

timeline_id提供此轨道被分配到的呈现时间线的时间线标识符。

无论用于覆盖或视点的文件格式如何，示例实施例的装置都可以由多种计算设备中的任何一种来提供，包括例如视频编码器、视频解码器、计算机工作站、服务器等等，或者通过各种移动计算设备中的任何一种，例如移动终端，例如智能电话、平板计算机、视频游戏机等。替代地，该装置可以由虚拟现实系统来体现，例如能够接收一个或多个数据流并渲染可呈现给用户的视觉和视听内容的虚拟现实耳机。

指示MPEG-DASH中的切换模式

下面结合MPEG-DASH描述一些示例实施例。需要理解的是，示例实施例被提供为示例，并且实施例不限于MPEG-DASH。

根据一个实施例，可以在具有SupplementalProperty和/或EssentialProperty描述符的MPD中承载切换模式信息，该描述符与已经声明其之间的切换模式的媒体分量具有关联/关系。

在示例实施例中，OMAF的关联描述符可以指示覆盖之间的关联，这些覆盖被消费以作为利用指示可以由用户切换的覆盖之间的关系的@associationKindList的呈现的替代方式。

根据一个实施例，定义了称为@switchingModes的新属性，其指示由@associationKindList列出的覆盖之间的切换模式。@switchingModes的值是上述切换模式值的列表。

在示例实施例中，与定义属性@switchingMode不同，与上文所描述的类似，新元素SwitchingModes被定义为被承载在描述符内并与OMAF的关联描述符一起使用。SwitchingModes元素可以包括[email protected]属性(它是上面提到的切换模式值的列表)和另一个属性[email protected](它指示在@SwitchingModes具有值2的情况下将要使用的偏移)。

在另一示例实施例中，视点信息描述符可以指示视点之间的可切换模式。定义了一个新属性[email protected]，该属性指示视点之间的切换模式。[email protected]的值与上面定义的相同。

根据一个实施例，将包括时间线信息的元素创作为MPD和/或从MPD解析。该元素例如可以是必要的描述符元素。该元素可以例如包含在AdaptationSet元素中(因此描述了适应集的所有表示)或表示元素中(因此描述了表示)。该元素包括，但不限于，以下一项或多项：

-呈现时间线标识符。在一个实施例中，MPD作者将该值设置为等于PresentationTimelineBox的timeline_id。

-指示当表示变为活动状态(例如可见)时，其呈现时间被设置为主时间线的当前呈现时间。在一个实施例中，主时间线与从MPD推测的媒体呈现时间线对齐。在一个实施例中，例如可以通过将其标识符包含到元素中来指示主时间线。

-指示表示的呈现时间在其未处于活动状态时暂停，并在变为活动状态时恢复。

-指示当轨道变为活动状态(例如可见)时，表示的呈现时间从0开始。

-指示当表示变为活动状态(例如可见)时，表示的呈现时间从其媒体样本的最早呈现时间开始。在一个实施例中，MPD作者将该值设置为EditListBox中的第一非空条目的呈现时间。

-指示重复或循环表示，即指示当表示的呈现时间达到最大呈现时间时，将其重置为一个可以推测为等于0或可以在元素中指示的值。换句话说，该表示被无缝地重复。在一个实施例中，当EditListBox中的(标志&1)等于1时，MPD作者设置该指示。

根据一个实施例，DASH客户端得出结论：相关联的表示的呈现时间是否遵循从MPD推测的媒体呈现时间线。该结论可以基于根据以上任何实施例的信息。例如，从MPD解析包括所描述的时间线信息的元素，以得出结论：相关联的表示是否遵循从MPD推测的媒体呈现时间线。当表示遵循从MPD推测的媒体呈现时间线时，通常会发出(子)分段请求。当表示不遵循从MPD推测的媒体呈现时间线时，将导出表示的时间线的时间范围，以使该时间范围对应于要进行的下一个(子)分段请求。例如，当用于表示的呈现时间已经被重置时(例如由于表示的激活或由于循环)，该时间范围可以不同于根据从MPD推测的媒体呈现时间线的下一个(子)分段请求的相应时间范围。可以将该时间范围进一步转换为分段索引和/或用于(子)分段的字节范围。于是，可以基于该时间范围发出请求，例如HTTP GET请求。

指示MPEG-DASH中的MasterTimeline

根据一个实施例，可以在MPD级别和/或周期级别和/或适应集级别和/或表示集级别处，在MPD中承载回放时间线的创建。

在示例实施例中，[email protected]元素指示用于MPD中所有周期和适应集的主时间线的ID。具有@masterTimelineID的不同值的新MPD指示新MPD中表示的媒体具有不同的主时间线。具有@masterTimelineID的相同值的新MPD指示在该新MPD中表示的媒体具有与先前MPD相同的主时间线(MPD刷新后的示例)。

@masterTimelineID元素的存在向播放器指示：新的时间线需要由播放器创建并且MPD表示的媒体遵循主时间线。

在另一示例实施例中，[email protected]元素指示给定周期的主时间线的ID。

在另一示例实施例中，当包含第一视点的适应集与包含第二或更多视点的一个或多个适应集相关联时，关联描述符应作为包含第一视点的AdaptationSet元素的子元素存在。

在这种情况下，关联描述符应包括以下两项：

·关联(Association)元素中的XPath字符串，其评估为包含第二或更多个视点的一个或多个AdaptationSet元素。

·针对关联元素的[email protected]属性的仅一个“vpts”值。在这种情况下：

ο当[email protected]包括一个“vpts”值并且在上面的关联元素中的XPath字符串评估为的元素数目大于1时，视点时间线切换应用于所有视点。

ο当[email protected]包括一个“vpts”值并且在上面的关联元素中XPath字符串评估为的元素数等于1时，视点时间线切换单独地应用于其他视点。

包含视点的适应集内可以存在多个此类关联描述符。

如上所述，当包含视点的适应集与包含其他视点的一个或多个适应集相关联时，它们旨在基于给定的切换模式在彼此之间切换。

在示例实施例中，[email protected]元素指示通过关联描述符与由“vpts”指示的[email protected]相关联的视觉媒体的主时间线ID。

图7是示出根据实施例的方法的流程图。一种用于编码的方法，包括：生成701定义呈现的比特流，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；在比特流中指示702与第一视觉媒体分量相关联的第一呈现时间线；在比特流中指示703与第二视觉媒体分量相关联的第二呈现时间线；在比特流中指示704到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；以及在比特流中指示705切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

一种根据实施例的装置，包括：用于生成定义呈现的比特流的模块，所述呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；用于在比特流中指示与第一视觉媒体分量相关联的第一呈现时间线的模块；用于在比特流中指示与第二视觉媒体分量相关联的第二呈现时间线的模块；用于在比特流中指示到与第二视觉媒体分量相关联的第二呈现时间线的切换模式的模块；用于在比特流中指示切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的模块。所述模块包括处理器、存储器以及驻留在该存储器中的计算机程序代码，其中该处理器可以进一步包括处理器电路。

图8是示出根据另一实施例的方法的流程图。一种用于解码的方法，包括：从比特流确定801呈现，所述呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；从比特流解码802与第一视觉媒体分量相关联的第一呈现时间线；从比特流解码803与第二视觉媒体分量相关联的第二呈现时间线；从比特流解码804到与第二视觉媒体分量相关联的第二呈现时间线的切换模式；从比特流解码805切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的。

一种根据实施例的装置，包括：用于从比特流确定呈现的模块，该呈现包括全向视觉媒体内容以及第一视觉媒体分量和第二视觉媒体分量；用于从比特流解码与第一视觉媒体分量相关联的第一呈现时间线的模块；用于从比特流解码与第二视觉媒体分量相关联的第二呈现时间线的模块；用于从比特流解码到与第二视觉媒体分量相关联的第二呈现时间线的切换模式的模块；用于从比特流解码该切换模式是关于第一呈现时间线的或者是关于第二呈现时间线的模块。所述模块包括处理器、存储器以及驻留在该存储器中的计算机程序代码，其中该处理器可以进一步包括处理器电路。

在图9中示出了用于装置的数据处理系统的示例。可以用单个物理设备来执行几种功能，例如如果需要，所有计算过程都可以在单个处理器中执行。数据处理系统包括主处理单元100、存储器102、存储设备104、输入设备106、输出设备108和图形子系统110，它们均经由数据总线112彼此连接。

主处理单元100是被布置为在数据处理系统内处理数据的常规处理单元。主处理单元100可以包括或实现为一个或多个处理器或处理器电路。存储器102、存储设备104、输入设备106和输出设备108可以包括本领域技术人员所公知的常规组件。存储器102和存储设备104将数据存储在数据处理系统100中。

计算机程序代码驻留在存储器102中，用于实现例如根据图7或图8的流程图的方法。输入设备106将数据输入到系统中，而输出设备108从数据处理系统接收数据并例如向显示器转发数据。数据总线112是常规的数据总线，并且虽然显示为单线，但是它可以是以下各项的任意组合：处理器总线、PCI总线、图形总线、ISA总线。因此，技术人员容易认识到该装置可以是任何数据处理设备，例如计算机设备、个人计算机、服务器计算机、移动电话、智能电话或因特网访问设备(例如因特网平板计算机)。

可以借助于驻留在存储器中并使相关装置执行本发明的计算机程序代码来实现本发明的各种实施例。例如，设备可以包括用于处理、接收和发送数据的电路和电子设备、存储器中的计算机程序代码、以及在运行计算机程序代码时使设备执行实施例的特征的处理器。此外，诸如服务器的网络设备可以包括用于处理、接收和发送数据的电路和电子设备、存储器中的计算机程序代码、以及在运行计算机程序代码时使网络设备执行实施例的特征的处理器。

如果需要，可以以不同的顺序和/或与其他同时执行本文讨论的不同功能。此外，如果需要，上述功能和实施例中的一个或多个可以是可选的或可以被组合。

尽管在独立权利要求中陈述了实施例的各个方面，但是其他方面包括来自所描述的实施例和/或独立权利要求的特征与来自从属权利要求的特征的其他组合，而不仅是权利要求中明确提出的组合。

在上面，已经关于DASH或MPEG-DASH描述了一些实施例。需要理解的是，实施例可以用任何其他类似的流式传输系统和/或与DASH中使用的那些类似的协议和/或与DASH中使用的那些类似的任何分段和/或清单格式和/或与DASH客户端类似的任何客户端操作，来类似地实现。例如，一些实施例可以用M3U清单格式实现。此外，实施例不限于用于流式传输的媒体描述，而是还适用于其他类型的媒体应用(例如会议)。例如，可以使用IETF SDP协议作为媒体描述来实现实施例。

在上面，已经关于ISOBMFF描述了一些实施例。需要理解的是，可以利用诸如Matroska之类的任何其他文件格式来类似地实现实施例。

在此还应注意，尽管以上描述了示例实施例，但是这些描述不应以限制性的意义来理解。而是，在不脱离所附权利要求书所限定的本公开的范围的情况下，可以进行多种变型和修改。