具体实施方式

现在将在下文中参考附图更全面地描述一些实施例，附图中示出了本发明的一些但不是全部的实施例。实际上，本发明的各种实施例可以以很多不同的形式实施并且不应当被解释为限于本文中阐述的实施例；相反，提供这些实施例使得本公开将满足适用的法律要求。相同的附图标记始终指代相同的元素。如本文中使用的，术语“数据”(data)、“内容”(content)、“信息”(information)和类似术语可以互换使用以指代能够根据本发明的实施例被传输、接收和/或存储的数据。因此，对任何这样的术语的使用都不应当被认为用于限制本发明的实施例的精神和范围。

此外，如本文中使用的，术语“电路系统”是指(a)纯硬件电路实现(例如，模拟电路系统和/或数字电路系统中的实现)；(b)一起工作以引起装置执行本文中描述的一个或多个功能的电路和(多个)计算机程序产品的组合，包括存储在一个或多个计算机可读存储器上的软件和/或固件指令；以及(c)需要软件或固件进行操作(即使该软件或固件在物理上不存在)的电路，诸如(多个)微处理器或(多个)微处理器的一部分。“电路系统”的这一定义适用于该术语在本文中(包括在任何权利要求中)的所有使用。作为另一示例，如本文中使用的，术语“电路系统”还包括具有一个或多个处理器和/或其(多个)部分以及随附的软件和/或固件的实现。作为另一示例，本文中使用的术语“电路系统”还包括例如用于移动电话的基带集成电路或应用处理器集成电路、或者服务器、蜂窝网络设备、其他网络设备和/或其他计算设备中的类似集成电路。

如本文中定义的，指代非暂态物理存储介质(例如，易失性或非易失性存储器设备)的“计算机可读存储介质”(computer-readable storage medium)可以与指代电磁信号的“计算机可读传输介质”(computer-readable transmission medium)区分开。

术语“图块”(tile)和“子图片”(sub-picture)可以互换使用。

根据示例实施例提供了一种方法、装置和计算机程序产品以提供用于视频编码中的后期绑定的机制。该方法、装置和计算机程序产品可以与各种视频格式结合使用，包括高效视频编码标准(HEVC或H.265/HEVC)、高级视频编码标准(AVC或H.264/AVC)、即将推出的通用视频编码标准(VVC或H.266/VVC)，和/或与各种视频和多媒体文件格式(包括国际标准组织(ISO)基本媒体文件格式(ISO/IEC 14496-12，可以缩写为如ISOBMFF)、运动图片专家组(MPEG)-4文件格式(ISO/IEC 14496-14，也称为MP4格式)、NAL(网络抽象层)单元结构视频文件格式(ISO/IEC 14496-15)和第三代合作伙伴计划(3GPP文件格式)(3GPP技术规范26.244，也称为3GP格式))结合使用。ISOBMFF是用于导出上述所有文件格式的基础。结合HEVC、ISOBMFF和DASH来描述示例实施例，然而，本公开不限于HEVC、ISOBMFF和DASH，而是，描述是针对一种可能的基础而给出的，在该基础之上，可以部分或全部实现本公开的示例实施例。

本公开的一些方面涉及容器文件格式，诸如国际标准组织(ISO)基本媒体文件格式(ISO/IEC 14496-12，可以缩写为ISOBMFF)、运动图片专家组(MPEG)-4文件格式(ISO/IEC14496-14，也称为MP4格式)、NAL(网络抽象层)单元结构化视频文件格式(ISO/IEC 14496-15)和第三代合作伙伴计划(3GPP文件格式)(3GPP技术规范26.244，也称为3GP格式)。可以结合MPEG或其派生物来描述示例实施例，然而，本公开不限于MPEG，而是，描述是针对一种可能的基础而给出的，在该基础之上，可以部分或全部实现本公开的示例实施例。

不管视频比特流的文件格式如何，示例实施例的装置可以由包括例如视频编码器、视频解码器、计算机工作站、服务器等在内的各种计算设备中的任何一种提供，或者由诸如移动终端(例如，智能电话、平板电脑、视频游戏机等)等各种移动计算设备中的任何一种提供。

不管实施该装置的计算设备是什么，示例实施例的装置10包括如图1所示的处理电路系统12、存储器14、通信接口16以及可选的用户接口18，或者装置10与这些部件相关联，或者以其他方式与这些部件通信。

处理电路系统12可以经由用于在装置10的组件之间传递信息的总线与存储器设备14通信。存储器设备可以是非暂态的并且可以包括例如一个或多个易失性和/或非易失性存储器。换言之，例如，存储器设备可以是电子存储设备(例如，计算机可读存储介质)，该电子存储设备包括被配置为存储可以由机器(例如，如处理电路系统等计算设备)可检索的数据(例如，位)的门(gate)。根据本公开的示例实施例，存储器设备可以被配置为存储用于使得装置能够执行各种功能的信息、数据、内容、应用、指令等。例如，存储器设备可以被配置为缓冲输入数据以供处理电路系统处理。另外地或替代地，存储器设备可以被配置为存储由处理电路系统执行的指令。

在一些实施例中，装置10可以实施在如上所述的各种计算设备中。然而，在一些实施例中，该装置可以实施为芯片或芯片组。换言之，该装置可以包括一个或多个物理封装(例如，芯片)，该物理封装包括结构组件(structural assembly)(例如，基板)上的材料、部件(component)和/或电线。结构组件可以为其上包括的部件电路系统提供物理强度、尺寸的保持和/或电相互作用的限制。因此，在一些情况下，该装置可以被配置为在单个芯片上或作为单个“片上系统”(system on a chip)实现本公开的实施例。因此，在一些情况下，芯片或芯片组可以构成用于执行用于提供本文中描述的功能的一个或多个操作的装置。

处理电路系统12可以以多种不同方式实施。例如，处理电路系统可以实施为各种硬件处理装置中的一种或多种，诸如协处理器、微处理器、控制器、数字信号处理器(DSP)、带有或不带有伴随DSP的处理元件、或各种其他电路系统，包括集成电路，诸如例如ASIC(专用集成电路)、FPGA(现场可编程门阵列)、微控制器单元(MCU)、硬件加速器、专用计算机芯片等。因此，在一些实施例中，处理电路系统可以包括被配置为独立执行的一个或多个处理核心(processing core)。多核心处理电路系统可以在单个物理封装内启用多处理。另外地或替代地，处理电路系统可以包括经由总线串联配置以启用指令、流水线和/或多线程的独立执行的一个或多个处理器。

在示例实施例中，处理电路系统12可以被配置为执行存储在存储器设备14中的或处理电路系统可访问的指令。替代地或另外地，处理电路系统可以被配置为执行硬编码功能(hard coded functionality)。因此，无论是通过硬件方法还是软件方法配置，还是通过其组合配置，处理电路系统都可以表示在相应配置时能够执行根据本公开的实施例的操作的实体(例如，物理地实施在电路系统中)。因此，例如，当处理电路系统被实施为ASIC、FPGA等时，处理电路系统可以是用于进行本文中描述的操作的专门配置的硬件。替代地，作为另一示例，当处理电路系统实施为指令的执行器时，指令可以将处理器具体地配置为在指令被执行时执行本文中描述的算法和/或操作。然而，在一些情况下，处理电路系统可以是被配置为通过用于执行本文中描述的算法和/或操作的指令来运用本发明的实施例的特定设备(例如，图像或视频处理系统)的处理器。处理电路系统可以包括被配置为支持处理电路系统的操作的时钟、算术逻辑单元(ALU)和逻辑门等。

通信接口16可以是被配置为接收和/或传输数据(包括视频比特流)的任何装置，诸如实施在硬件或硬件和软件的组合中的设备或电路系统。在这点上，通信接口可以包括例如用于启用与无线通信网络的通信的一个天线(或多个天线)和支持硬件和/或软件。另外地或替代地，通信接口可以包括用于与(多个)天线交互以引起经由(多个)天线的信号传输或处理经由(多个)天线接收的信号的接收的电路系统。在一些环境中，通信接口可以替代地或另外地支持有线通信。因此，例如，通信接口可以包括通信调制解调器和/或用于支持经由电缆、数字用户线(DSL)、通用串行总线(USB)或其他机制的通信的其他硬件/软件。

在一些实施例中，诸如在装置10被配置为对视频比特流进行编码的情况下，装置10可以可选地包括用户接口18，该用户接口18又可以与处理电路系统12通信以向用户提供输出(诸如通过输出编码视频比特流)并且在一些实施例中接收用户输入的指示。因此，用户接口可以包括显示器，并且在一些实施例中，还可以包括键盘、鼠标、操纵杆、触摸屏、触摸区域、软键、麦克风、扬声器或其他输入/输出机制。替代地或另外地，处理电路系统可以包括用户接口电路系统，用户接口电路系统被配置为控制一个或多个用户接口元件(诸如显示器，并且在一些实施例中，诸如扬声器、振铃器(ringer)、麦克风等)的至少一些功能。处理电路系统和/或包括处理电路系统的用户接口电路系统可以被配置为通过存储在处理电路系统可访问的存储器(例如，存储器设备14等)上的计算机程序指令(例如，软件和/或固件)来控制一个或多个用户接口元件的一个或多个功能。

在描述某些示例实施例时，术语文件(file)有时用作语法结构(syntaxstructure)的同义词或语法结构的实例。在其他上下文中，术语文件可以用于表示计算机文件，即，在存储装置中形成独立(standalone)单元的资源。

当描述各种语法时以及在某些示例实施例中，语法结构可以如下述那样指定。用大括号括起来的一组语句是一个复合语句(compound statement)，并且在功能上被视为单个语句。“while”结构指定条件是否为真的测试，如果为真，则指定对语句(或复合语句)的重复评估，直到条件不再为真。“do...while”结构指定对语句的一次评估，然后是条件是否为真的测试，如果为真，则指定对语句的重复评估，直到条件不再为真。“if...else”结构指定对条件是否为真的测试，如果条件为真，则指定对主要语句的评估，否则指定对替代语句的评估。如果不需要替代语句评估，则结构的“else”部分和相关联的替代语句将被省略。“for”结构指定对初始语句的评估，然后是条件的测试，如果条件为真，则指定对主要语句的重复评估，然后是后续语句，直到条件不再为真。

在H.264/AVC中，宏块(macroblock)是一个16×16的亮度样本块和对应的色度样本块。例如，在4:2:0采样模式中，宏块针对每个色度分量包含一个8×8的色度样本块。在H.264/AVC中，图片被划分为一个或多个切片组(slice group)，并且一个切片组包含一个或多个切片。在H.264/AVC中，切片可以包括特定切片组内在光栅扫描中连续排序的整数个宏块。

当描述视频编码和/或解码操作时，可以使用以下术语。编码块可以定义为针对某个N值的N×N个样本块，使得将编码树块划分为编码块是一个分区(partitioning)。编码树块(CTB)可以定义为针对某个N值的N×N个样本块，使得将组分(component)划分为编码树块是分区。编码树单元(CTU)可以定义为亮度样本的编码树块、具有三个样本数组的图片的色度样本的两个对应编码树块、或者单色图片或使用用于对样本进行编码的三个单独颜色平面和语法结构被编码的图片的样本的编码树块。编码单元(CU)可以定义为亮度样本的编码块、具有三个样本数组的图片的色度样本的两个对应编码块、或者单色图片或使用用于对样本进行编码的三个单独颜色平面和语法结构被编码的图片的样本的编码块。

在诸如高效视频编码(HEVC)编解码器等一些视频编解码器中，视频图片被划分为覆盖图片区域的编码单元(CU)。CU由定义CU内的样本的预测过程的一个或多个预测单元(PU)和定义CU中的样本的预测误差编码过程的一个或多个变换单元(TU)组成。通常，CU由具有从可能的CU大小的预定义集合中可选择的大小的方形样本块组成。具有最大允许大小的CU可以被命名为LCU(最大编码单元)或编码树单元(CTU)，并且视频图片被划分为非重叠LCU。LCU可以进一步拆分为更小CU的组合，例如通过递归地拆分LCU和结果CU(resultingCU)。每个结果CU通常具有至少一个PU和与其相关联的至少一个TU。每个PU和TU可以进一步拆分为更小的PU和TU，以分别增加预测过程和预测误差编码过程的粒度。每个PU具有与其相关联的预测信息，该预测信息定义要针对该PU内的像素应用哪种类型的预测(例如，用于帧间预测PU的运动矢量信息和用于帧内预测PU的帧内预测方向性信息)。

图像可以拆分为独立可编码且可解码图像分段(例如，切片或图块或图块组)，该图像分段也可以称为独立编码图片区域。这样的图像分段可以启用并行处理，本说明书中的“切片”(slice)可以是指由按默认编码或解码顺序被处理的一定数目的基本编码单元构成的图像分段，而“图块”(tile)可以是指已经定义为矩形图像区域的图像分段。图块组(tile group)可以定义为包含一个或多个图块的组。图像分段可以被编码为比特流中的单独单元，诸如H.264/AVC和HEVC中的VCL NAL单元。编码图像分段可以包括报头和有效载荷，其中报头包含解码有效载荷所需要的参数值。

