CN111034203A - 处理具有动态逐区封装的全向媒体 - Google Patents

Abstract

一种用于处理视频数据的实例装置包含经配置以存储全向视频流的存储器，以及在电路中实施且经配置以进行以下操作的处理器：处理(例如，编码、发射、接收或解码)所述全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及处理参考所述样本条目的所述文件格式样本集合的第二帧，所述第二帧具有与所述第一逐区封装方案不同的第二逐区封装方案。以此方式，单个全向视频位流可包含整个虚拟现实VR视频内容，所述整个虚拟现实视频内容具有以每单位面积最大数目的颜色样本经优化的最多请求区。

Description

处理具有动态逐区封装的全向媒体

本申请案要求2017年8月29日提交的第62/551,688号美国临时申请案和2018年8月28日提交的第16/115,355号美国申请案的权益，以上申请案中的每一者的整个内容特此以引用的方式并入本文中。

技术领域

本发明涉及例如视频数据等经编码媒体数据的存储和输送。

背景技术

数字视频能力可并入到广泛范围的装置中，包含数字电视、数字直播系统、无线广播系统、个人数字助理(PDA)、膝上型或桌上型计算机、数码相机、数字记录装置、数字媒体播放器、视频游戏装置、视频游戏控制台、蜂窝式或卫星无线电电话、视频电话会议装置，及其类似者。数字视频装置实施视频压缩技术，例如在由MPEG-2、MPEG-4、ITU-T H.263或ITU-T H.264/MPEG-4第10部分高级视频译码(AVC)、ITU-T H.265(也被称作高效视频译码(HEVC))定义的标准和此类标准的扩展(例如可缩放和多视图扩展)中描述的那些技术，以更高效地发射和接收数字视频信息。

在媒体数据已经编码之后，可将媒体数据包化以用于发射或存储。媒体数据可经组装成符合例如国际标准化组织(ISO)基础媒体文件格式(BMFF)及其扩展(例如，AVC)的多种标准中的任一个的媒体文件。

发明内容

大体来说，本发明描述与具有动态逐区封装的全向视频和其它媒体数据的处理和发射(例如，发送和/或接收或检索)有关的技术。动态逐区封装可大体上指代可在最大程度上从视频数据的帧到帧在参考共同样本条目的文件格式样本集合内改变的逐区封装方案。此类技术可例如用于虚拟现实(VR)、增强现实和/或360度视频应用。动态逐区封装可大体上使VR媒体服务提供者能够提供单个全向视频位流从而提供整个VR视频内容，其中最多请求区经优化以包含每单位面积最大数目的颜色样本。最多请求区可按导演剪辑而经初始化为区，且可稍后根据检索统计数据来更新。

在一个实例中，一种处理视频数据的方法包含：处理全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及处理参考所述样本条目的文件格式样本集合的第二帧，所述第二帧具有与第一逐区封装方案不同的第二逐区封装方案。

在另一实例中，一种用于处理视频数据的装置包含经配置以存储全向视频流的存储器，以及在电路中实施且经配置以进行以下操作的处理器：处理所述全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及处理参考所述样本条目的所述文件格式样本集合的第二帧，所述第二帧具有与所述第一逐区封装方案不同的第二逐区封装方案。

在另一实例中，一种计算机可读存储媒体具有存储于其上的指令，所述指令当执行时致使处理器：处理全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及处理参考所述样本条目的文件格式样本集合的第二帧，所述第二帧具有与第一逐区封装方案不同的第二逐区封装方案。

附图及以下描述中阐述了一或多个实例的细节。其它特征、目标和优势将从所述描述和图式以及从权利要求书而显而易见。

附图说明

图1是说明实施用于在网络上流式传输媒体数据的技术的实例系统的框图。

图2是说明根据全向媒体格式(OMAF)草案规范的实例逐区封装过程的概念图。

图3是说明检索单元的组件的实例集合的框图。

图4是说明实例多媒体内容的元素的概念图。

图5是说明可对应于表示的片段的实例视频文件的元素的框图。

图6是说明根据本发明的技术的用于处理全向视频流的视频数据的实例方法的流程图。

图7是说明根据本发明的技术的用于处理全向视频流的视频数据的另一实例方法的流程图。

具体实施方式

本发明的技术可应用于符合根据以下文件格式中的任一者封装的视频数据的视频文件：ISO基础媒体文件格式(ISOBMFF)、ISOBMFF的扩展、可缩放视频译码(SVC)文件格式、高级视频译码(AVC)文件格式、高效视频译码(HEVC)文件格式、第三代移动通信标准化伙伴项目(3GPP)文件格式，及/或多视点视频写码(MVC)文件格式，或其它视频文件格式。ISOBMFF的草案在ISO/IEC 14496-12中指定，可从phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zip获得。另一实例文件格式，即MPEG-4文件格式的草案在ISO/IEC 14496-15中指定，可从wg11.sc29.org/doc_end_user/documents/115_Geneva/wg11/w16169-v2-w16169.zip获得。

ISOBMFF用作许多编解码器囊封格式，例如AVC文件格式，以及许多多媒体容器格式，例如MPEG-4文件格式、3GPP文件格式(3GP)及数字视频广播(DVB)文件格式的基础。

除连续媒体(例如，音频和视频)之外，静态媒体(例如，图像)以及元数据也可存储在符合ISOBMFF的文件中。根据ISOBMFF结构化的文件可用于许多目的，其包含本地媒体文件播放、远程文件的即看式下载、通过HTTP的动态自适应流式传输(DASH)的片段、待流式传输的内容的容器及它的包化指令，以及记录接收到的实时媒体流。

框是在ISOBMFF中的基础语法结构，其包含四字符经译码的框类型、框的字节数及有效负载。ISOBMFF文件包含一系列框，并且框可含有其它框。根据ISOBMFF，电影框(“moov”)含有用于存在于文件中的连续媒体流的元数据，每一者在文件中表示为轨道。根据ISOBMFF，用于轨道的元数据封闭在轨道框(“trak”)中，而轨道的媒体内容或者封闭在媒体数据框(“mdat”)中或者直接地提供于单独的文件中。轨道的媒体内容包含一系列样本，例如音频或视频存取单元。

ISOBMFF规定以下类型的轨道：媒体轨道(含有基础媒体流)、提示轨道(包含媒体传输指令或者表示接收到的包流)和定时元数据轨道(包括时间同步的元数据)。

尽管ISOBMFF最初设计用于存储，但是已经证实ISOBMFF对于流式传输，例如即看式下载或DASH而言是有价值的。出于流式传输的目的，可以使用在ISOBMFF中定义的电影片段。

用于每一轨道的元数据包含样本描述条目的列表，每一条目提供在轨道中使用的译码或封装格式及处理所述格式所需要的初始化数据。每个样本与轨道的样本描述条目中的一个相关联。

ISOBMFF实现了以各种机制指定样本特定的元数据。已经标准化在样本表框(“stbl”)内的特定框以响应于通用需要。举例来说，同步样本框(“stss”)用以列出轨道的随机存取样本。样本分组机制实现根据四字符分组类型将样本映射到共享相同性质的样本的群组中，所述性质被规定为文件中的样本群组描述条目。在ISOBMFF中已经指定了若干分组类型。

虚拟现实(VR)是在通过浸没用户的移动相关的自然和/或合成图像和声音的再现产生的虚拟非实体世界中虚拟地存在从而允许与所述虚拟世界进行交互的能力。随着再现装置中取得的最近进展，例如头戴式显示器(HMD)和VR视频(经常也称为360度视频)创建，可提供显著的体验质量。VR应用包含游戏、训练、教育、体育视频、线上购物、娱乐等。

典型VR系统包含以下组件和步骤：

1)相机组，其通常包含在不同方向上指向的多个个别相机，理想地共同覆盖所述相机组周围的所有视点。

2)图像拼接，其中通过多个个别相机拍摄的视频图片在时域中同步并且在空间域中拼接以成为球面视频，但是映射到矩形格式，例如，相等矩形图(如同世界地图)或立方体图。

3)映射的矩形格式的视频是使用视频编解码器经编码/压缩的，例如，H.265/HEVC或H.264/AVC。

4)经压缩视频位流可以媒体格式存储和/或囊封且通过网络发射(可能仅覆盖用户看见的区域的子集，有时称为视口)到接收装置(例如，客户端装置)。

5)接收装置接收可能以文件格式囊封的视频位流或其部分，且将经解码视频信号或其部分发送到再现装置(其可与接收装置包含在同一客户端装置中)。

6)再现装置可以是例如HMD，其可跟踪头部移动以及甚至眼睛移动时刻，且可再现视频的对应部分以便将沉浸式体验传递给用户。

全向媒体格式(OMAF)正由运动图像专家组(MPEG)开发以定义实现全向媒体应用的媒体格式，其聚焦于具有360度视频和相关联音频的VR应用。OMAF指定一系列投影方法，所述方法可用于将球形或360度视频转换为二维矩形视频，随后是如何使用ISO基础媒体文件格式(ISOBMFF)存储全向媒体和相关联元数据以及如何使用通过HTTP的动态自适应流式传输(DASH)来封装、用信号表示和流式传输全向媒体，以及最终哪些视频和音频编解码器以及媒体译码配置可用于全向媒体信号的压缩和重放。OMAF将变为ISO/IEC 23090-2，且草案规范从wg11.sc29.org/doc_end_user/documents/119_Torino/wg11/16950.zip可供MPEG成员使用。

在HTTP流式传输协议(例如，DASH)中，频繁使用的操作包含HEAD、GET及部分GET。HEAD操作检索与给定的统一资源定位符(URL)或统一资源名(URN)相关联的文件的标头，而不检索与URL或URN相关联的有效负载。GET操作检索与给定URL或URN相关联的整个文件。部分GET操作接收字节范围作为输入参数，且检索文件的持续数目的字节，其中所述字节数目对应于接收到的字节范围。因而，可以提供电影片段以用于HTTP流式传输，因为部分GET操作可以获得一个或一个以上单独的电影片段。在一电影片段中，可能存在不同轨道的几个轨道片段。在HTTP流式传输中，媒体呈现可以是客户端可存取的数据的经构造集合。客户端可以请求和下载媒体数据信息以向用户呈现流式传输服务。

DASH在ISO/IEC 23009-1中指定，且是用于HTTP(自适应)流式传输应用的标准。ISO/IEC 23009-1主要指定媒体呈现描述(MPD)的格式，也被称为清单或清单文件，和媒体片段格式。MPD描述在服务器上可用的媒体，且允许DASH客户端在适当媒体时间自主地下载适当媒体版本。

在使用HTTP流式传输来流式传输3GPP数据的实例中，可能存在对于多媒体内容的视频和/或音频数据的多个表示。如下文所解释，不同表示可对应于不同译码特征(例如，视频译码标准的不同简档或水平)、不同译码标准或译码标准的扩展(例如多视图及/或可缩放扩展)或不同位速率。此类表示的清单可以在媒体呈现描述(MPD)数据结构中定义。媒体呈现可对应于HTTP流式传输客户端装置可存取的数据的经构造集合。HTTP流式传输客户端装置可以请求和下载媒体数据信息以向客户端装置的用户呈现流式传输服务。媒体呈现可在MPD数据结构中描述，MPD数据结构可包含MPD的更新。

