用于传输媒体内容的方法、装置和计算机程序

技术领域

本发明涉及用于封装和传输媒体数据的方法和装置。

背景技术

本发明涉及例如根据如MPEG标准化组织所定义的ISO基媒体文件格式来对虚拟现实媒体内容进行封装、解析和流传输，以提供便于虚拟现实媒体内容的交换、管理、编辑和呈现的灵活且可扩展的格式，并改善该虚拟现实媒体内容例如通过诸如使用自适应http流传输协议的因特网等的IP网络的传递。

国际标准化组织基媒体文件格式(ISO BMFF,ISO/IEC 14496-12)是描述供本地存储或者供经由网络或经由另一位流传递机制进行传输的编码定时媒体数据位流的众所周知的灵活且可扩展的格式。扩展的示例是ISO/IEC14496-15，其描述各种基于NAL(网络抽象层)单元的视频编码格式所用的封装工具。这样的编码格式的示例是AVC(高级视频编码)、SVC(可分级视频编码)、HEVC(高效率视频编码)和L-HEVC(分层HEVC)。文件格式扩展的另一示例是ISO/IEC 23008-12，其描述了诸如HEVC静止图像等的静止图像或静止图像序列所用的封装工具。该文件格式是面向对象的。该文件格式包括被称为框(box)(或以四字符代码为特征的数据结构)的构建块，其中这些框是顺次或层级组织的，并且定义了编码定时媒体数据位流的诸如定时参数和结构参数等的参数。在该文件格式中，整个呈现被称为动画(movie)。动画由在媒体或呈现文件的顶层的动画框(具有四字符代码“moov”)描述。该动画框表示包含描述呈现的各种框的集合的初始化信息容器。该动画框在逻辑上被划分成由轨框(具有四字符代码“trak”)表示的轨。(由轨标识符(track_ID)唯一地标识的)各轨表示属于呈现的媒体数据(例如，视频的帧)的定时序列。在各轨内，数据的各定时单元被称为样本；这可以是视频、音频或定时元数据的帧。样本按顺序隐含地编号。实际样本数据被存储在与动画框相同级别处的被称为媒体数据框(具有四字符代码“mdat”)的框中。动画可被时间上组织为包含整个呈现的信息的动画框、之后是数个动画片段和媒体数据框的列表。在动画片段(具有四字符代码“moof”的框)内，存在轨片段(具有四字符代码“traf”的框)的集合(针对各动画片段存在零个或多个轨片段)。而轨片段包含零个或多个轨运行框(“trun”)，各轨运行框记录该轨片段的样本的连续运行。

在文件格式中，媒体或呈现文件还可以包含在与动画框相同级别处的元框(“meta”)内描述的一个或多个静态项(例如，一个或多个静止图像)。该元框可以包含描述静态项的描述性信息，该描述性信息被组织在数个框中(例如，项信息框(“iinf”)中的项的列表和项位置框(“iloc”)中的数据项的(在数据框中的)位置)，各项由项标识符(item_ID)唯一地标识。实际项数据存储在元框中的项数据框(“idat”)中，或者存储在文件顶层的媒体数据框(“mdat”)中。

ISOBMFF文件可以包含多个编码定时媒体数据位流、或者形成多个轨(也称为视频内容的子图片轨)和/或多个静态项的编码定时媒体数据位流的子部分。ISOBMFF及其扩展包括多个分组机制以将轨、静态项或样本分组在一起。组通常共享共同的语义和/或特性。

例如，ISOBMFF包括实体组机制、轨组机制和样本分组机制。实体分组机制可用于指示根据所指示的分组类型或语义来将轨和/或静态项分组。轨分组机制可用于指示根据所指示的分组类型或语义来将轨分组。样本分组机制可用于指示与所指示的分组类型或语义相关联的某些性质适用于轨内的所指示的一组样本。

为了改善用户体验、并且特别是为了提供沉浸式体验，定时媒体数据位流(视频甚至音频)可以是全向的(或者多向的或多方向的)。在应用于视频(还称为360°全景视频)时，用户感觉位于所显示的场景中。

全向视频可以从360°照相机获得、以及/或者通过将从例如安装在特殊装备上以使得所有照相机都具有公共节点的数个照相机获得的视频流的图像进行组合来获得。这种图像的组合被称为图像拼接或照相机拼接。

这种全向视频可以根据用户的观看取向经由头戴式显示器来渲染、或者通过投影到环绕用户的曲面屏幕上来渲染。这种全向视频也可以显示在具有导航用户界面的传统2D屏幕上，以根据全向视频中的用户期望部分(也称为视口)而平移到该全向视频中。由于用户感觉在虚拟世界中，因此这种全向视频通常被称为虚拟现实(VR)。在向全向视频添加虚拟对象时，该操作被称为增强现实(AR)。

本发明人在描述和表示(signaling)与要传输的媒体数据有关的信息时，特别是在将全向媒体内容分成由多个轨承载的数个子部分时，注意到了数个问题。

示例涉及从客户端请求特定解析处理的轨的信令，这产生开销并且是复杂的。

另一示例涉及轨组的信令，并且特别是原始全向媒体内容与(以投影、打包或鱼眼编码方式)嵌入到多个子图片轨中的二维(2D)媒体内容之间的映射。

另一示例涉及被允许或不被允许组合以重建准备显示的全向媒体内容的子图片轨的信令。现有的解决方案或复杂或未经良好定义，并且不完全符合用于二维多轨封装处理的现有机制。

发明内容

设计了本发明以解决上述问题中的一个或多个。

在该上下文中，提供了用于例如通过诸如使用http协议的因特网等的IP网络来对媒体内容(例如，全向媒体内容)进行流传输的解决方案。

根据本发明的第一方面，提供一种用于对与场景的宽视图相对应的编码媒体数据进行封装的方法，所述方法包括：

从所述场景的宽视图获得投影图片；

将所获得的投影图片打包在至少一个打包图片中；

将所述至少一个打包图片分成至少一个子图片；

将所述至少一个子图片编码到多个轨中；

生成与编码轨相关联的描述性元数据，

其中，所述描述性元数据包括与各轨相关联的信息项，所述信息项指示编码在所述轨中的所述至少一个子图片与至少一个投影图片之间的空间关系。

根据本发明的另一方面，提供一种用于对与场景的宽视图相对应的编码媒体数据进行封装的方法，所述方法包括：

从所述场景的宽视图获得投影图片；

将所述投影图片分成至少一个子图片；

将所述至少一个子图片编码到多个轨中；

生成与编码轨相关联的描述性元数据，所述描述性元数据包括与各轨相关联的第一信息项，所述第一信息项指示编码在所述轨中的所述至少一个子图片与参考图片之间的空间关系，

其中，所述描述性元数据还包括指示所述参考图片的第二信息项。

根据实施例，将所述投影图片分成多个子图片包括：将所述投影图片打包到打包图片中，并且将所述打包图片分成多个子图片。

根据实施例，所述第二信息项是指示所述参考图片是所述投影图片的品牌值。

根据实施例，所述第二信息项是指示所述参考图片是所述打包图片的品牌值。

根据实施例，所述第二信息项包括在与各轨相关联的所述第一信息项中。

根据实施例，所述第二信息项被定义为所述第一信息项的参数。

根据实施例，所述参数的存在由提供至所述第一信息项的标志来指示。

根据实施例，所述第二信息项被定义为提供至所述第一信息项的标志。

根据实施例，所述第二信息项被定义为用于描述与子图片相对应的一组轨的性质的特定类型的组信息。

根据本发明的另一方面，提供一种用于从媒体文件生成至少一个图像的方法，所述媒体文件包括多个编码轨和关联的描述性元数据，所述方法包括：

确定为所述多个编码轨包括对至少一个子图片进行编码的一组轨，所述至少一个子图片是从通过对场景的宽视图的投影图片进行打包所获得的打包图片的分割得到的；

解析与所述一组轨相关联的描述性元数据；

其中，解析与所述一组轨相关联的描述性元数据包括：

解释与各轨相关联的信息项，所述信息项指示编码在所述轨中的所述至少一个子图片与至少一个投影图片之间的空间关系。

根据本发明的另一方面，提供一种用于从媒体文件生成至少一个图像的方法，所述媒体文件包括多个编码轨和关联的描述性元数据，所述方法包括：

确定为所述多个编码轨包括对至少一个子图片进行编码的一组轨，所述至少一个子图片是从场景的宽视图的投影图片的分割得到的；

解析与所述一组轨相关联的描述性元数据；

其中，解析与所述一组轨相关联的描述性元数据包括：

解释与各轨相关联的第一信息项，所述第一信息项指示编码在所述轨中的所述至少一个子图片与至少一个参考图片之间的空间关系；以及

解释指示所述参考图片的第二信息项。

根据实施例，场景的宽视图的投影图片的分割是通过分割通过对所述投影图像进行打包所获得的打包图片而获得的。

根据实施例，所述第二信息项是指示所述参考图片是所述投影图片的品牌值。

根据实施例，所述第二信息项是指示所述参考图片是所述打包图片的品牌值。

根据实施例，所述第二信息项包括在与各轨相关联的所述第一信息项中。

根据实施例，所述第二信息项被定义为所述第一信息项的参数。

根据实施例，所述参数的存在由提供至所述第一信息项的标志来指示。

根据实施例，所述第二信息项被定义为提供至所述第一信息项的标志。

根据实施例，所述第二信息项被定义为用于描述与子图片相对应的一组轨的性质的特定类型的组信息。

根据本发明的另一方面，提供一种计算装置，用于对与场景的宽视图相对应的编码媒体数据进行封装，所述计算装置被配置为：

从所述场景的宽视图获得投影图片；

将所获得的投影图片打包在至少一个打包图片中；

将所述至少一个打包图片分成至少一个子图片；

将所述至少一个子图片编码到多个轨中；

生成与编码轨相关联的描述性元数据，