每个TU可以与描述针对该TU内的样本的预测误差解码过程的信息(包括例如离散余弦变换系数信息)相关联。通常，在CU级别发信号通知是否针对每个CU而应用预测误差编码。在没有与CU相关联的预测误差残差的情况下，可以认为针对该CU没有TU。将图像划分为CU以及将CU划分为PU和TU通常在比特流中被发信号通知，以允许解码器再现这些单元的预期结构。

在HEVC标准中，可以将图片分区成图块，该图块是矩形的并且包含整数个CTU。在HEVC标准中，分区成图块形成网格(grid)，该网格可以由图块列宽列表(以CTU为单位)和图块行高列表(以CTU为单位)为特征。图块在比特流中按图块网格的光栅扫描顺序连续排序。图块可以包含整数个切片。

在HEVC中，切片可以包括整数个CTU。如果图块未使用，则按图块内或图片内的CTU的光栅扫描顺序来扫描CTU。切片可以包含整数个图块，并且切片可以被包含在图块中。在CTU内，CU具有定义的特定扫描顺序。

在HEVC中，切片被定义为一个独立切片分段中包含的整数个编码树单元、以及在同一访问单元(access unit)中的下一独立切片分段(如果有)之前的所有后续从属切片分段(如果有)。在HEVC中，切片分段被定义为在图块扫描中连续排序并且被包含在单个网络抽象层(NAL)单元中的整数个编码树单元。将每个图片划分为切片分段是分区。在HEVC中，独立切片分段被定义为不从前一切片分段的值推断切片分段报头的语法元素的值的切片分段，并且从属切片分段被定义为从按解码顺序的前一独立切片分段的值推断切片分段报头的一些语法元素的值的切片分段。在HEVC中，切片报头被定义为当前切片分段或独立切片分段的切片分段报头，该独立切片分段是当前从属切片分段之前的独立切片分段，并且切片分段报头被定义为包含数据元素的编码切片分段的一部分，该数据元素与切片分段中表示的第一或所有编码树单元有关。如果图块未使用，则按图块内或图片内的LCU的光栅扫描顺序扫描CU。在LCU内，CU具有特定扫描顺序。

在H.266/VVC的草案版本中，图片沿图块网格被分区成图块(类似于HEVC)。指定了两种类型的图块组，即，光栅扫描顺序图块组和矩形图块组，并且编码器可以在比特流中(例如，在PPS中)指示正在使用哪种类型的图块组。在光栅扫描顺序图块组中，图块在比特流中按图片内的图块光栅扫描顺序被排序，并且CTU在比特流中按图块内的光栅扫描顺序被排序。在矩形图块组中，图片被分区为矩形图块组，并且图块在比特流中按每个图块组内的光栅扫描顺序被排序，并且CTU在比特流中按图块内的光栅扫描顺序被排序。不管图块组类型如何，图块组包含比特流顺序的一个或多个完整图块，并且一个VCL NAL单元包含一个图块组。切片尚未被包括在H.266/VVC的草案版本中。注意，在该标准最终确定之前，本段中描述的内容可能仍会在H.266/VVC的后续草案版本中演进。

分别用于H.264/高级视频编码(AVC)或HEVC编码器的输出和H.264/AVC或HEVC解码器的输入的基本单元是NAL单元。为了通过面向分组的网络传输或存储到结构化文件中，NAL单元可以封装到分组或类似结构中。在ISO基本媒体文件格式中，访问单元的NAL单元形成样本，样本的大小在文件格式元数据中提供。

字节流格式已经在H.264/AVC和HEVC中指定以用于不提供帧结构的传输或存储环境。字节流格式通过在每个NAL单元前面附接起始代码(start code)来将NAL单元彼此分开。为避免NAL单元边界的错误检测，编码器运行面向字节的起始代码竞争(start codeemulation)预防算法，如果否则会发生起始代码，该算法会将竞争预防字节添加到NAL单元有效载荷中。为了启用面向分组的系统与面向流的系统之间的直接网关操作，无论是否使用字节流格式，都可以始终执行起始代码竞争预防。NAL单元可以定义为一种语法结构，该语法结构包含要遵循的数据类型的指示以及原始字节序列有效载荷(RBSP)的形式包含该数据的字节，并且该字节在必要时散布有竞争预防字节。RBSP可以定义为包含封装在NAL单元中的整数个字节的语法结构。

当描述与HEVC和VVC相关的示例实施例时，以下描述可以用于指定每个语法元素的解析(parsing)过程。

u(n)：使用n位的无符号整数。当语法表中的n为“v”时，比特数以依赖于其他语法元素的值的方式变化。该描述符的解析(parsing)过程由比特流中的接下来的n个位指定，该n个位被解释为无符号整数的二进制表示，其中最高有效位首先被写入。

ue(v)：无符号整数Exponential_Golomb编码语法元素，其中左位在前。

下面提供HEVC中的示例切片分段层原始字节序列有效载荷(RBSP)：

slice_segment_header()可以采用以下语法的形式：

first_slice_segment_in_pic_flag和slice_segment_address可以取决于切片分段在图片内的位置，而其他语法元素的值在同一编码图片的所有独立切片分段中多次不变。

比特流可以定义为比特序列，在一些编码格式或标准中，比特序列可以采用NAL单元流或字节流的形式，该NAL单元流或字节流形成编码图片和相关数据的表示，以形成一个或多个编码视频序列。在同一逻辑通道中，第一比特流之后可以是第二比特流，就像在同一文件中或在通信协议的同一连接中那样。基本流(在视频编码的上下文中)可以定义为一个或多个比特流的序列。在一些编码格式或标准中，第一比特流的结束可以由特定NAL单元指示，该特定NAL单元可以称为比特流结束(EOB)NAL单元并且是比特流的最后NAL单元。

可以以使得“带外”(out-of-band)数据分别与比特流或编码单元相关联但未被包括在其中的方式在权利要求和所描述的实施例中使用短语沿比特流(例如，沿比特流指示)或沿比特流的编码单元(例如，沿编码图块指示)来提及传输、信令或存储。短语沿比特流或沿比特流的编码单元等解码可以是指解码所提及的带外数据(其可以从带外传输、信令或存储获取)，该带外数据分别与比特流或编码单元相关联。例如，在以下情况下可以使用短语沿比特流：比特流被包含在容器文件(诸如符合ISO基本媒体文件格式的文件)中，并且某些文件元数据以将元数据与比特流相关联的方式存储在文件中，诸如包含比特流的轨道的样本条目中的框、包含比特流的轨道的样本组、或与包含比特流的轨道相关联的定时元数据轨道。

随机访问点(RAP)图片(也可以称为帧内随机访问点(IRAP)图片或随机访问图片)可以仅包括帧内编码图像分段。此外，RAP图片可以将输出顺序的子序列图片约束为使得它们可以被正确解码而无需执行按解码顺序在RAP图片之前的任何图片的解码过程。

运动受限图块集(MCTS)是帧间预测过程在编码中受到约束的图块集。以下限制可以适用：在运动受限图块集之外的样本值以及在使用在运动受限图块集之外的一个或多个样本值而导出的部分样本位置处的样本值都没有用于运动受限图块集内的任何样本的帧间预测。此外，MCTS的编码以使得从MCTS之外的块中导出的变量或任何解码结果在MCTS内的任何解码过程中均不使用的方式受到约束。例如，MCTS的编码以使得运动矢量候选不是从MCTS之外的块中导出的方式受到约束。这可以通过以下方式来强制执行：关闭HEVC的时间运动矢量(temporal motion vector)预测，或者禁止编码器使用TMVP候选或在合并或AMVP候选列表中在TMVP候选之后的任何运动矢量预测候选用于位于MCTS的右图块边界的正左侧的PU，MCTS的右下角的最后PU除外。通常，MCTS可以定义为独立于在MCTS之外的任何样本值和编码数据(诸如运动矢量)的图块集。MCTS序列可以定义为一个或多个编码视频序列等中的相应MCTS的序列。在某些情况下，可能需要MCTS来形成矩形区域。应当理解，根据上下文，MCTS可以是指图片内的图块集或图片序列中的相应图块集。相应图块集可以但通常不必在图片序列中并置。运动受限图块集可以被视为独立编码图块集，因为它可以在没有其他图块集的情况下解码。

帧间预测中使用的样本位置可以被饱和。结果，否则将在图片之外的位置被饱和以指向图片的对应边界样本。因此，如果图块边界也是图片边界，则运动矢量可以有效地跨越该边界，或者运动矢量可以有效地引起将引用该边界之外的位置的部分样本插值，因为采样位置被饱和到边界上。HEVC的时间运动受限图块集补充增强信息(SEI)消息可以用于指示比特流中运动受限图块集的存在。

360度视频或虚拟现实(VR)视频通常是指提供如此大的视场(FOV)以使得在典型显示布置中在单个时间点仅显示视频的一部分的视频内容。例如，VR视频可以在头戴式显示器(HMD)上观看，该HMD能够显示例如约100度的视场。要显示的VR视频内容的空间子集可以基于HMD的取向来选择。在另一示例中，假定典型的平板观看环境，其中例如可以显示大至40度的视场。当在这样的显示器上显示宽FOV内容(例如，鱼眼)时，可以显示空间子集而不是整个图片。VR视频采集、编码和回放的示例过程如图2A所示。

真实世界视听场景(A)由音频传感器和一组相机或具有多个镜头和传感器的相机设备捕获，如20所示。该采集产生一组数字图像/视频(Bi)和音频(Ba)信号。相机/镜头可以覆盖围绕相机组或相机设备的中心点的所有方向。音频可以使用不同麦克风配置来捕获并且存储为各种不同内容格式，包括基于通道的信号、静态或动态(例如，在3D场景中移动)对象信号和基于场景的信号(例如，高阶环绕声)。基于通道的信号通常符合在编码独立代码点(CICP)中定义的扬声器布局之一。在全向媒体应用中，所渲染的沉浸式音频节目的扬声器布局信号可以被二进制化以通过耳机呈现。同一时刻的图像(Bi)可以拼接、投影并且映射到打包图片(D)上。

对于单视场360度视频，一个时刻的输入图像被拼接以生成表示一个视图的投影图片，如22所示。用于单视场内容的图像拼接、投影和按区域打包过程的分解如图2B所示。输入图像(Bi)被拼接并且投影到三维投影结构上，该三维投影结构例如可以是单位球体。投影结构可以被认为包括一个或多个表面，诸如(多个)平面或其(多个)部分。投影结构可以定义为由一个或多个表面组成的三维结构，所捕获的VR图像/视频内容被投影在该表面上，并且可以从该表面形成相应投影图片。投影结构上的图像数据进一步被布置到二维投影图片(C)上。术语投影可以定义为将一组输入图像投影到投影帧上的过程。可以存在投影图片的一组预定义表示格式，包括例如等距柱状投影(ERP)格式和立方体映射投影(CMP)格式。可以认为投影图片覆盖整个球体。

可选地，可以应用按区域打包以将投影图片映射到打包图片上。如果不应用按区域打包，则打包图片与投影图片相同，并且投影图片作为图像/视频编码的输入而给出。如果应用按区域打包，则通过指示打包图片中每个区域的位置、形状和大小，将投影图片的区域映射到打包图片(D)上，并且打包图片(D)作为图像/视频编码的输入而给出。按区域打包是指将投影图片映射到打包图片的过程。打包图片是指由投影图片的按区域打包产生的图片。

帧间预测中使用的样本位置可以被饱和。结果，否则将在图片之外的位置被饱和以指向图片的对应边界样本。因此，在某些用例中，如果图块边界也是图片边界，则运动矢量可以有效地跨越该边界，或者运动矢量可以有效地引起将引用该边界之外的位置的部分样本插值，因为样本位置被饱和到边界上。在其他用例中，具体地，如果可以将编码图块从其位于与图片边界相邻的位置的比特流中提取到图块位于不与图片边界相邻的位置的另一比特流，则编码器可以类似于任何MCTS边界来在图片边界上约束运动矢量。HEVC的时间运动受限图块集补充增强信息(SEI)消息可以用于指示比特流中运动受限图块集的存在。

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

ISO基本媒体文件格式中的基本构造块称为框。每个框具有报头和有效载荷。框报头以字节指示框的类型和框的大小。框可以包含其他框，并且ISOBMFF指定在某种类型的框内允许的框类型。此外，每个文件中某些框的存在可以是强制性的，而其他框的存在可以是可选的。此外，对于某些框类型，可以允许在文件中存在一个以上的框。因此，可以考虑使用ISO基本媒体文件格式来指定框的层级结构。

根据ISOBMFF，文件包括封装到框中的媒体数据和元数据。每个框由四字符代码(4CC)标识，并且以报头开头，该报头告知框的类型和大小。

在符合ISO基本媒体文件格式的文件中，媒体数据可以在媒体数据'mdat'框(又称为MediaDataBox)中提供，而movie'moov'框(又称为MovieBox)可以用于封装元数据。在某些情况下，为了使文件可操作，可能需要同时存在'mdat'和'moov'框。movie'moov'框可以包括一个或多个轨道，并且每个轨道可以驻留在一个对应的TrackBox('trak')中。轨道可以是多种类型中的一种，包括引用根据媒体压缩格式(及其被封装到ISO基本媒体文件格式中)被格式化的样本的媒体轨道。轨道可以被认为是逻辑通道。