媒体呈现可含有一或多个周期的序列。每一周期可延伸直到下一周期的开始为止，或者在最后一个周期的情况下直到媒体呈现的结束为止。每个周期可以含有相同媒体内容的一或多个表示。表示可以是音频、视频、定时文本或其它此类数据的多个替代的编码版本中的一个。表示可按编码类型而不同，例如，按用于视频数据的位速率、分辨率和/或编解码器和用于音频数据的位速率、语言和/或编解码器而不同。术语表示可用于指代经编码音频或视频数据的对应于多媒体内容的特定周期并且用特定方式编码的区段。

特定周期的表示可指派给由MPD中的属性(所述属性指示表示所属的适应集合)指示的群组。同一适应集合中的表示通常被视为彼此的替代，因为客户端装置可在这些表示之间动态地且无缝地切换，例如，以执行带宽适应。举例来说，特定周期的视频数据的每个表示可指派给同一适应集合，使得可选择这些表示中的任一者进行解码以呈现对应周期的多媒体内容的媒体数据(例如，视频数据或音频数据)。在一些实例中，一个周期内的媒体内容可以由来自群组0(如果存在的话)的一个表示来表示，或者由来自每个非零群组的至多一个表示的组合来表示。可相对于周期的开始时间来表达所述周期的每一表示的定时数据。

一个表示可包含一或多个片段。每个表示可包含初始化片段，或表示的每个片段可自初始化。当存在时，初始化片段可含有用于存取所述表示的初始化信息。一般来说，初始化片段不含媒体数据。片段可由识别符唯一地参考，例如统一资源定位符(URL)、统一资源名(URN)或统一资源识别符(URI)。MPD可以提供每个片段的识别符。在一些实例中，MPD还可提供范围属性的形式的字节范围，所述范围属性可对应于可通过URL、URN或URI存取的文件内的片段的数据。

不同表示可选择用于不同类型的媒体数据的基本上同时的检索。举例来说，客户端装置可选择音频表示、视频表示及定时文本表示，从这些表示中检索区段。在一些实例中，客户端装置可选择特定适应集合以用于执行带宽适应。也就是说，客户端装置可选择包含视频表示的适应集合、包含音频表示的适应集合及/或包含定时文本的适应集合。替代地，客户端装置可选择用于某些类型媒体(例如，视频)的适应集合，且直接选择用于其它类型媒体(例如，音频和/或定时文字)的表示。

用于基于DASH的HTTP流式传输的典型过程包含以下步骤：

1)DASH客户端获得流式传输内容(例如，电影)的MPD。MPD包含关于流式传输内容的不同的替代表示的信息，例如，位速率、视频分辨率、帧速率、音频语言，以及HTTP资源(初始化片段和媒体片段)的URL。

2)基于MPD中的信息和可用于DASH客户端的本地信息，例如网络带宽、解码/显示能力和用户偏好，DASH客户端请求所要的表示，每次一个片段(或其一部分)。

3)当DASH客户端检测到网络带宽改变时，其请求具有较好匹配位速率的不同表示的片段，理想地从开始于随机存取点的片段开始。

在HTTP流式传输“会话”期间，为了响应往回搜寻到过去位置或向前搜寻到未来位置的用户请求，DASH客户端请求过去或未来片段，从靠近所要的位置且理想地开始于随机存取点的片段开始。用户还可请求快进内容，这可通过请求足以用于仅对经帧内译码视频图片或仅对视频流的时间子集进行解码的数据来实现。

可根据多种视频译码标准对视频数据进行编码。此类视频译码标准包含ITU-TH.261、ISO/IEC MPEG-1视觉、ITU-T H.262或ISO/IEC MPEG-2视觉、ITU-T H.263、ISO/IECMPEG-4视觉、ITU-T H.264或ISO/IEC MPEG-4AVC，包含其可缩放视频译码(SVC)和多视图视频译码(MVC)扩展，以及高效视频译码(HEVC)，也被称作ITU-T H.265和ISO/IEC 23008-2，包含其可缩放译码扩展(即，可缩放高效视频译码，SHVC)和多视图扩展(即，多视图高效视频译码，MV-HEVC)。

本发明描述可添加到OMAF草案规范和/或其它标准(例如，DASH、ISO BMFF、HEVC或类似物)以改进媒体数据的处理(例如囊封、解封、编码和/或解码)的各种约束。大体来说，此类约束允许装置推断媒体位流的特性，以使得例如数据组装器/构建器(例如内容准备装置或服务器装置)或数据剖析器(例如客户端装置，例如文件处理单元或解封单元)无需考虑根据约束无法发生的事件。举例来说，如果约束指定某些数据仅当条件为真时可存在，那么如果所述条件为假，则无需处理受约束数据。另外或替代地，如果数据存在，那么可推断所陈述条件为真。更确切地说，可形成对应于位流的上下文无关语法，其考虑各种条件以指定后续数据是否对应于受约束数据。同样，可根据上下文无关语法来实施和配置数据生成单元和数据剖析单元。

图1是说明实施用于在网络上流式传输媒体数据的技术的实例系统10的框图。在此实例中，系统10包含内容准备装置20、服务器装置60及客户端装置40。客户端装置40及服务器装置60通过网络74以通信方式耦合，所述网络可包括因特网。在一些实例中，内容准备装置20和服务器装置60还可通过网络74或另一网络耦合，或者可直接以通信方式耦合。在一些实例中，内容准备装置20和服务器装置60可包括相同装置。

在图1的实例中，内容准备装置20包括音频源22及视频源24。举例来说，音频源22可包括麦克风，所述麦克风产生表示将由音频编码器26编码的所捕获音频数据的电信号。或者，音频源22可包括存储先前记录的音频数据的存储媒体、音频数据产生器，例如计算机化的合成器，或音频数据的任何其它源。视频源24可包括：摄像机，其产生将由视频编码器28编码的视频数据；存储媒体，其通过先前记录的视频数据编码；视频数据生成单元，例如，计算机图形源；或视频数据的任何其它源。内容准备装置20未必在所有实例中都以通信方式耦合到服务器装置60，而是可将多媒体内容存储到由服务器装置60读取的单独媒体。

原始音频及视频数据可包括模拟或数字数据。模拟数据可在由音频编码器26和/或视频编码器28编码之前进行数字化。音频源22可在说话参与者正在说话时从所述说话参与者获得音频数据，且视频源24可同时获得所述说话参与者的视频数据。在其它实例中，音频源22可包含包括所存储的音频数据的计算机可读存储媒体，且视频源24可包含包括所存储的视频数据的计算机可读存储媒体。以此方式，本发明中所描述的技术可应用于实况、流式传输、实时音频及视频数据或所存档的、预先记录的音频及视频数据。

对应于视频帧的音频帧通常为含有通过音频源22捕获(或产生)的音频数据的音频帧，所述音频数据同时伴随包含于视频帧内的通过视频源24捕获(或产生)的视频数据。举例来说，当说话参与者通常通过说话而产生音频数据时，音频源22捕获音频数据，且视频源24同时(即，在音频源22正捕获音频数据的同时)捕获说话参与者的视频数据。因此，音频帧可在时间上对应于一个或一个以上特定视频帧。因此，对应于视频帧的音频帧大体上对应于同时捕获到音频数据和视频数据且音频帧和视频帧分别包括同时捕获到的音频数据和视频数据的情形。

在一些实例中，音频编码器26可对每一经编码音频帧中的表示记录经编码音频帧的音频数据的时间的时戳进行编码，并且类似地，视频编码器28可对每一经编码视频帧中的表示记录经编码视频帧的视频数据的时间的时戳进行编码。在此些实例中，对应于视频帧的音频帧可包括包含时戳的音频帧和包含相同时戳的视频帧。内容准备装置20可包含内部时钟，音频编码器26和/或视频编码器28可从所述内部时钟产生时戳，或者音频源22和视频源24可使用所述内部时钟分别使音频和视频数据与时戳相关联。

在一些实例中，音频源22可以向音频编码器26发送对应于记录音频数据的时间的数据，并且视频源24可以向视频编码器28发送对应于记录视频数据的时间的数据。在一些实例中，音频编码器26可对经编码音频数据中的序列识别符进行编码以指示经编码音频数据的相对时间排序，但未必指示记录音频数据的绝对时间，且类似地，视频编码器28也可使用序列识别符来指示经编码视频数据的相对时间排序。类似地，在一些实例中，序列识别符可映射或以其它方式与时戳相关。

音频编码器26通常产生经编码音频数据流，而视频编码器28产生经编码视频数据流。每一单独的数据流(不论是音频还是视频)可被称为基本流。基本流是一个表示的单个经数字译码的(可能经压缩)分量。举例来说，所述表示的经译码视频或音频部分可以是基本流。基本流可在囊封在视频文件内之前转换成包化基本流(PES)。在相同表示内，可使用流ID来区分属于一个基本流的PES包与属于其它基本流的PES包。基本流的数据的基本单元是包化基本流(PES)包。因此，经译码视频数据通常对应于基本视频流。类似地，音频数据对应于一或多个相应的基本流。

例如ITU-T H.264/高级视频译码(AVC)及ITU-T H.265/高效视频译码(HEVC)标准等许多视频译码标准定义无误差位流的语法、语义及解码过程，所述无误差位流中的任一者符合特定简档或水平。视频译码标准通常并不指定编码器，但编码器具有保证所产生的位流对于解码器来说是适应标准的任务。在视频译码标准的情形下，“简档”对应于算法、特征或工具及适用于其的约束的子集。举例来说，如通过H.264标准所定义，“简档”是通过H.264标准指定的整个位流语法的子集。“水平”对应于解码器资源消耗的限制，例如，解码器存储器及计算，其涉及图片分辨率、位速率及块处理速率。可以使用profile_idc(简档指示符)值用信号表示简档，而可以使用level_idc(水平指示符)值用信号表示水平。

举例来说，H.264标准承认，在给定简档的语法所施加的界限内，仍然可能需要编码器和解码器的性能有较大变化，这取决于位流中的例如经解码图片的指定大小等语法元素所取的值。H.264标准进一步承认，在许多应用中，实施能够处理特定简档内的语法的所有假设使用的解码器既不实际又不经济。因此，H.264标准将“水平”定义为强加于位流中的语法元素值的指定约束集合。这些约束可以是对值的简单限制。或者，这些约束可以采用值的算术组合(例如，图片宽度乘以图片高度乘以每秒解码的图片数目)的约束的形式。H.264标准进一步规定单独的实施方案对于每个所支持的简档可以支持一种不同水平。