其中，所述描述性元数据包括与各轨相关联的信息项，所述信息项指示编码在所述轨中的所述至少一个子图片与至少一个投影图片之间的空间关系。

根据本发明的另一方面，提供一种计算装置，用于对与场景的宽视图相对应的编码媒体数据进行封装，所述计算装置被配置为：

从所述场景的宽视图获得投影图片；

将所述投影图片分成至少一个子图片；

将所述至少一个子图片编码到多个轨中；

生成与编码轨相关联的描述性元数据，所述描述性元数据包括与各轨相关联的第一信息项，所述第一信息项指示编码在所述轨中的所述至少一个子图片与参考图片之间的空间关系，

其中，所述描述性元数据还包括指示所述参考图片的第二信息项。

根据本发明的另一方面，提供一种计算装置，用于从媒体文件生成至少一个图像，所述媒体文件包括多个编码轨和关联的描述性元数据，所述计算装置被配置为：

确定为所述多个编码轨包括对至少一个子图片进行编码的一组轨，所述至少一个子图片是从通过对场景的宽视图的投影图片进行打包所获得的打包图片的分割得到的；

解析与所述一组轨相关联的描述性元数据；

其中，解析与所述一组轨相关联的描述性元数据包括：

解释与各轨相关联的信息项，所述信息项指示编码在所述轨中的所述至少一个子图片与至少一个投影图片之间的空间关系。

根据本发明的另一方面，提供一种计算装置，用于从媒体文件生成至少一个图像，所述媒体文件包括多个编码轨和关联的描述性元数据，所述计算装置被配置为：

确定为所述多个编码轨包括对至少一个子图片进行编码的一组轨，所述至少一个子图片是从场景的宽视图的投影图片的分割得到的；

解析与所述一组轨相关联的描述性元数据；

其中，解析与所述一组轨相关联的描述性元数据包括：

解释与各轨相关联的第一信息项，所述第一信息项指示编码在所述轨中的所述至少一个子图片与至少一个参考图片之间的空间关系；以及

解释指示所述参考图片的第二信息项。

根据本发明的另一方面，提供一种可编程设备所用的计算机程序产品，所述计算机程序产品包括指令序列，所述指令序列用于在被载入所述可编程设备并由所述可编程设备执行的情况下，实现根据权利要求1至20中任一项所述的方法。

根据本发明的另一方面，提供一种存储有计算机程序的指令的计算机可读存储介质，所述指令用于实现根据权利要求1至20中任一项所述的方法。

根据本发明的另一方面，提供一种计算机程序，所述计算机程序在执行时，使得进行根据权利要求1至20中任一项所述的方法。

附图说明

在研究附图和具体实施方式时，本领域技术人员将明白本发明的更多优点。意图这里包含了任何附加优点。

以下将仅通过示例方式并且参考以下附图来说明本发明的实施例，其中：

图1示出用于从服务器向客户端捕获、处理、封装、传输和渲染全向视频的数据流的示例；

图2示出根据本发明实施例的封装的示例的框图；

图3是用于实现本发明的一个或多个实施例的计算装置的示意框图；

图4示出将包括来自不同媒体源的媒体数据的子图片编码在数个轨和组中的示例；

图5示出根据本发明实施例的SpatialRelationship2DdescriptionBox(空间关系2D描述框)和source_id的使用示例；

图6示出根据本发明实施例的SpatialRelationship2DdescriptionBox和source_id的第二使用示例；

图7示出根据本发明实施例的子图片封装；

图8示出根据本发明实施例的解析处理；

图9示出根据本发明实施例的系统；

图10a、10b、10c和10d示出根据本发明实施例的投影、可选打包和分成子图片轨的整体处理的数个示例。

具体实施方式

图1示出用于从服务器装置101向客户端装置170(也示为170’)捕获、传输和渲染全向媒体的数据流的示例。

如图所示，该媒体具有从照相机系统100获取到并传递至头戴式显示器(HMD)170和170’的视频内容。照相机系统100可以包含具有广角镜头的一个照相机、或者组装在一起的多个照相机的集合(例如，供虚拟现实用的照相机装备)。传递160例如可以经由流式服务器161和流式客户端162通过诸如使用自适应http流传输协议的因特网等的IP网络163来进行。

为了例示，所使用的照相机系统100基于与立方体的各面相关联的六个标准照相机的集合。照相机系统100用于捕获(步骤110)表示照相机系统周围的真实场景的图像。根据该布置，一个照相机提供前方图像，一个照相机提供后方图像，一个照相机提供左方图像，一个照相机提供右方图像，一个照相机提供底部图像，并且一个照相机提供顶部图像。

在服务器101中对从照相机系统100获得的图像进行处理(步骤120)，以创建形成也被称为360视频流或虚拟现实媒体数据流的全向视频流的360个图像。