可以使用影片片段，例如用于媒体内容的流传输递送或渐进式下载，或者在将内容记录到ISOBMFF文件时，例如，以便避免在记录应用崩溃、存储器空间不足或某种其他事件发生时丢失数据。如果没有影片片段，可能会发生数据丢失，因为文件格式可能要求将所有元数据(例如，影片框)写入文件的一个连续区域。此外，在记录文件时，可能没有足够量的存储器空间(例如，随机存取存储器RAM)来针对可用存储大小缓冲影片框，并且在影片关闭时重新计算影片框的内容可能太慢。此外，影片片段可以启用使用常规ISOBMFF文件解析器对文件的同时记录和回放。此外，当使用影片片段且与具有相同媒体内容但被结构化为没有影片片段的文件相比初始影片框更小时，渐进式下载(例如同时接收和回放文件)可能需要更短的初始缓冲持续时间。

影片片段特征可以启用将否则可能驻留在影片框中的元数据拆分为多个片段。每个片段可以对应于轨道的某个时间段。换言之，影片片段特征可以启用文件元数据和媒体数据的交错(interleave)。因此，影片框的大小可能会受到限制，并且上述用例可以被实现。

在一些示例中，如果影片片段的媒体样本与moov框在同一文件中，则影片片段的媒体样本可以驻留在mdat框中。然而，对于影片片段的元数据，可以提供moof框。moof框可以包括先前在moov框中的回放时间的某个持续时间的信息。moov框本身仍然可以表示有效的影片，但此外，它可以包括用于指示影片片段将在同一文件中跟随的mvex框(又称为MovieExtendsBox)。影片片段可以及时扩展与moov框相关联的呈现。

在影片片段内，可以存在一组轨道片段，包括每轨道从零到多个的任何地方。轨道片段又可以包括从零到多个轨道轮次(run)(又称为轨道片段轮次)的任何地方，其中每个文档是该轨道的样本的连续轮次。在这些结构中，很多字段是可选的并且可以是默认的。可以被包括在moof框中的元数据可以限于可以被包括在moov框中并且在一些情况下可以不同地编码的元数据的子集。有关可以被包括在moof框中的框的细节可以从ISO基本媒体文件格式规范中找到。自包含(self-contained)的影片片段可以定义为由按文件顺序是连续的moof框和mdat框组成，并且其中mdat框包含影片片段的样本(moof框为其提供元数据)并且不包含任何其他影片片段的样本(即，任何其他moof框)。

轨道引用机制可以用于将轨道彼此关联。TrackReferenceBox包括(多个)框，每个框提供从包含轨道(containing track)到一组其他轨道的引用。这些引用通过(多个)被包含框的框类型(即，框的四字符代码)进行标记。

被包含在TrackBox中的TrackGroupBox启用轨道组的指示，其中每个组共享特定特性或者组内的轨道具有特定关系。框包含零个或多个框，并且特定特性或关系由被包含框的框类型表示。所包含的框包括标识符，该标识符可以用于推断属于同一轨道组的轨道。包含与TrackGroupBox中所包含的框相同类型且在这些所包含的框内具有相同标识符值的轨道属于同一轨道组。

BoxFileIndexBox被指定为ISO/IEC 23001-14的一部分。BoxFileIndexBox提供相关联的文件或分段的框层级的摘要。它包含一组BoxIndexBox框，每个框描述一个顶级框，例如以给出框类型和框大小(以字节为单位)。

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

近来，超文本传输协议(HTTP)已经广泛用于通过互联网递送实时多媒体内容，诸如在视频流传输应用中。与基于用户数据报协议(UDP)的实时传输协议(RTP)的使用不同，HTTP易于配置并且通常可以穿越防火墙和网络地址转换器(NAT)，这使得其对多媒体流传输应用具有吸引力。

基于HTTP的若干自适应流传输商业解决方案(诸如SmoothStreaming、Adaptive HTTP Live Streaming和Dynamic Streaming)已经启动，并且标准化项目已经开展。自适应HTTP流传输(AHS)首次在第三代合作伙伴计划(3GPP)分组交换流传输(PSS)服务(3GPP TS 26.234第9版：“Transparent end-to-endpacket-switched streaming service(PSS)；protocols and codecs”(透明端到端分组交换流传输服务(PSS)；协议和编解码器))中被标准化。MPEG将3GPP AHS第9版作为MPEG DASH标准的起点(ISO/IEC 23009-1：“Dynamic adaptive streaming over HTTP(DASH)-Part1:Media presentation description and segment formats”(2014年国际标准第2版基于HTTP的动态自适应流传输(DASH)-第1部分：媒体呈现描述和分段格式))。3GPP继续致力于与MPEG通信的自适应HTTP流传输，并且发布了3GP-DASH(Dynamic Adaptive Streamingover HTTP(基于HTTP的动态自适应流传输)；3GPP TS 26.247：“Transparent end-to-endpacket-switched streaming Service(PSS)；Progressive download and dynamicadaptive Streaming over HTTP(3GP-DASH)”(透明端到端分组交换流传输服务(PSS)；基于HTTP的渐进式下载和动态自适应流传输(3GP-DASH)))。MPEG DASH和3GP-DASH在技术上彼此接近，并且因此可以统称为DASH。下面描述DASH的一些概念、格式和操作作为实施例可以在其中实现的视频流传输系统的示例。本发明的各方面不限于DASH，而是针对一种可能的基础给出描述，本发明的示例实施例可以部分地或完全地在该基础上实现。

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

在DASH中，层级数据模型用于如下构造媒体呈现。媒体呈现由一个或多个周期(period)的序列组成，每个周期包含一个或多个组，每个组包含一个或多个适配集(Adaptation Set)，每个适配集包含一个或多个表示，每个表示由一个或多个分段组成。表示是媒体内容或其子集的替代选择之一，通常因编码选择(例如比特率、分辨率、语言、编解码器等)而异。分段包含一定持续时间的媒体数据、以及用于解码和呈现所包括的媒体内容的元数据。分段由URI标识，并且通常可以通过HTTP GET请求进行请求。分段可以定义为与HTTP-URL相关联的数据单元、以及可选的由MPD指定的字节范围。

DASH MPD符合可扩展标记语言(XML)，因此通过在XML中定义的元素和属性进行指定。

在DASH中，所有描述符元素以相同方式构造，即它们包含提供用于对方案进行标识的URI的@schemeIdUri属性、以及可选属性@value和可选属性@id。元素的语义特定于所采用的方案。用于标识方案的URI可以是URN或URL。

在DASH中，独立表示(independent representation)可以定义为可以独立于任何其他表示被处理的表示。独立表示可以被理解为包括独立比特流或比特流的独立层。从属表示(dependent representation)可以定义为如下表示：对于所包含的媒体内容组件的呈现和/或解码，其互补表示(complementary representation)中的分段对于该表示是必要的。从属表示可以被理解为包括例如可伸缩比特流的预测层。互补表示可以定义为对至少一个从属表示进行补充的表示。互补表示可以是独立表示或从属表示。从属表示可以由包含@dependencyId属性的表示元素来描述。从属表示可以被视为常规表示，只是它们依赖于一组互补表示进行解码和/或呈现。@dependencyId包含所有互补表示的@id属性的值，即，呈现和/或解码该从属表示中包含的媒体内容组件所必需的表示。

ISOBMFF的轨道引用可以被反映在DASH MPD的@associationType属性中的四字符代码列表中，该列表以一对一的方式映射到在@associationId中给出的[email protected]值列表。这些属性可以用于将媒体表示与元数据表示链接。

DASH服务可以被提供作为点播服务或直播服务。在前者中，MPD是静态的，并且当内容提供者发布MPD时，媒体呈现的所有分段都已经可用。然而，在后者中，MPD可以是静态的或动态的，这取决于MPD所采用的分段URL构造方法，并且随着内容提供者生产内容并且将其发布到DASH客户端，分段被连续创建。分段URL构造方法可以是基于模板的分段URL构造方法，也可以是分段列表生成方法。在前者中，DASH客户端能够在请求分段之前构造分段URL，而无需更新MPD。在后者中，DASH客户端必须周期性地下载更新后的MPD以获取分段URL。因此，对于直播服务，基于模板的分段URL构造方法优于分段列表生成方法。

初始化分段(Initialization Segment)可以定义为包含元数据的分段，该元数据对于呈现封装在媒体分段中的媒体流而言是必需的。在基于ISOBMFF的分段格式中，初始化分段可以包括影片框('moov')，该影片框可能不包括任何样本的元数据，即，针对样本的任何元数据都在'moof'框中提供。

媒体分段(Media Segment)包含用于以正常速度回放的一定持续时间的媒体数据，这样的持续时间称为媒体分段持续时间或分段持续时间。内容生产者(contentproducer)或服务提供者可以根据服务的期望特性来选择分段持续时间。例如，在直播服务中可以使用相对较短的分段持续时间，以实现较短的端到端延迟。原因是，分段持续时间通常是由DASH客户端感知到的端到端延迟的下限，因为分段是为DASH生成媒体数据的离散单元。内容生成通常以使得整个媒体数据分段可用于服务器的方式来进行。此外，很多客户端实现使用分段作为GET请求的单位。因此，在用于直播服务的典型布置中，只有当媒体分段的整个持续时间可用且编码并封装到分段中时，DASH客户端才能请求分段。对于点播服务，可以使用不同的分段持续时间选择策略。

分段可以进一步分区为子分段(subsegment)，例如以启用分多个部分来下载分段。子分段可能需要包含完整的访问单元。子分段可以由分段索引框(又称为SegmentIndexBox或'sidx'框)索引，该分段索引框包含用于映射每个子分段的呈现时间范围和字节范围的信息。分段索引框还可以通过发信号通知分段中的子分段和流访问点的持续时间和字节偏移来描述分段中的子分段和流访问点。DASH客户端可以使用从(多个)分段索引框获取的信息以使用字节范围HTTP请求对特定子分段发出HTTP GET请求。如果使用相对较长的分段持续时间，则可以使用子分段来保持HTTP响应的大小合理且灵活以适应比特率。分段的索引信息可以放在该分段的开头的单个框中，也可以分布在分段中的多个索引框中。不同传播方法(诸如层级、菊花链和混合)是可能的。这种技术可以避免在分段的开头添加大框，并且因此可以防止可能的初始下载延迟。

SegmentIndexBox可以具有以下语法：

SegmentIndexBox的一些语法元素的语义可以如下指定。

reference_type：当设置为1时指示引用的是SegmentIndexBox；否则，引用的是媒体内容(例如，在基于ISOBMFF的文件的情况下，引用的是MovieFragmentBox)；如果使用单独索引分段，则引用类型为1的条目在索引分段中，且引用类型为0的条目在媒体文件中。

referenced_size：从被引用项的第一字节到下一被引用项的第一字节或在最后条目的情况下到被引用材料的结尾的以字节为单位的距离。

术语分段索引(Segment Index)可以被定义为与MPD分开的媒体分段内的时间范围到字节范围映射的紧凑索引。分段索引可以包括一个或多个SegmentIndexBoxes。

记号(子)分段((Sub)segment)是指分段(Segment)或子分段(Subsegment)。如果分段索引框不存在，则记号(子)分段是指分段。如果分段索引框存在，则例如取决于客户是基于分段还是子分段发出请求，记号(子)分段可以是指分段或子分段。

MPEG-DASH为ISO基本媒体文件格式和MPEG-2传输流两者定义了分段容器格式。其他规范可以指定基于其他容器格式的分段格式。例如，已经提出了基于Matroska容器文件格式的分段格式。

子表示(Sub-Representation)被嵌入在常规表示(regular Representation)中并且由SubRepresentation元素描述。SubRepresentation元素被包含在Representation元素中。SubRepresentation元素描述嵌入在Representation中的一个或若干媒体内容组件的属性。例如，它可以描述嵌入式音频组件(诸如编解码器、采样率等)、嵌入式字幕(诸如编解码器)的确切属性，或者它可以描述一些嵌入式低质量视频层(诸如某些较低帧速率或其他属性)。子表示和表示共享一些公共属性和元素。

如果@level属性存在于SubRepresentation元素中，则以下各项适用：

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

初始化分段和/或媒体分段和/或索引分段应当提供足够信息使得可以通过HTTP部分GET请求容易地访问数据。有关提供这样的信息的详细信息由使用中的媒体格式定义。

当ISOBMFF分段用于包括子表示的表示时，以下各项适用：

初始化分段(Initialization Segment)包含级别分配框(Level Assignmentbox)。

针对每个子分段都存在子分段索引框('ssix')。

属性@level指定所描述的子表示所关联的在子分段索引中的级别。表示、子表示和级别分配('leva')框中的信息包含有关媒体数据到级别的分配的信息。

媒体数据应当具有这样的顺序，该顺序使得每个级别与较低级别相比提供增强。

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