符合简档的解码器通常支持简档中定义的所有特征。举例来说，作为一个译码特征，B图片译码在H.264/AVC的基础简档中不被支持，但是在H.264/AVC的其它简档中被支持。符合一水平的解码器应能够对不需要超出所述水平中定义的限制的资源的任何位流进行解码。简档和水平的定义可以对可解释性有帮助。举例来说，在视频发射期间，可以针对整个发射会话协商和同意一对简档和水平定义。更确切地说，在H.264/AVC中，举例来说，水平可以定义需要处理的宏块数目、经解码图片缓冲器(DPB)大小、经译码图片缓冲器(CPB)大小、垂直运动向量范围、每两个连续MB的运动向量的最大数目和B块是否可以具有小于8x8像素的子宏块分区的限制。以此方式，解码器可以确定解码器是否能够恰当地对位流进行解码。

在图1的实例中，内容准备装置20的囊封单元30从视频编码器28接收包括经译码视频数据的基本流，且从音频编码器26接收包括经译码音频数据的基本流。在一些实例中，视频编码器28和音频编码器26可以各自包含用于从经编码数据形成PES包的包化器。在其它实例中，视频编码器28及音频编码器26可各自与用于从经编码数据形成PES包的相应包化器介接。在另外其它实例中，囊封单元30可包含用于从经编码音频和视频数据形成PES包的包化器。

视频编码器28可以用多种方式对多媒体内容的视频数据进行编码，以便以各种位速率并且用各种特性产生多媒体内容的不同表示，所述特性例如是像素分辨率、帧速率、对于各种译码标准的符合性、对于各种译码标准的各种简档和/或简档水平的符合性、具有一个或多个视图的表示(例如，对于二维或三维重放)或其它这些特性。如本发明中所使用，表示可包括音频数据、视频数据、文本数据(例如，用于隐藏字幕)或其它此类数据中的一者。表示可包含例如音频基本流或视频基本流的基本流。每个PES包可包含stream_id，其识别PES包所属的基本流。囊封单元30负责将基本流组装成各种表示的视频文件(例如，片段)。

囊封单元30从音频编码器26和视频编码器28接收用于表示的基本流的PES包且从所述PES包形成对应的网络抽象层(NAL)单元。经译码视频片段可经组织为NAL单元，其提供“网络友好的”视频表示，从而解决例如视频电话、存储、广播或流式传输等应用。NAL单元可分类为视频译码层(VCL)NAL单元和非VCL NAL单元。VCL单元可含有核心压缩引擎且可包含块、宏块和/或切片层级数据。其它NAL单元可为非VCL NAL单元。在一些实例中，一个时间实例中的经译码图片(通常呈现为初级经译码图片)可包含在存取单元中，所述存取单元可包含一或多个NAL单元。

非VCL的NAL单元可包含参数集NAL单元和SEI NAL单元等等。参数集可以含有序列等级标头信息(在序列参数集(SPS)中)和不频繁改变的图片层级标头信息(在图片参数集(PPS)中)。对于参数集(例如，PPS和SPS)，不频繁改变的信息不需要对于每个序列或图片重复，因此可改进译码效率。另外，使用参数集可以实现重要标头信息的频带外传输，避免了对于用于错误恢复的冗余传输的需要。在带外发射实例中，参数集NAL单元可以在与其它NAL单元(例如，SEI NAL单元)不同的信道上发射。

辅助增强信息(SEI)可以含有对于对来自VCL NAL单元的经译码图片样本进行解码不是必需的信息，但是可以辅助与解码、显示、抗误码和其它目的的过程。非VCL NAL单元中可以含有SEI消息。SEI消息是一些标准规范的标准化部分，并且因而对于标准的顺应性解码器实施方案并非始终是必选的。SEI消息可以是序列层级SEI消息或图片层级SEI消息。SEI消息中可含有一些序列层级信息，所述SEI消息例如是SVC的实例中的可缩放性信息SEI消息，和MVC中的视图可缩放性信息SEI消息。这些实例SEI消息可传达关于例如，操作点的提取及操作点的特性的信息。此外，囊封单元30可形成清单文件，例如描述表示的特性的媒体呈现描述符(MPD)。囊封单元30可根据可扩展标记语言(XML)将MPD格式化。

囊封单元30可向输出接口32提供用于多媒体内容的一或多个表示的数据以及清单文件(例如，MPD)。输出接口32可包括网络接口或用于向存储媒体进行写入的接口，例如通用串行总线(USB)接口、CD或DVD写入器或烧录器、到磁性或快闪存储媒体的接口，或用于存储或发射媒体数据的其它接口。囊封单元30可以向输出接口32提供多媒体内容的表示中的每一者的数据，所述输出接口可以经由网络发射或存储媒体向服务器装置60发送所述数据。在图1的实例中，服务器装置60包含存储媒体62，其存储各种多媒体内容64，每一多媒体内容包含一个相应的清单文件66和一或多个表示68A-68N(表示68)。在一些实例中，输出接口32还可向网络74直接发送数据。

在一些实例中，表示68可以分成适应集合。即，表示68的各种子集可包含特性的相应共同集合，例如编解码器、简档和水平、分辨率、视图的数目、用于片段的文件格式、可识别待以表示显示的文字的语言或其它特性的文字类型信息和/或待例如由扬声器解码且呈现的音频数据、可描述用于适应集合中的表示的场景的相机角度或现实世界相机视角的相机角度信息、描述针对特定观众的内容适合性的分级信息，或类似物。

清单文件66可包含指示对应于特定自适应集合的表示68的子集，以及所述自适应集合的共同特性的数据。清单文件66还可包含表示自适应集合的个别表示的个别特性，例如位速率的数据。以此方式，自适应集合可提供用于简化的网络带宽自适应。自适应集合中的表示可使用清单文件66的自适应集合要素的子代要素来指示。

服务器装置60包含请求处理单元70和网络接口72。在一些实例中，服务器装置60可包含多个网络接口。另外，服务器装置60的所述特征中的任何或全部可以在内容传递网络的其它装置(例如路由器、桥接器、代理装置、交换机或其它装置)上实施。在一些实例中，内容递送网络的中间装置可高速缓存多媒体内容64的数据，且包含大体上与服务器装置60的组件相符的组件。总的来说，网络接口72经配置以经由网络74发送和接收数据。

请求处理单元70经配置以从客户端装置(例如客户端装置40)接收对于存储媒体62的数据的网络请求。举例来说，请求处理单元70可以实施超文本传送协议(HTTP)版本1.1，如RFC 2616中R.Fielding等人(网络工作组，IETF，1999年6月)的“超文本传送协议-HTTP/1.1(Hypertext Transfer Protocol-HTTP/1.1,)”中所描述。也就是说，请求处理单元70可经配置以接收HTTP GET或部分GET请求，且响应于所述请求而提供多媒体内容64的数据。所述请求可例如使用表示68中的一者的片段的URL来指定所述片段。在一些实例中，所述请求还可指定所述片段的一或多个字节范围，因而包括部分GET请求。请求处理单元70可进一步经配置以服务于HTTP HEAD请求以提供表示68中的一者的片段的标头数据。在任何情况下，请求处理单元70可经配置以处理所述请求以向请求装置(例如，客户端装置40)提供所请求的数据。

另外或替代地，请求处理单元70可经配置以经由广播或多播协议(例如，eMBMS)传递媒体数据。内容准备装置20可以与所描述大体上相同的方式产生DASH片段和/或子片段，但服务器装置60可使用eMBMS或另一广播或多播网络传递协议递送这些片段或子片段。举例来说，请求处理单元70可经配置以从客户端装置40接收多播群组加入请求。即，服务器装置60可将与多播群组相关联的因特网协议(IP)地址通告给与特定媒体内容相关联的包含客户端装置40的客户端装置(例如，实时事件的广播)。客户端装置40又可提交加入所述多播群组的请求。此请求可遍及网络74(例如,构成网络74的路由器)传播，使得致使所述路由器将去往与多播群组相关联的IP地址的业务导向预订的客户端装置(例如，客户端装置40)。

如图1的实例中所说明，多媒体内容64包含清单文件66，其可以对应于媒体呈现描述(MPD)。清单文件66可以含有不同替代表示68(例如，具有不同品质的视频服务)的描述，并且所述描述可包含例如编解码器信息、简档值、水平值、位速率和表示68的其它描述性特性。客户端装置40可检索媒体呈现的MPD以确定如何接入表示68的片段。

具体来说，检索单元52可以检索客户端装置40的配置数据(未图示)以确定视频解码器48的解码能力和视频输出44的再现能力。配置数据还可包含客户端装置40的用户选择的语言偏好中的任何或所有、对应于客户端装置40的用户设置的深度偏好的一或多个相机视角和/或客户端装置40的用户选择的分级偏好。举例来说，检索单元52可包括网络浏览器或媒体客户端，其经配置以提交HTTP GET和部分GET请求。检索单元52可对应于客户端装置40的一或多个处理器或处理单元(未展示)执行的软件指令。在一些实例中，相对于检索单元52描述的功能性中的全部或部分可在硬件或硬件、软件及/或固件的组合中实施，其中可提供必需的硬件以执行针对软件或固件的指令。

检索单元52可将客户端装置40的解码及呈现能力与清单文件66的信息所指示的表示68的特性相比较。检索单元52可最初地检索清单文件66的至少一部分以确定表示68的特性。举例来说，检索单元52可请求描述一或多个适应集合的特征的清单文件66的一部分。检索单元52可选择具有可由客户端装置40的译码和再现能力满足的特性的表示68的子集(例如，适应集合)。检索单元52可以接着确定所述调适组中的表示的位速率、确定网络带宽的目前可用量和从具有网络带宽可以满足的位速率的表示中的一者检索片段。

一般来说，较高位速率表示可产生较高质量的视频播放，而在可用的网络带宽减少时较低位速率表示可提供足够质量的视频播放。因此，当可用的网络带宽相对高时，检索单元52可以从相对高的位速率表示检索数据，而当可用的网络带宽较低时，检索单元52可以从相对低的位速率表示中检索数据。以此方式，客户端装置40可以经由网络74流式传输多媒体数据，同时还适应于网络74的改变的网络带宽可用性。

另外或替代地,检索单元52可经配置以根据例如eMBMS或IP多播等广播或多播网络协议接收数据。在此等实例中,检索单元52可提交加入与特定媒体内容相关联的多播网络群组的请求。在加入多播群组之后，检索单元52可在无发布到服务器装置60或内容准备装置20的进一步请求的情况下接收多播群组的数据。检索单元52可提交当不再需要多播群组的数据时离开多播群组的请求，例如停止重放或将信道改变到不同多播群组。

网络接口54可以接收所选表示的片段的数据并且向检索单元52提供所述数据，所述检索单元又向文件处理单元50提供所述片段。文件处理单元50可将视频文件的元素解封成组成PES流，将PES流解包化以检索经编码数据并且根据经编码数据是音频流还是视频流的一部分(例如，如通过流的PES包标头所指示)而向音频解码器46或视频解码器48发送经编码数据。音频解码器46对经编码音频数据进行解码，并且向音频输出42发送经解码音频数据，而视频解码器48对经编码视频数据进行解码，并且向视频输出44发送所述经解码视频数据，其可包含流的多个视图。

