欢迎光临小豌豆知识网!
当前位置:首页 > 电学技术 > 电通讯技术> 用于针对虚拟现实应用程序发送信号通知子图片组合信息的系统和方法独创技术118938字

用于针对虚拟现实应用程序发送信号通知子图片组合信息的系统和方法

2020-11-26 19:51:06

用于针对虚拟现实应用程序发送信号通知子图片组合信息的系统和方法

  技术领域

  本公开涉及交互式视频分发领域,并且更具体地涉及用于在虚拟现实应用程序中发送信号通知子图片组合信息的技术。

  背景技术

  数字媒体回放功能可以结合到各种设备中,这些设备包括:数字电视(包括所谓的“智能”电视)、机顶盒、膝上型电脑或台式电脑、平板电脑、数字录音设备、数字媒体播放器、视频游戏设备、蜂窝电话(包括所谓的“智能”电话)、专用视频流设备等。数字媒体内容(例如,视频和音频编程)可以源自多个源,包括例如无线电视提供方、卫星电视提供方、有线电视提供方、在线媒体服务提供方(包括所谓的流媒体服务提供方)等。数字媒体内容可以通过分组交换网络递送,包括双向网络(诸如互联网协议(IP)网络)和单向网络(诸如数字广播网络)。

  可以根据视频编码标准来对包括在数字媒体内容中的数字视频进行编码。视频编码标准可以结合视频压缩技术。视频编码标准的示例包括ISO/IEC MPEG-4Visual和ITU-TH.264(也被称为ISO/IEC MPEG-4AVC)和高效视频编码(HEVC)。视频压缩技术能够减少存储和传输视频数据的数据需求。视频压缩技术可以通过利用视频序列中固有的冗余来减少数据需求。视频压缩技术可将视频序列再分成连续较小的部分(即,视频序列内的帧组、帧组内的帧、帧内的片段、片段内的编码树单元(例如,宏块)、编码树单元内的编码块等)。可以使用预测编码技术来生成待编码的单位视频数据与参考单位视频数据之间的差值。该差值可以被称为残差数据。残差数据可以被编码为量化变换系数。语法元素可以涉及残差数据和参考编码单元。残差数据和语法元素可以包括在兼容比特流中。可以根据数据结构来格式化兼容比特流和相关联元数据。可以根据传输标准将兼容比特流和相关联元数据从源传输到接收器设备(例如,数字电视或智能电话)。传输标准的示例包括数字视频广播(DVB)标准、综合业务数字广播标准(ISDB)标准和由高级电视系统委员会(ATSC)开发的标准,包括例如ATSC 2.0标准。ATSC目前正在开发所谓的ATSC 3.0标准系列。

  发明内容

  在一个示例中,发送信号通知与全向视频相关联的信息的方法包括发送信号通知轨道组标识符,其中发送信号通知轨道组标识符包括发送信号通知指示对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者的值:仅左视图;仅右视图;或者左视图和右视图。

  在一个示例中,确定与全向视频相关联的信息的方法包括解析与全向视频相关联的轨道组标识符,并且确定对应于轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者:仅左视图;仅右视图;或者基于所述轨道组标识符的所述值的左视图和右视图。

  附图说明

  图1是示出根据本公开的一种或多种技术的可被配置为传输编码视频数据的系统的示例的框图。

  图2A是示出根据本公开的一种或多种技术的经编码视频数据和对应数据结构的概念图。

  图2B是示出根据本公开的一种或多种技术的经编码视频数据和对应数据结构的概念图。

  图3是示出根据本公开的一种或多种技术的编码视频数据和对应数据结构的概念图。

  图4是示出根据本公开的一种或多种技术的坐标系的示例的概念图。

  图5A是示出根据本公开的一种或多种技术的指定球体上的区域的示例的概念图。

  图5B是示出根据本公开的一种或多种技术的指定球体上的区域的示例的概念图。

  图6是示出根据本公开的一种或多种技术的投影图片区域和封装图片区域的示例的概念图。

  图7是示出根据本公开的一种或多种技术的可被包括在可被配置为传输编码视频数据的系统的具体实施中的部件的示例的概念图。

  图8是示出可实现本公开的一种或多种技术的数据封装器的示例的框图。

  图9是示出可实现本公开的一种或多种技术的接收器设备的示例的框图。

  图10是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图11是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图12是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图13是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图14是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图15是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图16是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图17A是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图17B是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图18是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  图19是示出根据本公开的一种或多种技术的发送信号通知元数据的示例的计算机程序列表。

  具体实施方式

  一般来讲,本公开描述了用于发送信号通知与虚拟现实应用程序相关联的信息的各种技术。具体地讲,本公开描述了用于发送信号通知子图片信息的技术。应当指出的是,尽管在一些示例中,相对于传输标准描述了本公开的技术,但本文所述的技术可以是普遍适用的。例如,本文所述的技术通常适用于DVB标准、ISDB标准、ATSC标准、数字地面多媒体广播(DTMB)标准、数字多媒体广播(DMB)标准、混合广播和宽带电视(HbbTV)标准、万维网联盟(W3C)标准和通用即插即用(UPnP)标准中的任一者。此外,应当指出的是,尽管本公开的技术相对于ITU-T H.264和ITU-T H.265进行描述,但本公开的技术可普遍适用于视频编码,包括全向视频编码。例如,本文所述的编码技术可结合到视频编码系统(包括基于未来视频编码标准的视频编码系统)中,包括块结构、帧内预测技术、帧间预测技术、变换技术、滤波技术和/或熵编码技术,不同于ITU-T H.265中包括的那些技术。因此,对ITU-T H.264和ITU-T H.265的参考用于描述性目的,并且不应将其解释为限制本文所述的技术的范围。此外,应当指出的是,将文献以引用方式并入本文不应被解释为限制或产生相对于本文所用术语的歧义。例如,在某个并入的参考文献中提供的对某个术语的定义不同于另一个并入的参考文献和/或如本文所用的该术语的情况下,则该术语应以广泛地包括每个相应定义的方式和/或以包括替代方案中每个特定定义的方式来解释。

  在一个示例中,一种设备包括被配置为发送信号通知轨道组标识符的一个或多个处理器,其中发送信号通知轨道组标识符包括发送信号通知指示对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者的值:仅左视图;仅右视图;或者左视图和右视图。

  在一个示例中,一种非暂态计算机可读存储介质包括存储在其上的指令,这些指令在被执行时使得设备的一个或多个处理器发送信号通知轨道组标识符,其中发送信号通知轨道组标识符包括发送信号通知指示对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者的值:仅左视图;仅右视图;或者左视图和右视图。

  在一个示例中,一种装置包括用于发送信号通知轨道组标识符的装置件,其中发送信号通知轨道组标识符包括发送信号通知指示对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者的值:仅左视图;仅右视图;或者左视图和右视图。

  在一个示例中,一种设备包括一个或多个处理器,该一个或多个处理器被配置为解析与全向视频相关联的轨道组标识符,并且确定对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者:仅左视图;仅右视图;或者基于所述轨道组标识符的所述值的左视图和右视图。

  在一个示例中,一种非暂态计算机可读存储介质包括存储在其上的指令,这些指令在被执行时使得设备的一个或多个处理器解析与全向视频相关联的轨道组标识符,并且确定对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者:仅左视图;仅右视图;或者基于所述轨道组标识符的所述值的左视图和右视图。

  在一个示例中,一种装置包括用于解析与全向视频相关联的轨道组标识符的装置件,以及用于确定对应于该轨道组标识符的每个子图片轨道是否包括用于以下内容中的一者的装置件:仅左视图;仅右视图;或者基于所述轨道组标识符的所述值的左视图和右视图。

  在以下附图和描述中阐述了一个或多个示例的细节。其他特征、对象和优点将从描述和附图以及权利要求书中显而易见。

  视频内容通常包括由一系列帧组成的视频序列。一系列帧也可以被称为一组图片(GOP)。每个视频帧或图片可以包括一个或多个片段,其中片段包括多个视频块。视频块可以被定义为可以被预测性地编码的像素值(也被称为样本)的最大阵列。视频块可以根据扫描模式(例如,光栅扫描)来排序。视频编码器对视频块及其子分区执行预测编码。ITU-TH.264指定包括16×16亮度样本的宏块。ITU-T H.265指定类似的编码树单元(CTU)结构,其中图片可以被分割成相同大小的CTU,并且每个CTU可以包括具有16×16、32×32或64×64亮度样本的编码树块(CTB)。如本文所用,术语“视频块”通常可以指图片的区域,或者可以更具体地指可以被预测性地编码的像素值的最大阵列、其子分区和/或对应结构。此外,根据ITU-T H.265,每个视频帧或图片可以被分区为包括一个或多个图块,其中图块是对应于图片的矩形区域的编码树单元序列。

  在ITU-T H.265中,可以根据对应的四叉树块结构将CTU的CTB分区成编码块(CB)。根据ITU-T H.265,一个亮度CB连同两个对应的色度CB和相关联语法元素被称为编码单元(CU)。CU与对于CU定义一个或多个预测单元(PU)的预测单元(PU)结构相关联,其中PU与对应的参考样本相关联。也就是说,在ITU-T H.265中,使用帧内预测或帧间预测来对图片区域进行编码的决定是在CU级别下进行的,并且对于CU,对应于帧内预测或帧间预测的一个或多个预测可用于生成CU的CB的参考样本。在ITU-T H.265中,PU可以包括亮度和色度预测块(PB),其中方形PB被支持用于帧内预测,并且矩形PB被支持用于帧间预测。帧内预测数据(例如,帧内预测模式语法元素)或帧间预测数据(例如,运动数据语法元素)可将PU与对应的参考样本相关联。残差数据可以包括对应于视频数据的每个分量(例如,亮度(Y)和色度(Cb和Cr))的相应差值阵列。残差数据可能在像素域中。可对像素差值应用变换诸如离散余弦变换(DCT)、离散正弦变换(DST)、整数变换、小波变换或概念上类似的变换,以生成变换系数。应当指出的是,在ITU-T H.265中,CU可以进一步再分为变换单元(TU)。也就是说,为了生成变换系数,可以对像素差值的阵列进行再分(例如,可以将四个8×8变换应用于与16×16亮度CB对应的16×16残差值阵列),此类子分区可以被称为变换块(TB)。可以根据量化参数(QP)来量化变换系数。可以根据熵编码技术(例如,内容自适应可变长度编码(CAVLC)、上下文自适应二进制算术编码(CABAC)、概率区间划分熵编码(PIPE)等)对量化的变换系数(可以被称为位阶值)进行熵编码。此外,也可对语法元素(诸如,指示预测模式的语法元素)进行熵编码。熵编码量化变换系数和对应的熵编码语法元素可形成可用于再现视频数据的兼容比特流。作为熵编码处理的一部分,可以对语法元素执行二值化处理。二值化是指将语法值转换为一个或多个比特的序列的过程。这些比特可以被称为“二进制位”。

  虚拟现实(VR)应用程序可以包括可利用头戴式显示器渲染的视频内容,其中仅渲染对应于用户头部的取向的球形视频的区域。VR应用程序可以通过全向视频启用,该全向视频也被称为360°视频中的360°球形视频。全向视频通常由多个相机捕获,这些相机覆盖高达360°的场景。与普通视频相比,全向视频的显著特征在于,通常仅显示整个捕获视频区域的子集,即,显示对应于当前用户的视场(FOV)的区域。FOV有时也被称为视区。在其他情况下,视区可以被描述为球形视频中当前被显示并由用户查看的部分。应当指出的是,视区的尺寸可小于或等于视场。此外,应当指出的是,可以使用单视场相机或立体相机捕获全向视频。单视场相机可以包括捕获对象的单个视图的相机。立体相机可以包括捕获同一对象的多个视图(例如,使用两个镜头在略微不同的角度下捕获视图)的相机。此外,应当指出的是,在一些情况下,可以使用超广角镜头(即,所谓的鱼眼镜头)捕获用于全向视频应用程序中的图像。在任何情况下,通常可以将用于创建360°球形视频的过程描述为将输入图像拼接在一起并将拼接在一起的输入图像投影到三维结构(例如,球体或立方体)上,这可以导致形成所谓的投影帧。此外,在一些情况下,可以对投影帧的区域进行变换、尺寸调整和重新定位,这可以得到所谓的封装帧。

  传输系统可被配置为将全向视频传输到一个或多个计算设备。计算设备和/或传输系统可基于包括一个或多个抽象层的模型,其中每个抽象层的数据根据特定结构表示,例如,分组结构、调制方案等。包括已定义的抽象层的模型的示例是所谓的开放系统互连(OSI)模型。OSI模型定义了7层堆栈模型,包括应用层、呈现层、会话层、传输层、网络层、数据链路层和物理层。应当指出的是,相对于描述堆栈模型中的层,术语“上”和“下”的使用可基于作为最上层的应用程序层和作为最下层的物理层。此外,在一些情况下,术语“层1”或“L1”可以用于指物理层,术语“层2”或“L2”可以用于指链路层,并且术语“层3”或“L3”或“IP层”可以用于指网络层。

  物理层通常可以指电信号形成数字数据的层。例如,物理层可以指定义调制的射频(RF)符号如何形成数字数据帧的层。数据链路层(也可以被称为链路层)可以指在发送侧的物理层处理之前以及在接收侧的物理层接收之后使用的抽象层。如本文所用,链路层可以指用于在发送侧处将数据从网络层传输到物理层并且用于在接收侧处将数据从物理层传输到网络层的抽象层。应当指出的是,发送侧和接收侧是逻辑角色,并且单个设备可以在一个实例中作为发送侧操作并且在另一个实例中作为接收侧操作。链路层可以将封装在特定分组类型(例如,运动图像专家组-传输流(MPEG-TS)分组、互联网协议第4版(IPv4)分组等)中的各种类型的数据(例如,视频、音频或应用程序文件)抽象为单个通用格式,以供物理层处理。网络层通常可以指发生逻辑寻址的层。也就是说,网络层通常可以提供寻址信息(例如,互联网协议(IP)地址),使得数据分组可以被递送到网络内的特定节点(例如,计算设备)。如本文所用,术语“网络层”可以指链路层上方的层和/或结构中具有数据使得可以接收该数据以用于链路层处理的层。传输层、会话层、呈现层和应用程序层中的每一者均可以定义如何递送数据以供用户应用程序使用。

  ISO/IEC FDIS 23090-12:201x(E);“Information technology-Codedrepresentation of immersive media(MPEG-I)-Part 2:Omnidirectional media format(信息技术-沉浸式媒体的编码表示(MPEG-I)-第2部分:全向媒体格式)”,ISO/IEC JTC 1/SC 29/WG 11(2017年12月11日)定义了启用全向媒体应用程序的媒体应用程序格式,该文献以引用方式并入本文并在本文中称为MPEG-I。MPEG-I指定了用于全向视频的坐标系;可用于将球形视频序列或图像分别转换成二维矩形视频序列或图像的投影和矩形区域式封装方法;使用ISO基础媒体文件格式(ISOBMFF)存储全向媒体和相关联元数据;媒体流传输系统中的全向媒体的封装、发送信号通知和流传输;以及媒体配置文件和呈现配置文件。应当指出的是,为了简洁起见,本文未提供对MPEG-I的完整描述。然而,参考了MPEG-I的相关部分。

  MPEG-I提供其中根据ITU-T H.265对视频进行编码的媒体配置文件。ITU-T H.265在2016年12月的ITU-T H.265建议书的高效视频编码(HEVC)中有所描述,该文献以引用方式并入本文,并且在本文中称为ITU-T H.265。如上所述,根据ITU-T H.265,每个视频帧或图片可以被分区为包括一个或多个片段,并且进一步被分区为包括一个或多个图块。图2A至图2B是示出包括片段并将图片进一步分区为图块的一组图片的示例的概念图。在图2A所示的示例中,图片4被示出为包括两个片段(即,片段1和片段2),其中每个片段包括CTU序列(例如,以光栅扫描顺序排列)。在图2B所示的示例中,图片4被示出为包括六个图块(即,图块1至图块6),其中每个图块是矩形的并且包括CTU序列。应当指出的是,在ITU-T H.265中,图块可以由包含在不止一个片段中的编码树单元组成,并且片段可以由包含在不止一个图块中的编码树单元组成。然而,ITU-T H.265规定应满足以下一个或两个条件:(1)片段中的所有编码树单元属于同一个图块;以及(2)图块中的所有编码树单元属于同一个片段。

  360°球形视频可以包括区域。参考图3所示的示例,360°球形视频包括区域A至区域C,并且如图3所示,图块(即,图块1至图块6)可形成全向视频的区域。在图3所示的示例中,这些区域中的每个区域被示出为包括CTU。如上所述,CTU可形成编码视频数据的片段和/或视频数据的图块。此外,如上所述,视频编码技术可以根据视频块、其子分区和/或对应的结构对图片的区域进行编码,并且应当指出的是,视频编码技术使得视频编码参数能够在视频编码结构的各种水平上进行调整,例如,针对片段、图块、视频块和/或在子分区进行调整。在一个示例中,图3所示的360°视频可以表示体育赛事,其中区域A和区域C包括体育场的看台的视图,区域B包括运动场的视图(例如,视频是通过位于50码线处的360°相机捕获的)。

  如上所述,视区可以是球形视频中当前被显示并由用户查看的部分。因此,可以根据用户的视区选择性地递送全向视频的区域,即,可以在全向视频流中启用视区相关的递送。通常,为了启用视区相关的递送,在编码之前将源内容分割成子图片序列,其中每个子图片序列覆盖全向视频内容的空间区域的子集,然后将子图片序列彼此独立地编码为单层比特流。例如,参考图3,区域A、区域B和区域C中的每者或其部分可以对应于独立编码子图片比特流。每个子图片比特流可以被封装在文件中作为其自身的轨道,并且可以基于视区信息选择性地将轨道递送到接收器设备。应当指出的是,在一些情况下,子图片可能重叠。例如,参考图3,图块1、图块2、图块4和图块5可形成子图片,并且图块2、图块3、图块5和图块6可形成子图片。因此,特定样本可以被包括在多个子图片中。MPEG-I提供了组合对齐的样本包括轨道中的与另一个轨道相关联的样本中的一个样本的情况,该样本具有与该另一个轨道中的特定样本相同的组合时间,或者提供了当在该另一个轨道中具有相同的组合时间的样本不可用时,该样本具有相对于该另一个轨道中的特定样本的组合时间最近的先前组合时间。此外,MPEG-I提供了组成图片包括对应于一个视图的空间帧封装立体图片的一部分的情况,或者当不使用帧封装或使用时间交织帧封装布置时,提供图片本身。

  如上所述,MPEG-I指定了用于全向视频的坐标系。在MPEG-I中,坐标系由单位球体和三个坐标轴组成,即X(从后往前)轴、Y(侧向,从左往右)轴和Z(竖直,从下往上)轴,其中三个轴交于球体的中心。球体上的点的位置由一对球体坐标方位角(f)和仰角(θ)识别。图4示出了球体坐标方位角(f)和仰角(θ)与如MPEG-I中指定的X、Y和Z坐标轴的关系。应当指出的是,在MPEG-I中,方位角的值范围为-180.0°(包括端值)至180.0°(不包括端值),并且仰角的值范围为-90.0°(包括端值)至90.0°(包括端值)。MPEG-I指定了球体上的区域可由四个大圆来指定的情况,其中大圆(也被称为黎曼圆)是球体与穿过该球体的中心点的平面的交点,其中球体的中心和大圆的中心是协同定位的。MPEG-I还描述了球体上的区域可由两个方位角圆和两个仰角圆指定的情况,其中方位角圆是球体上的连接具有相同方位角值的所有点的圆,并且仰角圆是球体上的连接具有相同仰角值的所有点的圆。

  如上所述,MPEG-I指定了如何利用国际标准化组织(ISO)基础媒体文件格式(ISOBMFF)存储全向媒体和相关联元数据。MPEG-I指定了支持元数据的文件格式的情况,该元数据指定由投影帧覆盖的球形表面的区域。具体地讲,MPEG-I包括球体区域结构,该球体区域结构指定具有以下定义、语法和语义的球体区域:

  定义

  球体区域结构(SphereRegionStruct)指定球体区域。

  当centre_tilt等于0时,由该结构指定的球体区域如下导出:

  -如果azimuth_range和elevation_range二者均等于0,则由该结构指定的球体区域是球形表面上的点。

  -否则,使用如下导出的变量centreAzimuth、centreElevation、cAzimuth1、cAzimuth、cElevation1和cElevation2来定义球体区域:

  centreAzimuth=centre_azimuth÷65536

  centreElevation=centre_elevation÷65536

  cAzimuth1=(centre_azimuth-azimuth_range÷2)÷65536

  cAzimuth2=(centre_azimuth+azimuth_range÷2)÷65536

  cElevation1=(centre_elevation-elevation_range÷2)÷65536

  cElevation2=(centre_elevation+elevation_range÷2)÷65536

  参考包含SphereRegionStruct的该实例的结构的语义中指定的形状类型值来如下定义球体区域:

  -当形状类型值等于0时,球体区域由四个点cAzimuth1、cAzimuth2、cElevation1、cElevation2定义的四个大圆以及centreAzimuth和centreElevation定义的中心点指定,并且如图5A所示。

  -当形状类型值等于1时,球体区域由四个点cAzimuth1、cAzimuth2、cElevation1、cElevation2定义的两个方位角圆和两个仰角圆以及centreAzimuth和centreElevation定义的中心点指定,并且如图5B所示。

  当centre_tilt不等于0时,首先如上导出球体区域,然后沿着源自球体原点穿过球体区域的中心点的轴线应用倾斜旋转,其中当从原点朝轴线的正方向观察时,角度值顺时针增大。最终球体区域是在应用倾斜旋转之后的那一个球体区域。

  形状类型值等于0指定球体区域由四个大圆指定,如图5A中所示。

  形状类型值等于1指定球体区域由两个方位角圆和两个仰角圆指定,如图5B所示。

  保留大于1的形状类型值。

  语法

  

  

  语义

  centre_azimuth和centre_elevation指定球体区域的中心。centre_azimuth应在-180*216至180*216-1(包括端值)的范围内。centre_elevation应在-90*216至90*216(包括端值)的范围内。

  Centre_tilt指定球体区域的倾斜角。centre_tilt应在-180*216至180*216-1(包括端值)的范围内。

  azimuth_range和elevation_range(当存在时)分别指定由该结构指定的球体区域的以2–16°为单位的方位角和仰角范围。azimuth_range和elevation_range指定穿过球体区域的中心点的范围,如图5A或图5B所示。当SphereRegionStruct的该实例中不存在azimuth_range和elevation_range时,如包含SphereRegionStruct的该实例的结构的语义中所指定的那样推断它们。azimuth_range应在0至360*216(包括端值)的范围内。elevation_range应在0至180*216(包括端值)的范围内。

  interpolate的语义由包含SphereRegionStruct的该实例的结构的语义指定。

  应当指出的是,关于本文所用的公式,可以使用以下算术运算符:

  +加法

  -减法(作为双参数运算符)或负数(作为一元前缀运算符)

  *乘法,包括矩阵乘法

  xy求幂。将x指定为y的幂。在其他上下文中,此类符号用于上标而非旨在用于解释为求幂。

  /将结果向着零截断的整数除法。例如,将7/4和-7/-4截断为1,将-7/4和7/-4截断为-1。

  ÷在不旨在进行截断或舍入情况下用于表示数学公式中的除法。

  在不旨在进行截断或舍入情况下用于表示数学公式中的除法。

  x%y模量。x除以y的余数,仅针对x≥0且y>0的整数x和y定义。

  应当指出的是,关于本文所用的公式,可以使用以下逻辑运算符:

  x&&y x和y的布尔逻辑“和”

  x||y x和y的布尔逻辑“或”

  !布尔逻辑“否”

  x?y:z如果x为TRUE或不等于0,则求值为y;否则,求值为z。

  应当指出的是,关于本文所用的公式,可以使用以下关系运算符:

  >大于

  ≥大于或等于

  <小于

  ≤小于或等于

  ==等于

  !=不等于

  应当指出的是,在本文所用的语法中,无符号整数(n)是指具有n个比特的无符号整数。此外,比特(n)是指具有n个比特的比特值。

  此外,MPEG-I指定了内容覆盖范围包括一个或多个球体区域的情况。MPEG-I包括具有以下定义、语法和语义的内容覆盖范围结构:

  定义

  该结构中的字段提供内容覆盖范围,该内容覆盖范围由该内容所覆盖的一个或多个球体区域相对于全局坐标轴来表示。

  语法

  

  

  语义

  coverage_shape_type指定表示内容覆盖范围的球体区域的形状。coverage_shape_type具有与描述样本条目的子句(下文提供)中指定的shape_type相同的语义。当将描述球体区域的子句(上文提供)应用于ContentCoverageStruct的语义时,coverage_shape_type的值用作形状类型值。

  num_region指定球体区域的数量。保留值0。

  view_idc_presence_flag等于0指定不存在view_idc[i]。view_idc_presence_flag等于1指定存在view_idc[i],并且指示球体区域与特定(左、右或两者)视图的关联。

  default_view_idc等于0指示每个球体区域是单视场的,等于1指示每个球体区域在立体内容的左视图上,等于2指示每个球体区域在立体内容的右视图上,等于3指示每个球体区域在左视图和右视图两者上。

  view_idc[i]等于1指示第i个球体区域在立体内容的左视图上,等于2指示第i个球体区域在立体内容的右视图上,并且等于3指示第i个球体区域在左视图和右视图两者上。保留等于0的view_idc[i]。

  注:view_idc_presence_flag等于1使能够指示非对称立体覆盖范围。例如,非对称立体覆盖范围的一个示例可通过将num_regions设置为等于2来描述,从而指示一个球体区域位于覆盖-90°至90°(包括端值)的方位角范围的左视图上,并且指示另一个球体区域位于覆盖-60°至60°(包括端值)的方位角范围的右视图上。

  当SphereRegionStruct(1)包括在ContentCoverageStruct()中时,应用描述球体区域的子句(上文提供)并且interpolate应等于0。

  内容覆盖范围由num_regions SphereRegionStruct(1)结构的并集指定。当num_regions大于1时,内容覆盖范围可以是非连续的。

  MPEG-I包括具有以下定义、语法和语义的样本条目结构:

  定义

  样本条目中应只存在一个SphereRegionConfigBox。SphereRegionConfigBox指定由样本指定的球体区域的形状。当样本中的球体区域的方位角和仰角范围不变时,可以在样本条目中指示该方位角和仰角范围。

  语法

  

  语义

  shape_type等于0指定球体区域由四个大圆指定。shape_type等于1指定球体区域由两个方位角圆和两个仰角圆指定。保留大于1的shape_type值。当将描述球体区域的子句(上文提供)应用于球体区域元数据轨道的样本的语义时,shape_type的值用作形状类型值。

  dynamic_range_flag等于0指定球体区域的方位角和仰角范围在参考该样本条目的所有样本中保持不变。dynamic_range_flag等于1指定在样本格式中指示球体区域的方位角和仰角范围。

  static_azimuth_range和static_elevation_range分别指定参考该样本条目的每个样本的球体区域的以2-16°为单位的方位角和仰角范围。static_azimuth_range和static_elevation_range指定穿过球体区域的中心点的范围,如图5A或图5B所示。static_azimuth_range应在0至360*216(包括端值)的范围内。static_elevation_range应在0至180*216(包括端值)的范围内。当static_azimuth_range和static_elevation_range存在且二者均等于0时,参考该样本条目的每个样本的球体区域是球形表面上的点。当存在static_azimuth_range和static_elevation_range时,当将描述球体区域的子句(上文提供)应用于球体区域元数据轨道的样本的语义时,推断azimuth_range和height_range的值分别等于static_azimuth_range和static_elevation_range。

  num_regions指定参考该样本条目的样本中的球体区域的数量。num_regions应等于1。保留num_regions的其他值。

  此外,MPEG-I包括具有以下定义和语法的覆盖范围信息盒:

  定义

  盒类型:“covi”

  容器:ProjectedOmniVideoBox

  强制性的:No

  数量:零或一

  该盒提供关于该轨道的内容覆盖范围的信息,

  注释:当渲染全向视频内容时,完全由OMAF(Omnidirectional MediA Format)播放器处理未被该内容覆盖的区域。

  指定内容覆盖范围的球体区域内的每个球体位置应在解码图片中具有对应的样本。然而,可能存在确实在解码图片中具有对应样本但在内容覆盖范围之外的一些球体位置。

  语法

  aligned(8)class CoverageInformationBox extends FullBox('covi',0,0){

  ContentCoverageStruct()

  }

  如上所述,MPEG-I指定了可用于将球形视频序列转换成二维矩形视频序列的投影和矩形区域式封装方法。这样,MPEG-I指定了具有以下定义、语法和语义的区域式封装结构:

  定义

  RegionWisePackingStruct指定封装区域和相应投影区域之间的映射,并且指定保护带(如果有的话)的位置和尺寸。

  注释:在其他信息中,RegionWisePackingStruct还在2D笛卡尔图片域中提供内容覆盖信息。

  根据该语法结构的容器,该子句的语义中的解码图片是以下任一项:

  -针对视频,解码图片是由视频轨道的样本所得的解码输出。

  -针对图像项,解码图片是该图像项的重构图像。

  下文翔实地汇总了RegionWisePackingStruct的内容,而规范语义随后跟随在该子句中:

  -投影图片的宽度和高度分别用proj_picture_width和proj_picture_height明确地发送信号通知。

  -封装图片的宽度和高度分别用packed_picture_width和packed_picture_height明确地发送信号通知。

  -当投影图片是立体的并且具有从上到下或并排的帧封装布置时,constituent_picture_matching_flag等于1指定

  ο该语法结构中的投影区域信息、封装区域信息和保护带区域信息各自应用于每个组成图片,

  ο封装图片和投影图片具有相同的立体帧封装格式,并且

  ο投影区域和封装区域的数量是语法结构中num_region的值所指示的数量的两倍。

  -RegionWisePackingStruct包含循环,其中循环条目对应于两个组成图片中的相应投影区域和封装区域(当constituent_picture_matching_flag等于1时),或者对应于投影区域和相应封装区域(当constituent_picture_matching_flag等于0时),并且循环条目包含下述:

  ο指示封装区域的保护带的存在的标记,

  ο封装类型(然而,在MPEG-I中指定仅矩形区域式封装),

  ο矩形区域封装结构RectRegionPacking(i)中的投影区域和相应封装区域之间的映射,

  ο当保护带存在时,用于封装区域的保护带结构GuardBand(i)。

  下文翔实地汇总了矩形区域封装结构RectRegionPacking(i)的内容,而规范语义随后跟随在该子句中:

  -proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]和proj_reg_left[i]分别指定第i个投影区域的宽度、高度、顶部偏移和左侧偏移。

  -transform_type[i]指定应用于第i个封装区域以将其重新映射到第i个投影区域的旋转和镜像(如果有的话)。

  -packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]分别指定第i个封装区域的宽度、高度、顶部偏移和左侧偏移。

  下文翔实地汇总了保护带结构GuardBand(i)的内容,而规范语义随后跟随在该子句中:

  -left_gb_width[i]、right_gb_width[i]、top_gb_height[i]或bottom_gb_height[i]分别指定第i个封装区域的左侧、右侧、上方或下方的保护带尺寸。

  -gb_not_used_for_pred_flag[i]指示编码是否以保护带在帧间预测过程中不用作参考的方式受到约束。

  -gb_type[i][j]指定第i个封装区域的保护带的类型。

  图6示出了投影图片(左侧)内的投影区域的位置和尺寸以及具有保护带的封装图片(右侧)内的封装区域的位置和尺寸的示例。当constituent_picture_matching_flag的值等于0时,应用该示例。

  语法

  

  

  语义

  proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]和proj_reg_left[i]分别指定在投影图片内(当constituent_picture_matching_flag等于0时)或在投影图片的组成图片内(当constituent_picture_matching_flag等于1时)的第i个投影区域的宽度、高度、顶部偏移和左侧偏移。以相对投影图片样本单位指示proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]和proj_reg_left[i]。

  注1:两个投影区域可彼此部分重叠或完全重叠。当存在质量差异的指示(例如,通过区域式质量排名指示)时,则对于任何两个重叠投影区域的重叠区域,应当使用对应于被指示为具有较高质量的投影区域的封装区域进行渲染。

  transform_type[i]指定应用于第i个封装区域以将其重新映射到第i个投影区域的旋转和镜像。当transform_type[i]指定旋转和镜像两者时,在镜像之前应用旋转以用于将封装区域的样本位置转换为投影区域的样本位置。指定了以下值:

  0:无变换

  1:水平镜像

  2:旋转180°(逆时针)

  3:水平镜像前旋转180°(逆时针)

  4:水平镜像前旋转90°(逆时针)

  5:旋转90°(逆时针)

  6:水平镜像前旋转270°(逆时针)

  7:旋转270°(逆时针)

  注释2:MPEG-I指定了transform_type[i]的语义,用于将封装图片中的封装区域的样本位置转换为投影图片中的投影区域的样本位置。

  packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]分别指定在封装图片内(当constituent_picture_matching_flag等于0时)或在封装图片的每个组成图片内(当constituent_picture_matching_flag等于1时)的第i个封装区域的宽度、高度、偏移和左侧偏移。以相对封装图片样本单位指示packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]。packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]应表示解码图片内的亮度样本单元的整数水平坐标和竖直坐标。

  注释3:两个封装区域可部分地或完全地彼此重叠。

  应当指出的是,为了简洁起见,本文不提供矩形区域封装结构、保护带结构和区域式封装结构的完整语法和语义。此外,本文不提供区域式封装结构的语法元素的区域式封装变量和约束的完全推导。然而,参考了MPEG-I的相关部分。

  如上所述,MPEG-I指定了媒体流传输系统中的全向媒体的封装、发送信号通知和流传输。具体地讲,MPEG-I指定了如何利用超文本传输协议(HTTP)上的动态自适应流传输(DASH)来封装、发送信号通知和流传输全向媒体。DASH在ISO/IEC:ISO/IEC 23009-1:2014,“Information technology-Dynamic adaptive streaming over HTTP(DASH)-Part 1:Media presentation description and segment formats”,国际标准化组织,第2版,2014年5月15日(在下文中,“ISO/IEC 23009-1:2014”)中有所描述,该文献以引用方式并入本文。DASH媒体呈现可以包括数据分段、视频分段和音频分段。在一些示例中,DASH媒体呈现可对应于由服务提供方定义的给定持续时间的线性服务或线性服务的一部分(例如,单个TV节目或在一段时间内连续的线性TV节目集)。根据DASH,媒体呈现描述(MPD)是包括DASH客户端构造适当的HTTP-URL以访问分段并向用户提供流传输服务所需的元数据的文档。MPD文档片段可以包括可扩展标记语言(XML)编码的元数据片段集。MPD的内容为媒体呈现内的所识别资源提供分段的资源标识符和上下文。描述了相对于ISO/IEC 23009-1:2014的MPD片段的数据结构和语义。此外,应当指出的是,目前正在提出ISO/IEC 23009-1的草案版本。因此,如本文所用,MPD可以包括如ISO/IEC 23009-1:2014中描述的MPD、当前提出的MPD、和/或它们的组合。在ISO/IEC 23009-1:2014中,如MPD中描述的媒体呈现可以包括一个或多个周期的序列,其中每个周期可以包括一个或多个适应集。应当指出的是,在适应集包括多个媒体内容部件的情况下,可以单独描述每个媒体内容部件。每个适应集可以包括一个或多个表示。在ISO/IEC 23009-1:2014中,提供了每个表示:(1)作为单个分段,其中子分段在具有适应集的表示中对齐;以及(2)作为一系列分段,其中每个分段可以由模板生成的全球资源定位符(URL)寻址。每个媒体内容部件的属性可以由AdaptationSet元素和/或适应集内的元素描述,包括例如ContentComponent元素。

  ISO/IEC:ISO/IEC 23009-1,“Information technology-Dynamic adaptivestreaming over HTTP(DASH)-Part 1:Media presentation description and segmentformats(信息技术-HTTP上的动态自适应流(DASH)-第1部分:媒体呈现描述和片段格式)”,国际标准化组织,第3版,描述了相关联的表示,其中相关联的表示是为至少一个其他表示提供补充或描述信息的表示。由包含@associationId属性和任选地包含@associationType属性的表示元素的属性来描述相关联的表示。@associationId属性和@associationType属性在DASH中定义,如表1A中所提供:

  

  表1A

  如上所述,MPEG-I提供了组合对准的样本包括轨道中的与另一个轨道相关联的样本中的一个样本的情况,该样本具有与该另一个轨道中的特定样本相同的组合时间,或者提供了当在该另一个轨道中具有相同的组合时间的样本不可用时,该样本具有相对于该另一个轨道中的特定样本的组合时间最近的先前组合时间。Hannuksela等人在2017年12月的ISO/IEC JTC1/SC29/WG11 MPEG2017/W17279“Technologies under consideration onsub-picture composition track grouping for OMAF(OMAF子图片组合轨道分组技术研究)”(中国澳门,以引用方式并入,并且在本文中被称为“Hannuksela”)中提出了组合图片,该组合图片是适合呈现的图片,并且通过如由子图片组合轨道组的语法元素所指定的那样在空间上布置它们来从子图片组合轨道组的所有轨道的组合对准的样本的解码输出获得。

  相对于子图片组合轨道组,Hannuksela提供了具有以下定义、语法和语义的子图片组合轨道分组数据结构:

  定义

  track_group_type等于“spco”的TrackGroupTypeBox指示该轨道属于可以在空间上被布置用于获得组合图片的轨道的组合。映射到该分组的视觉轨道(即,在track_group_type等于“spco”的TrackGroupTypeBox内具有相同的track_group_id值的视觉轨道)共同表示可呈现的视觉内容。在没有其他视觉轨道的情况下可能或可能不旨在单独地呈现映射到该分组的每个单独的视觉轨道,而适合呈现组合图片。

  注释1:内容作者可以使用TrackHeaderBox的track_not_intended_for_presentation_alone标记来指示在没有其他视觉轨道的情况下不旨在单独地呈现单独的视觉轨道。

  注释2:当图块轨道集和相关联的图块基础轨道中携带有HEVC视频比特流并且该比特流表示由子图片组合轨道组指示的子图片时,仅图块基础轨道包含SubPictureCompositionBox。

  如根据下文的语义所指定的,通过在空间上布置属于相同子图片组合轨道组和属于相同另选组的所有轨道的组合对准的样本的解码输出来导出组合图片。

  语法

  

  语义

  track_x指定以亮度样本为单位的该轨道的样本的左上角在组合图片上的水平位置。track_x的值应在0到composition_width-1(包括端值)的范围内。

  track_y指定以亮度样本为单位的该轨道的样本的左上角在组合图片上的垂直位置。track_y的值应在0到composition_height-1(包括端值)的范围内。

  track_width指定以亮度样本为单位的该轨道的样本在组合图片上的宽度。track_width的值应在1到composition_width-1(包括端值)的范围内。

  track_height指定以亮度样本为单位的该轨道的样本在组合图片上的高度。track_height的值应在1到composition_height-1(包括端值)的范围内。

  composition_width指定以亮度样本为单位的组合图片的宽度。在具有相同的track_group_id值的SubPictureCompositionBox的所有实例中,composition_width的值应相同。

  composition_height指定以亮度样本为单位的组合图片的高度。在具有相同的track_group_id值的SubPictureCompositionBox的所有实例中,composition_height的值应相同。

  由track_x、track_y、track_width和track_height表示的矩形被称为该轨道的子图片矩形。

  对于属于相同子图片组合轨道组和属于相同另选组(即,具有相同的非零alternate_group值)的所有轨道,子图片矩形的位置和尺寸应分别相同。

  子图片组合轨道组的组合图片如下导出:

  1)在属于子图片组合轨道组的所有轨道中,从每个另选组中选取一个轨道。

  2)对于每个所选取的轨道,应用以下项:

  a.对于在0至track_width-1(包括端值)的范围内的i的每个值以及对于在0至track_height-1(包括端值)的范围内的j的每个值,将在亮度样本位置((i+track_x)%composition_width,(j+track_y)%composition_height)处的组合图片的亮度样本设置为等于在亮度样本位置(i,j)处的该轨道的子图片的亮度样本。

  b.当解码的图片具有除4:0:0的色度格式时,相应地导出色度分量。

  属于相同子图片组合轨道组和属于不同另选组(即,具有alternate_group等于0或是不同的alternate_group值)的所有轨道的子图片矩形不应重叠且不应有间隔,使得在组合图片的上述推导过程中,每个亮度样本位置(x,y)恰好遍历一次,其中x在0至composition_width-1(包括端值)的范围内,并且y在0至composition_height-1(包括端值)的范围内。

  此外,Hannuksela关于可如何将子图片组合轨道分组应用于全向视频提供了以下内容:

  当映射到子图片组合轨道组的轨道中的任一个在包括在样本条目中的SchemeTypeBox中具有等于“resv”的样本条目类型和等于“podv”的scheme_type时,则应用本子句。

  每个组合图片是封装图片,该封装图片具有由任何ProjectionFormatBox指示的投影格式,并且任选地具有由相同子图片组合轨道组的任何轨道的样本条目内的任何StereoVideoBox指示的帧封装布置,并且任选地具有由包括在相同子图片组合轨道组的任何SubPictureCompositionBox中的任何RegionWisePackingBox指示的区域式封装格式。

  SubPictureCompositionBox中的SubPictureRegionBox的track_width和track_height应分别等于由解码器以亮度样本为单位输出的图片的宽度和高度。

  将以下约束应用于映射到该分组的轨道:

  -映射到该分组的每个轨道应具有等于“resv”的样本条目类型。scheme_type应等于包括在样本条目中的SchemeTypeBox中的“podv”。

  -包括在映射到相同子图片组合轨道组的轨道的样本条目中的ProjectionFormatBox的所有实例的内容应相同。

  -RegionWisePackingBox不应存在于映射到任何子图片组合轨道组的轨道的样本条目中。

  -当RegionWisePackingBox存在于具有特定track_group_id值的SubPictureCompositionBox中时,其将存在于具有相同track_group_id值的SubPictureCompositionBox的所有实例中并且是相同的。

  注释:可将区域式封装应用于子图片轨道中携带的立体全向视频,使得子图片是单视场(仅包含一个视图)或立体的(包含两个视图)。当来自左视图和右视图两者的封装区域被布置为形成矩形区域时,该矩形区域的边界可以是由左视图和右视图两者组成的立体子图片的边界。当来自仅左视图或仅右视图的封装区域被布置为形成矩形区域时,该矩形区域的边界可以是仅由左视图或仅由右视图组成的单视场子图片的边界。

  -包括在映射到相同子图片组合轨道组的轨道的样本条目中的RotationBox的所有实例的内容应相同。

  -包括在映射到相同子图片组合轨道组的轨道的样本条目中的StereoVideoBox的所有实例的内容应相同。

  -包括在映射到相同子图片组合轨道组的轨道中的SubPictureCompositionBox的所有实例中的CoverageInformationBox的所有实例的内容应相同。

  将以下项应用于每个子图片组合轨道组:

  -单视场投影亮度图片的宽度和高度(分别为ConstituentPicWidth和ConstituentPicHeight)如下导出:

  ο如果RegionWisePackingBox不存在于SubPictureCompositionBox中,则分别将ConstituentPicWidth和ConstituentPicHeight设置为等于composition_width/HorDiv1和composition_height/VerDiv1。

  ο否则,分别将ConstituentPicWidth和ConstituentPicHeight设置为等于proj_picture_width/HorDiv1和proj_picture_height/VerDiv1。

  -如果RegionWisePackingBox不存在于SubPictureCompositionBox中,则将RegionWisePackingFlag设置为等于0。否则,将RegionWisePackingFlag设置为等于1。

  -该子图片组合轨道组的每个组合图片的样本位置的语义在MPEG-I的子句7.3.1中指定。

  Hannuksela提出的子图片区域盒可能不太理想。具体地讲,Hannuksela提出的SubPictureRegionBox可能相对于发送信号通知子图片组合轨道分组没有提供足够的灵活性。

  如上所述,在DASH中,轨道可以属于子图片组合轨道组。在适应集层级处,Hannuksela提出了@spatialSetId属性,以对属于相同子图片组合轨道组的轨道进行分组。具体地讲,Hannuksela提出了具有以下关于表1中给出的定义的@spatialSetId属性。应当指出的是,在下表中,对于使用,M=强制性的,CM=有条件地强制性的,并且O=任选的。此外应当指出的是,“使用”列可以替代性地被标记为“基数”。另外,“使用”列中条目1可改为M(即强制性的或必需的)或反之亦然,并且“使用”列中条目0..1可改为O(即任选的)或CM(即有条件地强制性的)或反之亦然。

  定义任选的适应集级别属性,@spatialSetId,并将其用于对携带属于相同子图片组合轨道组的轨道的适应集进行分组。@spatialSetId的语义如下:

  

  表1

  使用Hannuksela中提供的@spatialSetId属性对属于相同子图片组合轨道组的轨道进行分组具有以下限制:每个适应集仅可以属于单个子图片组合分组。在某些情况下,适应集可以属于多于一个子图片组合。例如,在视频由16个图块(每个图块在适应集中)组成的情况下,则一个子图片组合可以发送信号通知所有16个图块属于第一组合。例如,此类组合可由具有较高分辨率和较高级载体的视频解码器处理。同时,另一个子图片组合可以仅发送信号通知中心四个图块属于第二组成。例如,该组合可由较低分辨率、较低级的视频解码器处理。在另一个示例中,适应集1-6可以对应于立方映射投影的左视图,并且适应集7-12可以对应于立方映射投影的右视图。在这种情况下,针对单视场客户端的一个子图片组合可以使用六个适应集,而针对立体客户端的另一个子图片组合可以使用所有12个适应集。因此,同一适应集可以属于多个子图片组合。当同一适应集属于多个子图片组合时,不能用@spatialSetId属性发送信号通知这些类型的分组。

  图1是示出根据本公开的一种或多种技术的可以被配置为对视频数据进行编码(例如,编码和/或解码)的系统的示例的框图。系统100表示可以根据本公开的一种或多种技术来封装视频数据系统的示例。如图1所示,系统100包括源设备102、通信介质110和目标设备120。在图1所示的示例中,源设备102可以包括被配置为对视频数据进行编码并将编码视频数据传输到通信介质110的任何设备。目标设备120可以包括被配置为经由通信介质110接收编码视频数据并且对编码视频数据进行解码的任何设备。源设备102和/或目标设备120可以包括配备用于进行有线和/或无线通信的计算设备,并且可以包括例如机顶盒、数字视频录像机、电视机、台式电脑、膝上型电脑或平板电脑、游戏控制台、医学成像设备和移动设备(包括例如智能电话、蜂窝电话、个人游戏设备)。

  通信介质110可以包括无线和有线通信介质和/或存储设备的任意组合。通信介质110可以包括同轴电缆、光纤电缆、双绞线电缆、无线发射器和接收器、路由器、交换机、中继器、基站或可用于促进各种设备和站点之间的通信的任何其他设备。通信介质110可以包括一个或多个网络。例如,通信介质110可以包括被配置为允许访问万维网例如互联网的网络。网络可以根据一个或多个电信协议的组合操作。电信协议可以包括专有方面并且/或者可以包括标准化电信协议。标准化电信协议的示例包括数字视频广播(DVB)标准、高级电视系统委员会(ATSC)标准、综合服务数字广播(ISDB)标准、有线数据业务接口规范(DOCSIS)标准、全球移动通信系统(GSM)标准、码分多址(CDMA)标准、第3代合作伙伴计划(3GPP)标准、欧洲电信标准协会(ETSI)标准、互联网协议(IP)标准、无线应用协议(WAP)标准以及电气与电子工程师协会(IEEE)标准。

  存储设备可以包括能够存储数据的任何类型的设备或存储介质。存储介质可以包括有形或非暂态计算机可读介质。计算机可读介质可以包括光盘、闪存存储器、磁存储器或任何其他合适的数字存储介质。在一些示例中,存储器设备或其部分可以被描述为非易失性存储器,并且在其他示例中,存储器设备的部分可以被描述为易失性存储器。易失性存储器的示例可以包括随机存取存储器(RAM)、动态随机存取存储器(DRAM)和静态随机存取存储器(SRAM)。非易失性存储器的示例可以包括磁性硬盘、光盘、软盘、闪存或电可编程存储器(EPROM)或电可擦除和可编程(EEPROM)存储器的形式。一个或多个存储设备可以包括存储卡(例如,安全数字(SD)存储卡)、内部/外部硬盘驱动器和/或内部/外部固态驱动器。数据可以根据定义的文件格式存储在存储设备上。

  图7是示出可以被包括在系统100的具体实施中的部件的示例的概念图。在图7所示的示例具体实施中,系统100包括一个或多个计算设备402A至402N、电视服务网络404、电视服务提供方站点406、广域网408、局域网410以及一个或多个内容提供方站点412A至412N。图7中所示的具体实施表示系统的示例,该系统可被配置为允许数字媒体内容(诸如电影、现场体育赛事等)和与其相关联的数据和应用程序以及媒体呈现被分发到多个计算设备(诸如计算设备402A至402N)并由该多个计算设备访问。在图7所示的示例中,计算设备402A至402N可以包括被配置为从电视服务网络404、广域网408和/或局域网410中的一者或多者接收数据的任何设备。例如,计算设备402A至402N可以配备用于有线和/或无线通信,并且可被配置为通过一个或多个数据信道接收服务,并且可以包括电视,包括所谓的智能电视、机顶盒和数字视频记录器。此外,计算设备402A至402N可以包括台式计算机、膝上型计算机或平板计算机、游戏控制台、移动设备(包括例如“智能”电话、蜂窝电话和个人游戏设备)。

  电视服务网络404是被配置为允许分发可以包括电视服务的数字媒体内容的网络的示例。例如,电视服务网络404可以包括公共空中电视网络、公共或基于订阅的卫星电视服务提供方网络,以及公共或基于订阅的有线电视提供方网络和/或云上或互联网服务提供方。应当指出的是,尽管在一些示例中,电视服务网络404可以主要用于允许提供电视服务,但是电视服务网络404还可以根据本文所述的电信协议的任何组合允许提供其他类型的数据和服务。此外,应当指出的是,在一些示例中,电视服务网络404可以允许电视服务提供方站点406与计算设备402A至402N中的一个或多个之间的双向通信。电视服务网络404可以包括无线和/或有线通信媒体的任何组合。电视服务网络404可以包括同轴电缆、光纤电缆、双绞线电缆、无线发射器和接收器、路由器、交换机、中继器、基站或可用于促进各种设备和站点之间的通信的任何其他设备。电视服务网络404可以根据一个或多个电信协议的组合操作。电信协议可以包括专有方面并且/或者可以包括标准化电信协议。标准化电信协议的示例包括DVB标准、ATSC标准、ISDB标准、DTMB标准、DMB标准、有线数据服务接口规范(DOCSIS)标准、HbbTV标准、W3C标准和UPnP标准。

  再次参考图7,电视服务提供方站点406可被配置为经由电视服务网络404分发电视服务。例如,电视服务提供方站点406可以包括一个或多个广播站、有线电视提供方、或卫星电视提供方、或基于互联网的电视提供方。例如,电视服务提供方站点406可被配置为通过卫星上行链路/下行链路接收传输(包括电视节目)。此外,如图7所示,电视服务提供方站点406可以与广域网408通信,并且可被配置为从内容提供方站点412A至412N接收数据。应当指出的是,在一些示例中,电视服务提供方站点406可以包括电视演播室,并且内容可以源自该电视演播室。

  广域网408可以包括基于分组的网络,并且根据一个或多个电信协议的组合运营。电信协议可以包括专有方面并且/或者可以包括标准化电信协议。标准化电信协议的示例包括全球系统移动通信(GSM)标准、码分多址(CDMA)标准、第3代合作伙伴计划(3GPP)标准、欧洲电信标准协会(ETSI)标准、欧洲标准(EN)、IP标准、无线应用协议(WAP)标准、以及电气与电子工程师协会(IEEE)标准,诸如,一个或多个IEEE 802标准(例如,Wi-Fi)。广域网408可以包括无线和/或有线通信媒体的任何组合。广域网480可以包括同轴电缆、光纤电缆、双绞线电缆、以太网电缆、无线发射器和接收器、路由器、交换机、中继器、基站、或可用于促进各种设备和站点之间的通信的任何其他设备。在一个示例中,广域网408可以包括互联网。局域网410可以包括基于分组的网络,并且根据一个或多个电信协议的组合运营。可以基于访问级别和/或物理基础设施将局域网410与广域网408区分开。例如,局域网410可以包括安全家庭网络。

  再次参考图7,内容提供方站点412A至412N表示可以向电视服务提供方站点406和/或计算设备402A至402N提供多媒体内容的站点的示例。例如,内容提供方站点可以包括具有一个或多个工作室内容服务器的工作室,该工作室内容服务器被配置为向电视服务提供方站点406提供多媒体文件和/或流。在一个示例中,内容提供方站点412A至412N可被配置为使用IP套件提供多媒体内容。例如,内容提供方站点可被配置为根据实时流协议(RTSP)、HTTP等向接收器设备提供多媒体内容。此外,内容提供方站点412A至412N可被配置为通过广域网408向接收机设备402A至402N和/或电视服务提供方站点406中的一个或多个提供包括基于超文本的内容等的数据。内容提供方站点412A至412N可以包括一个或多个web服务器。可以根据数据格式来定义由数据提供方站点412A至412N提供的数据。

  再次参考图1,源设备102包括视频源104、视频编码器106、数据封装器107和接口108。视频源104可以包括被配置为捕获和/或存储视频数据的任何设备。例如,视频源104可以包括摄像机和可操作地与其耦接的存储设备。视频编码器106可以包括被配置为接收视频数据并生成表示视频数据的兼容比特流的任何设备。兼容比特流可以指视频解码器可以从其接收和再现视频数据的比特流。兼容比特流的各方面可根据视频编码标准来定义。当生成兼容比特流时,视频编码器106可以压缩视频数据。压缩可能是有损的(观察者可觉察的或不可觉察的)或无损的。

  再次参考图1,数据封装器107可以接收编码视频数据,并根据定义的数据结构生成兼容比特流,例如,NAL单元序列。接收兼容比特流的设备可以从其再现视频数据。应当指出的是,可以使用术语符合性比特流来代替术语兼容比特流。应当指出的是,数据封装器107不必要位于与视频编码器106相同的物理设备中。例如,被描述为由视频编码器106和数据封装器107执行的功能可以分布在图7所示的设备中。

  在一个示例中,数据封装器107可以包括被配置为接收一个或多个媒体部件并基于DASH生成媒体呈现的数据封装器。图8是示出可实现本公开的一种或多种技术的数据封装器的示例的框图。数据封装器500可被配置为根据本文所述的技术生成媒体呈现。在图8所示的示例中,部件封装器500的功能块对应于用于生成媒体呈现(例如,DASH媒体呈现)的功能块。如图8所示,部件封装器500包括媒体呈现描述生成器502、分段生成器504和系统存储器506。媒体呈现描述生成器502、分段生成器504和系统存储器506中的每一者可以互连(物理地、通信地和/或可操作地)以用于部件间的通信,并且可以被实现为各种合适电路中的任一者,诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑、软件、硬件、固件、或它们的任何组合。应当指出的是,尽管数据封装器500被示为具有不同的功能块,但此类图示是出于描述的目的,并且不会将数据封装器500限制到特定的硬件构架。可以使用硬件、固件和/或软件具体实施的任意组合来实现数据封装器500的功能。

  此外,媒体呈现描述生成器502可被配置为生成媒体呈现描述片段。分段生成器504可被配置为接收媒体部件并生成用于包括在媒体呈现中的一个或多个分段。系统存储器506可以被描述为非暂态或有形计算机可读存储介质。在一些示例中,系统存储器506可提供临时和/或长期存储。在一些示例中,系统存储器506或其部分可以被描述为非易失性存储器,并且在其他示例中,系统存储器506的部分可以被描述为易失性存储器。系统存储器506可被配置为存储可在操作期间由数据封装器使用的信息。

  如上所述,Hannuksela提出的子图片区域盒可能不太理想。在一个示例中,根据本文所述的技术,数据封装器107可以被配置为基于以下定义、语法和语义来发送信号通知子图片区域盒:

  定义

  track_group_type等于“spco”的TrackGroupTypeBox指示该轨道属于可以在空间上被布置用于获得组合图片的轨道的组合。映射到该分组的视觉轨道(即,在track_group_type等于“spco”的TrackGroupTypeBox内具有相同的track_group_id值的视觉轨道)共同表示可呈现的视觉内容。

  track_group_type等于“spco”的TrackGroupTypeBox内的track_group_id解释如下:

  如果track_group_id值的两个最低有效位是“10”,则指示具有该track_group_id值且track_group_type等于“spco”的每个子图片轨道仅包含左视图的内容。

  如果track_group_id值的两个最低有效位是“01”,则指示具有该track_group_id值且track_group_type等于“spco”的每个子图片轨道仅包含右视图的内容。

  如果track_group_id值的两个最低有效位是“11”,则指示具有该track_group_id值且track_group_type等于“spco”的每个子图片轨道包含左视图和右视图的内容。

  如果track_group_id值的两个最低有效位是“00”,则指示未发送信号通知关于具有该track_group_id值且track_group_type等于“spco”的子图片轨道是包含左视图还是右视图的内容的信息。在另选的示例中,保留两个最低有效位等于“00”的group_id值。

  在另选的示例中:

  如果track_group_id值的两个最低有效位是“11”,则指示具有该track_group_id值且track_group_type等于“spco”的子图片轨道包含左视图和右视图的内容。

  应当指出的是,在其他示例中,代替上文两个最低有效位,最高有效位可用于指示。在其他示例中,track_group_id中的任何两位可用于指示。在又一个示例中,可以在具有track_group_type等于“spco”的TrackGroupTypeBox中发送信号通知至少两个位宽的新位字段,并且可以将其用于指示以上左视图/右视图/两个视图的指示。

  在另一个变体示例中,track_group_id值空间可以如下划分以用于将来的可扩展性。

  该标准的该版本的track_group_id值应在0至65535的范围内。

  保留大于65535的track_group_id值。

  在另一个示例中,代替值65535,一些其他值可用于将track_group_id的值的空间划分为保留下来的值和该标准的该版本所用的值。

  在没有其他视觉轨道的情况下可能或可能不旨在单独地呈现映射到该分组的每个单独的视觉轨道,而适合呈现组合图片。

  注释1:内容作者可以使用TrackHeaderBox的track_not_intended_for_presentation_alone标记来指示在没有其他视觉轨道的情况下不旨在单独地呈现单独的视觉轨道。

  注释2:当图块轨道集和相关联的图块基础轨道中获得有HEVC视频比特流并且该比特流表示由子图片组合轨道组指示的子图片时,仅图块基础轨道包含SubPictureCompositionBox。

  如根据下文的语义所指定的,通过在空间上布置属于相同子图片组合轨道组和属于相同另选组的所有轨道的组合对准的样本的解码输出来导出组合图片。

  语法

  

  

  在另一示例中,用于track_x、track_y、track_width、track_height、composition_width、composition_height的以上位字段宽度中的一个或多个位字段宽度可以是16位而不是32位。

  语义

  track_x指定以亮度样本为单位的该轨道的样本的左上角在组合图片上的水平位置。track_x的值应在0到composition_width-1(包括端值)的范围内。

  track_y指定以亮度样本为单位的该轨道的样本的左上角在组合图片上的垂直位置。track_y的值应在0到composition_height-1(包括端值)的范围内。

  track_width指定以亮度样本为单位的该轨道的样本在组合图片上的宽度。track_width的值应在1到composition_width(包括端值)的范围内。

  track_height指定以亮度样本为单位的该轨道的样本在组合图片上的高度。track_height的值应在1到composition_height-track_y(包括端值)的范围内。在另一个示例中,track_height的值应在1到composition_height(包括端值)的范围内。

  composition_width指定以亮度样本为单位的组合图片的宽度。当不存在时,推断composition_width等于SubPictureCompositionBox中发送信号通知的composition_width语法元素,SubPictureCompositionBox的track_group_id值与该TrackGroupTypeBo相同,并且track_group_type等于“spco”。composition_width的值应大于或等于1。

  composition_height指定以亮度样本为单位的组合图片的高度。当不存在时,推断composition_height等于SubPictureCompositionBox中发送信号通知的composition_height语法元素,SubPictureCompositionBox的track_group_id值与该TrackGroupTypeBox相同,并且track_group_type等于“spco”。composition_height的值应大于或等于1。

  对于属于相同子图片组合轨道组的所有轨道,对于仅一个SubPictureCompositionBox,标记的最低有效位的值应等于1。因此,composition_width和composition_height元素应仅在一个SubPictureCompositionBox中发送信号通知。

  在另一个示例中:

  对于属于相同子图片组合轨道组的所有轨道,对于至少一个SubPictureCompositionBox,标记的最低有效位的值应等于1。

  因此,composition_width和composition_height元素应至少在一个SubPictureCompositionBox中发送信号通知。

  在变体示例中,代替对composition_width和composition_height大于0的约束,可以使用具有语义的减1编码来对这些语法元素进行编码,如下所示。

  composition_width_minus1加1指定以亮度样本为单位的组合图片的宽度。

  composition_height_minus1加1指定以亮度样本为单位的组合图片的高度。

  在变体示例中,代替标记的最低有效位值,可以使用标记中的其他位来调节composition_width和composition_height的信令。例如,在下文的语法中,标记的最高有效位用于此目的。

  

  

  在另一个示例中,用于track_x、track_y、track_width、track_height、composition_width、composition_height的以上一个或多个位字段宽度可以是32位而不是16位。

  由track_x、track_y、track_width和track_height表示的矩形被称为该轨道的子图片矩形。

  对于属于相同子图片组合轨道组和属于相同另选组(即,具有相同的非零alternate_group值)的所有轨道,子图片矩形的位置和尺寸应分别相同。

  子图片组合轨道组的组合图片如下导出:

  1)在属于子图片组合轨道组的所有轨道中,从每个另选组中选取一个轨道。

  2)对于每个所选取的轨道,应用以下项:

  a.对于在0至track_width-1(包括端值)的范围内的i的每个值以及对于在0至track_height-1(包括端值)的范围内的j的每个值,将在亮度样本位置((i+track_x)%composition_width,(j+track_y))处的组合图片的亮度样本设置为等于在亮度样本位置(i,j)处的该轨道的子图片的亮度样本。

  b.当解码的图片具有除4:0:0的色度格式时,相应地导出色度分量。

  属于相同子图片组合轨道组和属于不同另选组(即,具有alternate_group等于0或是不同的alternate_group值)的所有轨道的子图片矩形不应重叠且不应有间隔,使得在组合图片的上述推导过程中,每个亮度样本位置(x,y)恰好遍历一次,其中x在0至composition_width-1(包括端值)的范围内,并且y在0至composition_height-1(包括端值)的范围内。

  在一个示例中,子图片区域盒可基于语法:

  语法

  

  在其他示例中,用于track_x、track_y、track_width、track_height、composition_width、composition_height的以上一个或多个位字段宽度可以是16位而不是32位。

  其中track_x、track_y、track_width、track_height、composition_width和composition_height的语义可以基于上文提供的示例,并且composition_params_present_flag的语义基于以下项:

  composition_params_present_flag等于1指定该框中存在语法元素composition_width和composition_height。composition_params_present_flag等于0指定该框中不存在语法元素composition_width和composition_height。

  应当指出的是,相对于Hannuksela,在根据本文所述的技术的子图片区域盒中,SubPictureRegionBox中用于子图片组合轨道分组的语法元素的位宽从16位增加到了32位,放宽了对SubPictureRegionBox中用于子图片组合轨道分组的轨道宽度和轨道高度的语法元素的约束以允许更多的值,提出了对SubPictureRegionBox中用于子图片组合轨道分组的组合宽度和组合高度的语法元素的新约束,并且修改了对轨道高度的约束,并且修改了子图片组合轨道组的组合图片的推导。应当指出的是,由于在MPEG-I中不支持上下接缝扩展,所以这些修改提供了与MPEG-I的整体功能对准。

  此外,相对于Hannuksela,在根据本文所述的技术的子图片区域盒中,当由具有track_group_type“spco”和相同的track_group_id值的TrackGroupTypeBox指示子图片组合轨道分组时,提议划分track_group_id值的空间以指示属于组合的子图片轨道是否仅包括左视图、仅包括右视图或包括左视图和右视图两者的内容。track_group_id值空间的此类划分可以允许播放器避免解析SubPictureRegionBox和RegionWisePackingBox来确定关于子图片轨道和所得组合属于哪个视图的信息。相反,播放器可以仅解析track_group_id值以了解该信息。在其他示例中,track_group_id值范围的空间被划分为支持将来的可扩展性。

  此外,相对于Hannuksela,在根据本文所述的技术的子图片区域盒中,在具有相同track_group_id值的SubPictureCompositionBox的仅一个实例或至少一个实例中用于发送信号通知composition_width和composition_height语法元素的语法修改和标记提供了位的节省。

  建议使用新XML名称空间来定义包括用于OMAF版本2/OMAF修改的新DASH元素和属性的新XML架构。据断言,这提供了干净的向后兼容的设计。这可如下指定:

  x.y XML名称空间和架构

  定义并使用了许多新的XML元素和属性。在单独的名称空间“urn:mpeg:mpegI:omaf:2018”中定义这些新的XML元素。在每个部分的规范模式文档中定义这些元素。名称空间标志符“xs:”应当与“XML Schema Part 1:Structures Second Edition(XML架构部分1:结构第二版)”(W3C建议书,2004年10月28日,“https://www.w3.org/TR/xmlschema-1/”)中定义的名称空间http://www.w3.org/2001/XMLSchema对应。本文档中的表的“数据类型”列中的项目使用XML架构部分2中定义的数据类型,并且应具有“XML Schema Part 2:Datatypes Second Edition(XML架构部分2:数据类型第二版)”(W3C建议书,2004年10月28日,“https://www.w3.org/TR/xmlschema-2/”)中定义的含义。

  如上所述,在适应集级别处使用Hannuksela中提供的@spatialSetId属性对属于相同子图片组合轨道组的适应集进行分组具有以下限制:每个适应集仅可以属于单个子图片组合分组。在一个示例中,根据本文所述的技术,数据封装器107可被配置为发送信号通知子图片组合标识符元素。在一个示例中,子图片组合标识符元素可以基于表2中提供的示例。

  

  表2

  在一个示例中,可以将SubPicCompId发送信号通知为适应集元素的子元素。在一个示例中,可以将SubPicCompId发送信号通知为适应集元素和/或表示元素的子元素。在一个示例中,在适应集元素中可以存在多个SubPicCompId元素,以允许适应集属于多个不同的子图片组合。在一个示例中,当适应集元素中存在多个SubPicCompId元素时,每个SubPicCompId元素必须具有不同的值。在一个示例中,当不存在时,推断SubPicCompId等于0。在另一个示例中,当不存在时,适应集不是子图片,并且可以不属于(或不属于)子图片组合。这种情况下,可选择适应集用于单独呈现。SubPicCompId的数据类型可以如XML架构中所定义。图10示出了对应于表2所示示例性SubPicCompId的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。在一个示例中,图10的架构中的subPicCompPid元素可以替代地为如下:

  <xs:element name="SubPicCompId"type="xs:unsignedShort"minOccurs="0"maxOccurs="unbounded"/>

  在一个示例中,SubPicCompId元素可以替代地被称为SpatialSetId元素,如表2A所示。

  

  表2A

  在适应集元素中可存在多个SpatialSetId元素,以允许适应集属于多个不同的子图片组合。当适应集元素中存在多个SpatialSetId元素时,每个SpatialSetId元素必须具有不同的值。元素的数据类型应如XML架构中所定义。该元素的XML架构应如下所示。标准架构应以XML架构表示,XML架构具有名称空间urn:mpeg:mpegI:omaf:2018,并且指定如下:

  

  在一个示例中,SubPicCompId元素或SpatialSetId元素的数据类型可以是xs:unsignedInt或xs:unsignedByte或xs:unsignedLong或xs:string,而不是xs:unsignedShort的数据类型。

  在一个示例中,根据本文所述的技术,数据封装器107可以被配置为发送信号通知经修改的子图片组合标识符属性@SubPicCompId,其中@SubPicCompId从以十进制表示的非负整型修改为unsignedShort列表。应当指出的是,使用列表允许将多个空间集标识符与适应集相关联。在一个示例中,子图片组合标识符属性可以基于表3中提供的示例。

  

  表3

  在一个示例中,可以将@subPicCompId发送信号通知为适应集元素的属性。在一个示例中,可以将@subPicCompId元素发送信号通知为适应集元素和/或表示元素的属性。在另一个示例中,当属性omaf2:@subPicCompId不存在时,适应集不是子图片,并且可以不属于(或不属于)子图片组合。这种情况下,可选择适应集用于单独呈现。@subPicCompId的数据类型可以如XML架构所定义。图11示出了对应于表3所示示例性@subPicCompId的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。

  在一个示例中,@subPicCompId属性可以替代地被称为@spatialSetId元素,如表3A所示。

  

  

  表3A

  在一个示例中,@subPicCompId属性或@spatialSetId属性的数据类型可以是xs:unsignedInt的列表或xs:unsignedByte的列表或xs:unsignedLong的列表或xs:string的列表,而不是xs:unsignedShort的数据类型。

  在一个示例中,@spatialSetId属性可具有如表3B所示的unsignedShort的数据类型。

  

  表3B

  在这种情况下,@spatialId属性的XML架构可以如下:

  

  在关于上表3B的另一个示例中,omaf2:@spatialSetId的数据类型可以是unsignedByte或unsignedInt或unsignedLong或string,而不是unsignedShort。

  在一个示例中,根据本文所述的技术,数据封装器107可被配置为发送信号通知属性以指示属于子图片组合的特定适应集并非旨在被单独选择用于呈现给最终用户。在ISOBMFF文件中,可以将轨道指定为不单独呈现。此外,在DASH中,可以由DASH客户端独立地选择适应集。然而,在多个适应集形成子图片组合的情况下,应防止独立选择适应集。在一个示例中,根据本文所述的技术,数据封装器107可被配置为发送信号通知属性以指示属于子图片组合的特定适应集并非旨在被单独选择用于呈现给最终用户。在一个示例中,属性可以是在适应集层级处作为适应集元素的属性的可选属性。在一个示例中,属性可以基于表4中提供的示例。

  

  表4

  在一个示例中,属性@notIntendedForSelectionAlone可以替代地被称为@noSingleSelection或@notForSingleSelection或一些其他类似名称。图12示出了对应于表4所示示例性@SubPicCompId的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。

  在一个示例中,根据本文所述的技术,数据封装器107可被配置为发送信号通知属性以指示属于子图片组合的特定适应集并非旨在被单独选择用于呈现给最终用户,其中属性是上文关于表2所述的SubPicCompId元素的属性。在一个示例中,属性可以是在适应集层级处作为SubPicCompId元素的属性的可选属性。在一个示例中,属性可以基于表5中提供的示例。

  

  表5

  图13示出了对应于表5所示示例性@notIntendedForSelectionAlone的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。在关于图13和表5的一个示例中,所有发生的SubPicCompId可以被替换为SpatialSetId。因此,omaf2:@notIntendedForSelectionAlone属性可以被发送信号通知为上文关于表2A所述的SpatialSetId元素的属性。

  在一个示例中,代替使用仅可指定关于选择和呈现适应的两个可能值的omaf2:@notIntendedForSelectionAlone的布尔数据类型,可使用可指定关于单个选择的三个值的数据类型。在一个示例中,这三个值可分别指定:(1)不旨在单独选择和呈现适应集;(2)适应集不具有关于其被单独选择和呈现的任何限制;以及(3)可以或可不单独选择和呈现适应集。在一个示例中,在这种情况下,属性omaf2:@notIntendedForSelectionAlone可以基于表6中提供的示例。

  

  

  表6

  图14示出了对应于表6所示示例性@notIntendedForSelectionAlone的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。

  在一个示例中,在这种情况下,属性omaf2:@notIntendedForSelectionAlone可以基于表7中提供的示例,omaf2:@notIntendedForSelectionAlone可以作为SubPicCompId元素的属性存在于适应集层级处。

  

  表7

  图15示出了对应于表7所示示例性@notIntendedForSelectionAlone的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。在关于图15和表7的一个示例中,所有发生的SubPicCompId可以被替换为SpatialSetId。因此,omaf2:@notIntendedForSelectionAlone属性可以被发送信号通知为上文关于表2A所述的SpatialSetId元素的属性。

  关于以上示例,在一些情况下,SubPicCompId可以替代地被称为OmniVideoSequenceId或OdsrId或类似名称。在一个示例中,可以将数据类型unsignedByte而不是unsignedShort用于SubPicCompId元素。在一个示例中,可以将数据类型unsignedInt而不是unsignedShort用于SubPicCompId元素。在一个示例中,可以将unsignedByte的列表而不是unsignedShort的列表用于@subPicCompId属性。在一个示例中,可以将unsignedInt的列表而不是unsignedShort的列表用于@subPicCompId属性。

  现在描述子图片组合的DASH信令的另一个方面。该方面涉及封装在DASH中的定时元数据与DASH中的媒体信息的关联。关于这一点,在现有技术中,定时元数据轨道可以封装在DASH表示中,并且该表示的@associationId应当包含表示的@id属性,该属性包含与定时元数据轨道相关联的媒体轨道。然而,这种关联方式可能不足以与子图片组合关联。

  因此,提出了一种用于将定时元数据封装的DASH表示与对应于子图片组合的多个适应集相关联的技术。针对这一点描述了两个另选的选项。

  在选项1中:建议以适应集和/或表示级别发送信号通知新的@referenceIds属性,以将一个或多个子图片组合与定时元数据DASH表示相关联。

  在选项2中:建议在@associationId中发送信号通知多个representation@id值,以指示封装在DASH表示中的定时元数据与子图片组合的关联。

  当对子图片进行编码并在周期内将子图片发送信号通知为多个适应集时,需要有效的机制来将定时元数据封装的DASH表示与集合子图片组合而不是与单个子图片相关联。除此之外,在这种情况下,子图片的适应集通常可包括多个表示,并且此类多个适应集对应于总体子图片组合。因此,建议以适应集和/或表示级别发送信号通知新的@referenceIds属性,以将一个或多个子图片组合与定时元数据DASH表示相关联。

  另外,建议允许发送信号通知封装在DASH表示中的单个定时元数据轨道与多个媒体轨道之间的关联。据断言,多个媒体表示可与同一定时元数据轨道相关联,并且因此应允许将多个representation@id值与一个定时元数据轨道相关联,因为它更有效。例如,对于具有以不同比特率编码的多个DASH表示的全向视频,初始观看取向定时元数据可以是相同的。类似推荐,应允许封装在DASH表示中的视口时间元数据与以不同比特率编码的多个DASH表示相关联。因此,建议允许发送信号通知封装在DASH表示中的单个定时元数据轨道与多个媒体轨道之间的关联。

  下面描述选项1:

  建议以适应集和/或表示级别发送信号通知新的@referenceIds属性,以将一个或多个子图片组合与定时元数据DASH表示相关联。

  @referenceIds的值应为值列表,其中列表中的每个值等于该定时元数据轨道共同关联的适应集的@spatialSetId的值。

  在变体中,@referenceIds的值应当是该定时元数据轨道共同关联的子图片组合的适应集元素内的SubPicCompId的值列表。

  在变体中,referenceIds的值应当是包括来自该定时元数据轨道共同关联的子图片组合的适应集元素内的@SubPicCompId的值的值列表。

  在变体中,@referenceIds可被称为@associationAdaptationSetIds。

  可将参考标识符属性-@referenceIds发送信号通知为Representation和/或AdaptationSet元素的属性。这可如表8A所示发送信号通知。

  

  表8A

  属性的数据类型应如XML架构中所定义。该属性的XML架构应如下所示。标准架构应以XML架构表示,XML架构具有名称空间urn:mpeg:mpegI:omaf:2018,并且指定如下:

  

  在变体示例中,其他数据类型而不是数据类型listOfUnsignedShort可以用于omaf 2:@referenceId属性。这包括以下:

  ·可以将作为如下xs:unsignedByte的xs:list的数据类型listofUnsignedByte用于omaf2:@referenceId

  

  ·可以将作为如下xs:unsignedlnt的xs:list的数据类型listofUnsignedlnt用于omaf2:@referenceId

  

  ·可以将作为如下xs:string的xs:list的数据类型listofString用于omaf2:@referenceId

  

  在变体示例中,@referenceIds可被称为@referenceSpatialIds。在变体示例中,@referenceIds可被称为@associationSpatialIds或@associationAdaptationSetIds或@associationSpCompIds。

  在变体实例中,omaf2:@referenceIds的数据类型可以是单个数字或字符串而不是列表。因此,omaf2:@referenceIds的数据类型可以是unsignedShort或unsignedByte或unsignedInt或字符串。

  在变体示例中,可将ReferenceIds元素(而不是@referenceIds属性)发送信号通知为AdaptationSet元素和/或Representation元素的子元素。

  在变体示例中,可将附加的@referenceIdType属性发送信号通知为表9A中所示的Representation和/或AdaptationSet元素的属性。

  

  表9A

  属性的数据类型应如XML架构中所定义。该属性的XML架构应如下所示。标准架构应以XML架构表示,XML架构具有名称空间urn:mpeg:mpegI:omaf:2018,并且指定如下:

  

  下文描述了选项2。

  在选项2中:建议在@associationId中发送信号通知多个Representation@id值,以指示封装在DASH表示中的定时元数据与子图片组合的关联。

  本发明的文本如下:

  当例如轨道样本条目类型“invo”或“rcvp”或“ttsl”的定时元数据轨道封装在DASH表示中并且共同与子图片组合和/或全向视频相关联时,@associationId属性应包括一起形成子图片组合和/或全向视频的所有适应集中的所有表示的Representation@id列表,并且对应@associationType属性值应包括与@associationId列表中的Representation@id值相同数量的“cdtg”值。

  在这种情况下,包括@associationId列表的定时元数据轨道应共同应用于指示列表中等于“cdtg”的对应@associationType值的所有这些表示。

  另外,关于ISO/IEC FDIS 23090-2,据断言,多个媒体表示可与同一定时元数据轨道相关联,并且因此应允许将多个Representation@id值与一个定时元数据轨道相关联,因为它更有效。

  例如,对于具有以不同比特率编码的多个DASH表示的全向视频,初始观看取向定时元数据可以是相同的。类似推荐,应允许封装在DASH表示中的视口时间元数据与以不同比特率编码的多个DASH表示相关联。因此,建议允许发送信号通知封装在DASH表示中的单个定时元数据轨道与多个媒体轨道之间的关联。

  因此,提出了使用以下类型的关联:

  该元数据表示的@associationId属性应包含表示的属性Representation@id的一个或多个值,这些表示包含由与定时元数据轨道相关联的媒体轨道携带的全向媒体,如ISO/IEC FDIS 23090-2的条款7.1.5.1中所述。该元数据表示的@associationType属性应包含等于轨道参考类型的一个或多个值,定时元数据轨道通过该轨道参考类型与媒体轨道相关联,如ISO/IEC FDIS 23090-2的条款7.1.5.1所述。

  如上所述,在DASH中,相关联的表示是为至少一个其他表示提供补充或描述信息的表示,并且由包含@associationId属性和任选地包含@associationType属性的表示元素的属性来描述相关联的表示。MPEG-I提供了可封装在DASH表示中的定时元数据轨道,其中元数据表示的@associationId属性应包含表示的@id属性的一个或多个值,这些表示包含由通过“cdsc”轨道参考与定时元数据轨道相关联的媒体轨道携带的全向媒体,并且其中元数据表示的@associationType属性应等于“cdsc”。

  如上所述,在MPEG-I中,可对轨道分组。关于可分组的参考轨道(例如,定时元数据轨道),MPEG-I为track_IDs提供了以下语义:

  track_IDs是提供参考轨道的轨道标识符或参考轨道组的track_group_id值的整数阵列。track_IDs[i]的每个值是整数,其提供从包含的轨道到track_ID等于track_IDs[i]的轨道,或者到同时具有track_group_id等于track_IDs[i]且TrackGroupTypeBox(标志&1)等于1的轨道组的参考,其中i是对track_IDs[]阵列的有效索引。除非在特定轨道参考类型的语义中另有说明,否则当参考track_group_id值时,轨道参考单独应用于参考轨道组的每个轨道。值0应不存在。在阵列中给定值不应重复。

  Wang等人,ISO/IEC JTC1/SC29/WG11 MPEG2018/M42460-v2“[OMAF][DASH][FF]Efficient DASH and file format objects association”(美国,圣地亚哥,2018年4月,其以引用方式并入并且在本文中称为“Wang”)提议定义名为@associationIdType的任选的新表示层级属性,以指示ID被包括在@associationId中的DASH对象的类型,其中等于0、1、2或3的@associationIdType的值分别指示@associationId中的每个值为表示、适应集、视点或预选的ID,并且其中保留大于3的@associationIdType的值,并且当不存在时,推断@associationIdType的值等于0。具体地讲,Wang提出了对DASH进行以下文本更改:

  由包含@associationId属性、任选地包含@associationIdType属性和任选地包含@associationType属性的表示元素来描述相关联的表示。相关联的表示是提供关于其与其他表示、适应集、视点或预选的关系的信息的表示。相关联的表示的区段可以是可选的,用于解码和/或呈现由@associationId和@associationIdType识别的表示、适应集、视点或预选。它们可被认为是补充或描述信息,由@associationType属性指定的关联类型。

  注释-@associationId、@associationIdType等于0,并且@associationType只能在不同适应集中的表示之间使用。

  @associationId、@associationIdType和@associationType属性[在表8中]定义如下:

  

  表8

  Wang还提出了对MPEG-I进行以下文本更改:

  例如样本条目类型“invo”或“rcvp”的定时元数据轨道可以封装在DASH表示中。

  当该元数据表示的@associationIdType的值等于0、1、2或3时,该元数据表示的@associationId属性应分别包含表示、适应集、视点或预选的ID值,其包含由与定时元数据轨道相关联的媒体轨道携带的全向媒体。该元数据表示的@associationType属性应等于“cdsc”。

  应当指出的是,Wang中提出的方案不与先前DASH客户端向后兼容,因为当新提出的@associationIdType属性为1、2或3时,先前DASH客户端将无法理解@associationId中的值,先前DASH客户端在@associationId中仅期望Representation@id值,现在却发现未知的@id值。

  在一个示例中,根据本文所述的技术,数据封装器107可被配置为发送信号通知补充属性描述符,该补充属性描述符包括具有两个强制属性(association@associationElementIdList、association@associationKindList)和一个任选属性(association@associationElementType)的一个或多个关联元素。当不存在时,推断任选属性(association@associationElementType)的值。在一个示例中,数据封装器107可被配置为基于以下示例性描述发送信号通知补充属性描述符。应当指出的是,关于以下描述,在一个示例中,一次或多次出现的字词“父元素”可与字词“该元素描述符的父元素”互换,或反之亦然。在一个示例中,一次或多次出现的字词“该关联元素”可与字词“该属性的关联元素”互换,或反之亦然。

  @schemeIdUri属性等于"urn:mpeg:mpegI:omaf:assoc:2018"的SupplementalProperty元素被称为关联描述符。

  一个或多个关联描述符可存在于适应集层级、表示层级、预选层级、子表示层级。

  在一个示例中,包括具有值0的属性omaf2:@associationElementType的关联描述符不应存在于表示层级。

  包括在适应集/表示/预选/子表示元素内的关联描述符中的关联元素指示父元素(即,适应集/表示/预选/子表示元素)与如omaf2:@associationElementType属性指示的一个或多个适应集和/或表示和/或预选和/或子表示元素相关联,并且其通过由omaf2:@associationElementIdList发送信号通知的值列表来识别,并且关联类型由omaf2:@associationKindList发送信号通知。

  关联描述符的@value属性应不存在。关联描述符应包括具有如表9中指定的属性的一个或多个关联元素:

  

  

  表9

  图16示出了对应于表9所示的示例性关联描述符的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。

  在一个示例中,图16中的架构可以如下改变:

  <xs:attribute name="associationElementType"type="omaf2:AssociationElemType"use-"optional"default="0"/>

  可替换为

  <xs:attribute name="associationElementType"type="xs:unsignedByte"use="optional"default="0"/>

  在一个示例中,数据封装器107可被配置为基于以下示例描述发送信号通知补充属性描述符,其中在关联元素中发送信号通知ID列表,而不是使用属性association@associationElementIdList。应当指出的是,关于以下描述,在一个示例中,一次或多次出现的字词“父元素”可与字词“该元素描述符的父元素”互换,或反之亦然。在一个示例中,一次或多次出现的字词“该关联元素”可与字词“该属性的关联元素”互换,或反之亦然。

  @schemeIdUri属性等于"urn:mpeg:mpegI:omaf:assoc:2018"的SupplementalProperty元素被称为关联描述符。

  一个或多个关联描述符可存在于适应集层级、表示层级、预选层级、子表示层级。

  在一个示例中,包括具有值0的属性omaf2:@associationElementType的关联描述符不应存在于表示层级。

  包括在适应集/表示/预选/子表示元素内的关联描述符指示该元素的描述符的父元素(即,适应集/表示/预选/子表示元素)与如omaf2:@associationElementType属性指示的一个或多个适应集和/或表示和/或预选和/或子表示元素相关联,并且其通过由omaf2:@associationElementIdList发送信号通知的值列表标识,并且其通过关联元素中的值列表标识。关联类型由omaf2:@associationKindList发送信号通知。

  关联描述符的@value属性应不存在。关联描述符应包括具有如表10中指定的属性的一个或多个关联元素:

  

  

  表10

  图17A示出了对应于表10所示的示例性关联描述符的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。图17B示出了对应于表10所示的示例性关联描述符的标准XML架构的另一个示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。在图17B中,数据类型xs:unsignedByte用于associationElementType。

  在一个示例中,数据封装器107可被配置为基于以下示例性描述发送信号通知补充属性描述符,其中发送信号通知XPath字符串以指定元素与同一周期中的一个或多个其他元素/属性的关联。该示例允许将来的延展性和特异性。它还重复使用现有的XPath语法。在W3C中定义XPath:“XML路径语言(XPath)”(W3C建议书,2010年12月14日),其以引用方式并入本文。应当指出的是,尽管上述参考文献使用XPath 2.0,但也可使用其他版本的XPath,例如XPAth 1.0或XPath 3.0或一些未来版本的XPath。应当指出的是,关于以下描述,在一个示例中,一次或多次出现的字词“父元素”可以与字词“该元素的描述符的父元素”互换,或者反之亦然。在一个示例中,一次或多次出现的字词“该关联元素”可以与字词“该属性的关联元素”互换,或反之亦然。

  @schemeIdUri属性等于"urn:mpeg:mpegI:omaf:assoc:2018"的SupplementalProperty元素被称为关联描述符。

  一个或多个关联描述符可存在于适应集层级、表示层级、预选层级、子表示层级。

  包括在适应集/表示/预选/子表示元素内的关联描述符指示父元素(即,适应集/表示/预选/子表示元素)与MPD中的由omaf2:association元素中的XPath查询指示的一个或多个元素相关联,并且关联类型由omaf2:@associationKindList发送信号通知。

  关联描述符的@value属性应不存在。关联描述符应包括具有如表11中指定的属性的一个或多个关联元素:

  

  

  表11

  图18示出了对应于表11所示的示例性关联描述符的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。

  在一个示例中,当元素A经由发送信号通知的关联类型/种类与元素B相关联时,则元素B也通过发送信号通知的相同关联类型/种类与元素A相关联。在一个示例中,关联可以是双向的。因此,如果具有关联元素的关联描述符被包括在元素C中并且将元素C与元素D和元素E相关联,则元素C与元素D和元素E通过发送信号通知的关联类型/种类相关联,但是元素D和元素E可能不以相同的方式与元素C相关联。

  在另一个示例中,可以为关联描述符发送信号通知附加属性以指示关联是单向还是双向的。例如,可以如下表12中发送信号通知关联是单向还是双向的:

  

  表12

  图18示出了对应于表12所示的示例性关联描述符的标准XML架构的示例,其中标准架构具有名称空间urn:mpeg:mpegI:omaf:2018。

  应当指出的是,当关联适应集、表示和/或预选集时,本文所述的示例性关联描述符允许更简洁的信令。例如,通过发送信号通知“//AdaptationSet”的关联,不再需要发送信号通知associationIds中的全部(例如,1024、1025、1026、1027)。此外,通过发送信号通知“//AdaptationSet//Representation”的关联,处理量减少。

  这样,数据封装器107表示被配置为根据本文所述的技术中的一种或多种发送信号通知与虚拟现实应用程序相关联的信息的设备的示例。

  再次参考图1,接口108可以包括被配置为接收由数据封装器107生成的数据并且将数据传输和/或存储到通信介质的任何设备。接口108可以包括网络接口卡诸如以太网卡,并且可以包括光收发器、射频收发器或者可以传输和/或接收信息的任何其他类型的设备。此外,接口108可以包括计算机系统接口,该计算机系统接口可以使文件能够存储在存储设备上。例如,接口108可以包括支持外围部件互连(PCI)和高速外围部件互连(PCIe)总线协议、专用总线协议、通用串行总线(USB)协议、I2C的芯片组、或可用于互连对等设备的任何其他逻辑和物理结构。

  再次参考图1,目标设备120包括接口122、数据解封装器123、视频解码器124和显示器126。接口122可以包括被配置为从通信介质接收数据的任何设备。接口122可以包括网络接口卡诸如以太网卡,并且可以包括光收发器、射频收发器或者可接收和/或发送信息的任何其他类型的设备。此外,接口122可以包括允许从存储设备检索兼容视频比特流的计算机系统接口。例如,接口122可以包括支持PCI和PCIe总线协议、专用总线协议、USB协议、I2C的芯片组,或者可用于互连对等设备的任何其他逻辑和物理结构。数据解封装器123可被配置为根据本文所述的一种或多种技术接收由数据封装器107生成的比特流并且执行子比特流提取。

  视频解码器124可以包括被配置为接收比特流和/或其能够接受的变体,并且从其再现视频数据的任何设备。显示器126可以包括被配置为显示视频数据的任何设备。显示器126可以包括各种显示设备诸如液晶显示器(LCD)、等离子显示器、有机发光二极管(OLED)显示器或另外的类型的显示器中的一种。显示器126可以包括高清显示器或超高清显示器。显示器126可以包括立体显示器。应当指出的是,虽然在图1所示的示例中,视频解码器124被描述为将数据输出到显示器126,但视频解码器124可被配置为将视频数据输出到各种类型的设备和/或其子部件。例如,视频解码器124可被配置为将视频数据输出到任何通信介质,如本文所述。目标设备120可以包括接收设备。

  图9是示出可实现本公开的一种或多种技术的接收器设备的示例的框图。也就是说,接收器设备600可被配置为基于上述语义来解析信号。接收器设备600是计算设备的示例,其可被配置为从通信网络接收数据并允许用户访问多媒体内容(包括虚拟现实应用程序)。在图9所示的示例中,接收器设备600被配置为经由电视网络(诸如例如,上述电视服务网络404)接收数据。此外,在图9所示的示例中,接收器设备600被配置为经由广域网发送和接收数据。应当指出的是,在其他示例中,接收器设备600可被配置为通过电视服务网络404简单地接收数据。本文所述的技术可以由被配置为使用通信网络的任意组合和全部组合进行通信的设备利用。

  如图9中所示,接收器设备600包括中央处理单元602、系统存储器604、系统接口610、数据提取器612、音频解码器614、音频输出系统616、视频解码器618、显示系统620、I/O设备622和网络接口624。如图9所示,系统存储器604包括操作系统606和应用程序608。中央处理单元602、系统存储器604、系统接口610、数据提取器612、音频解码器614、音频输出系统616、视频解码器618、显示系统620、I/O设备622和网络接口624中的每一者可以互连(物理地、通信地和/或可操作地)用于部件间的通信,并且可以实现为各种合适的电路中的任一种,诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑、软件、硬件、固件或其任何组合。应当指出的是,尽管接收器设备600被示出为具有不同的功能块,但是此类图示是出于描述的目的,并且不会将接收器设备600限制到特定的硬件构架。可以使用硬件、固件和/或软件具体实施的任意组合来实现接收器设备600的功能。

  CPU 602可被配置为实现用于在接收器设备600中执行的功能和/或处理指令。CPU602可以包括单核和/或多核中央处理单元。CPU 602能够检索和处理用于实现本文所述的技术中的一种或多种的指令、代码和/或数据结构。指令可以存储在计算机可读介质诸如系统存储器604上。

  系统存储器604可以被描述为非暂态或有形计算机可读存储介质。在一些示例中,系统存储器604可以提供临时和/或长期存储。在一些示例中,系统存储器604或其部分可以被描述为非易失性存储器,并且在其他示例中,系统存储器604的部分可以被描述为易失性存储器。系统存储器604可被配置为存储可在操作期间由接收器设备600使用的信息。系统存储器604可以用于存储程序指令以供CPU 602执行,并且可以由在接收器设备600上运行的程序使用以在程序执行期间临时存储信息。此外,在其中接收器设备600作为数字视频录像机的一部分被包括的示例中,系统存储器604可被配置为存储多个视频文件。

  应用程序608可以包括在接收器设备600内实现或由其执行的应用程序,并且可以被实现或包含在接收器设备600的部件内,可以由该接收器设备的部件操作、执行,并且/或者可操作地/通信地耦接到该接收器设备的部件。应用程序608可以包括可使接收器设备600的CPU 602执行特定功能的指令。应用程序608可以包括在计算机编程语句中表达的算法,诸如for循环、while循环、if语句、do循环等。可以使用指定的编程语言来开发应用程序608。编程语言的示例包括JavaTM、JiniTM、C、C++、Objective C、swift、Perl、Python、PhP、UNIX Shell、Visual Basic和Visual Basic Script。在其中接收器设备600包括智能电视的示例中,应用程序可以由电视制造商或广播公司开发。如图9所示,应用程序608可结合操作系统606执行。也就是说,操作系统606可被配置为促进应用程序608与CPU 602以及接收器设备600的其他硬件部件的交互。操作系统606可以是被设计为安装在机顶盒、数字视频录像机、电视等上的操作系统。应当指出的是,本文所述的技术可以由被配置为使用软件架构的任意组合和全部组合进行操作的设备利用。

  系统接口610可被配置为允许接收器设备600的部件之间的通信。在一个示例中,系统接口610包括使数据能够从一个对等设备传输到另一个对等设备或传输到存储介质的结构。例如,系统接口610可以包括支持基于加速图形端口(AGP)的协议、基于外围部件互连(PCI)总线的协议(诸如PCI ExpressTM(PCIe)总线规范)的芯片组,其由外围部件互连专门兴趣组或者可用于互连对等设备的任何其他形式的结构(例如,专用总线协议)维护。

  如上所述,接收器设备600被配置为经由电视服务网络接收并任选地发送数据。如上所述,电视服务网络可以根据电信标准操作。电信标准可定义通信属性(例如,协议层),诸如物理信令、寻址、信道访问控制、分组属性和数据处理。在图9所示的示例中,数据提取器612可被配置为从信号中提取视频、音频和数据。可以根据例如DVB标准、ATSC标准、ISDB标准、DTMB标准、DMB标准和DOCSIS标准等方面来定义信号。

  数据提取器612可被配置为从信号中提取视频、音频和数据。也就是说,数据提取器612可以与服务分发引擎互逆的方式操作。此外,数据提取器612可被配置为基于上述结构中的一者或多者的任意组合来解析链路层分组。

  数据分组可以由CPU 602、音频解码器614和视频解码器618来处理。音频解码器614可被配置为接收和处理音频包。例如,音频解码器614可以包括被配置为实现音频编解码器的各方面的硬件和软件的组合。也就是说,音频解码器614可被配置为接收音频包并将音频数据提供给音频输出系统616以进行渲染。音频数据可以使用多信道格式编码,诸如由杜比和数字影院系统开发的格式。可以使用音频压缩格式对音频数据进行编码。音频压缩格式的示例包括运动图像专家组(MPEG)格式、高级音频编码(AAC)格式、DTS-HD格式和杜比数字(AC-3)格式。音频输出系统616可被配置为渲染音频数据。例如,音频输出系统616可以包括音频处理器、数字-模拟转换器、放大器和扬声器系统。扬声器系统可以包括各种扬声器系统中的任一种,诸如耳机、集成立体声扬声器系统、多扬声器系统或环绕声系统。

  视频解码器618可被配置为接收和处理视频包。例如,视频解码器618可以包括用于实现视频编解码器的各方面的硬件和软件的组合。在一个示例中,视频解码器618可被配置为解码根据任何数量的视频压缩标准编码的视频数据,这些视频压缩标准诸如ITU-TH.262或ISO/IEC MPEG-2 Visual、ISO/IEC MPEG-4 Visual、ITU-T H.264(也被称为ISO/IEC MPEG-4高级视频编码(AVC))、以及高效视频编码(HEVC)。显示系统620可被配置为检索和处理视频数据以供显示。例如,显示系统620可以从视频解码器618接收像素数据并输出数据以用于视觉呈现。此外,显示系统620可被配置为结合视频数据(例如,图形用户界面)输出图形。显示系统620可以包括各种显示设备中的一者,诸如液晶显示器(LCD)、等离子显示器、有机发光二极管(OLED)显示器、或能够向用户呈现视频数据的其他类型的显示设备。显示设备可被配置为显示标准清晰度内容、高清晰度内容或超高清内容。

  I/O设备622可被配置为在接收器设备600的操作期间接收输入并提供输出。也就是说,I/O设备622可允许用户选择要渲染的多媒体内容。可以从输入设备处生成输入,这些输入设备诸如按钮式遥控器、包括触敏屏幕的设备、基于运动的输入设备、基于音频的输入设备或被配置为接收用户输入的任何其他类型的设备。I/O设备622可以利用标准化通信协议可操作地耦接到接收器设备600,该标准化通信协议诸如通用串行总线协议(USB)、蓝牙、ZigBee或专有通信协议(诸如,专有的红外通信协议)。

  网络接口624可被配置为允许接收器设备600经由局域网和/或广域网发送和接收数据。网络接口624可以包括网络接口卡,诸如以太网卡、光收发器、射频收发器或者被配置为发送和接收信息的任何其他类型的设备。网络接口624可被配置为根据网络中利用的物理和媒体访问控制(MAC)层执行物理信令、寻址和信道访问控制。接收器设备600可被配置为解析根据上文相对于图8所描述的任何技术生成的信号。这样,接收器设备600表示被配置为解析包括与虚拟现实应用程序相关联的信息的一个或多个语法元素的设备的示例。

  在一个或多个示例中,所述功能可以通过硬件、软件、固件或其任何组合来实现。如果以软件实现,则可将功能作为一个或多个指令或代码存储在计算机可读介质上或经由计算机可读介质上传输,并且由基于硬件的处理单元执行。计算机可读介质可以包括对应于有形介质诸如数据存储介质的计算机可读存储介质,或者包括例如根据通信协议促进计算机程序从一个地方传输到另一个地方的任何介质的传播介质。这样,计算机可读介质通常可对应于:(1)非暂态的有形计算机可读存储介质,或者(2)通信介质诸如信号或载波。数据存储介质可以是可以由一个或多个计算机或一个或多个处理器访问以检索用于实现本公开中所述的技术的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。

  以举例而非限制的方式,此类计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储设备、磁盘存储设备或其他磁存储设备、闪存存储器、或者可用于存储指令或数据结构形式的所需程序代码并且可由计算机访问的任何其他介质。而且,任何连接都被适当地称为计算机可读介质。例如,如果使用同轴电缆、光纤电缆、双绞线、数字用户线路(DSL)或无线技术诸如红外线、无线电和微波从网站、服务器或其他远程源传输指令,则同轴电缆、光纤电缆、双绞线、DSL或无线技术诸如红外线、无线电和微波都包含在介质的定义中。然而,应当理解,计算机可读存储介质和数据存储介质不包括连接、载波、信号或其他暂态介质,而是针对非暂态有形存储介质。如本文所用,磁盘和光盘包括压缩光盘(CD)、激光盘、光学光盘、数字通用光盘(DVD)、软磁盘及Blu-ray光盘,其中磁盘通常以磁性方式复制数据,而光盘则利用激光以光学方式复制数据。上述的组合也应该包括在计算机可读介质的范围内。

  可以由一个或多个处理器诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其他等效集成或离散逻辑电路执行指令。因此,如本文所用的术语“处理器”可以指任何前述结构或适用于实现本文所描述的技术的任何其他结构。此外,在一些方面中,可以在被配置用于编码和解码的专用硬件和/或软件模块内提供本文所述的功能,或者将其结合到组合编解码器中。而且,这些技术可以完全在一个或多个电路或逻辑元件中实现。

  本公开的技术可以在各种设备或装置包括无线手机、集成电路(IC)或一组IC(例如,芯片组)中实现。在本公开中描述了各种部件、模块或单元,以强调被配置为执行所公开的技术的设备的功能方面,但是不一定需要通过不同的硬件单元来实现。相反,如上所述,可以将各种单元组合在编解码器硬件单元中,或者通过互操作硬件单元包括如上所述的一个或多个处理器的集合,结合合适的软件和/或固件来提供各种单元。

  此外,每个上述实施方案中所使用的基站设备和终端设备的每个功能块或各种特征可通过电路(通常为一个集成电路或多个集成电路)实施或执行。被设计为执行本说明书中所述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用或通用集成电路(ASIC)、现场可编程门阵列(FPGA),或其他可编程逻辑设备、分立栅极或晶体管逻辑器、或分立硬件部件、或它们的组合。通用处理器可为微处理器,或另选地,该处理器可为常规处理器、控制器、微控制器或状态机。通用处理器或上述每种电路可由数字电路进行配置,或可由模拟电路进行配置。此外,当由于半导体技术的进步而出现制成取代当前集成电路的集成电路的技术时,也能够使用通过该技术生产的集成电路。

  已经描述了各种示例。这些示例和其他示例在以下权利要求的范围内。

  <交叉引用>

  本非临时专利申请根据《美国法典》第35卷第119节(35 U.S.C.§119)要求于2018年4月4日提交的申请62/652,846、于2018年4月6日提交的申请62/654,260以及于2018年5月6日提交的申请62/678,126的优先权,这三个申请的全部内容据此以引用方式并入。

《用于针对虚拟现实应用程序发送信号通知子图片组合信息的系统和方法.doc》
将本文的Word文档下载到电脑,方便收藏和打印
推荐度:
点击下载文档

文档为doc格式(或pdf格式)