ISOBMFF包括所谓的级别机制来指定文件的子集。级别遵循依赖层级(dependencyhierarchy)，因此映射到级别n的样本可以依赖于级别m的任何样本，其中m<＝n，并且不依赖于级别p的任何样本，其中p>n。例如，级别可以根据时间子层(例如，HEVC的TemporalId)来指定。级别可以在影片扩展('mvex')框中包含的级别分配('leva')框(又称为LevelAssignmentBox)中声明。无法为初始影片指定级别。当存在级别分配框时，它适用于初始影片之后的所有影片片段序列。对于级别分配框的上下文，小部分(fraction)被定义为由一个或多个影片片段框和相关联的媒体数据框组成，可能仅包括最后媒体数据框的初始部分。在一个小部分内，每个级别的数据连续出现。一个小部分内各级别的数据以级别值的升序呈现。一个小部分中的所有数据都分配给各级别。级别分配框提供从特征(诸如可伸缩性层或时间子层)到级别的映射。特征可以通过轨道、轨道内的子轨道、或轨道的样本分组来指定。例如，时间级别样本分组可以用于指示图片到时间级别的映射，其等同于HEVC中的时间子层。也就是说，某个TemporalId值的HEVC图片可以使用时间级别样本分组被映射到特定时间级别(并且可以针对所有TemporalId值重复相同操作)。级别分配框然后可以在所指示的到级别的映射中引用时间级别样本分组。

子分段索引框('ssix'，又称为子分段索引框)提供从级别(如级别分配框指定的)到被索引子分段的字节范围的映射。换言之，该框提供紧凑索引，以用于说明子分段中的数据如何根据级别被排序为部分子分段。它使得客户端能够通过下载子分段中的数据范围轻松访问部分子分段的数据。当存在子分段索引框时，子分段中的每个字节被分配到一个级别。如果范围不与级别分配中的任何信息相关联，则可以使用未包括在级别分配中的任何级别。每个分段索引框存在0个或1个子分段索引框，子分段索引框仅对叶子分段进行索引，即，仅对子分段进行索引，而没有分段索引。子分段索引框(如果有)是相关分段索引框之后的下一个框。子分段索引框记录紧前的分段索引框中指示的子分段。每个级别可以被分配给一个部分子分段，即，一个级别的字节范围是连续的。部分子分段的级别通过增加子分段内的数字来分配，即，部分子分段的样本可以取决于同一子分段中在前部分子分段的任何样本，但反之则不然。例如，每个部分子分段包含具有相同时间子层的样本，并且部分子分段在子分段内以递增时间子层顺序出现。当以这种方式访问部分子分段时，最终媒体数据框可能不完整，即，访问的数据少于媒体数据框的长度指示所指示的存在的数据。媒体数据框的长度可能需要调节，或者可以使用填充。级别分配框中的padding_flag指示这个缺失数据是否可以替换为0。如果不是，则分配给级别的样本的未被访问的样本数据不存在，并且应当注意。

DASH通过动态请求来自适配集中不同表示的媒体分段以匹配变化的网络带宽来支持速率适配。当DASH客户端切换上/下表示时，必须考虑表示内的编码依赖性。表示切换可以发生在随机访问点(RAP)处，这通常用于视频编码技术，诸如H.264/AVC。在DASH中，引入了称为流访问点(SAP)的一个更通用的概念，以提供一种用于访问表示并且在表示之间进行切换的独立于编解码器的解决方案。在DASH中，SAP被指定为表示中的位置，该位置使得能够仅使用从该位置开始的表示数据中包含的信息(在初始化分段中在初始化数据之前，如果有)来开始媒体流的回放。因此，表示切换可以在SAP中执行。

在DASH中，已经基于以下各项在同一适配集中的表示之间进行自动选择：宽度和高度(@width和@height)；帧速率(@frameRate)；比特率(@bandwidth)；表示之间的所指示的质量排序(@qualityRanking)。@qualityRanking的语义规定如下：指定表示相对于同一适配集中的其他表示的质量排名。较低值表示较高质量内容。如果不存在，则不定义排名。

已经指定了若干类型的SAP，包括以下类型。SAP类型1对应于在一些编码方案中称为“封闭GOP随机访问点”(Closed GOP random access point)的内容(其中按解码顺序，所有图片可以被正确解码，得到被正确解码的图片的连续时间序列，而没有间隙)，另外，按解码顺序的第一图片也是按呈现顺序的第一图片。SAP类型2对应于在某些编码方案中称为“封闭GOP随机访问点”的内容(其中按解码顺序，所有图片可以被正确解码，得到被正确解码的图片的连续时间序列，而没有间隙)，其中按解码顺序的第一图片可以不是按呈现顺序的第一图片。SAP类型3对应于在一些编码方案中称为“开放GOP随机访问点”(Open GOPrandom access point)的内容，其中可能存在按解码顺序的一些图片，它们无法正确解码并且呈现时间少于与SAP相关联的帧内编码图片。

在诸如MPEG-2等一些视频编码标准中，每个帧内图片都是编码序列中的随机访问点。在一些视频编码标准(诸如H.264/AVC和H.265/HEVC)中灵活使用多个参考图片进行帧间预测的能力导致帧内图片可能不足以进行随机访问因此，图片可以根据其随机访问点功能进行标记，而不是根据编码类型来推断这样的功能；例如，在H.264/AVC标准中指定的IDR图片可以用作随机访问点。封闭图片组(GOP)是如下这样一组图片：其中所有图片都可以被正确解码。例如，在H.264/AVC中，封闭GOP可以从IDR访问单元开始。

开放图片组(GOP)是如下这样一组图片：其中按输出顺序在初始帧内图片之前的图片可能无法被正确解码，但按输出顺序在初始帧内图片之后的图片可以被正确解码。这样的初始帧内图片可以在比特流中指示和/或从来自比特流的指示推断，例如，通过在HEVC中使用CRA NAL单元类型。按输出顺序在开始开放GOP的初始帧内图片之前并且按解码顺序在初始帧内图片之后的图片可以称为前导图片(leading picture)。有两种类型的前导图片：可解码的和不可解码的。可解码前导图片(诸如HEVC的RADL图片)使得可以在从开始开放GOP的初始帧内图片开始解码时被正确解码。换言之，可解码前导图片仅使用初始帧内图片或按解码顺序的后续图片作为帧间预测的参考。不可解码前导图片(诸如HEVC的RASL图片)在从开始开放GOP的初始帧内图片开始解码时无法被正确解码。

DASH预选(DASH Preselection)定义了预期由单个解码器实例联合消耗的MPD的媒体分量的子集，其中消耗可以包括解码和渲染。包含用于预选的主要媒体分量的适配集称为主适配集。此外，每个预选可以包括一个或多个部分适配集。部分适配集可能需要与主适配集一起处理。主适配集和部分适配集可以通过以下两种方式之一来指示：预选描述符或预选元素。

对于360度视频，一个时刻的输入图像被拼接以生成表示两个视图的投影图片，各个视图分别对应于每只眼睛。两个视图都可以映射到同一打包图片上，并且由传统2D视频编码器编码。图2C示出了360度视频的编码过程。替代地，投影图片的每个视图可以被映射到其自己的打包图片，在这种情况下，图像拼接、投影和按区域打包可以以类似于图2B所示过程的方式来执行。左视图或右视图的打包图片序列可以被独立编码，或者在使用多视图视频编码器时基于另一视图来预测。

可以针对相同源图像多次执行图像拼接、投影和按区域打包过程，以创建相同内容的不同版本，例如用于投影结构的不同取向。类似地，可以从相同的投影图片多次执行按区域打包过程以创建要编码的打包图片的多于一个序列。

360度全景内容(即，图像和视频)水平地覆盖成像设备的捕获位置周围的完整360度视场。垂直视场可以变化并且可以是例如180度。覆盖水平360度视场和垂直180度视场的全景图像可以用球体表示，该球体已经使用等距柱状投影(ERP)映射到二维图像平面。在这种情况下，水平坐标可以被认为等同于经度，而垂直坐标可以被认为等同于纬度，没有应用变换或缩放。形成单视场等距柱状图全景图片的过程如图3所示。一组输入图像(诸如相机阵列或具有多个镜头和传感器的相机设备的鱼眼图像)被拼接到球面图像上。球面图像可以被进一步投影到圆柱体上(没有顶面和底面)。圆柱体展开以形成二维投影图片。这些操作中的一个或多个可以合并；例如，输入图像可以直接投影到圆柱体上，而没有中间投影到球体上。用于等距柱状图全景的投影结构可以被认为是包括单个表面的圆柱体。

360度内容可以映射到不同类型的立体几何结构上，诸如多面体(即，包含平面多边形面、直边和尖角或顶点的三维立体对象，例如立方体或金字塔)、圆柱体(通过将球面图像投影到圆柱体上，如上所述使用等距柱状投影)、圆柱体(直接投影，而不首先投影到球体上)、圆锥体等，然后展开到二维图像平面。

在一些实施例中，具有360度水平视场但垂直视场小于180度的全景内容可以被视为等距柱状投影的特殊情况，其中球体的极区没有被映射到二维图像平面上。在一些实施例中，全景图像可以具有小于360度的水平视场和高达180度的垂直视场，同时以其他方式具有等距柱状投影格式的特性。

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

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

作为示例，按区域打包预示以下使用场景：

1)视口无关投影的附加压缩是通过对不同区域的采样进行致密化以在整个球体上实现更高均匀性来实现的。例如，ERP的顶部和底部部分被过采样(oversample)，并且按区域打包可以被应用以对它们进行水平下采样(down-sample)。

2)以自适应方式布置基于平面的投影格式的各面，诸如立方图投影。

3)生成使用视口无关投影格式的视口相关比特流。例如，ERP的区域或CMP的面可以具有不同采样密度，并且底层的投影结构可以具有不同取向。

4)指示由提取器轨道表示的打包图片的区域，诸如当提取器轨道从不同分辨率的比特流中收集图块时。

MPEG全向媒体格式(ISO/IEC 23090-2)是一种虚拟现实(VR)系统标准。OMAF定义了一种媒体格式(包括源自ISOBMFF的文件格式以及用于DASH和MPEG媒体传输的流传输格式)。OMAF版本1支持360°视频、图像和音频、以及相关联的定时文本，并且促进三自由度(3DoF)内容消耗，这表示，可以选择具有被全方位内容覆盖的任意方位角(azimuth)、仰角(elevation)范围以及倾斜角(tilt angle)的视口，但内容与查看位置的任何平移变化不适配。下面进一步描述的视口相关流传输场景也已经被设计用于3DoF，尽管其可能潜在地适用于不同数目的自由度。

全向媒体格式(OMAF)允许省略图像拼接、投影和按区域打包，并且以其捕获格式对图像/视频数据进行编码。在这种情况下，图像(D)被认为与图像(Bi)相同，并且每个时刻的有限数目的鱼眼图像被编码。

对于音频信号，可能不需要拼接过程，因为所捕获的信号本质上是沉浸式和全向的。拼接图像(D)被编码为编码图像(Ei)或编码视频比特流(Ev)。捕获音频(Ba)被编码为音频比特流(Ea)。然后，根据特定媒体容器文件格式(例如，ISOBMFF)，编码图像、视频和/或音频被组合成用于文件回放的媒体文件(F)或用于流传输的初始化分段和媒体分段序列(Fs)。在本规范中，媒体容器文件格式是ISO基本媒体文件格式。文件封装器还将元数据封装到文件或分段中，诸如有助于渲染经解码的打包图片的投影和按区域打包信息。文件中的元数据可以包括：

-投影图片的投影格式，

-鱼眼视频参数，

-被打包图片覆盖的球面面积，

-与投影图片相对应的投影结构相对于全局坐标轴的取向，

-按区域打包信息，以及

-按区域质量排名(可选)。

可以使用递送机制将分段Fs递送给回放设备。包括文件封装器输出(F)的文件可以与包括文件解封装器输入(F')的文件相同。文件解封装器处理文件(F')或接收到的分段(F's)，提取编码比特流(E'a、E'v和/或E'i)，并且解析元数据。然后，音频、视频和/或图像被解码为解码信号(用于音频的B'a、以及用于图像/视频的D')。经解码的打包图片(D')基于当前查看取向或视口以及从文件中解析得到的投影、球面覆盖、投影结构取向和按区域打包元数据被投影到头戴式显示器或任何其他显示设备的屏幕上。同样，根据当前查看取向，经解码的音频(B'a)被渲染，例如通过耳机。当前查看取向由头部跟踪以及可能还有眼部跟踪功能来确定。除了被渲染器用来渲染经解码的视频和音频信号的适当部分，当前查看取向还可以被视频和音频解码器用于解码优化。

人眼不能观看整个360度空间，而是限于最大水平FOV和最大垂直FoV(分别为HHFoV、HVFoV)。此外，HMD设备具有技术限制，该技术限制仅允许在水平和垂直方向上查看整个360度空间的子集(分别为DHFoV、DVFoV)。在任何时间点，HMD上由应用渲染的视频渲染360度视频的一部分。这部分被定义为视口。视口是360度世界上的窗口，该窗口出现在经由渲染显示器显示的全方位视频中。视口的特征在于水平和垂直FoV(分别为VHFoV、VVFoV)。在下文中，VHFoV和VVFoV将简称为HFoV和VFoV。