视频编码器28、视频解码器48、音频编码器26、音频解码器46、囊封单元30、检索单元52和文件处理单元50各自在适当时可实施为多种合适的处理电路中的任一者，例如一或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑电路、软件、硬件、固件或其任何组合。视频编码器28和视频解码器48中的每一者可包含在一或多个编码器或解码器中，所述编码器或解码器中的任一者可集成为组合视频编码器/解码器(编解码器)的一部分。类似地，音频编码器26和音频解码器46中的每一个可包含在一或多个编码器或解码器中，所述编码器或解码器中的任一个可集成为组合编解码器的一部分。包含视频编码器28、视频解码器48、音频编码器26、音频解码器46、囊封单元30、检索单元52和/或文件处理单元50的设备可包括集成电路、微处理器和/或无线通信装置，例如蜂窝式电话。

客户端装置40、服务器装置60和/或内容准备装置20可经配置以根据本发明的技术操作。出于实例的目的，本发明相对于客户端装置40和服务器装置60描述这些技术。然而，应理解，代替服务器装置60(或除此之外)，内容准备装置20可经配置以执行这些技术。

囊封单元30可形成NAL单元，所述NAL单元包括识别NAL单元属于的节目的标头以及有效负载，所述有效负载例如音频数据、视频数据或描述NAL单元对应于的输送或节目流的数据。举例来说，在H.264/AVC中,NAL单元包含1字节标头和变化大小的有效负载。在其有效负载中包含视频数据的NAL单元可包括各种粒度水平的视频数据。举例来说，NAL单元可包括视频数据块、多个块、视频数据的切片，或视频数据的整个图片。囊封单元30可以从视频编码器28接收呈基本流的PES包的形式的经编码视频数据。囊封单元30可使每一基本流与对应程序相关联。

囊封单元30还可组装来自多个NAL单元的存取单元。一般来说,存取单元可包括用于表示视频数据帧以及对应于所述帧的音频数据(当此种音频数据可用时)的一或多个NAL单元。存取单元大体上包含用于一个输出时间实例的所有NAL单元，例如用于一个时间实例的所有音频和视频数据。举例来说，如果每个视图具有20帧每秒(fps)的帧率，那么每个时间实例可以对应于0.05秒的时间间隔。在此时间间隔期间，用于相同存取单元的所有视图的特定帧(相同时间实例)可同时再现。在一个实例中，存取单元可包括一个时间实例中的经译码图片，其可呈现为初级经译码图片。

因此，存取单元可包括共同时间实例的所有音频及视频帧，例如对应于时间X的所有视图。本发明还将特定视图的经编码图片称为“视图分量”。也就是说，视图分量可包括在特定时间针对特定视图的经编码图片(或帧)。相应地，存取单元可被定义为包括共同时间实例的所有视图分量。存取单元的解码次序不需要一定与输出或显示次序相同。

媒体呈现可包含媒体呈现描述(MPD)，其可含有不同替代表示(例如，具有不同质量的视频服务)的描述，且所述描述可包含例如编解码器信息、简档值和水平值。MPD为例如清单文件66等清单文件的一个实例。客户端装置40可检索媒体呈现的MPD以确定如何接入不同呈现的电影片段。电影片段可位于视频文件的电影片段框(moof框)中。

清单文件66(其可包括(举例来说)MPD)可通告表示68的片段的可用性。也就是说，MPD可包含指示表示68中的一个的第一片段变得可用时的挂钟时间的信息，以及指示表示68内的片段的持续时间的信息。以此方式，客户端装置40的检索单元52可基于开始时间以及在特定片段之前的片段的持续时间而确定何时每一片段可用。

在囊封单元30已基于所接收数据将NAL单元和/或存取单元组装到视频文件中之后，囊封单元30将视频文件传递到输出接口32以用于输出。在一些实例中，囊封单元30可将视频文件存储在本地，或经由输出接口32将视频文件发送到远程服务器，而非将视频文件直接发送到客户端装置40。输出接口32可包括例如发射器、收发器、用于将数据写入到计算机可读媒体的装置，例如光学驱动器、磁性媒体驱动器(例如，软驱动器)、通用串行总线(USB)端口、网络接口或其它输出接口。输出接口32将视频文件输出到计算机可读媒体，例如，发射信号、磁性媒体、光学媒体、存储器、快闪驱动器，或其它计算机可读媒体。

网络接口54可经由网络74接收NAL单元或存取单元，且经由检索单元52将NAL单元或存取单元提供到文件处理单元50。文件处理单元50可将视频文件的元素解封成组成PES流，将PES流解包化以检索经编码数据并且根据经编码数据是音频流还是视频流的一部分(例如，如通过流的PES包标头所指示)而向音频解码器46或视频解码器48发送经编码数据。音频解码器46对经编码音频数据进行解码，并且向音频输出42发送经解码音频数据，而视频解码器48对经编码视频数据进行解码，并且向视频输出44发送所述经解码视频数据，其可包含流的多个视图。

图2是说明根据OMAF草案规范的实例逐区封装过程的概念图。OMAF草案规范指定称为逐区封装(RWP)的机制。RWP实现对投影图片的任何矩形区的操纵(调整尺寸、重新定位、旋转和镜像)。RWP可用以生成对特定视口定向的强调或避开投影的弱点，例如朝向ERP中的极点的过取样。后者在图2的顶部描绘，其中在球体视频的极点附近的区域的分辨率降低。图2的底部描绘用于强调的视口定向的实例。

关于RWP的信息在RWP框中用信号表示，为此在最新OMAF草案文本的条款7.2.3中指定了指定RWP框中携载的信息的RegionWisePackingStruct，如下。

JCT-VC文档JCTVC-AA0026(王，“全向媒体格式SEI消息”，ITU-T SG 16WP 3和ISO/IEC JTC 1/SC 29/WG 11的JCT-VC，第28次会议：意大利都灵，2017年7月15-21日，可得自phenix.int-evry.fr/jct/doc_end_user/documents/28_Torino/wg11/JCTVC-AB0026-v3.zip)包含用于在视频位流中的RWP信息的信令的全向逐区封装SEI消息。

OMAF草案规范指定全向逐区封装SEI消息的语法和语义如下：

全向逐区封装SEI消息提供信息以实现所输出经解码图片的颜色样本到投影图片上的重新映射。“投影图片”和“封装图片”的定义如最新OMAF草案文本中定义。

等于1的omni_region_wise_packing_cancel_flag指示SEI消息按输出次序消除任何先前全向逐区封装SEI消息的持久性。等于0的omni_region_wise_packing_cancel_flag指示跟随的全向逐区封装信息。

omni_region_wise_packing_persistence_flag指定用于当前层的全向逐区封装SEI消息的持久性。

等于0的omni_region_wise_packing_persistence_flag指定全向逐区封装SEI消息仅适用于当前经解码图片。

假设picA为当前图片。等于1的omni_region_wise_packing_persistence_flag指定全向逐区封装SEI消息按输出次序针对当前层持续直到以下条件中的一或多个为真：

·当前层的新CLVS开始。

·位流结束。

·输出含有适用于当前层的全向逐区封装SEI消息的存取单元中的当前层中的图片picB，其中PicOrderCnt(picB)大于PicOrderCnt(picA)，其中紧接在调用用于picB的图片次序计数的解码过程之后，PicOrderCnt(picB)和PicOrderCnt(picA)分别为picB和picA的PicOrderCntVal值。

当具有等于0的omni_projection_information_cancel_flag的全向投影指示SEI消息不存在于适用于当前图片的CLVS中且按解码次序在全向逐区封装SEI消息前面时，具有等于0的omni_region_wise_packing_persistence_flag的全向逐区封装SEI消息将不存在于适用于当前图片的CLVS中。解码器将忽略具有等于0的omni_region_wise_packing_persistence_flag的全向逐区封装SEI消息，所述消息按解码次序并不跟随适用于当前图片的CLVS中的具有等于0的omni_projection_information_cancel_flag的全向投影指示SEI消息。

rwp_reserved_zero_6bits在符合本说明书的此版本的位流中应等于0。rwp_reserved_zero_6bits[i]的其它值经保留用于ITU-T|ISO/IEC未来使用。解码器将忽略rwp_reserved_zero_6bits[i]的值。

num_packed_regions指定封装区的数目。num_packed_regions的值应大于0。

proj_picture_width和proj_picture_height分别指定投影图片的宽度和高度。proj_picture_width和proj_picture_height的值都应大于0。

rwp_reserved_zero_4bits在符合本说明书的此版本的位流中应等于0。rwp_reserved_zero_4bits[i]的其它值经保留用于ITU-T|ISO/IEC未来使用。解码器将忽略rwp_reserved_zero_4bits[i]的值。

packing_type[i]指定逐区封装的类型。等于0的packing_type[i]指示矩形逐区封装。保留其它值。packing_type[i]的值在本说明书的此版本中应等于0。解码器应允许大于0的packing_type[i]的值，且应忽略针对任何i值具有大于0的packing_type[i]的所有全向逐区封装SEI消息。

proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]和proj_reg_left[i]在具有分别等于proj_picture_width和proj_picture_height的宽度和高度的投影图片中的明度样本的单元中指示。

proj_reg_width[i]指定第i投影区的宽度。proj_reg_width[i]应大于0。

proj_reg_height[i]指定第i投影区的高度。proj_reg_height[i]应大于0。

proj_reg_top[i]和proj_reg_left[i]分别指定投影图片中的顶部明度样本行和最左明度样本列。proj_reg_top[i]和proj_reg_left[i]的值应在从指示投影图片的左上角的0(包含性)分别到proj_picture_height-1(包含性)和proj_picture_width-1(包含性)的范围内。

proj_reg_width[i]和proj_reg_left[i]总和应小于proj_picture_width。proj_reg_height[i]和proj_reg_top[i]的总和应小于proj_picture_height。

当投影图片是立体的时，proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]和proj_reg_left[i]应使得由这些字段识别的投影区在投影图片的单个组成图片内。

transform_type[i]指定已经应用于第i投影区以将其映射到在编码之前的封装图片的旋转和镜像。当transform_type[i]指定旋转和镜像两者时，已在逐区封装中从投影图片到编码之前的封装图片的镜像之后应用旋转。transform_type[i]的值在下表中指定：

transform_type[i]值的表

rwp_reserved_zero_5bits在符合本说明书的此版本的位流中应等于0。rwp_reserved_zero_5bits[i]的其它值经保留用于ITU-T|ISO/IEC未来使用。解码器应忽略rwp_reserved_zero_5bits[i]的值。

packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]分别指定封装图片中的封装区的宽度、高度、顶部明度样本行和最左明度样本列。

假设packedPicWidth和packedPicHeight是具有与符合性裁剪窗口相同尺寸的封装图片的宽度和高度。packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]的值受约束如下：