处理步骤120涉及拼接和投影相同时间实例的捕获图像。首先将图像拼接并投影到表示在水平维度和垂直维度这两者上形成360°视图的球体121的三维投影结构上。该投影结构上的360图像数据例如使用等量矩形投影(https://en.wikipedia.org/wiki/Equirectangular_projection)被进一步转换到二维投影图像122(也表示为捕获投影)上。该投影图像覆盖整个球体。

可替代地，如果全向媒体是立体360度视频，则照相机系统100可以包括多个照相机，这多个照相机在步骤110中捕获表示随后可由客户端用来渲染三维360度场景的左视图和右视图的图像序列。在这种情况下，将上述的处理步骤120单独应用于左视图和右视图这两者的图像序列。可选地，在步骤125中，可以应用帧打包以将相同时间实例的各左视图图像和右视图图像打包到相同的投影图像上，从而得到单一左+右投影图像序列。数个立体帧打包布置是可能的，例如，并排、上下、基于列的交错、基于行的交错、交替的左视图和右视图的时间交错。可替代地，立体帧打包布置还可以涉及在编码步骤140之后将左视图和右视图保持在单独且独立的投影图像序列中，从而得到独立的视频位流。例如，一个视频位流表示左视图图像，并且另一视频位流表示右视图图像。

可选地，然后应用区域级打包130以将投影图像122映射到打包图像131上。区域级打包涉及对投影图像的区域应用变换(例如，像素块的旋转、镜像、复制或移动…)、调整大小和重定位，以便例如使与球体上的对于用户而言的最有用部分有关的信号信息最大化。可以注意到，打包图像可以仅覆盖整个球体的一部分。如果不应用区域级打包，则打包图像131与投影图像122相同。在立体全向媒体的情况下，区域级打包根据在步骤125中选择的帧打包布置而应用于左+右投影图像序列、或者单独应用于左视图和右视图的投影图像序列。

在步骤140中，将投影图像122或打包图像131编码到一个或数个视频位流中。在立体全向媒体的情况下，编码步骤根据在步骤125中选择的帧打包布置而应用于左+右打包图像序列、或者单独应用于左视图和右视图的打包图像序列。可替代地，可以将多视图编码用在左视图和右视图的打包图像序列上。

编码格式的示例是AVC(高级视频编码)、SVC(可分级视频编码)、HEVC(高效率视频编码)或L-HEVC(分层HEVC)。在下文，HEVC用于指代HEVC及其分层扩展(L-HEVC)这两者。

HEVC和类似的视频编码格式定义样本(例如，图片)的不同空间细分：区块(tile)、条带(slice)和条带分段(slice segment)。区块定义图片的矩形区域，其中该图片由水平边界和垂直边界(即，行和列)限定，并且包含整数个编码树单元(CTU)或编码块(以下全部称为编码单元)。如此，区块是表示图片的空间子部分的良好候选。然而，在句法方面的编码视频数据(位流)组织及其到NAL单元(或NALU)中的封装是基于条带和条带分段(如在AVC中那样)。

HEVC中的条带是条带分段的集合，其中至少第一条带分段是独立条带分段，其它条带分段(在存在的情况下)是依赖条带分段。条带分段包含整数个连续(按光栅扫描顺序)CTU。条带不必一定具有矩形形状(因而，对于空间子部分表现不如区块适合)。将条带分段作为以下而被编码在HEVC位流中：slice_segment_header，之后是slice_segment_data。独立条带分段(ISS)和依赖条带分段(DSS)的不同之处在于这两者的头部：依赖条带分段由于重复使用来自独立条带分段的头部的信息，因而具有较短的头部。独立条带分段和依赖条带分段这两者都包含位流中的进入点的列表。

在利用区块对视频位流进行编码时，区块可以是运动约束的，以确保区块不取决于同一图片中的相邻区块(空间依赖性)并且不取决于先前参考图片中的相邻区块(时间依赖性)。因此，运动约束的区块是可独立解码的。

可替代地，投影图像122或打包图像131可在编码之前被分成数个空间子图片，各子图片被独立编码，从而例如形成独立的编码HEVC位流。

可替代地，可以在无需在存储器中生成完整中间打包图像131的情况下同时进行区域级打包步骤130和分成数个空间子图片步骤。投影图像122(或在可选步骤125之后得到的立体投影图像)可被分成子部分，并且各子部分可被直接打包到空间子图片中以供在步骤140处进行编码。

图10a、10b、10c和10d示出根据本发明实施例的投影、可选打包和分成子图片轨的整体处理的数个示例。来自投影图片1001中的一个或多个区域(标记为1、2、3和4)通过应用数个变换操作(标识、向上或向下缩放、旋转、镜像、重定位…)被重新排列成打包区域1002(标记为1’、2’、3’和4’)，然后被分成和重新组织成一个或多个子图片轨1003。该分割也可以得到针对各打包区域(1’、2’、3’和4’)的一个子图片轨。也可以直接从投影图片1011到一个或多个子图片轨1012立即进行打包和分割操作。图10c和10d提供在全向内容是立体内容的情况下的不同可能封装的示例。在这种情况下，捕获步骤110使用允许立体记录(通常为针对各眼睛一个视频)的照相机装备。

图10c描述不存在帧打包(图1的可选步骤125)的立体全向内容的示例。然后，当(在1022中)对各视图应用区域级打包时，对各投影视图1021进行独立封装(可能地封装到如1023那样的子图片轨中)。在该示例中，针对各视图的各区域存在一个子图片轨。甚至可以决定将相同区域的两个视图封装在相同的子图片轨中。然后，子图片轨将在指示所使用的帧打包的样本描述级别包含立体视频框。

图10d描述立体全向内容的示例，其中在该立体全向内容中，应用了帧打包(图1的步骤125)，以将两个投影视图1031打包在单个帧打包图片1032中。然后，对如此得到的帧打包图片1032进行封装(可能地封装到如1033那样的子图片轨中)。在该示例中，各子图片轨描述了给定空间区域的两个视图。关于在打包之后的投影，一个子图片轨可以对一个区域或多个区域进行封装(如图10所示)。封装模块可以决定描述成本vs访问粒度权衡，以将内容封装到例如包含多个打包区域的子图片轨中。这可以是通过计算打包区域的逆投影的封装发现在打包帧中的连续区域的逆投影中不存在间隙的情况。这可以是用以将来自打包图片的这些区域分组到单个子图片轨中的决策准则。图10a、10b、10c和10d示出数个区域这样聚集在同一子图片轨中。在封装模块将多个区域聚集于在投影图片中生成间隙、孔或未覆盖像素的子图片轨中的情况下，封装模块可以将子图片轨位置和大小设置成等于这些多个区域的限界框的位置和大小。

因此，作为编码步骤140的结果，投影图像122或打包图像131可以由一个或多个独立编码位流或者由包括一个或多个独立编码的子位流的至少一个编码位流表示。

然后，在步骤150中，根据封装文件格式(例如，根据如MPEG标准化组织所定义的ISO基媒体文件格式和全向媒体格式(OMAF–ISO/IEC 23090-2))将这些编码后的位流和子位流封装在文件或小的时间分段文件165中。如此得到的文件或分段文件可以是mp4文件或mp4分段。在封装期间，可以将音频流以及提供与视频或音频流有关的信息的元数据轨添加到视频位流。

然后，将封装后的文件或分段文件经由传递机制160(例如通过使用http(超文本传输协议)协议的因特网或者在例如盘等的可移除数字介质上)传递至客户端170。为了例示，使用来自MPEG标准化委员会(“ISO/IEC 23009-1,经由HTTP的动态自适应流传输(DASH),Part1:Media presentation descriptionand segment formats”)的诸如DASH(经由HTTP的动态自适应流传输)等的经由HTTP的自适应流传输来进行传递160。

该标准使得能够将媒体呈现的媒体内容的紧凑描述与HTTP统一资源定位符(URL)相关联。这种关联通常在被称为清单文件或描述文件164的文件中描述。在DASH的上下文中，该清单文件是也称为MPD文件(媒体呈现描述)的XML文件。

通过接收MPD文件，客户端装置170获得各媒体内容成分的描述。因此，客户端装置170获知在媒体呈现中提出的媒体内容成分的种类，并且知晓要用于经由流式客户端162从流式服务器161下载关联的媒体分段165的HTTPURL。因此，客户端170可以决定(经由HTTP请求)下载和播放(即，在接收到媒体分段之后解码并播放)哪些媒体内容成分。

应当注意，客户端装置可以根据用户的视口(即，当前显示并由用户观看的球形视频的一部分)仅获得与表示场景的宽视图的完整打包图像的空间部分相对应的媒体分段。场景的宽视图可以表示由完整打包图像表示的完整视图。

在接收时，在步骤171期间解析封装后的虚拟现实媒体文件或媒体分段，以提取在步骤172中解码的一个或多个数据流。在步骤171中接收到的ISOBMFF文件或分段的情况下，该解析通常由mp4读取器或mp4解析器来处理，其中该mp4读取器或mp4解析器可以从描述性元数据中提取封装后的视频位流和/或视频子位流。

接着，可选地，在步骤173中，对从解码步骤172得到的打包图像或打包子图像进行解包以获得投影图像，然后对这些投影图像进行处理以进行视频渲染(步骤174)并进行显示(步骤175)。

可替代地，打包子图像在被解包成投影图片之前，可被重新排列以组成中间完整打包图像。

应当注意，视频渲染取决于作为用户的视角、视点和用于创建投影图像的投影的多个参数。如图所示，渲染视频包括将解码后的投影图像重新投影在球体上的步骤。将从这种重新投影获得的图像显示在头戴式显示器170’中。

为了处理立体视图，可以重复或部分重复通过参考图1所述的处理。

已观察到，将UHD(超高清)视频流的数个图像拼接成虚拟现实媒体数据流的全景图像得到位率非常高且分辨率非常高的虚拟现实媒体数据流。因此，从系统的角度来看、并且为了避免浪费带宽并且保持与客户端播放器的处理能力兼容，需要优化对虚拟现实媒体数据的访问。

虚拟现实媒体数据流可用于除通过参考图1所述的目的以外的其它目的这一需求甚至更重要。特别地，虚拟现实媒体数据流可用于利用如360°投影仪阵列那样的特定显示器来显示360°图像。虚拟现实媒体数据流也可用于显示特定视野以及/或者改变视角、视野和视点。

根据特定实施例，根据封装文件格式(例如，ISO基媒体文件格式(ISO/IEC 14496-12和ISO/IEC 14496-15)、全向媒体格式(OMAF)(ISO/IEC23090-2)和如MPEG标准化组织所定义的关联规范)，将通过打包图像131的编码(图1的步骤140)产生的编码位流和子位流封装到文件或小的时间分段文件中。

编码位流(例如，HEVC)以及可能的其子位流(例如，区块化HEVC、MV-HEVC、可分级HEVC)可被封装为单一轨。可替代地，在空间上相关的(即，作为投影图像的子空间部分的)多个编码位流可被封装为数个子图片轨。可替代地，包括数个子位流(区块、视图、层)的编码位流(例如，区块化HEVC、MV-HEVC、可分级HEVC)可被封装为多个子图片轨。

子图片轨是嵌入有图片或图像的子部分(通常为空间部分或矩形区域)的数据的轨。子图片轨可以与其它子图片轨有关，或者与描述该子图片被提取于的完整图片的轨有关。例如，子图片轨可以是区块轨。子图片轨可以由AVC轨、HEVC轨、HEVC区块轨或被封装为样本序列的任何压缩视频位流来表示。

区块轨是与图像的空间部分或者与图像或图片的子图片相对应的定时视频样本的序列。区块轨例如可以是图像中的关注区域或该图像中的任意区域。与区块轨相对应的数据可以来自于视频位流，或者可以来自于视频位流的子部分。例如，区块轨可以是AVC或HEVC兼容的位流，或者可以是AVC或HEVC或任何编码位流的子部分，例如HEVC区块那样。在优选实施例中，区块轨是可独立解码的(编码器注意通过生成“运动约束”区块来从其它区块去除运动预测)。在区块轨对应于利用区块以HEVC编码的视频位流时，该区块轨可被封装到如在ISO/IEC 14496-15第四版中所述的表示为“hvt1”轨的HEVC区块轨中。然后，该区块轨可以参考区块基轨以获得参数集、高级信息以设置视频解码器。该区块轨也可被封装到HEVC轨“hvc1”或“hev1”轨中。区块轨可用于将子图片空间复合成更大的图像或图片。

区块基轨是一个或多个区块轨共同的轨，其中该一个或多个区块包含这些一个或多个轨之间共享的数据或元数据。区块基轨可以包含用于从一个或多个区块轨组成图像的指示。区块轨可以依赖于区块基轨以进行完全解码或渲染。在区块基轨源自于利用区块以HEVC编码的视频位流时，该区块基轨被封装到表示为“hvc2”或“hev2”轨的HEVC轨中。另外，该区块基轨由HEVC区块轨经由轨参考“tbas”来参考，并且该区块基轨应指示如在ISO/IEC14496-15第四版中所述的、使用向HEVC区块轨的“sabt”轨参考的区块排序。

复合轨(也表示为参考轨)是参考其它轨来组成图像的轨。复合轨的一个示例在视频轨的情况下是将子图片轨组成为更大图像的轨。这可以通过例如在源自于视频轨的如下轨中的解码后操作来进行，其中该轨提供变换和变换参数以将来自各视频轨的图像组成为更大的图像。复合轨还可以是具有提取器NAL单元的轨，这些提取器NAL单元提供用以从其它视频轨或区块轨提取NAL单元以在解码通过子位流级联产生的位流之前形成的指示。复合轨也可以是例如通过向其它轨的轨参考来隐含地提供复合指示的轨。

ISO/IEC 14496-12提供位于轨级别(即，在ISOBMFF框层级中的“trak”框内)以描述轨组的框，其中各组共享特定特性或者组内的轨具有特定关系。该轨组框是按照如下定义的空容器：

Box Type：‘trgr′

Container：TrackBox(′trak′)

Mandatory：No

Quantity：Zero or one

dligned(8) cldss TrdckGroupBox extends Box(′trgr′){

}

该轨组框可以包含按照如下定义的轨组类型框的集合：

由该轨组类型框的实例声明的特定特性或关系由框类型(track_group_type)指示。该框还包括可用于确定属于相同轨组的轨的标识符(track_group_id)。包括具有track_group_type值和track_group_id值相同的轨组类型框的轨组框的所有轨是相同轨组的一部分。该框还允许声明与特定轨组类型的轨相关联的特定参数。MPEG ISOBMFF标准(ISO/IEC 14496-12第7版第1次修订–2018年5月)正提出用于二维空间关系的特定轨组SpatialRelationship2DDescriptionBox作为类型“2dcc”的TrackGroupTypeBox(轨组类型框)。

track_group_type等于“2dcc”的SpatialRelationship2DDescriptionBoxTrackGroupTypeBox指示该轨属于具有2D空间关系的(例如，对应于视频源的平面空间部分的)一组轨。具有给定track_group_id的SpatialRelationship2DDescriptionBoxTrackGroupTypeBox隐含地定义了具有任意原点(0,0)以及由total_width和total_height定义的最大大小的坐标系；x轴被定向成从左到右，并且y轴被定向成从上到下。SpatialRelationship2DDescriptionBox TrackGroupTypeBox内的source_id的值相同的轨被映射为源自于相同源，并且这些轨的关联坐标系共享相同的原点(0,0)及其轴的朝向。源或视频源对应于由照相机或照相机的集合为了全向内容而正捕获的内容。例如，非常高分辨率的视频可能已被分成子图片轨。然后，各子图片轨传送其在源视频中的位置和大小。

具有相同source_ID的相同轨组中的轨应当声明相同的output_width和output_height。

按照如下定义类型“2dcc”的二维空间关系轨组：

其中：

object_x指定轨的左上角在由封闭轨组指定的区域内的水平位置。位置值是在0至total_width-1(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，其中total_width是由封闭轨组定义的，

object_y指定轨的左上角在由封闭轨组指定的区域内的垂直位置。位置值是在0至total_height-1(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，其中total_height是由封闭轨组定义的，

object_width指定轨在由封闭轨组指定的区域内的宽度。位置值是在1至total_width(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，其中total_width是由封闭轨组定义的，

object_height指定轨在由封闭轨组指定的区域内的高度。位置值是在1至total_height(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，其中total_height是由封闭轨组定义的，

total_width以像素为单位来指定“srd”轨组的坐标系中的最大宽度。total_width的值应当在具有track_group_id的相同值的SpatialRelationshipDescriptionBox的所有实例中相同，

total_height以像素为单位来指定“srd”轨组的坐标系中的最大高度。total_height的值应当在具有track_group_id的相同值的SpatialRelationshipDescriptionBox的所有实例中相同，

source_id参数提供源的唯一标识符。source_id隐含地定义与该源相关联的坐标系。

SubPictureRegionBox()是提供由封闭轨组指定的区域内的轨的静态位置和大小的可选框。

如果SubPictureRegionBox()存在于SpatialRelationship2DDescriptionBox中，则在关联轨中不应存在关联的SpatialRelationship2DGroupEntry(空间关系2D组条目)(该轨具有恒定静态的大小和位置)。

如果SubPictureRegionBox()不存在于SpatialRelationship2DDescriptionBox中，则在关联轨中应存在一个或多个关联的SpatialRelationship2DGroupEntry(该轨可能具有动态的大小和/或位置)。

定义“2dcc”样本分组的SpatialRelationship2DGroupEntry()允许从二维空间关系轨组中的子图片轨声明样本的位置和大小。当grouping_type等于“2dcc”时，应使用SampleToGroupBox(样本到组框)的版本1。grouping_type_parameter的值应等于相应空间关系轨组的track_group_id。

按照如下定义SpatialRelationship2DGroupEntry()：

其中：

object_x指定该组中的样本的左上角在由相应的空间关系轨组指定的坐标系内的水平位置。位置值是在0到total_width-1(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，其中total_width包括在相应的SpatialRelationship2DDescriptionBox中，

object_y指定该组中的样本的左上角在由相应的空间关系轨组指定的坐标系内的垂直位置。位置值是在0到total_height-1(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，其中total_height包括在相应的SpatialRelationship2DDescriptionBox中，

object_width指定该组中的样本在由相应的空间关系轨组指定的坐标系内的宽度。位置值是在1到total_width(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值，以及

object_height指定该组中的样本在由相应的空间关系轨组指定的坐标系内的高度。位置值是在1到total_height(包括端点)的范围内的、在应用由轨宽度和高度引起的隐式重采样(若有的话)之前的值。

“2dcc”轨组中的各轨的样本可以与来自该相同组中的其它轨的样本(在相同的复合或解码时间)在空间上组成，以产生更大图像。

根据通过打包图像131的编码(图1的步骤140)得到的编码位流和子位流，可以实现采用文件格式的封装的数个变形。

图2示出根据本发明实施例的文件/分段封装(图1的步骤150)的示例的框图。

在步骤200中，服务器判断是否存在数个空间相关的视频位流(即，表示打包图像的空间子部分，并且针对该视频位流，空间复合可以创建更大图像)、或者是否存在可被作为多个子图片轨暴露给客户端的包括表示运动约束的区块或者多个视图的视频子位流的视频位流。如果编码后的打包图像由于被编码为单个视频位流而不能被暴露为多个轨、或者内容创建者不希望将编码后的打包图像暴露为多个轨，则视频位流或视频子位流被封装到单一轨中(步骤210)。否则，在步骤220中判断要封装的媒体内容是否包括表示运动约束的区块的视频子位流。如果为“是”，则可能需要提供至少一个复合轨来表示数个区块轨的至少一个复合。该复合可以表示完整打包图像或仅表示完整打包图像的子部分。使用具有区块轨的复合轨避免了在客户端侧需要流的单独渲染和解码。要向客户端暴露的可能组合的数量取决于内容创建者的选择。例如，内容创建者可能想要根据当前用户的视口来组合具有不同视觉质量的区块。为此，内容创建者可以对具有不同视觉质量的打包图像进行多次编码，并且提出表示包括视觉质量方面的不同区块组合的完整打包图像的数个复合轨。通过根据用户的视口组合不同质量的区块，内容创建者可以减少网络资源的消耗。

如果在步骤220中判断为必须提供复合轨，则判断隐式重建是否可用于复合轨(步骤240)。

例如在ISO/IEC 14496-15第四版中定义的，隐式重建是指从区块基轨和区块轨的位流重建。代替使用诸如提取器等的流内结构以通过用提取器在区块轨的样本中所参考的数据替换复合轨的样本中的提取器、来从区块轨的样本重建复合轨的样本，隐式重建允许通过按轨参考(例如，HEVC隐式重建中的“sabt”轨参考)的顺序级联复合轨和区块轨的样本来重建复合轨的样本。

隐式重建的使用取决于使用的场景。在与编码时的区块顺序相比、数个区块轨的复合在解码时需要区块的重新布置时，必须重写一些条带地址。在这种情况下，不能进行隐式重建，并且必须选择利用提取器的显式重建。

如果可以进行隐式重建，则生成区块基轨(步骤241)，并且将视频子位流封装为不可独立解码的区块轨(例如，被封装为HEVC“hvt1”轨)。

否则，生成提取器轨(步骤242)，并且将视频子位流封装为可独立解码的区块轨(例如，封装为HEVC“hvc1”或“hev1”轨)。

返回到步骤220，如果媒体内容不包含区块子位流或者内容创建者不想创建和暴露复合轨，则将空间相关的视频位流或视频子位流(例如，区块或多个视图)封装到单独的子图片轨中(步骤230)。在该特定情况下，如果区块子位流是HEVC区块，则将这些区块子位流封装为HEVC轨“hvc1”或“hev1”轨。

在步骤250中，添加空间复合所用的信令以将空间相关的视频位流或视频子位流分组在一起。空间复合信令可以通过定义组成该组的各轨(子图片轨、区块轨、复合轨)中的特定TrackGroupTypeBox来提供，其中该组例如是如在前面所述的MPEG ISOBMFF(ISO/IEC14496-12第7版第1次修订)中定义的对于属于相同组的所有轨具有相同的track_group_id的类型“2dcc”的轨组：

该轨组框“2dcc”将提供复合内的轨的相对二维坐标以及通过复合形成的图像的总体大小。该复合可以表示整个打包图像或仅打包图像的子部分。例如，内容创建者可能想要暴露多个复合轨，从而允许构建整个打包图像或仅打包图像的子部分。

可替代地，复合可以表示整个投影图像或仅表示投影图像的子部分。

来自“2dcc”轨组的参数(track_group_id、source_id、total_width、total_height、object_x,object_y、object_width、object_height)直接匹配(在ISO/IEC 23009-1第3版中定义的)DASH空间关系描述(SRD)描述符的参数，该描述符可用在DASH清单中以描述表示这些轨的自适应集的空间关系：

track_group_id将匹配DASH SRD spatial_set_id参数，

source_id将匹配DASH SRD source_id参数，

object_x、object_y、object_width、object_height将分别匹配DASH SRD参数object_x、object_y、object_width、object_height参数，以及

(经由track_group_id)来自关联轨组的total_width和total_height将匹配DASHSRD total_width、total_height参数。

作为替代，在存在复合轨的情况下，空间复合信令可以由该复合轨隐含地提供。实际上，在复合轨是区块基轨的情况下，区块基轨经由类型“sabt”的轨参考来参考区块轨的集合。该区块基轨和区块轨的集合形成复合组。同样，如果复合轨是提取器轨，则提取器轨经由类型“scal”的轨参考来参考区块轨的集合。该提取器轨和区块轨的集合也形成复合组。在这两个情况下，如在ISO/IEC 14496-15第四版中定义的，可以通过定义类型“trif”的样本分组或默认样本分组来提供复合内的各区块轨的相对二维坐标。

作为另一替代，可以通过定义新的实体组来提供空间复合信令。实体组是项目或轨的分组。实体组在MetaBox(元框)中的GroupsListBox(组列表框)中表示。参考轨的实体组可以在文件级MetaBox的GroupsListBox中或者在动画级MetaBox的GroupsListBox中指定。GroupListBox(“grpl”)包含各自被称为EntityToGroupBox(实体到组框)的完整框的集合，其中关联的四字符代码表示所定义的分组类型。按照如下定义EntityToGroupBox：

通常，group_id提供组的id，并且entity_id的集合提供属于实体组的轨的track_ID。在entity_id的集合之后，可以通过针对特定grouping_type定义附加数据来扩展EntityToGroupBox的定义。根据实施例，可以定义例如grouping_type等于“egco”(EntityGroup Composition(实体组复合)的缩写)的新的EntityToGroupBox以描述二维空间相关的视频位流或视频子位流的复合。entity_id的集合将包含组成组的轨(子图片、区块轨、复合轨)的track_ID的集合。可以将通过复合形成的图像的总体大小作为与该新的grouping_type“egco”相关联的附加数据的一部分来提供。

将按照如下定义EntityToGroupBox(“egco”)：

其中：total_width和total_height提供复合的大小，并且source_id提供源的唯一标识符，并且隐含地定义与源相关联的坐标系(即，原点(0,0)及其轴的朝向)。

与DASH相比，group_id将匹配DASH SRD spatial_set_id参数，source_id将匹配DASH SRD source_id参数，并且total_width和total_height将分别匹配DASH SRD total_width和total_height参数。

由类型“egco”的实体分组所定义的复合内的各轨的相对二维坐标可以通过定义如以下所定义的类型(“egco”)的轨组来提供：

其中：object_x、object_y、object_width和object_height提供复合中的各轨的相对二维坐标。

通过定义成group_id等于track_group_id，类型“egco”的给定EntityToGroupBox与相应的SpatialRelationship2DDescriptionBox相关联。

可选地，如在ISO/IEC 14496-15第4版中所定义的，可以通过在各区块轨中定义类型“trif”的样本分组或默认样本分组来提供由类型“egco”的实体分组所定义的复合内的各轨的相对二维坐标。作为替代，可以将相对二维坐标定义为将位于属于组的各区块轨中的VisualSampleEntry(视觉样本条目)中的新的通用完整框2DCoordinateForEntityGroupBox(实体组框的2D坐标)(“2dco”)：

其中：

entity_group_id提供定义组的关联EntityToGroupBox(“egco”)的标识符，

object_x和object_y提供复合内的该轨的样本的左上角的水平和垂直位置，以及

object_width和object_height提供复合内的该轨的样本的宽度和高度。

作为替代，可以按照如下将该新的通用框2DCoordinateForEntityGroupBox(“2dco”)定义为新的样本分组：

返回到图2，在步骤260中，将轨的区域级打包信息添加到描述视频位流或视频子位流的封装的元数据。

区域级打包提供了用于将打包区域中的亮度样本位置重新映射到相应投影区域的亮度样本位置的信息。在MPEG OMAF中，可以根据以下的数据结构来描述区域级打包：

其中：

proj_picture_width和proj_picture_height分别以相对投影图片样本为单位指定投影图片的宽度和高度，

packed_picture_width和packed_picture_height分别以相对打包图片样本为单位指定打包图片的宽度和高度，

num_regions指定当constituent_picture_matching_flag等于0时的打包区域的数量。当constituent_picture_matching_flag等于1时，打包区域的总数量等于2*num_regions，并且RectRegionPacking(i)和GuardBand(i)中的信息适用于投影图片和打包图片的各立体构成图片，

RectRegionPacking(i)指定第i个打包区域和第i个投影区域之间的区域级打包(即，利用可选变换(旋转、镜像)将x、y、宽度、高度坐标从打包区域转换到投影区域)，以及

GuardBand(i)指定第i个打包区域的保护带(若有的话)。

根据本发明的实施例，当在子图片轨中定义区域级打包信息时，该结构仅通过参考完整投影图片来描述子图片轨的打包。因而，packed_picture_width和packed_picture_height等于子图片轨的宽度和高度。

在步骤270中，将针对轨和针对轨的复合的内容覆盖信息添加到描述视频位流或视频子位流的封装的元数据。该步骤是可选的。

轨覆盖信息提供与球体上的由该轨表示的内容所覆盖的区域有关的信息。

复合覆盖信息提供同球面上的与一个或多个轨的组合相关联的区域有关的信息。例如，在动画文件包含具有空间关系的多个视频轨时，复合覆盖信息是球面上的由这些多个视频轨的空间复合所覆盖的区域。在另一示例中，媒体文件包含多个视频轨和表示如何渲染轨的该集合的变换矩阵，然后复合覆盖信息对应于由轨的组装集合覆盖的区域。“复合覆盖信息”也可以表示“全局覆盖信息”或“轨组复合信息”。复合或全局覆盖信息还可以描述球面上的通过这些多个视频轨的子集的复合所得到的区域。

作为第一实施例，可以在无需附加信令的情况下使用单个公共CoverageInformationBox(覆盖信息框)来表示轨覆盖信息和复合覆盖信息。在这种情况下，CoverageInformationBox的范围取决于该框在框层级中的定义的位置。客户端可以仅通过考虑声明的位置来判断覆盖信息是与轨内容有关还是与整个内容有关。根据本实施例，按照如下定义CoverageInformationBox：

Box Type：′covi′

Container：Projected omnidirectional video box(′povd′)or SpatialRelationship2DDescriptionBox(‘2dcc’)

Mandatory：No

Quantity：Zero or one

aligned(8) class CoverageInformationBox extends FullBox(′covi′，0，0)

{

ContentCoverageStruct()

}

其中，ContentCoverageStruct(内容覆盖结构)按照如下指定由SphereRegionStruct()描述的所覆盖的区域的数量：

其中：

coverage_shape_type指定表示内容覆盖的球体区域的形状，

num_regions指定球体区域的数量，

view_idc_presence_flag、default_view_idc和view_idc[i]是用于指示第i个球体区域是在立体内容的左视图、右视图还是这两个视图上的属性，以及

center_azimuth、center_elevation和center_tilt指定所覆盖的区域相对于全局坐标轴的视口朝向；azimuth_range和elevation_range在存在时分别指定所覆盖的球体区域的方位角和仰角范围，并且当前未使用interpolate。

因此，CoverageInformationBox提供与球体上的被内容所覆盖的区域有关的信息。内容的性质取决于该框的容器(Container)。当存在于SpatialRelationship2DDescriptionBox“2dcc”中时，内容是指由属于相同子图片复合轨组的所有轨表示的整个内容，并且由这些轨组成的复合图片被称为整个内容的打包图片。当存在于轨的样本条目中时，内容是指由该轨本身表示的内容，并且该轨中的样本的图片被称为整个内容的打包图片。在对于轨不存在CoverageInformationBox时，这表示内容覆盖整个球体。

应当注意，投影全向视频框(“povd”)是由MPEG OMAF定义且位于轨内的VisualSampleEntry中的中间框。

另外，按照如下修改SpatialRelationship2DDescriptionBox轨组框(“2dcc”)：

作为第二实施例，可以使用具有标志值的单个公共CoverageInformationBox来表示轨覆盖信息和复合覆盖信息，以区分局部和全局指示。由于CoverageInformationBox是ISOBMFF FullBox，因此轨和全局覆盖之间的区分可以通过框的flags(标志)参数来表示。

根据该第二实施例，按照如下定义CoveragInformationBox：

Box Type：′covi′

Container：Projected omnidirectional video box(′povd′)

Mandatory：No

Quantity：Zero or more

aligned(8) class CoverageInformationBox extends FullBox(′covi′，0，0)

{

ContentCoverageStruct()

}

除了在局部的情况下可以定义框的多个实例并且必须在相同轨中定义复合覆盖信息之外，框的结构与在先前实施例中几乎相同。

然后，CoverageInformationBox被定义为提供与球体上的被内容覆盖的区域有关的信息。内容的性质由flags参数给出。覆盖信息flags的默认值是0，这意味着该框描述整个内容的覆盖。如果该轨属于二维空间关系轨组，则整个内容是指由属于相同二维空间关系轨组的所有轨表示的内容，并且从这些轨组成的复合图片被称为整个内容的打包或投影图片。否则，整个内容是指由该轨本身表示的内容，并且该轨中的样本的图片被称为整个内容的打包或投影图片。

在覆盖信息flags的值是1时，该框描述了由该轨表示的内容的打包或投影图片所覆盖的球形区域。

该框的不存在指示内容覆盖整个球体。

另外，按照如下定义新的标志值：

Coverage_local：指示覆盖信息是包含框的轨本地的。标志值是0x000001。在默认情况下，不设置该值。

返回到图2，在步骤280中，检查虚拟现实媒体内容是否实际上是立体虚拟现实媒体内容、即包括左视图和右视图。

如果内容仅是单视场的，则处理直接进入步骤290。

如果内容是立体的，则在步骤285中将立体信令添加到封装。

对于立体内容，传统上，从立体照相机获取左视图序列和右视图序列这两者，并且将这两者根据复合类型复合为视频序列或两个视频序列。

用以将表示立体内容的两个不同视图的两个帧组合成单一帧的处理被称为帧打包(参见图1的步骤125)。

帧打包涉及将形成立体对的两个视图打包成单个帧。存在数个公知的已使用的帧打包方案：并排、上下、帧顺序、垂直线交织类型...。例如，MPEG应用格式ISO/IEC 23000-11第一版(“立体视频应用格式”)或ISO/IEC 23001-8第二版(“编码独立代码点(CICP)”)定义这些方案中的一些方案。帧打包还可以涉及将各视图保持在单独帧中，例如在ISO/IEC23001-8第二版(“CICP”)中定义的具有值6的VideoFramePackingType(视频帧打包类型)那样。

例如，仍根据本说明书，值3表示各解码帧包含两个构成视图的对应帧的并排打包布置，值4表示各解码帧包含两个构成视图的对应帧的上下打包布置。

为了表示轨是否包含立体媒体数据，在轨中的VisualSampleEntry中定义StereoVideoBox(立体视频框)。

返回到图2的步骤250，定义SpatialRelationship2DdescriptionBox以匹配如在经由HTTP的动态自适应流传输(DASH)协议(ISO/IEC 23009-1第3版)中定义的空间关系描述符“SRD”的定义，从而表示如在下表中提供的视频轨之间的空间关系：

具有“2dcc”track_grouping_type的TrackGroupTypeBox指示轨属于与视频的空间部分相对应的一组轨。track_group_type“2dcc”的TrackGroupTypeBox内的source_id的值相同的轨被映射为源自于相同源(即，具有相同的原点(0,0)及其轴的相同朝向)。更确切地，来自具有相同source_id的两个轨组的完整复合图片(具有大小total_width和total_height)在感知上或在视觉上是等同的(例如，两个复合图片以两个不同的分辨率或两个不同的质量表示相同的视觉内容)。

属于具有“2dcc”track_grouping_type和相同track_group_id的TrackGroupTypeBox的所有子图片轨应具有相同的source_id。

属于具有“2dcc”track_grouping_type和不同的track_group_id的TrackGroupTypeBox的轨是兼容的，并且在这些轨具有相同的source_id的情况下可以组合在一起。否则，子图片轨不表示相同源的子部分，以及/或者子图片轨不打算与来自具有“2dcc”track_grouping_type和不同的track_group_id的另一TrackGroupTypeBox的子图片轨组合。例如，当表示相同源的二维投影图片在视觉上不等同时，两个子图片轨不表示该源的子部分(例如，这两个子图片轨具有不同的投影格式或不同的视口朝向)。

作为替代，即使存在来自具有不同source_id的“2dcc”轨组的备选组分组子图片轨，该后者规则也适用。这意味着，这些子图片轨是替代的(例如，这些子图片轨具有不同的编码格式，例如AVC和HEVC)，但这些子图片轨不打算与具有不同编码格式的子图片轨组合。

图4示出上述规则的示例。轨#1至#4属于track_group_id等于10且source_id等于1的类型“2dcc”的轨组41。轨#5至#8属于track_group_id等于20但相同的source_id 400等于1的类型“2dcc”的不同轨组42。还存在track_group_id等于30且不同的source_id 401等于2的类型“2dcc”的第三轨组43。另外，存在数个备选组44至47。属于相同备选组的所有轨(即，在轨头框“tkhd”中具有相同的alternate_group标识符的轨)指定包含备选数据的一组轨或轨的集合。备选数据可以对应于备选位率、编解码、语言、包大小等。在任何一个时间应播放或流传输备选组内的仅一个轨。在该示例中，轨#1、#5和#9属于标识符等于100的相同备选组44。例如，轨#1和轨#5是具有不同质量的备选组，并且轨#9在编解码方面是轨#1和轨#5的备选轨。轨#2、#6和#10属于标识符等于200的相同备选组45。例如，轨#2和轨#6是具有不同分辨率的备选组，并且轨#10在帧频等方面是轨#2和轨#6的备选轨，等等。

轨组41和42具有相同的source_id 400，并且轨组43具有不同的source_id401，这意味着(相对于其它约束，即针对各备选组存在几乎一个子图片轨)可以将属于轨组41和42的子图片轨组合在一起。相反，尽管来自轨组43的子图片轨与来自轨组41和42的任何子图片轨可能属于相同的备选组，但由于这些子图片轨不具有相同的source_id，因此来自轨组43的子图片轨不打算与来自轨组41和42的任何子图片轨组合。然后，source_id参数向播放器提供与可以是相同空间复合的一部分的子图片轨有关的指示。对于给定的空间位置，一个子图片轨可被视为在视觉上等同于相同给定空间位置处的另一子图片轨。这对于当将媒体内容提供到多个轨中时的(子图片)轨选择是有用的。此外，根据所选择的子图片轨，这允许(质量/位率或分辨率方面的)动态适应以显示相同的空间复合。根据图5和图6来说明一些使用示例。

图5示出根据本发明实施例的SpatialRelationship2DdescriptionBox和source_id的使用示例。从质量(@quality1和@quality2)方面，使用相同的视频源(例如，相同的投影视频源)来生成两个替代版本。各替代版本被分成(包含投影区域或打包区域的)八个子图片轨。子图片轨的第一集合以低质量可用。子图片轨的第二集合以更高质量可用。定义两个轨组，即针对各质量级别一个轨组。相应的子图片轨可被描述为在图5的右部分上(在“trak”框层级中)。这两个轨组都具有相同的source_id、total_width和total_height。子图片轨坐标(object_x,object_y,object_width,object_height)描述了子图片轨在各自的轨组复合内的空间关系或位置。由于两个轨组具有相同的source_id，因此这意味着这两个轨组表示相同源，并且可以相对于在复合中的相应位置，将来自第一轨组(track_group_id等于10)的子图片轨与来自相同轨组的子图片轨以及来自第二轨组(track_group_id等于20)的子图片轨组合。

图6示出根据本发明实施例的SpatialRelationship2DdescriptionBox和source_id的第二使用示例。从分辨率(@resolution1和@resolution2)方面，使用相同的视频源(例如，相同的投影视频源)来生成两个替代版本。存在子图片轨的两个集合：用于高分辨率的集合和用于低分辨率的集合。

相应的子图片轨可被描述为在图6的右部分(在“trak”框层级中)。两个轨组具有相同的source_id，但具有与子图片轨的各集合的分辨率相对应的不同的total_width和total_height。子图片轨坐标(object_x,object_y,object_width,object_height)描述了子图片轨在各自的轨组复合内的空间关系或位置。再次地，由于两个轨组具有相同的source_id，因此这意味着这两个轨组表示相同的源，并且可以相对于在各自的复合中的各个位置，将来自第一轨组(track_group_id等于10)的子图片轨与来自相同轨组的子图片轨以及来自第二轨组(track_group_id等于20)的子图片轨组合。在这种情况下，如果将来自不同轨组的子图片轨组合在一起，则应对这些子图片轨应用缩放。缩放因子可以是从来自各轨组的total_height和total_width之间的比率(例如，H1/H2和W1/W2)推导出的。

根据该示例，可以通过从各备选组中选择一个子图片来组成由track_group_id等于10的轨组表示的复合图片。

与二维(2D)视频内容相反，OMAF媒体内容表示用于示出用户从球体中心朝向球体内表面向外观看的观看视角的全向媒体内容。然后通过应用视频投影格式将该360°媒体内容投影在二维平面上。然后，可选地，应用区域级打包以将来自投影图片的区域重新组织成打包区域。360°媒体内容也可以由用鱼眼镜头(广角照相机镜头)捕获到的数个圆形图像来表示。

因此，在OMAF的上下文中，2D图片可以是投影图片或打包图片，并且子图片轨可以包含不同种类的内容：

-(无打包的)投影图片的子部分，

-例如当内容为立体时的帧打包图片的子部分，

-投影和打包图片的子部分，或者

-鱼眼编码图片的子部分。

根据本发明的实施例，改进了SpatialRelationship2DdescriptionBox的定义，以指示包含OMAF媒体内容的子图片轨的大小和位置坐标是与投影图片、打包图片还是另一图片相关。

在一个实施例中，定义了SpatialRelationship2DdescriptionBox，使得包含OMAF媒体内容的子图片轨的大小和位置坐标始终与打包图片相关。当不存在打包时，打包图片等于投影图片。

在另一实施例中，定义了SpatialRelationship2DdescriptionBox，使得包含OMAF媒体内容的子图片轨的大小和位置坐标是与投影图片或打包图片或在捕获步骤110和编码步骤140之间的处理步骤中的任何中间图片相关。特别地，在用于全向媒体的应用格式(OMAF)的情况下，不清楚在2D空间关系中表示的位置和大小是指投影图片还是打包图片。

在一个实施例中，SpatialRelationship2DdescriptionBox始终与打包图片相关。在不存在打包的情况下，打包图片与投影图片相同。

在另一实施例中，优选方法是定义SpatialRelationship2DdescriptionBox始终与投影图片相关。

用于对与场景的宽视图相对应的编码媒体数据进行封装的方法在一些实施例中可以包括以下步骤：

从场景的宽视图获得投影图片；

将所获得的投影图片打包在至少一个打包图片中；

将该至少一个打包图片分成至少一个子图片；

将该至少一个子图片编码到多个轨中；

生成与编码轨相关联的描述性元数据，

其中，该描述性元数据包括与各轨相关联的信息项，该信息项指示编码在轨中的至少一个子图片与至少一个投影图片之间的空间关系。

因此，不需要参考图片的特殊信令。即使子图片是通过分割打包图片所获得的，参考图片也被定义为投影图片。

用于对与场景的宽视图相对应的编码媒体数据进行封装的方法在一些实施例中可以包括以下步骤：

从场景的宽视图获得投影图片；

将该投影图片分成至少一个子图片；

将该至少一个子图片编码到多个轨中；

生成与编码轨相关联的描述性元数据，该描述性元数据包括与各轨相关联的第一信息项，该第一信息项指示编码在轨中的至少一个子图片与参考图片之间的空间关系；

其中，该描述性元数据还包括指示参考图片的第二信息项。

因此，通过在元数据中指定参考图片，可以独立于分割操作而生成与投影图片、打包图片和任何其它参考图片中的任何图片有关的子图片数据。

下表提出了：针对包含例如使用等距柱状投影(ERP)或立方体贴图投影的投影、打包或鱼眼内容的子图片轨，在OMAF的上下文中SpatialRelationship2DdescriptionBox轨组大小和坐标属性相对于投影图片的实际映射。在下表中，“rwpk”是区域级打包结构(即，用于指定打包区域和各个投影区域之间的映射并且指定保护带(若有的话)的位置和大小的结构)的快捷方式。同样，“fovi”是FisheyeVideoEssentialInfoStruct(鱼眼视频基本信息结构)(描述用于使得能够在OMAF播放器处拼接和渲染鱼眼图像的参数的结构)的快捷方式。

将SpatialRelationship2DdescriptionBox属性定义为与投影图片相关与将SpatialRelationship2DdescriptionBox属性定义为与打包图片相关相比为应用提供了优势。实际上，在依赖于视口的流传输的情况下，应用可能仅想要下载与当前用户的视口相对应的(即，与用户的视野和朝向相对应的)子图片轨。如果SpatialRelationship2DdescriptionBox属性被定义为与投影图片相关，则应用可以直接使用来自SpatialRelationship2DdescriptionBox轨组的该信息，以在适当的子图片轨正在投影图片内移动时选择该适当的子图片轨。否则，该应用除了需要解析轨组信息之外，还需要解析位于VisualSampleEntry中的区域级打包信息，以在能够选择适当的子图片轨之前将子图片打包内容转换成投影图片。

可选地，描述空间关系的轨组(例如，“2dcc”轨组)可以包含附加描述符，该附加描述符为给定子图片轨提供其向360°球体的映射。该附加描述符在无需任何计算的情况下为媒体播放器提供在2D视频子图片轨和3D视口之间的映射，使得播放器对与给定用户的观看方向相对应的相关轨或轨集合的选择更容易。描述空间关系的轨组然后按照如下重写：

其中：SpatialRelationship2DSourceBox(空间关系2D源框)和SubPictureRegionBox(子图片区域框)分别描述属于轨组的子图片轨的2D坐标系及其位置和大小；

其中：SphericalRegionBox(球形区域框)是按照如下定义的新框(四字符代码仅仅是示例，可以使用任何四字符代码，只要该四字符代码是为球形区域的指示所保留的即可)：

aligned(8)class SphericalRegionBox extends FullBox(′sspr′，0，0){

SphereRegionStruct(1)；

}

其中：SphereRegionStruct(球体区域结构)将球体区域指定为具有针对方位角(垂直)和仰角(水平)维度的范围的三元组(centre_azimuth，center_elevation，center_pitch)或者有时为具有(yaw，pitch，roll)。

图7示出根据本发明实施例的子图片封装。该图对应于具有可选步骤260和280和285的图1的步骤250。在步骤701中，用户对封装模块(例如，负责图1的步骤150的ISOBMFF写入器或mp4打包器或写入器)进行配置。这可以通过控制封装软件的图形用户界面来实现。这涉及：指定与要封装的源有关的信息或封装(如分解成例如子图片轨或者生成单个媒体文件或许多分段文件那样)所用的参数。可选地，这可被预先登记为捕获场景的记录装置(照相机、网络照相机、智能电话…)中的设置。然后，封装模块在步骤702中将参考图像初始化为捕获图像。这涉及将所捕获到的图像的大小存储在运行封装模块的装置的RAM中。接着，在步骤703中，封装模块检查封装配置是否包含投影步骤。如果为假，则下一步骤是706。例如，当所捕获到的内容是360°内容时，该内容可被投影到称为投影图片的2D图像上。如果投影在使用中(测试703为真)，则封装模块将使用中的投影的描述插入(步骤704)在媒体文件(或媒体分段)的描述性元数据中。这例如可以是根据OMAF规范的投影全向视频框“povd”。然后(步骤705)，将参考图片设置为投影图片。这意味着，例如，将该投影图片的大小存储在存储器中。步骤706涉及检查所捕获到的源是否是立体的、以及视图是否被打包在单个帧中。如果测试706为真，则封装模块将立体内容的描述符插入(步骤707)在媒体文件中。在OMAF或ISOBMFF的情况下，该描述符是StereoVideoBox(立体视频框)。如果测试706为假，则下一步骤是709。在步骤707之后，将帧打包图片存储在参考图片处的存储器中。测试709涉及检查封装配置是否指示需要将投影和可选的帧打包图片进一步重新排列到打包区域中。如果测试709为真，则封装模块将该打包的描述插入(步骤710)到区域中(相当于图1的可选步骤260)。在OMAF的情况下，该描述可以是由“rwpk”框类型标识的RegionWisePackingBox(区域级打包框)。然后，在711中，将参考图片设置为打包图片。如果测试709为假，则下一步骤是712。步骤712中的测试涉及检查封装配置：用户或应用选择或设置了针对子图片轨的隐式信令还是显式信令。如果隐式信令为关闭，则在步骤713中，封装模块插入了用于提供哪个参考图片用于子图片轨生成(即，各自封装在子图片轨中的已分成空间部分的图片)的描述性元数据。如果隐式信令为开启，则下一步骤是714。在步骤714中，封装模块将描述空间关系的轨组插入分割图片的不同空间部分之间。特别地，将子图片轨的如此得到的复合的大小设置为存储器中所存储的参考图片的大小(在702、705、708或711中)。这例如可以是SpatialRelationship2DSourceBox中的total_width和total_height参数。最后，在步骤715中，封装模块从参考图像中的位置和大小方面描述各子图片轨。这例如涉及在OMAF或ISOBMFF中当SubPictureRegionBox的参数为静态时将通过分割得到的值放置在这些参数中，或者涉及用于空间关系描述的样本组描述框(例如，SpatialRelationship2DGroupEntry框)。

可以如连同图8所示的解析处理的描述一起所述以各种方式进行步骤713的显式信令。

用于从包含多个编码轨和关联的描述性元数据的媒体文件生成至少一个图像的方法在一些实施例中可以包括：

确定为多个编码轨包括对至少一个子图片进行编码的一组轨，该至少一个子图片是从通过对场景的宽视图的投影图片进行打包所获得的打包图片的分割得到的；

解析与该一组轨相关联的描述性元数据；

其中，解析与该一组轨相关联的描述性元数据包括：

解释与各轨相关联的信息项，该信息项指示编码在轨中的至少一个子图片与至少一个投影图片之间的空间关系。

用于从包含多个编码轨和关联的描述性元数据的媒体文件生成至少一个图像的方法在一些实施例中可以包括：

确定为多个编码轨包括对至少一个子图片进行编码的一组轨，该至少一个子图片是从场景的宽视图的投影图片的分割得到的；

解析与该一组轨相关联的描述性元数据；

其中，解析与该一组轨相关联的描述性元数据包括：

解释与各轨相关联的第一信息项，该第一信息项指示编码在轨中的至少一个子图片与至少一个参考图片之间的空间关系；以及

解释指示参考图片的第二信息项。

媒体播放器在801中使用ISOBMFF解析器接收OMAF文件。该OMAF文件识别媒体文件中所存在的不同轨并且特别是视频轨。对于这些视频轨，解析器检查这些视频轨是经典的2D视频还是已投影到2D图片上的全向媒体的视频轨。这是通过在步骤802中查看主要品牌(brand)或者在“ftyp”框中的兼容品牌列表内进行查找来确定的。例如，设置为“ovdp”的品牌指示媒体文件包含使用OMAF依赖于视口的基线呈现配置文件所用的技术的VR体验。本发明在实施例中提出定义显式品牌(作为major_brand值或要放在兼容品牌的列表中)，该显式品牌指示根据OMAF依赖于视口的配置文件的VR体验进一步使用子图片轨。可以定义品牌的至少两个具体值(主要或兼容)：

对于全向相关配置文件，可以定义第一值(例如，命名为“odpr”)。该值指示将全向媒体分成参考投影图片的子图片轨。符合该品牌的任何ISOBMFF解析器或OMAF播放器应将子图片轨位置解释为投影图片中的位置。同样，total_width和total_height应分别被解释为投影图片的宽度和高度。

对于全向相关配置文件，可以定义第二值(例如，命名为“odpa”)。该值指示将全向媒体分成参考打包图片的子图片轨。符合该品牌的任何ISOBMFF解析器或OMAF播放器应将子图片轨位置解释为打包图片中的位置。同样，total_width和total_height应分别被解释为打包图片的宽度和高度。

当存在该品牌其中之一时，OMAF播放器或媒体播放器立即识别如何获得参考图片信息。然后，OMAF播放器或媒体播放器针对包含参考图片的指示的空间关系描述解析显式轨组。这是在步骤803中进行的。

当在“ftyp”框中不存在这些品牌时，媒体文件解析器或媒体播放器必须进一步解析媒体文件，以判断子图片轨的存在以及子图片轨是否参考投影或打包图片(测试对象802)。如果根据本发明的实施例、描述空间关系的轨组是显式轨组，则解析器在803中解析这些显式轨组。解析器在步骤804中确定使用中的参考图片以描述(例如经由track_group_id标识的)给定轨组中的子图片轨。当向用户呈现子图片轨以供选择时或者当渲染子图片轨时，必须考虑到这一点。可能需要附加变换以从在参考图片中所表示的子图片轨到捕获图片生成图像。例如，当参考图片是要在投影图片中表示的打包图片时，必须解包子图片轨位置和大小。该处理是步骤812的对象。现在解释如何在封装步骤713期间进行显式信令，以供由解析器在步骤803中使用。

在新品牌的替代实施例中，提出了在轨或轨组级别添加显式信令。这可以使用ISOBMFF中的用于2D空间关系描述的“2dcc”轨组来进行。该附加信令可以帮助解析器或播放器处理子图片轨，特别是判断这些子图片轨是否表示针对投影图片或针对打包图片的位置和大小。

这样的信令的一个实施例可以是在用于空间关系描述的特定轨组类型框中定义新的参数。优选地，在用于空间关系描述的轨组框(即，SpatialRelationship2DSourceBox)的强制部分中定义新的参数，使得解析器可以获得该信息。

本实施例的示例可以是：

其中：“reference_picture”是新参数，该新参数当取值“0”时，指示该组中的子图片轨的位置是在投影图片坐标系中表示的。当取值“1”时，该新参数指示该组中的子图片轨是在打包图片中表示的。赋予该参数的名称是示例。同样，total_width和total_height也分别指示投影图片的宽度和高度。

为了比简单地支持在投影或打包图片之间选择参考图片更通用，reference_picture可以取数个值，其中与中间图片相对应的值用作捕获和编码之间的参考。例如，当不存在投影时，值0可用于所捕获到的图像(步骤702)；当仅存在投影时，可以使用值1(步骤705)；对于帧打包图片，可以使用值2(步骤708)；并且对于打包帧，可以使用值3(步骤711)。与仅支持投影和打包帧的先前实施例相比，该指示将需要2个位。

作为更明确信令的另一实施例涉及(代替整数值)提供4cc代码以描述参考图片。在描述方面，这将更昂贵(针对各子图片轨为4个字节)。例如，为了指示参考图片是投影图片，参考图片值可被设置为“povd”。对于打包图片，参考图片值可被设置为“rwpk”；对于帧打包图片，参考图片值可以为“stvi”。对于所捕获到的图像，默认情况可被设置为专用四字符代码：对于“default”为“dflt”，这意味着所捕获到的图像。优选地，例如由mp4登记机构定义和登记中间图片和整数代码之间的映射，以具有用于参考图片值的互操作代码。

可以可替代地在SpatialRelationship2DDescriptionBox的可选部分(即，SubPictureRegionBox)中声明附加的reference_picture参数。当在步骤712中决定显式信令时，使该参数在强制部分中可以是优选的。这是为了确保解析器或播放器可以找到该信息。

在另一替代实施例中，用于空间关系描述的特定轨组类型框中的附加信令是以该附加信令保持与ISOBMFF或OMAF中的空间关系描述的较早版本的向后兼容性的方式定义的。为此，定义TrackGroupTypeBox的新版本，例如，版本＝1或相同的版本＝0但具有flags值。要注意，现有技术中的TrackGroupTypeBox不允许flags值。向TrackGroupTypeBox提供flags值是本发明实施例的一部分。

可以定义例如设置为值0x01的标志值“Reference_info_is_present”，以指示该轨组包含与参考图片有关的信息，从而考虑空间关系信息的位置和大小。然后，可以按照如下表示2dcc轨组：

其中：reference_picture是新参数，该新参数当取值“0”时，指示该组中的子图片轨的位置是在投影图片坐标系中表示的。参数的名称是作为示例给出的。同样，total_width和total_height分别表示投影图片的宽度和高度。

例如对于2D经典视频，当不存在与参考图片有关的歧义时，使用flags降低了各子图片轨的描述成本。使用flags来指示参考图片的有无允许重复使用2dcc轨分组类型来处理将全向内容分成子图片轨的两个情况(有或无区域级打包步骤)。

在又一实施例中，使用TrackGroupingTypeBox(轨分组类型框)或如SpatialRelationship2DDescriptionBox那样的继承框其中之一的flags参数来直接在flags值中提供参考图片。例如，当flags参数的最低有效位设置为0时，这意味着在全向视频的情况下参考图片是投影图片。当flags参数的最低有效位设置为1时，这意味着在全向视频的情况下参考图片是打包图片。默认值是flags参数设置为0的最低有效位。利用本实施例，在SpatialRelationship2DSourceBox中不存在附加参数，这样使文件描述更加紧凑(针对各子图片轨节省4个字节)。

在替代实施例中，通过使用两个不同的轨分组类型来进行隐式或显式子图片轨信令之间的区别。当前分组类型用于隐式信令，针对显式空间关系轨组定义新的轨分组类型。例如，使用四字符代码“edcc”，并且按照如下创建新的TrackGroupingTypeBox：

当封装配置被判断为“隐式”(测试801和802为假)、这意味着未使用特定信令时，解析器进入参考图片的隐式确定。该隐式确定涉及：解析在限制信息框“rinf”中声明的方案，其中必须对这些方案进行变换或后解码操作并且这些方案潜在地提供参考图片。对于OMAF，在大部分时间，参考图片可以是打包图片或投影图片。对于立体内容，参考图片也可以是帧打包图片。然后，解析器检查OMAF描述符的存在以确定候选参考图片。解析器假定：当在媒体文件中不存在区域级打包指示(测试810为假)时，相对于投影图片表示用于空间关系描述的位置和大小参数。当存在区域级打包框时，相对于打包图片表示空间关系描述的位置和大小参数(步骤811)。可选地，解析器可以通过测试描述空间关系的轨组的子图片轨中的stvi框的存在来考虑帧打包图片的有无(步骤808)。在存在的情况下，解析器将帧打包图片记录为候选参考图片。更一般地，对于隐式信令，子图片轨的位置和大小被视为在从捕获110和编码140之间的不同处理步骤得到的最后一个图片中表示。这些不同的处理被反映在限制方案信息框“rinf”中。例如，当内容准备包含投影120、帧打包125和区域级打包130时，RestrictedSchemeInfoBox(限制方案信息框)“rinf”框在其SchemeTypeBox(方案类型框)中包含指示应用了投影的“povd”框。该“povd”框自身可以包含描述130处进行的区域级打包的结构，例如作为RegionWisePackingBox“rwpk”。同样，例如在CompatibleSchemeTypeBox(兼容方案类型框)中存在立体视频框以指示步骤125中所使用的帧打包。

对于优化的隐式模式并且在封闭系统中，封装和解析器可以交换配置信息或定义设置，以声明用于子图片轨描述的预定义默认模式。例如，当媒体包含全向内容时，封装和解析器可能会同意子图片轨总是参考投影图像。

图9示出根据本发明实施例的包括编码器950和解码器900至少之一以及通信网络999的系统991/995。根据实施例，系统995用于处理内容(例如，用于显示/输出或流传输视频/音频内容的视频和音频内容)，并且例如经由包括解码器900的用户终端或与解码器900进行通信的用户终端的用户界面将该内容提供给访问了解码器900的用户。这样的用户终端可以是计算机、移动电话、平板电脑、或者能够向用户提供/显示(所提供/流传输的)内容的任何其它类型的装置。系统995经由通信网络999(以连续流或信号的形式(例如在正显示/输出较早的视频/音频时))获得/接收位流901。根据实施例，系统991用于处理内容并存储处理后的内容(例如，为了在稍后时间显示/输出/流传输所处理的视频和音频内容)。系统991获得/接收包括由编码器950接收到并处理的、例如与本发明实施例中的宽视图场景相对应的原始图像序列951的内容，并且编码器950生成要经由通信网络991通信至解码器900的位流901。然后，将位流901以多个方式通信至解码器900，例如，位流901可以是由编码器950预先生成、并作为数据存储在通信网络999中的存储设备中(例如，服务器或云存储装置上)，直到用户从存储设备请求内容(即，位流数据)为止，此时从存储设备将数据通信/流传输至解码器900。系统991还可以包括内容提供设备，该内容提供设备用于(例如，通过通信要显示在用户终端上的用户界面所用的数据)向用户提供/流传输存储设备中所存储的内容的内容信息(例如，内容的标题以及用于识别、选择和请求内容的其它元/存储位置数据)，并且用于接收和处理对内容的用户请求，使得可以将所请求的内容从存储设备传递/流传输至用户终端。有利地，在本发明的实施例中，用户终端是头戴式显示器。可选地，当用户请求内容时，编码器950生成位流901并将该位流901直接通信/流传输至解码器900。然后，解码器900接收到位流901(或信号)，并根据本发明对子图片轨进行解码，以获得/生成视频信号909和/或音频信号，该视频信号909和/或音频信号然后由用户终端使用以将所请求的内容提供给用户。

图3是用于实现本发明的一个或多个实施例的计算装置300的示意框图。计算装置300可以是诸如微计算机、工作站或轻型便携式装置等的装置。计算装置300包括通信总线，其中该通信总线连接有以下组件：

-诸如微处理器等的中央处理单元(CPU)301；

-随机存取存储器(RAM)302以及寄存器，其中所述随机存取存储器(RAM)302用于存储本发明实施例的方法的可执行代码，这些寄存器被配置为记录实现用于读取和写入清单以及/或者对视频进行编码以及/或者读取或生成采用给定文件格式的数据的方法所需的变量和参数，其存储器容量例如可以利用连接至扩展端口的可选RAM来扩展；

-只读存储器(ROM)303，用于存储实现本发明实施例所用的计算机程序；

-网络接口304，其通常连接至发送或接收要处理的数字数据所经由的通信网络。网络接口304可以是单个网络接口、或者包括不同的网络接口的集合(例如，有线接口和无线接口或者不同种类的有线接口或无线接口)。在CPU301中运行的软件应用的控制下，将数据写入网络接口以供发送或者从网络接口读取数据以供接收；

-用户接口(UI)305，用于从用户接收输入或向用户显示信息；

-硬盘(HD)306；

-I/O模块307，用于相对于诸如视频源或显示器等的外部装置进行数据的接收/发送。

可执行代码可以存储在只读存储器303中、硬盘306上或者例如盘等的可移除数字介质上。根据变形例，程序的可执行代码可以在执行之前利用通信网络经由网络接口304来接收，从而存储在通信装置300的诸如硬盘306等的存储部件其中之一内。

中央处理单元301被配置为控制和引导根据本发明实施例的程序的指令或软件代码的一部分的执行，其中这些指令存储在上述存储部件其中之一内。在通电之后，CPU 301例如能够在从程序ROM 303或硬盘(HD)306加载了来自主RAM存储器302的与软件应用有关的指令之后，执行这些指令。这种软件应用在由CPU 301执行的情况下，使得进行上述附图所示的流程图的各步骤。

在本实施例中，该设备是使用软件来实现本发明的可编程设备。然而，可选地，本发明可以以硬件形式(例如，以专用集成电路或ASIC的形式)来实现。

尽管以上已经参考具体实施例说明了本发明，但本发明不限于这些具体实施例，并且本领域技术人员将明白存在于本发明的范围内的变形。

例如，本发明可以嵌入用作TV或多媒体显示器的远程控制器的如照相机、智能电话、头戴式显示器或平板终端那样的装置中，以例如放大到特定关注区域上。还可以从相同装置使用本发明，以通过选择特定关注区域来获得多媒体呈现的个性化浏览体验。用户根据这些装置和方法的另一用途是与其它所连接的装置共享他所喜好的视频中的一些选中的子部分。本发明还可用在智能电话或平板终端中以监视在处于监控下的建筑物的特定区域中发生了什么，只要监控照相机支持根据本发明的用于提供数据的方法即可。

在参考仅以示例方式给出且并不意图限制本发明范围的前述例示实施例的情况下，许多其它修改和改变对本领域普通技术人员是不言自明的，其中所述范围仅由所附权利要求书来确定。特别地，在适当情况下，可以互换来自不同实施例的不同特征。