在诸如OMAF等各种媒体格式中，利用图4所示的坐标系。如图4所示，坐标系由一个单位球体和三个坐标轴组成，即，X(从后到前)轴、Y(横向左右)轴和Z(垂直向上)轴，其中三个轴在球体的中心处交叉并且从那里正交延伸。球体上一点的位置由一对球体坐标方位角(φ)和仰角(θ)确定。方位角的取值范围为-180.0度(包括)至180.0度(不包括)。仰角的取值范围为-90.0度(包括)至90.0度(包括)。

图5示出了可以在内容创作中使用的从球形图片到打包图片的转换以及可以在各种媒体播放器(诸如OMAF播放器)中使用的从打包图片到要渲染的球形图片的对应转换。本节中的示例针对出现在投影全向视频轨道中的打包图片进行描述。可以针对图像项导出类似描述。内容创作可以包括以下有序操作：

操作A：作为输入提供的源图像被拼接以在每个全局坐标轴的单位球面上生成球面图片，如50所示。

操作B：然后，单位球体相对于全局坐标轴被旋转，如52所示。从局部坐标轴转换到全局坐标轴的旋转量可以由在RotationBox语法结构中指示的旋转角度来指定。单位球体的局部坐标轴是已被旋转的坐标系的轴。RotationBox的缺失可以表明局部坐标轴与全局坐标轴相同。

操作C：如54所示，然后，旋转后的单位球面上的球面图片被转换为二维投影图片，例如使用等距柱状投影。当应用立体内容的空间打包时，两个视图的两个球形图片被转换为两个组分图片，然后，帧打包被应用以将两个组分图片打包成一个投影图片。

操作D：可以应用矩形按区域打包以从投影图片获取打包图片。54和56中示出了一个打包示例。54中的虚线矩形指示投影图片上的投影区域，56中的相应区域指示对应打包区域。在该示例中，投影区域1和3被水平下采样，而投影区域2保持其原始分辨率。

CoverageInformationBox语法结构可以用于指示球体的哪个部分被打包图片覆盖。

为了将打包图片的样本位置(诸如56中的样本位置)映射到50所示的渲染中使用的单位球体，OMAF播放器可以执行以下有序操作：

-打包图片(诸如56中的打包图片)是从视频轨道或图像项中解码图片的结果。

-如果需要，打包图片的色度样本阵列可以被上采样到打包图片的亮度样本阵列的分辨率，并且还可以执行色彩空间转换。

-如果按区域打包被指示，则打包图片的样本位置被转换为相应投影图片的样本位置，诸如54中的样本位置。否则，投影图片与打包图片相同。

-如果投影图片的空间帧打包被指示，则投影图片的样本位置被转换为投影图片的相应组分图片的样本位置。否则，投影图片的构成图片(constituent picture)与投影图片相同。

-投影图片的组分图片的样本位置被转换为相对于局部坐标轴的球坐标，如针对所使用的全向投影格式所指定的。结果样本位置(resulting sample locations)对应于52所示的球体图片。

-如果旋转被指示，则相对于局部坐标轴的球坐标被转换为相对于全局坐标轴的球坐标。否则，全局坐标轴与局部坐标轴相同。

为了降低VR视频的流传输比特率，可以引入视口相关递送，其中覆盖主要视口(例如，当前视图方向)的360度视频内容的子集以最佳质量/分辨率被传输，而360度视频的其余部分以较低质量/分辨率被传输。在视口特定编码/打包中，360度图像内容被打包到同一帧中，并且强调主视口(例如，空间区域更大)。针对不同主要视口取向和/或FOV创建内容的若干版本。视口特定编码/打包可以通过非对称投影(又称为视口相关投影)来实现，其中视口区域以最高采样密度被编码，并且360°场景的其余部分以使得采样密度从视口到非视口区域逐渐减小的方式被投影。重投影非视口区域被打包到与视口区域相同的图像平面中。在按区域混合质量方法中，视口区域以最高图像质量被编码，而其他区域以较低质量被编码。在按区域混合分辨率方法中，视口无关投影被应用，并且所投影的2D图片在其编码之前按区域被重新采样使得视口源自最高2D分辨率并且其他区域源自较低2D分辨率。

在基于图块的视口相关流传输方法中，投影图片被分区成被编码为运动受限图块集(MCTS)的图块。基于图块的视口自适应流传输媒体方案可以分类如下：

1.按区域混合质量(RWMQ)360°视频：内容的若干版本使用MCTS在同一图块网格上被编码，每个版本具有不同比特率和图片质量。播放器在MCTS的基础上选择接收哪个版本，使得覆盖视口的MCTS的质量高于接收到的其他MCTS的质量。

2.视口+360°视频：接收完整低分辨率全向图片的MCTS和覆盖视口的高分辨率图块。

3.按区域混合分辨率(RWMR)360°视频：图块以多个分辨率被编码。播放器选择覆盖视口的高分辨率图块和其余区域的低分辨率图块的组合。

无论正在使用的是客户端驱动比特流重写(又称为后期绑定)还是作者驱动图像分段(例如，MCTS)合并(又称为早期绑定)(诸如提取器驱动子图片轨道合并)，都可以应用所有这些方法。在后期绑定中，播放器选择要接收的MCTS序列，根据需要选择性地重写所接收的视频数据的部分(例如，可能需要重写参数集和切片分段报头)以将所接收的MCTS组合成单个比特流，并且将单个比特流解码。早期绑定是指使用作者驱动信息来根据需要重写所接收的视频数据的部分，以将MCTS合并为要解码的单个比特流，并且在某些情况下用于选择要接收的MCTS序列。早期绑定与后期绑定之间可以存在一些方法：例如，可以让播放器在没有作者指导的情况下选择要接收的MCTS序列，而作者驱动的方法用于MCTS合并和报头重写。早期绑定方法包括提取器驱动方法和图块跟踪方法，随后将对这些方法进行描述。在所有这些方法中，图块(或它们的保护带)可以以在预处理或编码中所选择的量重叠。

在图块轨道方法中，从比特流中提取一个或多个运动受限图块集序列，并且每个所提取的运动受限图块集序列作为图块轨道(例如，HEVC图块轨道)存储在文件中。图块基础轨道(例如，HEVC图块基础轨道)可以被生成并且存储在文件中。图块基础轨道通过从图块轨道隐式收集运动受限图块集来表示比特流。图块轨道可以用于如下的视口相关流传输：在接收器侧，可以基于查看取向来选择要流传输的图块轨道。客户端可以接收覆盖整个全向内容的图块轨道。与覆盖其余360度视频的质量或分辨率相比，针对当前视口可以接收质量更好或分辨率更高的图块轨道。图块基础轨道可以包括对图块轨道的轨道引用，和/或图块轨道可以包括对图块基本轨道的轨道引用。例如，在HEVC中，'sabt'轨道参考用于从图块基础轨道引用图块轨道，并且图块排序由'sabt'轨道参考所包含的图块轨道的顺序指示。此外，在HEVC中，图块轨道具有对图块基础轨道的'tbas'轨道参考。

当提取器由需要提取器的文件读取器处理时，提取器在逻辑上被替换为在按其出现顺序分解(resolve)所包含的构造器时产生的字节。在一些实施例中，可能不允许嵌套提取，例如，样本构造器引用的字节可以不包含提取器；并且提取器不得直接或间接引用另一提取器。提取器可以包含一个或多个构造器，构造器用于从当前轨道或通过'scal'类型的轨道引用链接到提取器所在轨道的另一轨道提取数据。

在一个示例中，所分解的提取器的字节是以下之一：

a)一个完整NAL单元；注意，当引用聚合器(Aggregator)时，所包括的字节和所参考的字节都会被复制

b)一个以上的完整NAL单元

在两种情况下，所分解的提取器的字节都以有效长度字段和NAL单元报头开始。

样本构造器的字节仅从通过所指示的'scal'轨道参考所参考的轨道中的单个标识样本来复制。对准是在解码时间上进行的，例如，仅使用时间-样本表格(time-to-sampletable)，然后是采样数中的计数偏移。提取器是媒体级别的概念，因此在考虑任何编辑列表之前应用于目的地轨道。很多时候，两个轨道中的编辑列表是相同的。可以使用以下语法：

NALUnitHeader()是HEVC NAL单元的前两个字节。特定nal_unit_type值指示提取器，例如，nal_unit_type等于49。constructor_type指定正在使用的构造器。EndOfNALUnit()是一个函数，当该提取器中有更多数据时，该函数返回0(假)；否则，返回1(真)。示例构造器(SampleConstructor)可以具有以下语法：

track_ref_index标识从中提取数据的源轨道。track_ref_index是'scal'类型的轨道参考的索引。第一轨道参考的索引值为1；值0被保留。从中提取数据的轨道中的样本在时间上对准或在媒体解码时间线中是最接近的在前样本，例如，仅使用时间-样本表格，被调节由sample_offset指定的偏移，其中样本包含提取器。sample_offset给出可以用作信息源的所链接的轨道中样本的相对索引。与包含提取器的样本的解码时间相比，样本0(零)是具有相同或最接近的在前解码时间的样本；样本1(一)是下一样本，样本-1(负1)是前一样本，以此类推。data_offset是要复制的参考样本中第一字节的偏移。如果提取从该样本中数据的第一字节开始，则偏移取值为0。data_length是要复制的字节数。

内联构造器的语法可以如下指定：

长度是属于在该字段之后的InlineConstructor的字节数。inline_data是在分解内联构造器时要返回的数据字节。

在提取器驱动方法中，从比特流中提取一个或多个运动受限图块集序列，并且所提取的每个运动受限图块集序列被修改以成为其自身的兼容比特流(例如，HEVC比特流)并且作为子图片轨道存储在文件中(例如，对于HEVC，具有未变换的样本条目类型'hvc1')。一个或多个提取器轨道(例如，HEVC提取器轨道)可以生成并且存储在文件中。提取器轨道通过从子图片轨道中显式地提取(例如，通过HEVC提取器)运动受限图块集来表示比特流。在接收器侧，可以基于查看取向来选择要流传输的子图片轨道。客户端可以接收覆盖整个全向内容的子图片轨道。与覆盖其余360度视频的质量或分辨率相比，可以为当前视口接收更好质量或更高分辨率的子图片轨道。

需要理解，尽管详细描述了图块轨道方法和提取器驱动方法，特别是在HEVC的上下文中，但它们也适用于其他编解码器和与图块轨道或提取器类似的概念。此外，图块轨道和提取器驱动方法也可以组合或混合。例如，这种混合可以基于图块轨道方法，但图块基础轨道可以包含用于客户端的重写操作的指导，例如，图块基础轨道可以包括重写切片或图块组报头。

作为基于MCTS的内容编码的替代物，如下所述，可以使用基于子图片的内容创作来实现用于基于图块的视口相关流传输的内容创作。预处理(在编码之前)包括将未压缩图片分区为子图片。同一未压缩子图片序列的若干子图片比特流被编码，例如以相同分辨率、但不同的质量和比特率被编码。编码可以以使得能够将经编码的子图片比特流合并到表示全向视频的兼容比特流的方式被约束。例如，通过以在帧间预测过程中不会参考图片外的样本位置的方式选择运动矢量，可以在编码中避免对解码图片边界之外的样本的依赖性。每个子图片比特流可以封装为子图片轨道，并且可以附加地形成合并不同子图片位置的子图片轨道的一个或多个提取器轨道。如果以基于图块轨道的方法为目标，则每个子图片比特流被修改以成为MCTS序列并且作为图块轨道存储在文件中，并且针对图块轨道创建一个或多个图块基础轨道。

例如取决于播放器在其中运行的设备和操作系统的能力，基于图块的视口相关流传输方法可以通过执行单个解码器实例或每个MCTS序列一个解码器实例(或在某些情况下，介于这两者之间，例如具有相同分辨率的每个MCTS一个解码器实例)来实现。单个解码器实例的使用可以通过后期绑定或早期绑定来启用。为了促进多个解码器实例，提取器驱动方法可以使用符合编码格式或标准的子图片轨道而无需修改。其他方法可能需要在客户端侧重写图像分段报头、参数集和/或类似信息以构造合规比特流或者具有能够在不存在其他编码视频数据的情况下对MCTS序列进行解码的解码器实现。

在图块轨道方法和提取器驱动方法中可以存在至少两种方法分别用于封装和参考图块轨道或子图片轨道：

从图块基础轨道或提取器轨道参考轨道标识符。

从图块基础轨道或提取器轨道参考图块组标识符，其中由图块组标识符标识的图块组包含并置图块轨道(collocated tile track)或作为所提取的替代物的子图片轨道。

在RWMQ方法中，每个图片大小和每个图块网格有一个提取器轨道就足够了。在360°+视口视频和RWMR视频中，每个不同查看取向可能需要一个提取器轨道。