·packed_reg_width[i]和packed_reg_height[i]都应大于0。

·packed_reg_top[i]和packed_reg_left[i]的值应在从指示封装图片的左上角明度样本的0(包含性)分别到packedPicHeight-1(包含性)和packedPicWidth-1(包含性)的范围内。

·packed_reg_width[i]和packed_reg_left[i]的总和应小于packedPicWidth。

·packed_reg_height[i]和packed_reg_top[i]的总和应小于packedPicHeight。

·由packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]和packed_reg_left[i]指定的矩形应不与针对在0到i-1(包含性)的范围内的任何j值由packed_reg_width[j]、packed_reg_height[j]、packed_reg_top[j]和packed_reg_left[j]指定的矩形重叠。

OMAF草案规范在条款7.3.1中指定某些受限制方案类型如下：

方案类型

投影全向视频(‘podv’)

用于受限制视频样本条目类型‘resv’的投影全向视频方案的使用指示经解码图片是含有单像或立体内容的封装图片。投影全向视频方案的使用由SchemeTypeBox或CompatibleSchemeTypeBox内的等于‘podv’(投影全向视频)的scheme_type指示。

投影单像图片的格式是以SchemeInformationBox内含有的ProjectedOmnidirectionalVideoBox来指示。当方案类型是‘podv’时在SchemeInformationBox中应存在一个且仅一个ProjectedOmniVideoBox。

注意：当使用‘podv’scheme_type时允许任何projection_type值，且‘podv’也可与在本文档的未来版本中指定的潜在projection_type值一起使用。

当SchemeInformationBox中存在ProjectedOmniVideoBox时，StereoVideoBox可存在于同一SchemeInformationBox中。

对于立体视频，投影左和右图片的帧封装布置是以SchemeInformationBox内含有的StereoVideoBox来指示。StereoVideoBox的不存在指示轨道的全向投影内容是单像。当用于全向视频方案的SchemeInformationBox中存在StereoVideoBox时，stereo_scheme应等于4且stereo_indication_type应指示顶部-底部帧封装或并排帧封装在使用中且梅花形取样不在使用中。

任选的逐区封装是以ProjectedOmniVideoBox内含有的RegionWisePackingBox来指示。RegionWisePackingBox的不存在指示未应用逐区封装，即，封装图片相同于投影图片。

等矩形投影视频(‘erpv’)

注意：此方案类型可用于指定媒体简档。

当在SchemeTypeBox或CompatibleSchemeTypeBox中scheme_type等于‘erpv’时，轨道符合scheme_type等于‘podv’的约束和所有以下额外约束：

·在ProjectedOmniVideoBox内的ProjectionFormatBox应指示等矩形投影。

·当RegionWisePackingBox存在时，以下约束全部适用：

οnum_regions的值应等于HorDiv1*VerDiv1。

οpacking_type[i]的值应等于0。

οtransform_type[i]的值应等于0。

οpacked_reg_width[i]的值应等于proj_reg_width[i]。

οpacked_reg_height[i]的值应等于proj_reg_height[i]。

封装等矩形或立方体图投影视频(‘ercm’)

注意：此方案类型可用于指定媒体简档。

当在SchemeTypeBox或CompatibleSchemeTypeBox中scheme_type等于‘ercm’时，轨道符合scheme_type等于‘podv’的约束和所有以下额外约束：

·在ProjectedOmniVideoBox内的ProjectionFormatBox应指示等矩形投影或立方体图投影。

鱼眼全向视频(‘fodv’)

用于受限制视频样本条目类型‘resv’的鱼眼全向视频方案的使用指示经解码图片是鱼眼视频图片。鱼眼全向视频方案的使用由SchemeTypeBox或CompatibleSchemeTypeBox内的等于‘fodv’(鱼眼全向视频)的scheme_type指示。

鱼眼视频的格式是以SchemeInformationBox内含有的FisheyeOmniVideoBox指示。当方案类型是‘fodv’时在SchemeInformationBox中应存在一个且仅一个FisheyeOmniVideoBox。

当SchemeInformationBox中存在FisheyeOmniVideoBox时，同一SchemeInformationBox中不应存在StereoVideoBox。

OMAF草案规范在条款10.1中指定两个HEVC媒体简档。这两者当中，HEVC视口独立基线简档如下再现：

HEVC视口独立基线简档

总则(提供信息的)

支持至多360度的单像和立体球形视频两者。简档既不要求视口相依性递送也不要求视点相依性解码。常规HEVC编码器、DASH封装器、DASH客户端、文件格式剖析器和HEVC解码器引擎可用于编码、分布和解码。简档还使用于基本互操作性的选项最少。

基本流约束

NAL单元流应遵守HEVC主10简档，主层次，层级5.1。

所有图片应经编码为经译码帧，且不应经编码为经译码字段。

随后的字段应如下设定：

·general_progressive_source_flag应设定成1。

·general_frame_only_constraint_flag应设定成1。

·general_interlaced_source_flag应设定成0。

当VUI存在时，aspect_ratio_info_present_flag应设定成1且aspect_ratio_idc应设定成1(正方形)。

对于每一图片，在适用于图片的位流中应存在等矩形投影SEI消息。

当视频是立体的时，对于每一图片，在适用于图片的位流中应存在帧封装布置SEI消息。

当视频不提供完整360覆盖时，对于每一图片，在适用于图片的位流中应存在逐区封装SEI消息。

当存在时，帧封装布置SEI消息和逐区封装SEI消息应指示遵守在条款7.3.1.2中指定的等矩形投影视频方案类型‘erpv’的约束。

ISO基础媒体文件格式约束

FileTypeBox中的compatible_brands应包含‘ovid’。

视频样本条目类型应等于‘resv’。

如条款7中指定的用于‘resv’轨道的约束适用。

等于‘podv’和‘erpv’的scheme_type值应存在于SchemeTypeBox和CompatibleSchemeTypeBox内。

在RestrictedSchemeInfoBox内的OriginalFormatBox的类型应等于‘hvc1’。

注意：因此，参数集在样本内并不在带内存在。

LHEVCConfigurationBox在OriginalFormatBox中应不存在。

OriginalFormatBox中的HEVCConfigurationBox应指示符合在10.1.2.2中指定的基本流约束。

对于样本描述框中的解码器配置记录，以下适用：

·其应含有一或多个解码参数集。(含有用于HEVC视频的VPS、SPS和PPS NAL)。轨道中的每一视频样本应参考样本条目中的参数集。

当视频基本流含有帧封装布置SEI消息时，StereoVideoBox应存在。当StereoVideoBox存在时，其应用信号表示基本流中的帧封装布置SEI消息中包含的帧封装格式。

当视频基本流含有逐区封装SEI消息时，RegionWisePackingBox应存在。当存在时，RegionWisePackingBox应用信号表示与逐区封装SEI消息中相同的信息。

当希望使用除了由相对于全局坐标轴线等于(0，0)的(方位角，高度)指示的定向之外的另一定向开始重放时，如7.5.4中指定的球体上初始视点区元数据应存在。

接收器要求

符合此媒体简档的接收器应能够处理10.1.2.2中的所有参考SEI消息或在用于等矩形投影视频方案类型的SchemeInformationBox内的所有允许的框。

CMAF媒体简档

此条款定义用于HEVC视口独立基线简档的CMAF媒体简档。此媒体简档可以兼容性标牌‘cvid’来用信号表示。

用于HEVC视口独立基线简档的CMAF媒体简档轨道应符合以下两者：

·10.1.2.3中指定的约束。

·如[CMAF]附录B.1中定义的HEVC CMAF视频轨道。

应注意，通过所述两者的组合，仅HEVC CMAF视频轨道的受限制集合可用于此简档。基于ISO BMFF轨道约束仅可使用‘hvc1’。VUI参数的存在和不存在由CMAF给出。

用于HEVC视口独立基线简档的CMAF切换集合应符合如[CMAF]附录B.2.1中定义的CMAF切换集合约束。

另外，对于用于HEVC视口独立基线简档的CMAF切换集合，以下适用：

·相同投影格式应用于一个CMAF切换集合中的所有CMAF轨道。

·相同帧封装格式应用于一个CMAF切换集合中的所有CMAF轨道。

·相同覆盖信息应用于一个CMAF切换集合中的所有CMAF轨道。

·相同空间分辨率应用于一个CMAF切换集合中的所有CMAF轨道。

到CMAF可寻址对象的映射遵循[CMAF]条款7.6中的规则。

DASH整合

DASH中的HEVC视口独立基线简档的实例化应当表示为一个适应集合，可能具有多个表示。如果是，则所述适应集合应当提供以下信令：

·@编解码器＝'resv.podv.hvc1.1.6.L93.B0'

·@mimeType＝’视频/mp4简档＝"ovid"’

·可使用提供帧封装布置的补充描述符或基本描述符。

注意：通过使用受限制视频方案和参考此媒体简档的@简档，DASH客户端具有所有信息来识别此媒体简档是否可重放。对于额外信息，补充描述符用以提供关于含有的表示的配置的一些细节。

在用于HEVC视口独立基线媒体简档的一个表示上的所有DASH片段的串接应符合在10.1.2.3中指定的所有约束。

另外可通过符合如[CMAF]附录B.1中定义的HEVC CMAF视频轨道来提供对CMAF的符合性。

另外，对于适应集合，以下适用：

·在一个适应集合中的所有表示上应使用同一投影格式。

·在一个适应集合中的所有表示上应使用同一帧封装格式。

·在一个适应集合中的所有表示上应使用同一覆盖信息。

·在一个适应集合中的所有表示上应使用同一空间分辨率。

当希望使用除了由相对于全局坐标轴线等于(0，0)的(方位角，高度)指示的定向之外的另一定向开始重放时，如条款7.5.4中指定的含有球体上初始视点区元数据的表示应存在且与如8.2.8中指定的所有相关媒体表示相关联。

本发明认识到OMAF草案文本并不支持具有动态逐区封装的全向视频，其中动态逐区封装指代可在最大程度上从帧到帧在参考同一样本条目的文件格式样本集合内改变的逐区封装方案。这并不使VR媒体服务提供者能够提供单个全向视频位流而提供整个VR视频内容，其中最多请求区是以每单位面积最大数目的颜色样本来优化。

相比之下，本发明的技术可使VR媒体服务提供者能够提供单个全向视频位流而提供整个VR视频内容，其中最多请求区是以每单位面积最大数目的颜色样本来优化。确切地说，本发明描述例如内容准备装置20和/或服务器装置60等VR媒体服务提供者可以动态逐区封装来编码、存储和流式传输全向视频的技术，其中动态逐区封装指代可在最大程度上从帧到帧在参考同一样本条目的文件格式样本集合内改变的逐区封装方案。因此，内容准备装置20和/或服务器装置60可发送且客户端装置40可接收提供整个VR视频内容的单个全向视频位流，其中最多请求区是以每单位面积最大数目的颜色样本来优化。内容准备装置20和/或服务器装置60可按导演剪辑将最多请求区初始化为区，且稍后使用统计数据更新最多请求区，例如，来自例如客户端装置40等客户端装置和经由网络74与服务器装置60和/或内容准备装置20通信的其它客户端装置的检索统计数据。