标识出的媒体数据框可以具有与MediaDataBox相同的语义，但它另外包含用于设置对所包含的媒体数据的数据参考的标识符。标识符可以例如是标识出的媒体数据框包含的第一元素。标识出的媒体数据框的语法可以如下指定，其中imda_identifier是框的标识符。注意，虽然在语法中使用64位无符号整数类型的imda_identifier，但其他字段长度和其他基本数据类型(例如，字符串)同样是可能的。下面提供示例标识元数据框：

本文中称为DataEntryImdaBox的框可以用于参考标识出的媒体数据框中的数据。DataEntryImdaBox标识包含通过与该DataEntryImdaBox相对应的data_reference_index而访问的媒体数据的IdentifiedMediaDataBox。DataEntryImdaBox包含所引用的IdentifiedMediaDataBox的imda_identifier的值。媒体数据偏移与所引用的IdentifiedMediaDataBox的有效载荷的第一字节有关。换言之，媒体数据偏移0指向所引用的IdentifiedMediaDataBox的有效负载的第一字节。样本条目包含data_reference_index，data_reference_index标识DataReferenceBox的哪个数据参考用于包含参考样本条目的样本。当IdentifiedMediaDataBox用于包含样本时，data_reference_index被设置为指向DataEntryImdaBox的值。DataEntryImdaBox的语法可以如下指定，其中imda_ref_identifier提供imda_identifier值，并且从而标识特定的IdentifiedMediaDataBox：

在一个示例中，确定(子)分段或影片片段的标识出的媒体数据框的标识符值，并且该标识符值被提供作为(子)分段或影片片段的媒体数据的数据参考基础。在一个示例中，用于标识出的媒体数据框的标识符的模板方案被定义为用作样本数据的数据参考，例如在DataReferenceBox中。模板方案可以基于但不限于影片片段序号(诸如MovieFragmentHeaderBox的sequence_number字段)或轨道片段解码时间(诸如TrackFragmentBaseMediaDecodeTimeBox的baseMediaDecodeTime字段)。需要理解，除了或代替上述那些，针对影片片段或轨道片段而提供的任何标识符可以适用于模板方案。在一个示例中，可以使用以下语法来使用用于导出标识符的模板来参考标识出的媒体数据框。

aligned(8)class DataEntryTfdtBasedImdaBox(bit(24)flags)

extends FullBox(′imdt′，version＝0，flags){}

DataEntryTfdtBasedImdaBox标识包含通过与该DataEntryTfdtBasedImdaBox相对应的data_reference_index而访问的媒体数据的IdentifiedMediaDataBox。媒体数据偏移0指向imda_identifier等于TrackFragmentBaseMediaDecodeTimeBox的baseMediaDecodeTime的IdentifiedMediaDataBox的有效载荷的第一字节。在一个实施例中，使用64位imda_identifier值以承载(carry)baseMediaDecodeTime的64位值。如果使用32位baseMediaDecodeTime值，则64位imda_identifier的最高有效位可以设置为0。对于自包含影片片段，当所参考的数据参考条目的类型为DataEntryTfdtBasedImdaBox时，要求IdentifiedMediaDataBox的imda_identifier等于TrackFragmentBaseMediaDecodeTimeBox的baseMediaDecodeTime。

在另一示例中，可以使用以下语法来使用用于导出标识符的模板来引用标识出的媒体数据框。

aligned(8)class DataEntrySeqNumImdaBox(bit(24)flags)

extends FullBox(′snim′，version＝0，flags){}

DataEntrySeqNumImdaBox标识包含通过与该DataEntrySeqNumImdaBox相对应的data_reference_index而访问的媒体数据的IdentifiedMediaDataBox。当样本条目中包含的data_reference_index引用DataEntrySeqNumImdaBox时，引用样本条目的每个样本被包含在影片片段中，并且媒体数据偏移0指向imda_identifier等于包含样本的影片片段的MovieFragmentHeaderBox的sequence_number的IdentifiedMediaDataBox的有效载荷的第一字节。

在确定影片片段的(多个)轨道的(多个)基本数据偏移时，不需要知道MovieFragmentBox的大小，并且因此，MovieFragmentBox的子框(例如，TrackFragmentHeaderBox和TrackRunBoxes)可以在影片片段的所有编码媒体数据可用之前被“逐步”创作。此外，内容封装器不需要正确估计分段报头的大小，并且具有分段持续时间的一些动态可变性的灵活性。

在一些实施例中，通过编译指示用于分段报头和对应分段有效载荷的单独统一资源定位符(URL)的流传输清单，可以使媒体分段报头和分段有效载荷单独可用。诸如DASH媒体呈现描述(MPD)等流传输清单可以提供URL模板，或者用于附加在MPD中给出的基本URL的URL模板方案可以被指示为是适用的。在一些实施例中，流传输清单还可以指示分段有效载荷中的数据按解码顺序被紧密地打包。分段有效载荷可以是指例如MediaDataBox。紧密打包是指属于视频比特流的分段有效载荷的所有字节，例如，分段有效载荷由视频比特流的多个连续字节组成。例如，这样的指示可以被提供作为DASH MPD中的补充属性。分段有效载荷中的视频比特流可以是封装视频比特流。例如，分段有效载荷可以由ISOBMFF文件的视频轨道的一组连续样本组成。

索引分段可以定义为主要包含媒体分段的索引信息的分段。MPD可以提供指示可以用于获取索引分段的URL的信息。信息的示例如下：

-SegmentBase元素中的RepresentationIndex元素指定URL，包括表示索引分段的可能字节范围。

-SegmentList元素包括多个SegmentURL元素，这些元素可以包括媒体分段的URL(在@media属性中)、由@media属性的URL标识的资源内的字节范围、索引分段的URL(在@index属性中)、和/或由@index属性的URL标识的资源内的字节范围。@media属性中的URL与@mediaRange属性(如果存在)相结合指定媒体分段的HTTP-URL。@index属性中的URL与@indexRange属性(如果存在)相结合指定索引分段的HTTP-URL。

-SegmentTemplate元素的@index属性指定用于创建索引分段列表(IndexSegment List)的模板。分段模板包括字符串，从该字符串可以导出分段列表(由其URL标识)。分段模板可以包括由分配给分段的动态值替换以创建分段列表的特定标识符。

每个分段可以分配有可以在明确声明的索引分段中提供的分段索引信息。例如，显式索引分段信息的存在可以通过以下任何一项来指示：

-存在一个RepresentationIndex元素为整个表示提供分段索引，或

者

-在SegmentList.SegmentURL元素中存在@index和@indexRange两个属性中的至少一个，或者

-存在[email protected]属性。

@indexRange属性也可以用于为媒体分段内的索引提供字节范围，这是媒体分段格式所允许的。在这种情况下，@index属性不存在，并且指定范围完全位于为媒体分段而指定的任何字节范围内。索引分段的可用性可以与它们所对应的媒体分段的可用性相同。

为了有效地实现具有后期绑定的视口相关流传输，优选利用每个(子)分段的一个请求来取回所有可用轨道的所有影片片段报头。客户端中影片片段报头的可用性使用关于图片粒度的编码图片数据的字节范围促进HTTP GET请求，从而可以减少质量切换的延迟。然而，当前，没有与DASH信令或DASH概念兼容的解决方案。

首先，在DASH MPD中没有机制来与相应媒体数据分开地宣布(子)分段报头的URL。(子)分段报头包括(多个)影片片段报头，即，(多个)MovieFragmentBox，并且相应媒体数据可以包括(多个)MediaDataBox和/或包含在其中的媒体数据。其次，MPEG文档N18235中提出的后期绑定方法包括(多个)MovieFragmentBox(被包含在MetaBox的DataInformationBox的DataReferenceBox中)内的媒体数据的URL，其具有以下缺点：

-通过不同服务器和内容递送网络(CDN)进行内容递送很困难，因为如果内容被移动到新服务器或CDN，则需要改变MovieFragmentBox。

-无法处理多服务器/多CDN递送，因为只能使用一个URL。(相反，DASH MPD可以列出同一内容的多个基本URL。)

-它与ISOBMFF不兼容，因为轨道的数据参考被承载在TrackBox的MediaBox的MediaInformationBox的DataInformationBox的DataReferenceBox中。TrackFragmentHeaderBox和TrackExtendsBox的sample_description_index字段是指在TrackBox中包含的DataReferenceBox中给出的数据参考的索引列表。

根据DASH标准的当前版本，DASH表示的媒体分段中包括的(子)分段报头元数据(例如，MovieFragmentBoxes)对应于同一DASH表示中包括的媒体数据。然而，在后期绑定的情况下，元数据应当对应于接收到的媒体数据的超集，因为元数据描述所有可用轨道，而只有媒体数据的子集被接收到。尚未提出处理所有可用轨道的(子)分段元数据和轨道子集的(子)分段媒体数据的获取的机制。因此，需要更好的后期绑定机制。

在一些实施例中，编码器可以获取具有图块轨道的文件或(多个)初始化和媒体分段。编码器可以将每个图块轨道编码为表示，并且将并置图块轨道的每组表示编码为适配集。编码器可以生成包括图块轨道的分段元数据的(多个)索引分段。对于基本轨道，编码器还可以获取包括(多个)图块基础轨道的文件或(多个)初始化和媒体分段。编码器可以将图块基础轨道编码为表示，并且将表示编码为它自己的适配集。在表示和适配集被编码之后，编码器可以进行媒体表示描述和分段创作。

在一些实施例中，编码器可以将指示(多个)索引分段的(多个)URL的信息编码到MPD中。在一些实施例中，编码器可以将指示特定于个体表示的(多个)媒体分段的(多个)URL的信息编码到MPD中。(多个)索引分段还可以包括(多个)图块基础轨道的信息。指示特定于(多个)图块基础轨道的(多个)表示的(多个)媒体分段的(多个)URL的信息也可以被编码到MPD中。并置图块轨道的例如不同比特率的若干版本可以通过以下方式来处理：在文件中或在指示轨道组的(多个)初始化分段信息中进行编码，使得每组并置图块轨道形成轨道组(例如，'alte'类型)；并且从来自图块基础轨道的轨道参考来参考轨道组。参考轨道组意味着，轨道组中的一个轨道将被选择用于基于区块基础轨道重构比特流。

图6示出了由例如图1的装置10所实施的编码器执行的媒体呈现描述和分段创作的过程。如框60所示，诸如图1的装置10等装置包括用于将第一信息项编码到媒体描述中的诸如处理电路系统12等部件，第一信息项指示一组表示的分段元数据的第一定位符。在一些实施例中，第一信息项包括标识基于ISOBMFF的媒体分段的(多个)索引分段的信息。(多个)索引分段描述轨道集合的一个或多个分段(例如特定媒体内容的所有图块轨道中的分段)，并且可能还描述相应的(多个)图块基础轨道。在一些实施例中，媒体描述符合DASHMPD。

如框62所示，诸如图1的装置10等装置包括用于将一个或多个表示特定信息项编码到媒体描述中的诸如处理电路系统12等部件，该一个或多个表示特定信息项指示该组表示中的一个或多个表示的分段媒体数据的(多个)表示特定定位符。在一些实施例中，在MPD中，指示包含要成为预选的主适配集的图块基础轨道的适配集的信息也被编码。在一些实施例中，在MPD中，指示适配集和包含要被包括在预选中的图块轨道的表示的信息也被编码。在一些实施例中，指示预选的适配集(例如，预选的主适配集)的(多个)索引分段的描述在同一预选的适配集的表示中所承载的轨道的信息也被编码在MPD中。MPD中可以包括附加指示以指示索引分段覆盖整个预选，而不仅仅是主适配集的表示。在一些实施例中，表示特定信息项包括标识基于ISOBMFF的媒体分段的(多个)媒体分段的信息。在一些实施例中，(多个)基于ISOBMFF的媒体分段包括没有ISOBMFF元数据的媒体数据。在一些实施例中，(多个)基于ISOBMFF的媒体分段包括ISOBMFF的(多个)IdentifiedMediaDataBox。

如框64所示，诸如图1的装置10等装置包括用于引起媒体描述与该组表示被一起存储的诸如处理电路系统12和存储器14等部件。

在一些实施例中，分段元数据包括影片片段报头，例如(多个)MovieFragmentBox，并且可以包括以下中的零个或多个：(多个)SegmentTypeBox、(多个)SegmentIndexBox、(多个)SubsegmentIndexBox和/或(多个)ProducerReferenceTimeBox。

图7A和7B示出了可以与例如DASH实时服务利用相结合使用的示例索引分段和媒体分段。例如，考虑具有2个子图片作为不同适配集的表示，每个适配集具有2个表示，其特征如下：

-DASH周期

о适配集_1

表示_1(承载图块轨道轨道_1)

表示_2(承载图块轨道轨道_2)

о适配集_2

表示_3(承载图块轨道轨道_3)

表示_4(承载图块轨道轨道_4)

о适配集_3

表示_5(承载图块基本轨道轨道_5)

图7A中示出了用于示例呈现的索引分段。图7B中示出了示例呈现的媒体分段。每个图示的'imda'框都封装在单独的媒体分段中，该媒体分段具有可以从MPD中导出的URL。影片片段序列号可以是唯一的并且可以用作IdentifiedMediaDataBoxes内的标识符。在初始化分段中，DataEntrySeqNumImdaBox被包括在数据参考条目中。TrackFragmentHeaderBoxes和/或TrackExtendsBoxes使用参考DataEntrySeqNumImdaBox的数据参考条目的示例描述条目。轨道标识符值也是唯一的。

在一个实施例中，SegmentIndexBox的reference_type的语义如下指定：reference_type等于1指示参考的是SegmentIndexBox或MovieFragmentBox(被包含在与包含reference_type的SegmentIndexBox相同的分段中)。reference_type等于0指示参考的是媒体分段(可能不包含MovieFragmentBoxes)内参考的子分段的第一框(诸如IdentifiedMediaDataBox或MediaDataBox)的开始。替代地，可以指定reference_type等于0表示参考的是媒体分段内参考的子分段的第一媒体数据框(诸如IdentifiedMediaDataBox或MediaDataBox)的开始，而不管子分段的第一媒体数据框是否为子分段的第一框。上述reference_type的语义可以被文件写入器和/或文件读取器和/或另一实体有条件地使用，其中该条件可以是但不限于以下一项或多项：

-包含reference_type的SegmentIndexBox被包括在索引分段中。

-SegmentIndexBox的框报头标志中的预定义标志等于1。

-SegmentIndexBox的框报头中的预定义版本(或版本值范围)。

-预定义印记(brand)被包括在FileTypeBox和/或TrackTypeBox中。

在一个实施例中，当上述条件不满足时，文件写入器和/或文件读取器和/或另一实体使用如当前在ISOBMFF中指定的且如本文档中别处描述的reference_type的语义。

在一个实施例中，文件写入器或另一实体创建具有(多个)SegmentIndexBox和(多个)MovieFragmentBox的索引分段，并且在指向索引分段中的MovieFragmentBox的SegmentIndexBox中包括等于1的reference_type。

在一个实施例中，文件读取器或另一实体完全或部分地解析索引分段(IndexSegment)。作为该索引分段解析的一部分，文件读取器或另一实体从索引分段中包含的SegmentIndexBox中解析出等于1的reference_type，其中等于1的reference_type指向索引分段中的MovieFragmentBox。在一个实施例中，文件读取器或另一实体推断(conclude)或估计等于1的reference_type的哪些实例指向SegmentIndexBox而哪些实例指向MovieFragmentBox。该结论可以基于所有SegmentIndexBox在索引分段中的所有MovieFragmentBox之前的知识(例如，标准中的要求或解析出的指示)得出。这样，通过推断或估计对索引分段内的最后SegmentIndexBox或第一MovieFragmentBox的参考，就可以知道后续参考的都是MovieFragmentBoxes。例如，文件读取器或另一实体可以在索引分段内按参考的出现顺序解析之，直到找到第一MovieFragmentBox。因此，文件读取器或另一实体可以选择要请求和/或处理的MovieFragmentsBox的子集。因此，可以仅取回索引分段的所选择的MovieFragmentBoxes，并且因此可以使用较小比特率来提取索引分段。

当媒体分段包含一个以上的IdentifiedMediaDataBox(例如，每个子分段一个)时，DASH客户端可能会针对IdentifiedMediaDataBoxes的子集(例如，仅某些子分段)或甚至一个特定的IdentifiedMediaDataBox的一部分(例如，仅从随机访问图片开始的某些编码图片)发出字节范围请求。在这点上，示例实施例被配置为指示(在内容创作中)和/或解析(在客户端中)个体IndentifiedMediaDataBox的(多个)字节范围，包括：

1.具有referenced_size且reference_type等于0的SegmentIndexBox指示每个子分段的'imda'框的大小。图8以图形方式示出了选项1。图8所示的示例可以与DASH按需简档使用结合使用。

a.在一些实施例中，分段被创作以遵守如下这样的约束：reference_type等于0的循环条目可以紧跟在reference_type等于1的循环条目之前，并且该循环条目可以指向'moof'框(或除'sidx'之外的可以启动子分段的元数据的某个其他框)。在一些实施例中，解析利用该约束来推断'sidx'框的哪些参考指向'moof'框。

2.单独例如通过使用以下语法结构中的任何一种来指示媒体分段的字节范围索引：

a.索引分段格式中包括的BoxFileIndexBox(fidx)，用于指示相应(时间对准)媒体分段的结构。

·因为不同表示的媒体分段可以被包括在不同文件/资源中(例如，可以使用不同URL来获取它们)也可以不被包括在不同文件/资源中，所以BoxFileIndexBox与正确媒体分段的关联应当是明确的。这可以通过以下方法中的任何一种来进行：

i.'fidx'框的新容器框被定义，并且承载相关媒体分段中承载的(多个)轨道ID：

ii.框顺序可以指定关联。例如，BoxFileIndexBox可以与紧随其后的'sidx'或'moof'框相关联，并且可以描述承载由相关联的'sidx'或'moof'框所描述的轨道的文件。

可以指定无BoxFileIndexBox以指示媒体分段承载单个'imda'框b.作为'moof'框的子框或在'moof'框旁边被包括的(新)字节范围框。字节范围框可以包括所有'imda'框的字节范围和/或大小。

c.作为'moof'框的子框或在'moof'框旁边被包括的BoxIndexBox；

定义其语义以指示媒体分段的相应子分段的框索引。

d.在SegmentIndexBox中单独指示的MovieFragmentBoxes和媒体数据框(例如，IdentifiedMediaDataBoxes)的偏移和/或字节范围和/或字节计数。

在属于上述类别d的实施例中，针对SegmentIndexBox如下指定：SegmentIndexBox的框标志中的预定义标志被指定，当等于1时，指示对于在SegmentIndexBox中具有等于0的reference_type的每个条目，在SegmentIndexBox中存在媒体数据的偏移或字节范围或字节计数。另一预定义标志或SegmentIndexBox的框标志中的相同标志被指定，当等于1时，指示媒体数据的字节计数的偏移或字节范围与包含SegmentIndexBox的资源不同的资源(例如，没有SegmentIndexBoxes或MovieFragmentBoxes的媒体分段)相关。例如，可以使用以下语法：

media_data_offset指定到所参考的MediaDataBox或子分段的IdentifiedMediaDataBox的开始的偏移。如果(flags&8)等于0，则偏移是相对于子分段的开始的，即，在SegmentIndexBox的第一循环中由等于0的相应reference_type指示的MovieFragmentBox。否则，偏移是相对于包含所参考的MediaDataBox或IdentifiedMediaDataBox的媒体分段的开始的。偏移可以以字节为单位来指示。需要理解，虽然上面参考偏移描述了实施例，但是它同样可以通过在语法中除了偏移之外还包括字节计数或结束偏移来应用于字节范围。同样，该实施例同样可以应用于字节计数而不是偏移，因此文件读取器或另一实体(在同一循环中)可以导出偏移作为先前偏移的总和。

如果使用选项1，则包括解码器的客户端设备可以被配置为取回索引分段的初始部分(包含'sidx'框)。因为索引分段是在子分段基础上交错的，所以它可以使用字节范围(从'sidx'框中找到)按子分段被请求。客户端设备还可以被配置为取回(多个)所选择的媒体分段的(多个)所选择的子分段，对于这些子分段，相应'imda'框的(多个)字节范围是从相应'sidx'框中包括的reference_type 0的参考中获取的。

应当理解，由于(多个)媒体分段的URL与MPD中的(多个)索引分段的URL分开指示，因此它们在逻辑上驻留在不同文件或资源中。因此，(多个)索引分段中承载的分段报头在逻辑上位于与媒体数据不同的文件中。因此，SegmentIndexBoxes中参考类型为1的条目在索引分段中，并且参考类型为0的条目在媒体分段中，其中相对于媒体分段本身的字节偏移在SegmentIndexBoxes中指示。由于DASH MPD允许对HTTP URL使用字节范围，因此(多个)索引分段和(多个)媒体分段可以物理地驻留在同一文件中，并且仅具有在MPD中指示的不同字节范围。然而，即使在这种情况下，(多个)索引分段和(多个)媒体分段在逻辑上仍然位于不同文件或资源中，并且在SegmentIndexBoxes中提供的偏移的解释保持不变。

上面已经描述了这样的实施例，其中每个轨道存在一个或多个SegmentIndexBox。这种轨道特定SegmentIndexBoxes可能是不必要的，因为所有图块轨道和图块基础轨道通常共享相同属性，诸如SAP位置。可以通过避免轨道特定SegmentIndexBox来实现字节数节省。此外，轨道特定SegmentIndexBoxes可能需要约束，例如在标准中，以用于不同轨道的SegmentIndexBoxes的排序和/或交错。根据一个实施例，轨道以以下布置共享相同的一个或多个SegmentIndexBox：

-使用SubRepresentation，每个SubRepresentation对应于不同轨道。

-SubsegmentIndexBoxes出现在分段报头中(在索引媒体数据的对应SegmentIndexBoxes旁边)。

-LevelAssignmentBox存在于初始化分段中，并且指示基于轨道的级别分配，即，从针对级别而指示的特征到所指示的轨道的映射。

因此，对于图块基础轨道和由图块基础轨道参考的所有图块轨道，可以存在单个表示。当图块基础轨道包括对轨道组的轨道参考(例如，'alte'类型)时，单个表示中可以存在不同版本的并置图块轨道(例如，比特率和/或质量不同)。

在一个实施例中，每个子分段存在单个MovieFragmentBox，并且MovieFragmentBox包括用于表示中的每个轨道的TrackFragmentBox。客户端可以如其他实施例中描述的那样解析与MovieFragmentBox相对应的IdentifiedMediaDataBox的字节范围，或者可以断定整个资源(由URL标识)对应于IdentifiedMediaDataBox。客户端确定哪些轨道被接收，例如基于当前视口并且得出对应SubRepresentation、级别和轨迹。所选择的轨道的TrackFragmentBoxes中的字节偏移是相对于与MovieFragmentBox相对应的IdentifiedMediaDataBox的开头的。因此，TrackFragmentBoxes中的字节偏移可以与URL和IdentifiedMediaDataBox的字节范围的潜在起始字节偏移一起使用，以确定请求哪些字节范围来取回所选择的轨道的媒体数据。

在一些实施例中，代替使用(多个)IdentifiedMediaDataBox，可以定义和使用新类型的数据参考：“外部提供的URL”(externally provided URL)。如果不将该URL提供给文件读取器，则无法处理文件。给定URL可以在轨道片段的基础上改变。基于ISOBMFF的媒体分段可以只包含(多个)MediaDataBox、(多个)IdentifiedMediaDataBox、或未封装在(多个)框中的媒体数据。媒体分段类型、简档等可以指示正在使用哪种类型的媒体分段。媒体分段URL可以从MPD中标识并且被提供给文件读取器。文件读取器可以应用从(多个)SegmentIndexBox和/或(多个)MovieFragmentBox中获取的字节偏移，该字节偏移是相对于由提供给文件读取器的URL标识的资源的开始的。SegmentIndexBox中引用类型为0的条目可以被指定为在媒体文件中，例如，由提供给文件读取器的URL标识的资源。

在一些实施例中，索引分段由索引分段中包括的SegmentTypeBox('styp')中的特定四字符代码标识。在一些实施例中，根据其他实施例的媒体分段由媒体分段中的SegmentTypeBox('styp')中包括的特定四字符代码标识。接收器、文件读取器等可以基于所接收的针对SegmentTypeBox的特定四字符代码来识别出其需要如在其他实施例中描述的那样处理(多个)分段。

在一些实施例中，索引分段格式如下指定，但是需要理解，可以同样地创建具有在其他实施例中描述的特征的关于索引分段格式的其他类似实施例。每个索引分段可能需要以'styp'框开始，并且在'styp'框中可能需要存在特定印记(例如，'sibm')。这种格式的索引分段布置如下：所有SegmentIndexBoxes在所有MovieFragmentBoxes之前。当索引分段描述若干轨道时，所有轨道的分段是对准的，并且同一对准分段的所有MovieFragmentBox在索引分段中是连续的，即，不与任何其他子分段的任何MovieFragmentBox交错。每个轨道的MovieFragmentBoxes以递增的时间顺序出现。MovieFragmentBoxes使用参考DataEntrySeqNumImdaBox的示例条目。索引分段要么与单个媒体分段相关联，要么与所有媒体分段相关联。索引分段可以包含SubsegmentIndexBoxes。预选(Preselection)的主适配集的表示的索引分段提供预选的所有表示的分段索引。

在一个实施例中，文件写入器或另一实体以使得同一轨道或相同轨道在索引分段的每个子分段的第一MovieFragmentBox中被一致地描述的方式写入索引分段。因此，当使用SegmentIndexBox('sidx')来描述子分段时，应用于子分段的第一MovieFragmentBox的referenced_size(在'sidx'框中)指示子分段的所有MovieFragmentBoxes的集体大小。在一个实施例中，文件写入器或另一实体在文件中(例如，在SegmentIndexBox中使用等于1的预定义框标志)或沿文件(例如，在MPD中)指示同一轨道或相同轨道在索引分段的每个子分段的第一MovieFragmentBox中被一致地描述。