下文详细描述两个实例，但应理解，本发明的技术不限于以下实例。

在第一实例中，内容准备装置20、服务器装置60和客户端装置40可经配置以使用新的受限制方案类型，具有动态逐区封装的等矩形投影视频(‘erp2’)。即，内容准备装置20和/或服务器装置60可处理(例如，编码和/或发射)且客户端装置40可处理(例如，接收和/或解码)包含参考样本条目的文件格式样本集合的全向视频流，所述文件格式样本集合包含具有第一逐区封装方案的第一帧和具有第二不同逐区封装方案的第二帧。此方案类型可用于指定媒体简档。内容准备装置20、服务器装置60和客户端装置40可经配置以使得当在SchemeTypeBox或CompatibleSchemeTypeBox中scheme_type等于‘erp2’时，轨道符合等于‘podv’的scheme_type的约束和如下额外约束：

·在ProjectedOmniVideoBox内的ProjectionFormatBox应指示等矩形投影。

·RegionWisePackingBox可或可不存在。无论RegionWisePackingBox是否存在，在跨越图片可为动态的逐区封装SEI消息中用信号表示的逐区封装信息适用。

在此第一实例中，内容准备装置20、服务器装置60和客户端装置40可根据HEVC视口独立基线简档的更新定义来配置。确切地说，基本流约束、ISO基础媒体文件格式约束和DASH整合可如下更新。其它方面可保持不变。大体来说，本说明书文字的相关部分在下文再现，其中改变部分被强调，使得斜体文字表示对本说明书文字的添加且移除部分是使用“[移除：“”]”指示。

基本流约束

NAL单元流应遵守HEVC主10简档，主层次，层级5.1。

所有图片应经编码为经译码帧，且不应经编码为经译码字段。

随后的字段应如下设定：

·general_progressive_source_flag应设定成1。

·general_frame_only_constraint_flag应设定成1。

·general_interlaced_source_flag应设定成0。

当VUI存在时，aspect_ratio_info_present_flag应设定成1且aspect_ratio_idc应设定成1(正方形)。

对于每一图片，在适用于图片的位流中应存在等矩形投影SEI消息。

当视频是立体的时，对于每一图片，在适用于图片的位流中应存在帧封装布置SEI消息。

当视频不提供完整360覆盖时，对于每一图片，在适用于图片的位流中应存在逐区封装SEI消息。

当存在时，帧封装布置SEI消息和逐区封装SEI消息应指示遵守等矩形投影视频方案类型‘erpv’或‘erp2’的约束。

ISO基础媒体文件格式约束

FileTypeBox中的compatible_brands应包含‘ovid’。

视频样本条目类型应等于‘resv’。

如条款7中指定的用于‘resv’轨道的约束适用。

等于‘podv’和‘erpv’或‘podv’和‘erp2’的scheme_type值应存在于SchemeTypeBox和CompatibleSchemeTypeBox内。

在RestrictedSchemeInfoBox内的OriginalFormatBox的类型应等于‘hvc1’。

注意：因此，参数集在样本内并不在带内存在。

LHEVCConfigurationBox在OriginalFormatBox中应不存在。

OriginalFormatBox中的HEVCConfigurationBox应指示符合在10.1.2.2中指定的基本流约束。

对于样本描述框中的解码器配置记录，以下适用：

·其应含有一或多个解码参数集。(含有用于HEVC视频的VPS、SPS和PPS NAL)。轨道中的每一视频样本应参考样本条目中的参数集。

当视频基本流含有帧封装布置SEI消息时，StereoVideoBox应存在。当StereoVideoBox存在时，其应用信号表示基本流中的帧封装布置SEI消息中包含的帧封装格式。

当方案类型'erpv'存在时且当视频基本流含有逐区封装SEI消息时，以下适用：

·RegionWisePackingBox应存在。

·当存在时，RegionWisePackingBox应用信号表示与逐区封装SEI消息中相同的信息。

当希望使用除了由相对于全局坐标轴线等于(0，0)的(方位角，高度)指示的定向之外的另一定向开始重放时，如7.5.4中指定的球体上初始视点区元数据应存在。

DASH整合

除现有DASH整合规范之外，还将受限制方案类型‘erpv’或‘erp2’用信号表示为任选的MIME类型参数。

在第二替代实例中，内容准备装置20、服务器装置60和客户端装置40可经配置有新HEVC媒体简档的定义，其等效于当等于‘erp2’的scheme_type存在时上文的HEVC视口独立基线简档的经更新定义。

图3是更详细地说明图1的检索单元52的组件的实例集合的框图。在此实例中，检索单元52包含eMBMS中间件单元100、DASH客户端110和媒体应用程序112。

在此实例中，eMBMS中间件单元100进一步包含eMBMS接收单元106、高速缓冲存储器104和代理服务器102。在此实例中，eMBMS接收单元106经配置以例如根据单向输送文件传递(FLUTE)经由eMBMS接收数据，所述FLUTE在T·派拉(T.Paila)等的“FLUTE-单向输送文件传递(FLUTE-File Delivery over Unidirectional Transport)”(网络工作组，RFC6726，2012年11月)中描述，其在http://tools.ietf.org/html/rfc6726可用。即，eMBMS接收单元106可经由广播从例如服务器装置60接收文件，所述服务器装置可充当广播多播服务中心(BM-SC)。

在eMBMS中间件单元100接收用于文件读数据时，eMBMS中间件单元100可将接收的数据存储于高速缓冲存储器104中。高速缓冲存储器104可包括计算机可读存储媒体，例如快闪存储器、硬盘、RAM或任何其它合适的存储媒体。

代理服务器102可充当用于DASH客户端110的服务器。举例来说，代理服务器102可将MPD文件或其它清单文件提供到DASH客户端110。代理服务器102可通告用于MPD文件中对片段的可用性时间，以及可从其检索片段第超链接。这些超链接可以包含对应于客户端装置40的本地主机地址前缀(例如，用于IPv4的127.0.0.1)。以此方式，DASH客户端110可使用HTTP GET或部分GET请求从代理服务器102请求片段。举例来说，对于从链接http://127.0.0.1/rep1/seg3可用的片段，DASH客户端110可构造包含针对http://127.0.0.1/rep1/seg3的请求的HTTP GET请求，且将请求提交到代理服务器102。代理服务器102可响应于此类请求从高速缓冲存储器104检索所请求的数据且将数据提供到DASH客户端110。

DASH客户端110可根据如上文所论述的本发明的技术中的任一个或全部单独或以任何组合来配置。

图4是说明实例多媒体内容120的元素的概念图。多媒体内容120可对应于多媒体内容64(图1)，或存储于存储媒体62中的另一多媒体内容。在图4的实例中，多媒体内容120包含媒体呈现描述(MPD)122和多个表示124A-124N(表示124)。表示124A包含任选的标头数据126和片段128A-128N(片段128)，而表示124N包含任选的标头数据130和片段132A-132N(片段132)。为了方便起见，使用字母N来标明表示124中的每一者中的最后一个电影片段。在一些实例中，表示124之间可能存在不同数目的电影片段。

MPD 122可包括与表示124分开的数据结构。MPD 122可对应于图1的清单文件66。类似地，表示124可对应于图3的表示68。一般来说，MPD 122可包含通常描述表示124的特性的数据，例如，译码及再现特性、适应集合、MPD 122所对应的简档、文本类型信息、相机角度信息、分级信息、特技模式信息(例如，指示包含时间子序列的表示的信息)和/或用于检索遥远周期(例如，用于在重放期间向媒体内容中插入定向广告)的信息。

标头数据126当存在时可描述片段128的特性，例如，随机存取点(RAP，也称为流存取点(SAP))的时间位置、片段128中的哪一个包含随机存取点、到片段128内的随机存取点的字节偏移、片段128的统一资源定位符(URL)，或片段128的其它方面。标头数据130当存在时可描述片段132的类似特性。另外或替代地，此类特性可完全包含在MPD 122内。

片段128、132包含一或多个经译码视频样本，其中的每一个可包含视频数据的帧或切片。片段128的经译码视频样本中的每一个可具有类似特性，例如，高度、宽度和带宽要求。可通过MPD 122的数据描述此类特性，但在图4的实例中未说明此类数据。MPD 122可包含3GPP规范描述的特性，并且添加了本发明中描述的用信号表示信息中的任何或所有。

片段128、132的每一个可与唯一统一资源定位符(URL)相关联。因此，片段128、132中的每一个可使用流式传输网络协议(例如，DASH)可独立地检索。以此方式，例如客户端装置40的目的地装置可以使用HTTP GET请求来检索片段128或132。在一些实例中，客户端装置40可使用HTTP部分GET请求来检索片段128或132的特定字节范围。

MPD 122可包含根据本发明的技术中的任一个或全部单独或以任何组合构造的数据。

图5是说明可对应于例如图4的片段114、124中的一个的表示的片段的实例视频文件150的元素的框图。片段128、132中的每一个可以包含基本上符合在图5的实例中说明的数据的布置的数据。视频文件150可以被称为囊封一个片段。如上文所描述，根据ISO基础媒体文件格式及其扩展的视频文件在被称作“框”的一系列对象中存储数据。在图5的实例中，视频文件150包含文件类型(FTYP)框152、电影(MOOV)框154、片段索引(sidx)框162、电影片段(MOOF)框164和电影片段随机存取(MFRA)框166。虽然图5表示视频文件的实例，但应理解，根据ISO基础媒体文件格式及其扩展，其它媒体文件可包含类似于视频文件150的数据结构化的其它类型的媒体数据(例如，音频数据、定时文字数据或类似物)。

文件类型(FTYP)框152通常描述视频文件150的文件类型。文件类型框152可包含识别描述视频文件150的最佳用途的规范的数据。文件类型框152可替代地放置在MOOV框154、电影片段框164和/或MFRA框166之前。

在一些实例中，例如视频文件150的片段可以包含在FTYP框152之前的MPD更新框(未示出)。MPD更新框可以包含指示对应于包含待更新的视频文件150的表示的MPD的信息，连同用于更新MPD的信息。举例来说，MPD更新框可以提供用于待用于更新MPD的资源的URI或URL。作为另一实例，MPD更新框可以包含用于更新MPD的数据。在一些实例中，MPD更新框可以紧跟视频文件150的片段类型(STYP)框(未示出)，其中STYP框可以定义用于视频文件150的片段类型。下文更详细地论述的图7提供关于MPD更新框的额外信息。

在图5的实例中，MOOV框154包含电影标头(MVHD)框156、轨道(TRAK)框158和一或多个电影延伸(MVEX)框160。大体来说，MVHD框156可描述视频文件150的一般特性。举例来说，MVHD框156可包含描述视频文件150原始何时创建、视频文件150最后何时经修改、视频文件150的时间尺度、视频文件150的重放的持续时间的数据，或大体上描述视频文件150的其它数据。