在一个实施例中，文件读取器或另一实体推断出同一轨道或相同轨道在索引分段的每个子分段的第一MovieFragmentBox中被一致地描述。在一个实施例中，该推断基于从文件(例如，从在SegmentIndexBox中等于1的预定义框标志)或沿文件(例如，从MPD)读取以下指示：同一轨道或相同轨道在索引分段的每个子分段的第一MovieFragmentBox中被一致地描述。在一个实施例中，例如在标准中预先定义同一轨道或相同轨道在索引分段的每个子分段的第一MovieFragmentBox中被一致地描述，因此该推断基于以下结论：文件、表示等符合其中已经进行了该预定义的标准(等)。在一个实施例中，已经得出结论，同一轨道或相同轨道在索引分段的每个子分段的第一MovieFragmentBox中被一致地描述，文件读取器或另一实体发出单个HTTP GET请求，该请求的字节范围从referenced_size字节中导出以取回子分段的所有MovieFragmentBoxes。因此，为了取回子分段的所有MovieFragmentBox，文件读取器或另一实体无需推断或请求多个字节范围。

在一些实施例中，如下指定索引分段格式，但是需要理解，可以同样地创建具有在其他实施例中描述的特征的关于索引分段格式的其他类似实施例。每个媒体分段可能需要以'styp'框开始，并且在'styp'框中可能需要存在特定印记(例如，'imds')。这种格式的媒体分段在一个或多个IdentifiedMediaDataBox中包含媒体数据(并且可能不允许在其他框中包含媒体数据)。

图9A和9B示出了由例如图1的装置10所实施的回放设备执行的客户端设备操作的过程。如图9A的框902所示，诸如图1的装置10等装置包括诸如处理电路系统12和通信接口16等部件，这些部件用于接收指示分段或子分段元数据中到分段或子分段媒体数据的字节偏移与包含分段或子分段媒体数据的框相关的信息。在一个实施例中，该信息包括对(多个)标识出的媒体数据框的数据参考。在一个实施例中，该信息包括初始化分段，该初始化分段包括DataReferenceBox，该DataReferenceBox包括指定给标识出的媒体数据框的数据参考。数据参考可以例如是DataEntryImdaBox、DataEntryTfdtBasedImdaBox、DataEntrySeqNumImdaBox等。

如图9A的框904所示，该装置包括诸如处理电路系统12和通信接口16等部件，这些部件用于接收轨道集合的分段或子分段元数据。在一个实施例中，轨道集合的分段或子分段元数据包括索引分段。

如图9A的框906所示，诸如图1的装置10等装置包括诸如处理电路系统12等部件，该部件用于诸如通过解析分段或子分段媒体数据来确定分段或子分段媒体数据的定位符。在一个实施例中，分段或子分段媒体数据的定位符是根据DASH MPD确定的媒体分段的HTTPURL。

如图9A的框908所示，该装置包括诸如处理电路系统12等部件，该部件用于确定除定位符外是否需要字节范围以请求分段或子分段媒体数据。在一个实施例中，索引分段包括多个子分段及其字节范围的信息。因此，除了定位符(例如，HTTP URL)，还需要从索引分段推断出的字节范围以请求子分段媒体数据。

如图9B的框910中所示，该装置包括诸如处理电路系统12等部件，该部件用于在需要字节范围的情况下例如通过解析字节范围框针对轨道集合个体地从分段或子分段元数据中确定相应分段或子分段媒体数据的一个或多个字节范围部件。

如图9B的框912所示，该装置包括用于从轨道集合中选择轨道子集的诸如处理电路系统12等部件。

如图9B的框914所示，该装置包括诸如处理电路系统12和通信接口16等部件，这些部件用于通过具有相应定位符的请求接收所选择的轨道子集的分段或子分段媒体数据。

如图9B的框916所示，该装置包括诸如处理电路系统12等部件，该部件用于解析轨道子集的分段或子分段元数据以获取适合于解码分段或子分段媒体数据的解封装媒体数据。

客户端可以针对时间对准索引和媒体分段迭代地执行图9A和9B中的操作以及取回索引分段并选择从中请求和接收(多个)媒体分段的表示或轨道的操作。客户端设备还可以将索引分段和接收到的媒体分段串联，并且传递串联的分段以用于文件解析和后续解码(诸如914和916)。由于从(多个)MovieFragmentBox派生的字节偏移是相对于(多个)IdentifiedMediaDataBox的开始的，这样的串联是可能的，因此不受串联分段中存在哪些框和/或使用哪种串联顺序的影响。

图10A和10B是在客户端设备的操作中使用的索引和媒体分段的图示。例如，索引和媒体分段可以与DASH实时服务利用相结合使用。图10A示出了请求、取回和选择操作，图10B示出了重构的串联文件。

不具有相应'imda'框的'moof'框可以被移除。只要'imda'框在串联文件中在相关'moof'框之后，则串联文件中的'moof'框和'imda'的顺序可以基于内容创建者的选择进行布置。

已经关于具有后期绑定的360度3DoF视频的视口相关流描述了实施例。需要理解，实施例不限于360度视频或视口相关流。在一个实施例中，表示可以包括与6DoF视频、叠加(overlay)、视点或点云数据相关的媒体/元数据。在另一实施例中，可以通过利用如上定义的表示和适配集来流传输具有图块、具有或不具有2D/3D投影的任何2D视频媒体。具有自适应比特率逻辑的播放器将利用分段来决定下载哪个分段。

图11示出了由例如图1的装置10实施的编码器执行的媒体呈现描述和分段创作的过程。如框110所示，诸如图1的装置10等装置包括诸如处理电路系统12和通信接口16等部件，这些部件用于接收文件或初始化分段和具有一个或多个图块轨道的一个或多个媒体分段。

如框112所示，该装置包括诸如处理电路系统12等部件，该部件用于将一个或多个图块轨道编码在表示中。

如框114所示，该装置包括诸如处理电路系统12等部件，该部件用于分离分段元数据和分段媒体数据以针对一个或多个媒体分段中的每个媒体分段分离媒体分段的部分。

如框116所示，该装置包括诸如处理电路系统12等部件，该部件用于针对一个或多个媒体分段中的每个媒体分段在媒体分段内按子分段交错顺序对分段元数据进行排序。

该装置还可以包括诸如处理电路系统12等部件，该部件用于指示一个或多个媒体分段中的每个媒体分段内的按子分段和按轨道媒体数据的字节范围。图12示出了可以与DASH点播服务利用相结合使用的示例媒体分段。在所示示例中，'imda'框在轨道基础上交错。当用一个请求来请求轨道的若干连续子分段时，这可能是优选的。另一选择是在子分段的基础上交错'imda'框。为了确定与要通过字节范围请求来请求的'imda'框相对应的字节范围，存在与某些基于索引分段的实施例类似的选项。选项至少包括：

1.在媒体分段的开头包括BoxFileIndexBox。BoxFileIndexBox描述(例如，提供其大小)媒体分段的顶级框。

2.包括(新的)字节范围框('byra')作为'moof'框的子框或在'moof'框旁边

3.使用与由'sidx'框参考的'moof'框相关联的'imda'框的字节范围来扩展SegmentIndexBox(即，对reference_type 0的参考)

4.还定义新的框'First Data Box Offset'(fdbo)：fdbo放在第一sidx框之前，以指示第一'imda'box的字节偏移。这启用分段报头(包括sidx和moof框)和imda框的渐进式下载。此外，'imda'框的大小或字节范围用上述任何方法指示。

FirstDataBoxOffsetBox的示例数据结构可以如下：

图13示出了可以与DASH按需服务利用相结合使用的示例字节范围框。在接收(子)分段之后并且在解析(子)分段之前，关于与'imda'框相关的字节范围的信息可以被重写或移除，因为仅接收到'imda'框的子集。例如，可以更新BoxFileIndexBox以仅描述接收到的具有正确字节范围的框。

已经参考'imda'框(即，IdentifiedMediaDataBox)描述了实施例。应当理解，实施例可以用其他类型的媒体数据框或未在框结构中承载的媒体数据来实现。这种实现的一个缺点是，可能需要一些辅助信息来校正从分段报头到媒体数据的字节偏移，因为最初被包括在媒体分段中的字节偏移可能会假定所有媒体数据都被接收到，而实际上媒体数据仅一部分被接收到。

已经参考图块轨道和图块基础轨道描述了实施例。需要理解，实施例可以用其他类似的概念来类似地实现，诸如分别是子图片轨道和提取器轨道，而不是图块轨道和图块基础轨道。

已经参考图块或MCTS描述了实施例。需要理解，实施例可以通过其他类似的概念来类似地实现。例如，在H.266标准草案(又称为通用视频编码)中，子图片是由整数个完整切片组成的矩形区域，并且子图片的边界可以像图片边界一样处理，即，在(解码)编码过程中，对子图片边界之外的样本位置的任何参考都可以在(解码)编码过程中被饱和，以使用子图片边界上最接近的样本位置。

已经关于特定语法描述了实施例。应当理解，实施例类似地适用于具有相同或相似功能的其他语法。

已经关于特定语法描述了实施例。应当理解，实施例适用于编写这种语法的实体。例如，在关于文件格式语法描述实施例的情况下，实施例也适用于根据文件格式语法创建文件或(多个)分段的文件写入器。类似地，实施例适用于读取这种语法的实体。例如，在关于文件格式语法描述实施例的情况下，实施例也适用于根据文件格式语法解析或处理文件或(多个)分段的文件读取器。

上述本发明的示例实施例根据单独的编码器和解码器装置描述了编解码器，以帮助理解所涉及的过程。然而，应当理解，装置、结构和操作可以实现为单个编码器解码器装置/结构/操作。此外，编码器和解码器可以共享一些或所有公共元素。

虽然以上示例描述了由装置内的编解码器执行的某些实施例，但是应当理解，其他实施例可以被实现为任何视频编解码器的一部分。因此，例如，某些实施例可以在视频编解码器中实现，该视频编解码器可以通过固定或有线通信路径实现视频编码。

如上所述，图6、9A、9B和11包括根据某些示例实施例的装置10、方法和计算机程序产品的流程图。应当理解，流程图的每个框以及流程图中的框的组合可以通过各种方式来实现，诸如硬件、固件、处理器、电路系统、和/或与软件的执行相关联的其他设备，包括一个或多个计算机程序指令。例如，上述过程中的一个或多个可以由计算机程序指令来体现。在这点上，体现上述过程的计算机程序指令可以由采用本发明的实施例的装置的存储器14存储并且由该装置的处理电路系统12执行。应当理解，任何这样的计算机程序指令可以被加载到计算机或其他可编程装置(例如，硬件)上以生产机器，使得所得到的计算机或其他可编程装置实现流程图框中指定的功能。这些计算机程序指令也可以存储在计算机可读存储器中，该存储器可以指导计算机或其他可编程装置以特定方式运行，使得存储在计算机可读存储器中的指令产生制品，该制品的执行实现流程图框中指定的功能。计算机程序指令也可以加载到计算机或其他可编程装置上，使一系列操作在计算机或其他可编程装置上被执行，以产生计算机实现的过程，使得在计算机或其他可编程装置上执行的指令装置提供用于实现在流程图框中指定的功能的操作。

因此，计算机程序产品在其中计算机程序指令(诸如计算机可读程序代码部分)由至少一个非暂态计算机可读存储介质存储的实例中定义，其中计算机程序指令(诸如计算机可读程序代码部分)被配置为在执行时执行上述功能，诸如与图6、9A、9B和11的流程图相结合。在其他实施例中，计算机程序指令(诸如计算机可读程序代码部分)不需要由非暂态计算机可读存储介质存储或以其他方式实施，而是可以由暂态介质体现，其中计算机程序指令(诸如计算机可读程序代码部分)在执行时仍被配置为执行上述功能。

因此，流程图的框支持用于执行指定功能的装置的组合和用于执行指定功能的操作的组合以执行指定功能。还应当理解，流程图的一个或多个框、以及流程图中的框的组合可以由执行指定功能的基于专用硬件的计算机系统、或者专用硬件和计算机指令的组合来实现。

在一些实施例中，上述操作中的某些操作可以修改或进一步放大。此外，在一些实施例中，可以包括附加的可选操作，诸如由图2-4中的虚线勾勒的框表示。对上述操作的修改、添加或放大可以以任何顺序和任何组合执行。

受益于前述描述和相关附图中呈现的教导，本发明所属领域的技术人员将想到本文中阐述的本发明的很多修改和其他实施例。因此，应当理解，本发明不限于所公开的具体实施例，并且修改和其他实施例旨在被包括在所附权利要求的范围内。此外，虽然前述描述和相关附图在元素和/或功能的某些示例组合的上下文中描述示例实施例，但是应当理解，在不脱离所附权利要求的范围的情况下，替代实施例可以提供元素和/或功能的不同组合。在这点上，例如，如可以在所附权利要求中的一些中阐述的，还可以设想与上面明确描述的不同的元素和/或功能的组合。尽管本文中使用了特定术语，但它们仅用于一般和描述性意义，而不是出于限制的目的。