TRAK框158可包含用于视频文件150的轨道的数据。TRAK框158可包含描述对应于TRAK框158的轨道的特性的轨道标头(TKHD)框。在一些实例中，TRAK框158可以包含经译码视频图片，而在其它实例中，轨道的经译码视频图片可以包含于电影片段164中，所述电影片段可以通过TRAK框158和/或sidx框162的数据参考。

在一些实例中，视频文件150可以包含多于一个轨道。相应地，MOOV框154可包含与视频文件150中的轨道的数目相等的数目的TRAK框。TRAK框158可以描述视频文件150的对应的轨道的特性。举例来说，TRAK框158可以描述对应的轨道的时间和/或空间信息。当囊封单元30(图4)包含例如视频文件150等视频文件中等参数集轨道时，类似于MOOV框154的TRAK框158的TRAK框可描述参数集轨道的特性。囊封单元30可用信号表示在描述参数集轨道的TRAK框内的参数集轨道中序列层级SEI消息的存在。

MVEX框160可以描述对应的电影片段164的特征，例如，以用信号通知除包含在MOOV框154内的视频数据(如果存在的话)之外，视频文件150还包含电影片段164。在流式传输视频数据的背景下，经译码视频图片可包含于电影片段164中而不是MOOV框154中。因此，所有经译码视频样本可包含于电影片段164中而不是MOOV框154中。

MOOV框154可包含等于视频文件150中的电影片段164的数目的数目的MVEX框160。MVEX框160中的每一者可描述电影片段164中的对应一个的特性。举例来说，每一MVEX框可包含描述电影片段164中的所述对应一者的时间持续时间的电影延伸标头框(MEHD)框。

如上文所指出，囊封单元30可在并不包含实际经译码视频数据的视频样本中存储序列数据集。视频样本可以通常对应于存取单元，所述存取单元是在特定时间实例处经译码图片的表示。在AVC的情形下，经译码的图片包含一或多个VCL NAL单元，所述VCL NAL单元含有信息以构造存取单元和其它相关联的非VCL NAL单元(例如，SEI消息)的所有像素。相应地，囊封单元30可以包含序列数据集，所述序列数据集可以包含在电影片段164中的一个中的序列层级SEI消息。囊封单元30可以进一步用信号表示序列数据集和/或序列层级SEI消息的存在作为存在于在对应于电影片段164中的一个的MVEX框160中的一个内的电影片段164中的一个中。

SIDX框162是视频文件150的任选的元素。即，符合3GPP文件格式或其它此类文件格式的视频文件不一定包含SIDX框162。根据3GPP文件格式的实例，SIDX框可用以识别片段(例如，视频文件150内含有的片段)的子片段。3GPP文件格式将子片段定义为“具有对应的媒体数据框的一或多个连续的电影片段框的独立的集合并且包含电影片段框所参考的数据的媒体数据框必须在电影片段框之后并且在包含关于相同轨道的信息的下一个电影片段框之前”。3GPP文件格式还指示SIDX框“包含通过框记录的(子)片段的子片段的参考的序列”。所参考的子片段在呈现时间中是连续的。类似地，由片段索引框所指代的字节在片段内始终是连续的。所参考的大小给出在所参考的材料中的字节的数量的计数。

SIDX框162通常提供表示包含于视频文件150中的片段的一或多个子片段的信息。举例来说，此类信息可包含子片段开始和/或结束的重放时间、子片段的字节偏移、子片段是否包含(例如，开始于)流存取点(SAP)、SAP的类型(例如，SAP是否为瞬时解码器刷新(IDR)图片、清洁随机存取(CRA)图片、断链存取(BLA)图片或类似物)、子片段中的SAP的位置(在重放时间和/或字节偏移方面)，及类似物。

电影片段164可以包含一或多个经译码视频图片。在一些实例中，电影片段164可以包含图片的一或多个群组(GOP)，其中的每一个可以包含多个经译码视频图片，例如，帧或图片。另外，如上文所述，在一些实例中，电影片段164可以包含序列数据集。电影片段164中的每一个可以包含电影片段标头框(MFHD，在图5中未示出)。MFHD框可以描述对应的电影片段的特征，例如，电影片段的序号。可以按视频文件150中的序号的次序包含电影片段164。

MFRA框166可以描述视频文件150的电影片段164内的随机存取点。这可以辅助于执行特技模式，例如，执行对通过视频文件150囊封的片段内的特定时间位置(即，重放时间)的寻找。在一些实例中，MFRA框166通常是任选的并且无需包含于视频文件中。同样，例如客户端装置40等客户端装置不一定需要参考MFRA框166来正确地解码和显示视频文件150的视频数据。MFRA框166可包含等于视频文件150的轨道数目或在一些实例中等于视频文件150的媒体轨道(例如，非提示轨道)数目的数目的轨道片段随机存取(TFRA)框(未图示)。

在一些实例中，电影片段164可以包含一或多个流存取点(SAP)，例如，IDR图片。类似地，MFRA框166可以提供SAP的视频文件150内的位置的指示。因此，视频文件150的时间子序列可由视频文件150的SAP形成。时间子序列还可包含其它图片，例如取决于SAP的P帧和/或B帧。时间子序列的帧和/或切片可以布置在片段内，使得取决于子序列的其它帧/切片的时间子序列的帧/切片可以恰当地得到解码。举例来说，在数据的分级布置中，用于预测其它数据的数据也可以包含于时间子序列中。

视频文件150可包含根据本发明的技术中的任一个或全部单独或以任何组合构造的数据。举例来说，电影片段164可对应于视频文件150的文件格式样本集合的帧。文件格式样本集合可指代视频文件150的样本条目。文件格式样本集合的帧可经动态地逐区封装。即，文件格式样本集合的帧中的两个或更多个可具有不同的逐区封装方案。以此方式，单个全向视频流可包含整个虚拟现实(VR)视频内容，其具有以每单位面积最大数目的颜色样本经优化的一或多个最多请求区。即，帧集合中的帧可各自经布置以在帧中集中每单位面积最大数目的颜色样本。

视频文件150的方案类型框(‘schm’框)或兼容方案类型框可包含于视频文件150的元框内，所述元框自身可直接包含于视频文件150中、MOOV框154内或TRAK框158内。方案类型框或兼容方案类型框可包含“erp2”的scheme_type值以指示对应轨道符合“podv”的scheme_type和额外约束：在ProjectedOmniVideoBox内的ProjectionFormatBox应指示等矩形投影；且RegionWisePackingBox可或可不存在。无论RegionWisePackingBox是否存在，在跨越图片可为动态的逐区封装SEI消息中用信号表示的逐区封装信息适用。

图6是说明根据本发明的技术的用于处理全向视频流的视频数据的实例方法的流程图。确切地说，在图6的实例中，处理包含编码和/或发射全向视频流，且更具体地说全向视频流的帧。将在此实例中相对于图1的内容准备装置20阐释图6的方法，但应理解，例如服务器装置60等其它装置可经配置以执行此方法或相似方法。

最初，内容准备装置20可重新布置投影图片的区以形成第一封装图片(200)。举例来说，内容准备装置20可执行投影图片的逐区封装，如相对于图2所示和描述。确切地说，内容准备装置20可最初从由视频源24捕获的图像数据捕获或另外获得投影图片。视频源24可捕获一或多个图像，例如用于将投影到投影上的虚拟现实(VR)，例如球形投影。因此，图像可称为投影图片。内容准备装置20可随后根据第一逐区封装方案重新布置投影图片的区，所述方案优化第一封装图片的每单位面积最大数目的颜色样本。举例来说，内容准备装置20可封装投影图片以使得具有每单位面积较大数目颜色样本的区保持正常大小，但具有每单位面积较小数目颜色样本的区经抽取或另外降低分辨率。

视频编码器28可随后对第一封装图片进行编码(202)。囊封单元30可随后将经编码第一封装图片添加到视频文件的文件格式样本集合(204)，所述视频文件例如图5的视频文件150。所述视频文件可对应于例如DASH片段。囊封单元30可进一步用信号表示表示用于第一封装图片的第一逐区封装方案的语法元素的值。

以类似方式，内容准备装置20可重新布置另一投影图片的区以形成第二封装图片(206)。同样，投影图片可由视频源24捕获，且内容准备装置20可根据第二逐区封装方案重新布置区，所述方案优化第二封装图片的每单位面积最大数目的颜色样本。特别地，第二逐区封装方案可与第一逐区封装方案不同。

视频编码器28可随后对第二封装图片进行编码(208)，且囊封单元30可将经编码第二封装图片添加到文件格式样本集合(210)。虽然图6中出于实例的目的论述两个帧，但应理解，内容准备装置20可以此方式使用动态逐区封装为文件格式样本集合准备多个帧。

囊封单元30可进一步将文件格式样本集合的参考值编码为对应于特定样本条目(212)。即，文件格式样本集合(包含第一和第二封装帧)可对应于共同样本条目。内容准备单元20可随后经由输出接口32发射文件格式样本集合(其可对应于单个全向视频流)(214)例如到服务器装置60或客户端装置40。

以此方式，图6的方法表示处理视频数据的方法的实例，包含：处理全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及处理参考样本条目的文件格式样本集合的第二帧，所述第二帧具有与第一逐区封装方案不同的第二逐区封装方案。在此情况下，“处理”可以指代编码和/或发射中的任一者或两者。

图7是说明根据本发明的技术的用于处理全向视频流的视频数据的另一实例方法的流程图。确切地说，在图7的实例中，处理包含接收和/或解码全向视频流，且更具体地说全向视频流的帧。将在此实例中相对于图1的客户端装置40阐释图7的方法，但应理解，其它装置可经配置以执行此方法或相似方法。

最初，客户端装置40(且确切地说，检索单元52)接收文件格式样本集合(220)。确切地说，文件格式样本集合可包含于单个全向视频流中。客户端装置40(且确切地说，文件处理单元50)可解码文件格式样本集合到特定样本条目的参考(222)。即，文件格式样本集合的帧可对应于共同样本条目。

文件处理单元50可随后从文件格式样本集合提取第一封装图片(224)。文件处理单元50可将第一封装图片提供到视频解码器48，所述视频解码器可对第一封装图片进行解码(226)。客户端装置40可进一步对表示用于第一封装图片的第一逐区封装方案的数据进行解码，且接着相应地重新布置第一封装图片的区以形成投影图片(228)。举例来说，客户端装置40可执行图2所示且相对于图2描述的过程的逆过程。大体来说，客户端装置40可根据第一逐区封装方案重新布置图像的分辨率降低的区和/或执行图像的分辨率降低的区的内插。

文件处理单元50还可从文件格式样本集合提取第二封装图片(230)。文件处理单元50可将第二封装图片提供到视频解码器48，所述视频解码器可对第二封装图片进行解码(232)。客户端装置40可进一步对表示用于第二封装图片的第二逐区封装方案的数据进行解码，且接着相应地重新布置第二封装图片的区以形成投影图片(234)。特别地，尽管第一和第二封装图片包含于对应于共同样本条目的文件格式样本集合内，第二逐区封装方案也可与第一逐区封装方案不同。视频输出44可随后呈现投影图片的图像数据中的一些或全部(236)。

以此方式，图7的方法表示处理视频数据的方法的实例，包含：处理全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及处理参考样本条目的文件格式样本集合的第二帧，所述第二帧具有与第一逐区封装方案不同的第二逐区封装方案。在此情况下，“处理”可指代接收和/或解码中的任一者或两者。

在一或多个实例中，所描述功能可以硬件、软件、固件或其任何组合来实施。如果在软件中实施，那么所述功能可作为一或多个指令或代码在计算机可读媒体上存储或传输，并且由基于硬件的处理单元执行。计算机可读媒体可包含计算机可读存储媒体，其对应于如数据存储媒体或通信媒体的有形媒体，通信媒体(例如)根据通信协议包含有助于将计算机程序从一处传送到另一处的任何媒体。以此方式，计算机可读媒体通常可对应于(1)非暂时性的有形计算机可读存储媒体，或(2)通信媒体，例如，信号或载波。数据存储媒体可为可由一或多个计算机或者一或多个处理器存取以检索用于实施本发明中描述的技术的指令、代码和/或数据结构的任何可用媒体。计算机程序产品可以包含计算机可读媒体。

通过举例而非限制的方式，这种计算机可读存储媒体可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或其它磁性存储装置、快闪存储器、或可以用于以指令或数据结构的形式存储期望的程序代码并且可以被计算机存取的任何其它媒体。此外，适当地将任何连接称作计算机可读媒体。举例来说，如果使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)或例如红外线、无线电及微波等无线技术从网站、服务器或其它远程源传输指令，则同轴电缆、光纤电缆、双绞线、DSL或例如红外线、无线电及微波等无线技术包含在媒体的定义中。但是，应理解，所述计算机可读存储媒体及数据存储媒体并不包括连接、载波、信号或其它暂时性媒体，而是实际上针对于非暂时性有形存储媒体。如本文中所使用，磁盘和光盘包含压缩光盘(CD)、激光光盘、光学光盘、数字多功能光盘(DVD)、软性磁盘及蓝光光盘，其中磁盘通常以磁性方式再现数据，而光盘用激光以光学方式再现数据。以上各个的组合也应包含在计算机可读媒体的范围内。

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

本发明的技术可实施于广泛多种装置或设备中，包含无线手持机、集成电路(IC)或一组IC(例如，芯片组)。本发明中描述各种组件、模块或单元是为了强调经配置以执行所揭示的技术的装置的功能方面，但未必需要通过不同硬件单元实现。确切地，如上文所描述，各种单元可结合合适的软件和/或固件组合在编解码器硬件单元中，或由互操作硬件单元的集合来提供，所述硬件单元包含如上文所描述的一或多个处理器。

已经描述各种实例。这些和其它实例在随附权利要求书的范围内。

Claims (30)

1.一种处理视频数据的方法，所述方法包括：

处理全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及

处理参考所述样本条目的所述文件格式样本集合的第二帧，所述第二帧具有与所述第一逐区封装方案不同的第二逐区封装方案。

2.根据权利要求1所述的方法，其中处理所述第一帧和处理所述第二帧包括将所述全向视频流处理为包含整个虚拟现实VR视频内容的单个全向视频流，所述整个虚拟现实视频内容具有以每单位面积最大数目的颜色样本经优化的一或多个最多请求区，所述单个全向视频流包括包含所述第一帧和所述第二帧的所述文件格式样本集合。

3.根据权利要求1所述的方法，其中所述全向视频流包含文件格式信息的方案类型语法元素，所述方案类型语法元素具有指示所述全向视频流包含具有动态逐区封装的等矩形投影视频的值。

4.根据权利要求3所述的方法，其中所述方案类型语法元素的所述值是‘erp2’。

5.根据权利要求1所述的方法，其中所述全向视频流包含具有‘podv’和‘erpv’或‘podv’和‘erp2’的值的方案类型语法元素。

6.根据权利要求5所述的方法，其中当所述方案类型‘erpv’存在于所述全向视频流中时，所述方法包含确定逐区封装框存在于所述全向视频流中且所述逐区封装框用信号表示信息，所述信息还在用于所述全向视频流的一或多个逐区补充增强信息SEI消息中用信号表示。

7.根据权利要求6所述的方法，其中所述逐区封装框包含于所述全向视频流中包含的文件的文件格式信息中，所述文件包含所述文件格式样本集合。

8.根据权利要求1所述的方法，其中‘erpv’或‘erp2’方案类型中的至少一个在所述全向视频流中用信号表示为用于网络流式传输协议的任选MIME类型参数。

9.根据权利要求8所述的方法，其中所述网络流式传输协议包括通过HTTP的动态自适应流式传输DASH。

10.根据权利要求8所述的方法，其进一步包括处理用于所述网络流式传输协议的清单文件，所述清单文件包括所述‘erpv’或‘erp2’方案类型。

11.根据权利要求10所述的方法，其中所述清单文件包括媒体呈现描述MPD。

12.根据权利要求1所述的方法，其中所述全向视频流符合高效视频译码HEVC媒体简档，所述高效视频译码媒体简档定义指示所述全向视频流包含具有动态逐区封装的等矩形投影视频的方案类型语法元素值。

13.根据权利要求1所述的方法，

其中处理所述第一帧包括编码或发射所述第一帧，所述方法进一步包括：

确定所述第一帧的所述第一逐区封装方案；以及

对用于所述第一帧的第一方案类型值进行编码以指示所述第一帧的所述第一逐区封装方案；且

其中处理所述第二帧包括编码或发射所述第二帧，所述方法进一步包括：

确定所述第二帧的所述第二逐区封装方案；以及

对用于所述第二帧的第二方案类型值进行编码以指示所述第二帧的所述第二逐区封装方案。

14.根据权利要求1所述的方法，

其中处理所述第一帧包括接收或解码所述第一帧，所述方法进一步包括：

对用于所述第一帧的第一方案类型值进行解码；以及

从所述第一方案类型值确定所述第一帧的所述第一逐区封装方案；且

其中处理所述第二帧包括接收或解码所述第二帧，所述方法进一步包括：

对用于所述第二帧的第二方案类型值进行解码；以及

从所述第二方案类型值确定所述第二帧的所述第二逐区封装方案。

15.根据权利要求15所述的方法，其进一步包括：

对所述第一帧进行解码；

根据所述第一逐区封装方案重新布置所述第一经解码帧的一或多个区；

对所述第二帧进行解码；以及

根据所述第二逐区封装方案重新布置所述第二经解码帧的一或多个区。

16.一种用于处理视频数据的装置，所述装置包括：

存储器，其经配置以存储全向视频流；以及

处理器，其在电路中实施且经配置以进行以下操作：

处理所述全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及

处理参考所述样本条目的所述文件格式样本集合的第二帧，所述第二帧具有与所述第一逐区封装方案不同的第二逐区封装方案。

17.根据权利要求16所述的装置，其中所述处理器经配置以将所述全向视频流处理为包含整个虚拟现实VR视频内容的单个全向视频流，所述整个虚拟现实视频内容具有以每单位面积最大数目的颜色样本经优化的一或多个最多请求区，所述单个全向视频流包括包含所述第一帧和所述第二帧的所述文件格式样本集合。

18.根据权利要求16所述的装置，其中所述全向视频流包含文件格式信息的方案类型语法元素，所述方案类型语法元素具有指示所述全向视频流包含具有动态逐区封装的等矩形投影视频的值。

19.根据权利要求18所述的装置，其中所述方案类型语法元素的所述值是‘erp2’。

20.根据权利要求16所述的装置，其中所述全向视频流包含具有‘podv’和‘erpv’或‘podv’和‘erp2’的值的方案类型语法元素。

21.根据权利要求20所述的装置，其中所述处理器经配置以当所述方案类型‘erpv’存在于所述全向视频流中时，确定逐区封装框存在于所述全向视频流中且所述逐区封装框用信号表示信息，所述信息还在用于所述全向视频流的一或多个逐区补充增强信息SEI消息中用信号表示。

22.根据权利要求21所述的装置，其中所述逐区封装框包含于所述全向视频流中包含的文件的文件格式信息中，所述文件包含所述文件格式样本集合。

23.根据权利要求16所述的装置，其中‘erpv’或‘erp2’方案类型中的至少一者用信号表示为用于网络流式传输协议的任选MIME类型参数。

24.根据权利要求23所述的装置，其中所述网络流式传输协议包括通过HTTP的动态自适应流式传输DASH。

25.根据权利要求23所述的装置，其中所述处理器进一步经配置以处理用于所述网络流式传输协议的清单文件，所述清单文件包括所述‘erpv’或‘erp2’方案类型。

26.根据权利要求25所述的装置，其中所述清单文件包括媒体呈现描述MPD。

27.根据权利要求16所述的装置，其中所述全向视频流符合高效视频译码HEVC媒体简档，所述高效视频译码媒体简档定义指示所述全向视频流包含具有动态逐区封装的等矩形投影视频的方案类型语法元素值。

28.根据权利要求16所述的装置，

其中为了处理所述第一帧，所述处理器经配置以编码或发射所述第一帧，且其中所述处理器进一步经配置以：

确定所述第一帧的所述第一逐区封装方案；以及

对用于所述第一帧的第一方案类型值进行编码以指示所述第一帧的所述第一逐区封装方案；且

其中为了处理所述第二帧，所述处理器进一步经配置以编码或发射所述第二帧，且其中所述处理器进一步经配置以：

确定所述第二帧的所述第二逐区封装方案；以及

对用于所述第二帧的第二方案类型值进行编码以指示所述第二帧的所述第二逐区封装方案。

29.根据权利要求16所述的装置，

其中为了处理所述第一帧，所述处理器经配置以接收或解码所述第一帧，且其中所述处理器进一步经配置以：

对用于所述第一帧的第一方案类型值进行解码；以及

从所述第一方案类型值确定所述第一帧的所述第一逐区封装方案；且

其中为了处理所述第二帧，所述处理器经配置以接收或解码所述第二帧，且其中所述处理器进一步经配置以：

对用于所述第二帧的第二方案类型值进行解码；以及

从所述第二方案类型值确定所述第二帧的所述第二逐区封装方案。

30.一种计算机可读存储媒体，其具有存储于其上的指令，所述指令在执行时致使处理器进行以下操作：

处理全向视频流的文件格式样本集合的第一帧，所述文件格式样本集合参考样本条目，所述第一帧具有第一逐区封装方案；以及

处理参考所述样本条目的所述文件格式样本集合的第二帧，所述第二帧具有与所述第一逐区封装方案不同的第二逐区封装方案。

Images