CN112673638B - 处理媒体数据的方法和装置 - Google Patents

Abstract

所描述的实施例包括用于创建媒体容器文件的方法和技术。一种示例性方法包括步骤，其中代替基于所述分段持续时间估计媒体分段报头的所述大小，所标识的媒体数据盒被使用。在所述方法中，所标识的媒体数据元素被写入容器文件中。包括在所述所标识的数据元素中，标识符被其他元素用作所述分段的所述所标识的媒体数据的参考。所述标识符可以是第一影视片段序列号或者第一轨片段解码时间。

Description

处理媒体数据的方法和装置

技术领域

本发明涉及一种用于视频编码和解码的装置、方法和计算机程序。

背景技术

媒体容器文件格式是媒体内容生产、操纵、传输和消耗的链中的元素。在该上下文中，编码格式(即，基本流格式)与将内容信息编码为比特流的特定编码算法的动作有关。容器文件格式包括用于以这样的方式组织所生成的比特流的机制，即，它可以被访问以用于本地解码和回放、作为文件传送(transfer)、或流式传输，全部利用各种存储装置和运输架构。容器文件格式还可以促进媒体的互换和编辑以及将接收到的实时流记录到文件。

在根据ISO基础媒体文件格式(ISOBMFF；ISO/IEC 14496-12)的容器文件中，媒体数据和元数据被布置在各种类型的盒中。ISOBMFF提供影视片段特征，其可以将以其他方式可能驻留在影视盒中的元数据拆分为多个片。因此，影视盒的大小可以被限制，以避免在任何不希望的意外发生的情况下丢失数据。

在容器文件中，也可以使用提取器，提取器可以被定义为被存储在样本中的结构，并且在处理播放器中的轨时通过参考从其他轨提取编码视频数据。提取器使轨的紧凑形成成为可能，这些轨通过参考提取编码视频数据。

然而，在使用影视片段特征或提取器时，与有效载荷相比，元数据或提取器轨的开销可能会变得显著。

发明内容

现在，为了至少减轻上述问题，在本文中介绍了一种经增强编码方法。

根据第一方面的方法包括：在容器文件中写入至少一个样式，该至少一个样式指示针对样式中的每个样本的每样本元数据；以及通过将相应媒体数据的样本与该样式的每样本元数据循环地关联，在分段元数据中指示至少一个样式中的哪个样式用于相应媒体数据。

根据第二方面的装置包括：用于在容器文件中写入至少一个样式的部件，该至少一个样式指示针对样式中的每个样本的每样本元数据；以及用于通过将相应媒体数据的样本与该样式的每样本元数据循环地关联而在分段元数据中指示至少一个样式中的哪个样式用于相应媒体数据的部件。

根据一个实施例，容器文件是根据ISOBMFF构造的，该装置还包括：用于在容器文件中写入至少一个样式的部件，该至少一个样式包括TrackRunBox元数据和样本大小的比特/半字节/字节计数；以及用于在TrackRunBox中包括样本大小的每样本信令的部件。

根据一个实施例，该装置还包括：用于在容器文件中写入至少一个样式的部件，该至少一个样式包括默认提取器的至少一个样式；用于将提取器轨的样本循环地指派给至少一个样式的部件；以及用于将上述至少一个样式的样式中的默认提取器指派给提取器轨的样本的提取器的部件。

根据一个实施例，该装置还包括用于指示针对默认提取器的多于一个备选的部件。

根据一个实施例，该装置还包括：用于在该多于一个备选之中的其他备选中的参考轨不可用的情况下指示要使用的该多于一个备选之中的备选的部件。

根据一个实施例，该装置还包括用于指示针对轨片段运行的样本偏移保持不变的部件。

根据一个实施例，该装置还包括用于编译流清单的部件，该流清单指示针对分段报头和对应的分段有效载荷的单独URL。

根据一个实施例，流清单还指示分段有效载荷中的数据被紧密打包并且按解码顺序。

包括用于执行根据其他方面的方法的部件的方法和相关装置包括：从容器文件解析至少一个样式，该至少一个样式指示针对该样式中的每个样本的每样本元数据；从分段元数据解析至少一个样式中的哪个样式用于相应的媒体数据；以及将相应媒体数据的样本与样式的每样本元数据循环地关联。

包括用于执行根据其他方面的方法的部件的方法和相关装置包括：在比特流中接收至少一个样式，该至少一个样式指示针对样式中的每个样本的每样本元数据；接收媒体数据的字节范围和分段元数据的初始部分，该初始部分通过将相应媒体数据的样本与样式的每样本元数据循环地关联来指示至少一个样式中的哪个样式用于相应媒体数据；接收一个或多个指示的集合，该一个或多个指示指示字节范围包括连续的且以解码顺序出现的长度前缀媒体数据单元；从长度前缀推断出字节范围内的媒体数据单元的边界；使用访问单元边界检测来推断出媒体数据单元到访问单元的映射；以及将推断出的访问单元与样式的每样本元数据循环地关联。

其他方面涉及在其上存储有代码的装置和计算机可读存储介质，其被布置为执行以上方法以及与之相关的一个或多个实施例。

附图说明

为了更好地理解本发明，现在将通过示例的方式参照附图，其中：

图1示意性地示出了采用本发明的实施例的电子设备；

图2示意性地示出了适于采用本发明的实施例的用户装备；

图3还示意性地示出了采用本发明的实施例的电子设备，其使用无线和有线网络连接而被连接；

图4示意性地示出了适于实施本发明的实施例的编码器；

图5示出了根据本发明的实施例的编码方法的流程图；

图6示出了根据本发明的实施例的解析方法的流程图；

图7示出了根据本发明的实施例的协议序列图的示例；

图8示出了根据本发明的实施例的解码方法的流程图；

图9a和图9b对应地示出了根据本发明的一个实施例和根据现有技术的协议序列图的示例；

图10示出了适于实施本发明的实施例的解码器的示意图；以及

图11示出了在其内可以实施各种实施例的示例多媒体通信系统的示意图。

具体实施方式

下文更详细地描述了用于实施下面描述的实施例的合适装置和可能机制。在这方面，首先参照图1和图2，其中图1示出了根据示例实施例的视频编码系统的框图作为示例性装置或电子设备50的示意性框图，其可以包含根据本发明的实施例的编解码器(codec)。图2示出了根据示例实施例的装置的布局。接下来将解释图1和图2的元件。

电子设备50可以例如是无线通信系统的移动终端或用户装备。然而，要了解的是，本发明的实施例可以在可能需要编码和解码或者编码或解码视频图像的任何电子设备或装置内实施。

装置50可以包括用于包含和保护设备的壳体30。装置50还可以包括液晶显示器形式的显示器32。在本发明的其他一些实施例中，显示器可以是适于显示图像或视频的任何合适的显示技术。装置50还可以包括小键盘(keypad)34。在本发明的其他一些实施例中，可以采用任何合适的数据或用户界面机制。例如，用户界面可以被实施为虚拟键盘或数据录入系统，作为触敏显示器的一部分。

该装置可以包括麦克风36或者可以是数字或模拟信号输入的任何合适的音频输入。装置50还可以包括音频输出设备，其在本发明的实施例中可以是听筒38、扬声器或者模拟音频或数字音频输出连接中的任何一项。装置50还可以包括电池(或者在本发明的其他一些实施例中，该设备可以由诸如太阳能电池、燃料电池或发条发电机等任何合适的移动能量设备供电)。该装置还可以包括能够记录或拍摄图像和/或视频的相机。装置50还可以包括用于与其他设备的短距离视线通信的红外端口。在其他一些实施例中，装置50还可以包括任何合适的短距离通信解决方案，诸如例如蓝牙无线连接或USB/火线有线连接。

装置50可以包括用于控制装置50的控制器56、处理器或处理器电路装置。控制器56可以连接至存储器58，在本发明的实施例中，该存储器58可以以图像和音频数据的形式存储数据和/或还可以存储用于在控制器56上实施的指令。控制器56还可以连接至编解码器电路装置54，该编解码器电路装置54适于执行音频和/或视频数据的编码和解码或者辅助由控制器执行的编码和解码。

装置50还可以包括卡读取器48和智能卡46，例如UICC和UICC读取器，以用于提供用户信息并且适于提供用于在网络处对用户进行认证和授权的认证信息。

装置50可以包括无线电接口电路装置52，该无线电接口电路装置52连接至控制器并且适于生成例如与蜂窝通信网络、无线通信系统或无线局域网通信的无线通信信号。装置50还可以包括天线44，该天线44连接至无线电接口电路装置52，以用于将在无线电接口电路装置52处生成的射频信号传输给(多个)其他装置，并且以用于从(多个)其他装置接收射频信号。

装置50可以包括能够记录或检测各个帧的相机，然后这些帧被传递给编解码器54或控制器以用于处理。该装置可以在传输和/或存储之前从另一设备接收视频图像数据以用于处理。装置50还可以无线地或通过有线连接接收图像以用于编码/解码。上述装置50的结构元件表示用于执行相应功能的部件的示例。

关于图3，示出了在其内可以使用本发明的实施例的系统的示例。系统10包括可以通过一个或多个网络进行通信的多个通信设备。系统10可以包括有线或无线网络的任何组合，包括但不限于无线蜂窝电话网络(诸如GSM、UMTS、CDMA网络等)、诸如由任何IEEE 802.x标准中的任一标准定义的无线局域网(WLAN)、蓝牙个人局域网、以太网局域网、令牌环局域网、广域网和互联网。

系统10可以包括适于实施本发明的实施例的有线和无线通信设备和/或装置50。

例如，图3所示的系统示出了移动电话网络11和互联网28的表示。与互联网28的连接性可以包括但不限于长距离无线连接、短距离无线连接、以及各种有线连接，包括但不限于电话线、电缆线、电源线和类似的通信途径。

系统10所示的示例通信设备可以包括但不限于电子设备或装置50、个人数字助理(PDA)和移动电话14的组合、PDA 16、集成的消息收发设备(IMD)18、台式计算机20、笔记本计算机22。当由移动的个人携带时，装置50可以是静止的或移动的。装置50也可以以运输模式被定位，包括但不限于汽车、卡车、出租车、公共汽车、火车、轮船、飞机、自行车、摩托车或任何类似的合适运输模式。

实施例也可以实施在机顶盒(即，可能/可能不具有显示器或无线能力的数字TV接收器)中，实施在平板计算机或(膝上型)个人计算机(PC)(具有硬件或软件或编码器/解码器实施方式的组合)中，实施在各种操作系统中，并且实施在芯片组、处理器、DSP和/或提供基于硬件/软件的编码的嵌入式系统中。

一些或其他装置可以发送和接收呼叫和消息，并且通过与基站24的无线连接25与服务提供者进行通信。基站24可以连接至允许移动电话网络与互联网28之间进行通信的网络服务器26。该系统可以包括附加的通信设备和各种类型的通信设备。

通信设备可以使用各种传输技术进行通信，包括但不限于码分多址(CDMA)、全球移动通信系统(GSM)、通用移动电信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议-互联网协议(TCP-IP)、短消息收发服务(SMS)、多媒体消息收发服务(MMS)、电子邮件、即时消息收发服务(IMS)、蓝牙、IEEE 802.11和任何类似的无线通信技术。涉及实施本发明的各种实施例的通信设备可以使用各种介质进行通信，包括但不限于无线电、红外、激光、电缆连接以及任何合适的连接。

在电信和数据网络中，信道可以指物理信道或逻辑信道。物理信道可以指诸如电线等物理传输介质，而逻辑信道可以指复用介质之上的逻辑连接，能够表达多个逻辑信道。信道可以用于将信息信号(例如比特流)从一个或若干个发送器(sender)(或发送器(transmitter))传达给一个或若干个接收器。

在ISO/IEC 13818-1中指定的或在ITU-T建议书H.222.0中等效地指定的MPEG-2传输流(TS)是用于在复用流中携带音频、视频和其他介质以及程序元数据或其他元数据的格式。分组标识符(PID)用于标识TS内的基本流(也称为打包基本流)。因此，MPEG-2 TS内的逻辑信道可以被认为对应于特定的PID值。

可用的媒体文件格式标准包括ISO基础媒体文件格式(ISO/IEC 14496-12，可以缩写为ISOBMFF)和NAL单元结构化视频的文件格式(ISO/IEC 14496-15)，该文件格式从ISOBMFF导出。

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

ISO基础媒体文件格式中的基础构建块称为盒。每个盒都具有报头和有效载荷。盒报头按照字节指示盒的类型和盒的大小。盒可以包围其他盒，并且ISO文件格式指定在某种类型的盒内允许哪些盒类型。此外，在每个文件中一些盒的存在可能是强制性的，而其他盒的存在可能是可选的。附加地，针对一些盒类型，可能允许在文件中存在多于一个盒。因此，可以考虑ISO基础媒体文件格式来指定盒的分层结构。

根据ISO族的文件格式，文件包括封装在盒中的媒体数据和元数据。每个盒都由四个字符代码(4CC)标识，并且以报头开始，该报头通知盒的类型和大小。

在符合ISO基础媒体文件格式的文件中，媒体数据可以在媒体数据‘mdat’盒(也称为MediaDataBox)中被提供，并且影视‘moov’盒(也称为MovieBox)可以用于包围元数据。在一些情况下，为了使文件可操作，可能需要存在‘mdat’和‘moov’盒两者。影视‘moov’盒可以包括一个或多个轨，并且每个轨可以驻留在一个对应的轨‘trak’盒(也称为TrackBox)中。轨可以是许多类型中的一个类型，包括媒体轨，该媒体轨是指根据媒体压缩格式(及其对ISO基础媒体文件格式的封装)被格式化的样本。

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

影视片段特征可以使拆分以其他方式可能驻留在影视盒中的元数据为多个片变成可能。每个片可以对应于轨的某个时段。换言之，影视片段特征可以使交织文件元数据和媒体数据变成可能。因此，影视盒的大小可能受到限制，并且可以实现上面提及的用例。

当存在时，MovieExtendsBox(‘mvex’)被包含在MovieBox中。它的存在警告读者，该文件或流中可能有影视片段。要了解轨中的所有样本，会按顺序获得和扫描影视片段，并将它们的信息逻辑地添加到MovieBox中的信息。MovieExtendsBox包含每轨一个TrackExtendsBox。TrackExtendsBox包含由影视片段使用的默认值。在TrackExtendsBox中可以给出的默认值包括：默认样本描述索引(即，默认样本条目索引)、默认样本持续时间、默认样本大小和默认样本标志。样本标志包括依赖性信息，诸如该样本是否依赖于(多个)其他样本、(多个)其他样本是否依赖于该样本、以及样本是否为同步样本。

在一些示例中，如果针对影视片段的媒体样本与moov盒位于同一文件中，则它们可以驻留在mdat盒中。然而，对于影视片段的元数据，可以提供moof盒(也称为MovieFragmentBox)。moof盒可以包括如下信息，该信息先前已经在moov盒中存在某些持续时间的回放时间。moov盒其自身可能也表示有效的影视，但是附加地，它还可以包括mvex盒，mvex盒指示影视片段将在同一文件中跟进。影视片段可以及时扩展与moov盒相关联的呈现。

在影视片段内，可能存在轨片段的集合，包括每轨从零到多个的任何位置。轨片段又可以包括从零到多个轨运行的任何位置，其文档的每个文档都是针对该轨的样本的连续运行。在这些结构内，许多字段是可选的，并且可以是默认的。可以包括在moof盒中的元数据可以限于可以包括在moov盒中的元数据的子集，并且在一些情况下可以以不同方式编码。可以从ISO基础媒体文件格式规范中找到关于可以被包括在moof盒中的盒的细节。

TrackFragmentBox中所包含的TrackFragmentHeaderBox包括sample_description_index，其标识在该轨片段中使用哪个样本条目。

可以指示基础数据偏移(TrackFragmentHeaderBox中的base_data_offset)，为轨运行中的数据偏移提供显式锚。备选地，可以指示用于针对第一轨片段的数据参考的基础数据偏移(TrackFragmentHeaderBox中的base_data_offset)是相对于包围的MovieFragmentBox的第一字节的位置的，并且针对后续轨片段，默认的基础数据偏移是由在前轨片段定义的数据的末尾。备选地或附加地，针对轨片段，可以指示基础数据偏移(TrackFragmentHeaderBox中的base_data_offset)是相对于包围的MovieFragmentBox的第一字节的位置的。

轨片段包括一个或多个轨片段运行(也称为轨运行)，每个运行由TrackRunBox描述。轨运行记载了针对轨的连续样本集合，这也是媒体数据字节的连续范围。

ISOBMFF中的TrackRunBox的语法如下：

可选字段的存在由tr_flags的值控制，如下：

-0x000001 data-offset-present。

-0x000004 first-sample-flags-present；这仅覆盖针对第一样本的默认标志。这样就可以记录一组帧，其中第一帧是密钥，并且其余帧是差异帧，而无需供应针对每个样本的显式标志。如果该标志和字段被使用，则需要将sample-flags-present设置为等于0。

-0x000100 sample-duration-present：指示每个样本具有自己的持续时间，否则使用默认值。

-0x000200 sample-size-present：每个样本具有自己的大小，否则使用默认值。

-0x000400 sample-flags-present；每个样本具有自己的标志，否则使用默认值。

-0x000800 sample-composition-time-offsets-present；每个样本具有合成时间偏移(例如用于MPEG中的I/P/B视频)。

data_offset(当存在时)被添加到在轨片段报头中所建立的隐式或显式(基础)数据偏移。first_sample_flags提供针对轨运行的第一样本的样本标志。

TrackFragmentBaseMediaDecodeTimeBox(‘tfdt’)提供在轨片段中按解码顺序的第一样本的在解码时间轴上测量的绝对解码时间。例如，当在文件中执行随机访问时，这可能很有用；不必须对先前片段中的所有在前样本的样本持续时间求和来找到该值(其中样本持续时间是TimeToSampleBox中的增量和在前轨运行中的sample_durations)。TrackFragmentBaseMediaDecodeTimeBox可能被包含在TrackFragmentBox中。在轨片段中按解码顺序的第一样本的解码时间可以被称为baseMediaDecodeTime，并且可以被提供为32位或64位的无符号整数值。

可以将自包含的影视片段定义为包括以文件顺序连续的moof盒和mdat盒，并且其中mdat盒包含影视片段的样本(moof盒针对其提供元数据)，并且不包含任何其他影视片段的样本(即，任何其他的moof盒)。

轨参考机制可以用于将轨彼此关联。TrackReferenceBox包括(多个)盒，每个盒都提供从包含轨到其他轨的集合的参考。这些参考通过所包含的(多个)盒的盒类型(即，盒的四字符代码)被标记。

轨分组机制能够指示轨的组，其中每个组共享特定的特性，或者组内的轨具有特定的关系。TrackGroupBox可能被包含在TrackBox中。TrackGroupBox包含从TrackGroupTypeBox导出的零个或多个盒。特定特性或关系由所包含的盒的盒类型指示。所包含的盒包括标识符，该标识符可以用于推断出属于同一轨组的轨。在TrackGroupBox内包含相同类型的所包含的盒并且在这些所包含的盒内具有相同标识符值的轨属于同一轨组。

ISO基础媒体文件格式包含可以与特定样本相关联的定时元数据的三个机制：样本组、定时元数据轨、和样本辅助信息。所导出的规范可以利用这三个机制中的一个或多个提供类似的功能性。

ISO基础媒体文件格式及其派生(诸如AVC文件格式和SVC文件格式)的样本分组可以被定义为基于分组准则将轨中的每个样本指派为一个样本组的成员。样本分组中的样本组不限于连续的样本，并且可以包含不相邻的样本。由于可能存在针对轨中的样本的多于一个的样本分组，所以每个样本分组都可以具有类型字段来指示分组的类型。样本分组可以由两个相链接的数据结构表示：(1)SampleToGroupBox(sbgp盒)表示将样本指派给样本组；以及(2)SampleGroupDescriptionBox(sgpd盒)包含针对每个样本组的样本组条目，其描述该组的属性。基于不同的分组准则，可能存在SampleToGroupBox和SampleGroupDescriptionBox的多个实例。这些可以由用于指示分组的类型的类型字段来区分。SampleToGroupBox可以包括grouping_type_parameter字段，其可以用于例如指示分组的子类型。

已经指定了若干类型的流访问点(SAP)，包括以下。SAP类型1对应于一些编码方案中所谓的“封闭GOP随机访问点”(其中按解码顺序的所有图片都可以被正确解码，从而导致正确解码图片的连续时间序列且无间隙)，另外，按解码顺序的第一图片也是按呈现顺序的第一图片。SAP类型2对应于一些编码方案中所谓的“封闭GOP随机访问点”(其中按解码顺序的所有图片都可以被正确解码，从而导致正确解码图片的连续时间序列且无间隙)，其中按解码顺序的第一图片可以不是按呈现顺序的第一图片。SAP类型3对应于一些编码方案中所谓的“开放GOP随机访问点”，其中可能存在按解码顺序的一些图片无法被正确解码，并且具有比与该SAP相关联的帧内编码图片少的呈现时间。

ISOBMFF中指定的流访问点(SAP)样本组将样本标识为所指示的SAP类型的样本。

同步样本可以被定义为对应于SAP类型1或SAP类型2的样本。同步样本可以看作是开始新的独立样本序列的媒体样本；如果解码从同步样本开始，则按解码顺序的它和随后样本都可以正确地被解码，并且所得的解码样本的集合形成从具有最早合成时间的解码样本开始的媒体的正确呈现。同步样本可以利用SyncSampleBox被指示(针对其元数据存在于TrackBox中的那些样本)，或者可以在针对轨片段运行所指示或所推测的样本标志内被指示。

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

视频编解码器包括将输入视频变换为适于存储/传输的压缩表示的编码器和可以将压缩视频表示解压缩回可视形式的解码器。视频编码器和/或视频解码器也可以彼此分离，即，不需要形成编解码器。通常，编码器会丢弃原始视频序列中的一些信息，以便以更紧凑的形式(即，较低的比特率)表示视频。

典型的混合视频编码器(例如ITU-T H.263和H.264的许多编码器实施方式)在两个阶段对视频信息编码。首先，例如通过运动补偿手段(找到并指示在先前编码的视频帧中的一个编码的视频帧中的与被编码的块紧密对应的区域)或通过空间手段(使用要以指定方式被编码的块周围的像素值)来预测某个图片区域(或“块”)中的像素值。其次，预测误差(即，预测像素块与原始像素块之间的差异)被编码。通常通过使用指定的变换(例如离散余弦变换(DCT)或其变型)来变换像素值的差、量化系数并且对经量化的系数进行熵编码来完成。通过改变量化过程的保真度，编码器可以控制像素表示的准确性(图片质量)与所得编码视频表示的大小(文件大小或传输比特率)之间的平衡。

在时间预测中，预测源是先前解码的图片(又称为参考图片)。在块内复制(IBC；又称为块内复制预测)中，预测与时间预测类似地被应用，但是参考图片是当前图片，并且在预测过程中仅可以参考先前解码的样本。层间或视图间预测可以与时间预测类似地被应用，但是参考图片分别是来自另一可缩放层或来自另一视图的解码图片。在一些情况下，帧间预测可以仅指时间预测，而在其他一些情况下，帧间预测可以共同指时间预测以及块内复制、层间预测和视图间预测中的任何一个，前提是它们以与时间预测相同或类似的过程执行。帧间预测或时间预测有时可以称为运动补偿或运动补偿预测。

帧间预测(也可以称为时间预测、运动补偿或运动补偿预测)减少了时间冗余。在帧间预测中，预测源是先前解码的图片。帧内预测利用同一图片内的相邻像素很可能关联的事实。可以在空间域或变换域中执行帧内预测，即，可以预测样本值或变换系数。通常在不应用帧间预测的帧内编码中利用帧内预测。

编码过程的一个结果是编码参数的集合，诸如运动向量和量化的变换系数。如果许多参数首先从空间上或时间上邻近的参数被预测，则可以更有效地被熵编码。例如，运动向量可以从空间上相邻的运动向量被预测，并且可以仅编码相对于运动向量预测器的差异。编码参数的预测和帧内预测可以统称为图片内预测。

图4示出了适于采用本发明的实施例的视频编码器的框图。图4呈现了针对两层的编码器，但是要了解的是，所呈现的编码器可以类似地被扩展以对多于两个层编码。图4图示了视频编码器的实施例，其包括用于基础层的第一编码器区段500和用于增强层的第二编码器区段502。第一编码器区段500和第二编码器区段502中的每一个可以包括用于对传入图片编码的类似元件。编码器区段500、502可以包括像素预测器302、402、预测误差编码器303、403和预测误差解码器304、404。图4还示出了像素预测器302、402的实施例，其包括帧间预测器306、406、帧内预测器308、408、模式选择器310、410、滤波器316、416和参考帧存储器318、418。第一编码器区段500的像素预测器302接收300视频流的基础层图像，以在帧间预测器306(其确定图像与运动补偿参考帧318之间的差异)和帧内预测器308(其仅基于当前帧或图片的已处理部分确定针对图像块的预测)两处被编码。帧间预测器和帧内预测器两者的输出都被传递给模式选择器310。帧内预测器308可以具有多于一个帧内预测模式。因此，每个模式可以执行帧内预测并且将预测的信号提供给模式选择器310。模式选择器310还接收基础层图片300的副本。相应地，第二编码器区段502的像素预测器402接收400视频流的增强层图像，以在帧间预测器406(其确定图像与运动补偿参考帧418之间的差异)和帧内预测器408(其仅基于当前帧或图片的已处理部分确定针对图像块的预测)两处被编码。帧间预测器和帧内预测器两者的输出都被传递给模式选择器410。帧内预测器408可以具有多于一个帧内预测模式。因此，每个模式可以执行帧内预测，并且将预测的信号提供给模式选择器410。模式选择器410还接收增强层图片400的副本。

取决于哪个编码模式被选择以对当前块编码，帧间预测器306、406的输出或者可选帧内预测器模式中的一个帧内预测模式的输出或者模式选择器内的表面编码器的输出被传递给模式选择器310、410的输出。模式选择器的输出被传递给第一求和设备321、421。第一求和设备可以从基础层图片300/增强层图片400减去像素预测器302、402的输出，以产生被输入给预测误差编码器303、403的第一预测误差信号320、420。

像素预测器302、402还从初步重构器339、439接收图像块312、412的预测表示与预测误差解码器304、404的输出338、438的组合。初步重构图像314、414可以被传递给帧内预测器308、408和滤波器316、416。接收初步表示的滤波器316、416可以滤波初步表示并且输出可以被保存在参考帧存储器318、418中的最终重构图像340、440。参考帧存储器318可以被连接至帧间预测器306，以用作在帧间预测操作中与将来的基础层图片300进行比较的参考图像。根据一些实施例，在基础层被选择并且被指示为针对增强层的层间样本预测和/或层间运动信息预测的源的情况下，参考帧存储器318也可以被连接至帧间预测器406以用作在帧间预测操作中与将来的增强层图片400进行比较的参考图像。而且，参考帧存储器418可以被连接至帧间预测器406，以用作在帧间预测操作中与将来的增强层图片400进行比较的参考图像。

根据一些实施例，在基础层被选择并且被指示为用于预测增强层的滤波参数的源的情况下，来自第一编码器区段500的滤波器316的滤波参数可以被提供给第二编码器区段502。

预测误差编码器303、403包括变换单元342、442和量化器344、444。变换单元342、442将第一预测误差信号320、420变换到变换域。该变换是例如DCT变换。量化器344、444对变换域信号(例如DCT系数)进行量化，以形成量化系数。

预测误差解码器304、404接收来自预测误差编码器303、403的输出，并且执行预测误差编码器303、403的相反过程，以产生解码的预测误差信号338、438，当解码的预测误差信号338、438与第二求和设备339、439处的图像块312、412的预测表示组合时，产生初步重构图像314、414。预测误差解码器可以被认为包括对量化系数值(例如DCT系数)进行去量化以重构变换信号的去量化器361、461以及对重构的变换信号执行逆变换的逆变换单元363、463，其中逆变换单元363、463的输出包含(多个)重构块。预测误差解码器还可以包括块滤波器，该块滤波器可以根据进一步解码的信息和滤波器参数来对(多个)重构块进行滤波。

熵编码器330、430接收预测误差编码器303、403的输出，并且可以对信号执行适当的熵编码/可变长度编码，以提供误差检测和校正能力。熵编码器330、430的输出可以例如被复用器508插入到比特流中。

H.264/AVC标准是由国际电信联盟电信标准化部门(ITU-T)的视频编码专家组(VCEG)和国际标准化组织(ISO)/国际电工委员会(IEC)的移动图像专家组(MPEG)的联合视频组(JVT)开发的。H.264/AVC标准是由两个父级标准化组织发布的，并且被称为ITU-T建议书H.264和ISO/IEC国际标准14496-10，也称为MPEG-4部分10高级视频编码(AVC)。存在H.264/AVC标准的多个版本，将新的扩展或特征集成到规范中。这些扩展包括可缩放视频编码(SVC)和多视图视频编码(MVC)。

高效视频编码(H.265/HEVC，又称为HEVC)标准的第1版是由VCEG和MPEG的联合协作组-视频编码(JCT-VC)开发的。该标准是由两个父级标准化组织发布的，并且被称为ITU-T建议书H.265和ISO/IEC国际标准23008-2，也称为MPEG-H部分2高效视频编码(HEVC)。H.265/HEVC的稍后版本包括可缩放、多视图、保真度范围扩展、三维和屏幕内容编码扩展，可以分别缩写为SHVC、MV-HEVC、REXT、3D-HEVC和SCC。

SHVC、MV-HEVC和3D-HEVC使用在HEVC标准的版本2的附录F中指定的通用基础规范。该通用基础包括例如指定比特流的层的特性中的一些特性的例如高级语法和语义(诸如层间依赖性)以及解码过程，诸如参考图片列表构造，包括针对多层比特流的层间参考图片和图片顺序计数导出。附录F也可以被用于HEVC的潜在后续多层扩展中。要理解的是，即使在下面可以参照诸如SHVC和/或MV-HEVC等特定扩展来描述视频编码器、视频解码器、编码方法、解码方法、比特流结构、和/或实施例，但是它们通常应用于HEVC的任何多层扩展，甚至更一般地适用于任何多层视频编码方案。

通用视频编码(VVC，H.266或H.266/VVC)标准的标准化已在ITU-T和MPEG的联合视频专家组(JVET)中开始。

在本章节中描述了H.264/AVC和HEVC的一些关键定义、比特流和编码结构、以及概念作为视频编码器、解码器、编码方法、解码方法和比特流结构的示例，其中实施例可以被实施。H.264/AVC的一些关键定义、比特流和编码结构、以及概念与HEVC中的相同，因此下面将对其进行共同描述。本发明的各个方面不限于H.264/AVC或HEVC，而是针对一种可能的基础给出了描述，在此基础上可以部分或完全地实现本发明。以下描述的在H.264/AVC或HEVC的上下文中的许多方面可以应用于VVC，并且因此本发明的各个方面可以应用于VVC。

与许多早期的视频编码标准类似，在H.264/AVC和HEVC中指定比特流语法和语义以及针对无误差比特流的解码过程。没有指定编码过程，但是编码器必须生成一致的比特流。可以利用假设参考解码器(HRD)验证比特流和解码器一致性。这些标准包含有助于解决传输误差和丢失的编码工具，但是在编码中对该工具的使用是可选的，并且尚未指定针对错误的比特流的解码过程。

以用于向H.264/AVC或HEVC编码器的输入和H.264/AVC或HEVC解码器的输出的基本单位分别是图片。作为输入被赋予给编码器的图片也可以被称为源图片，并且通过解码而解码的图片可以被称为解码图片。

源图片和解码图片分别包括一个或多个样本阵列，诸如以下样本阵列集中的一个阵列集：

-仅亮度(Y)(单色)。

-亮度和两个色度(YCbCr或YCgCo)。

-绿色、蓝色和红色(GBR，也称为RGB)。

-表示其他未指定的单色或三刺激色采样的阵列(例如YZX，也称为XYZ)。

在下文中，这些阵列可以被称为亮度(或L或Y)和色度，其中两个色度阵列可以被称为Cb和Cr；不管使用的实际颜色表示方法。使用的实际颜色表示方法可以例如在编码比特流中例如使用H.264/AVC和/或HEVC的视频可用性信息(VUI)语法而被指示。分量可以被定义为来自三个样本阵列(亮度和两个色度)中的一个样本阵列的阵列或单个样本或者构成单色格式图片的阵列或阵列的单个样本。

在H.264/AVC和HEVC中，图片可以是帧或字段。帧包括亮度样本以及可能的对应色度样本的矩阵。字段是帧的交替样本行的集合，并且当源信号被隔行扫描时，可以被用作编码器输入。当与亮度样本阵列相比时，色度样本阵列可能不存在(因此可能使用单色采样)，或者色度样本阵列可能会被二次采样。色度格式可以总结如下：

-在单色采样中，只有一个样本阵列，名义上可以认为是亮度阵列。

-在4:2:0采样中，两个色度阵列中的每个色度阵列都具有亮度阵列的一半高度和一半宽度。

-在4:2:2采样中，两个色度阵列中的每个色度阵列都具有亮度阵列的相同高度和一半宽度。

-在没有使用单独颜色平面的4:4:4采样中，两个色度阵列中的每个色度阵列都具有与亮度阵列相同的高度和宽度。

在H.264/AVC和HEVC中，能够将样本阵列作为单独颜色平面编码到比特流中，并且分别对来自比特流的单独编码的颜色平面解码。当使用单独颜色平面时，利用单色采样将它们中的每个单独颜色平面分别作为图片(由编码器和/或解码器)进行处理。

分割可以被定义为将集合划分为子集，使得集合的每个元素恰好在子集中的一个子集中。

当描述HEVC编码和/或解码的操作时，可以使用以下术语。可以将编码块定义为针对某个值N的NxN样本块，使得对编码树块到编码块的划分是分割。可以将编码树块(CTB)定义为针对某个值N的NxN样本块，使得对分量到编码树块的划分是分割。可以将编码树单元(CTU)定义为亮度样本的编码树块、具有三个样本阵列的图片的色度样本的两个对应的编码树块、或者单色图片或使用三个单独颜色平面和用于对样本编码的语法结构而被编码的图片的样本的编码树块。可以将编码单元(CU)定义为亮度样本的编码块、具有三个样本阵列的图片的色度样本的两个对应的编码块、或者单色图片或使用三个单独颜色平面和用于对样本编码的语法结构而被编码的图片的样本的编码块。具有最大允许大小的CU可以被命名为LCU(最大编码单元)或编码树单元(CTU)，并且视频图片被划分为非重叠的LCU。

CU包括定义CU内的样本的预测过程的一个或多个预测单元(PU)和定义所述CU中的样本的预测误差编码过程的一个或多个变换单元(TU)。通常，CU包括正方形样本块，其大小能够从可能的CU大小的预定义集合中选择。每个PU和TU还可以被拆分为较小的PU和TU，以分别增加预测和预测误差编码过程的粒度。每个PU具有与其相关联的预测信息，该预测信息定义将对该PU内的像素应用哪种预测(例如用于帧间预测的PU的运动向量信息和用于帧内预测的PU的帧内预测方向性信息)。

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

在HEVC中，图片可以被分割图块，图块是矩形并且包含整数数目的LCU。在HEVC中，对图块的分割形成规则的网格，其中图块的高度和宽度彼此之间最多相差一个LCU。在HEVC中，切片被定义为一个独立切片分段中所包含的编码树单元的整数数目以及在同一访问单元内的下一独立切片分段(如果有的话)之前的所有后续从属切片分段(如果有的话)。在HEVC中，切片分段被定义为在图块扫描中被连续地排序并且被包含在单个NAL单元中的整数数目的编码树单元。对每个图片到切片分段的划分是分割。在HEVC中，将独立切片分段定义为如下切片分段，针对该切片分段，切片分段报头的语法元素的值不是从针对在前切片分段的值推测出的，并且从属切片分段被定义为如下切片分段，针对该切片分段，切片分段报头的一些语法元素的值是从针对按照解码顺序的在前独立切片分段的值推测出的。在HEVC中，切片报头被定义为独立切片分段的切片分段报头，该独立切片分段是当前切片分段或者是在当前从属切片分段之前的独立切片分段，并且切片分段报头被定义为编码切片分段的一部分，该编码切片分段包含与切片分段中所表示的第一或所有编码树单元相关的数据元素。如果未使用图块，则以图块内或图片内的LCU的光栅扫描顺序扫描CU。在LCU内，CU具有特定的扫描顺序。

帧内编码切片(也称为I切片)是这样的，仅包含帧内编码块。I切片的语法可以排除与帧间预测相关的语法元素。帧间编码切片是这样的，其中块可以被帧内或帧间编码。帧间编码切片还可以被分类为P和B切片，其中P切片是这样的切片，块可以被帧内编码或帧间编码，但仅使用单预测，并且B切片中的块可以利用单预测或双预测被帧内编码或帧间编码。

运动受限的图块集(MCTS)是这样的，帧间预测过程在编码中受到约束，使得没有样本值在运动受限的图块集之外，并且没有使用运动受限的图块集之外的一个或多个样本值导出的样本值在分数样本位置处被用于对运动受限的图块集内的任何样本进行帧内预测。附加地，以不从MCTS之外的块导出运动向量候选的方式来约束对MCTS的编码。这可以通过关闭HEVC的时间运动向量预测来实施，或通过禁止编码器使用TMVP候选或者禁止在合并中在TMVP候选之后的任何运动向量预测候选或者禁止针对如下PU的AMVP候选列表来实施，该PU位于MCTS的右图块边界的正左侧，但MCTS右下角的最后一个除外。通常，MCTS可以被定义为独立于MCTS之外的任何样本值和编码数据(诸如运动向量)的图块集。在一些情况下，可能需要MCTS来形成矩形区域。应该理解，取决于上下文，MCTS可以参考图片内的图块集或图片序列中的相应图块集。相应图块集可以但通常不需要在图片序列中共同定位。

要注意的是，帧间预测中使用的样本位置可以通过编码和/或解码过程饱和，使得本将在图片之外的位置以其他方式饱和以指向图片的对应边界样本。因此，如果图块边界也是图片边界，则在一些用例中，编码器可以允许运动向量有效地越过该边界，或者允许运动向量有效地导致分数样本内插，该分数样本内插本将指该边界之外的位置，因为样本位置饱和到边界上。在其他用例中，具体地，如果可以从位于与图片边界相邻的位置的比特流将编码图块提取到其中图块位于与图片边界不相邻的位置的另一比特流，则编码器可以与任何MCTS边界类似地将运动向量约束在图片边界上。

HEVC的时间运动受限的图块集SEI消息可以被用于指示比特流中运动受限的图块集的存在。

解码器通过应用类似于编码器的预测手段来重构输出视频，以形成像素块的预测表示(使用由编码器创建并且存储在压缩表示中的运动或空间信息)和预测误差解码(预测误差编码的逆运算恢复空间像素域中的量化的预测误差信号)。在应用预测和预测误差解码手段之后，解码器对预测和预测误差信号(像素值)求和以形成输出视频帧。解码器(和编码器)还可以应用附加滤波手段，以提高输出视频的质量，然后传递该输出视频以用于显示和/或将其存储为视频序列中即将到来的帧的预测参考。

例如，滤波可以包括以下一项或多项：去块、样本自适应偏移(SAO)、和/或自适应环路滤波(ALF)。H.264/AVC包括去块，而HEVC包括去块和SAO。

在典型的视频编解码器中，利用与每个运动补偿图像块相关联的运动向量(诸如预测单元)来指示运动信息。这些运动向量中的每个运动向量表示对待编码(在编码器侧)或待解码(在解码器侧)的图片中的图像块和先前编码或解码的图片中的一个图片中的预测源块的位移。为了有效地表示运动向量，通常相对于特定于块的预测的运动向量对它们以差分形式编码。在典型的视频编解码器中，以预定义方式创建预测的运动向量，例如计算相邻块的编码或解码的运动向量的中值。创建运动向量预测的另一方式是从时间参考图片中的相邻块和/或共同定位的块生成候选预测的列表，并且用信号通知所选的候选作为运动向量预测器。除了预测运动向量值之外，还可以预测哪些(多个)参考图片被用于运动补偿预测，并且该预测信息可以例如由先前编码/解码的图片的参考索引表示。通常从时间参考图片中的相邻块和/或共同定位的块中预测参考索引。而且，典型的高效视频编解码器采用附加的运动信息编码/解码机制，通常称为合并(merging)/合并(merge)模式，其中所有运动字段信息(包括运动向量和针对每个可用参考图片列表的对应参考图片索引)被预测，并且在没有任何修改/校正的情况下被使用。类似地，预测运动字段信息通过使用时间参考图片中的相邻块和/或共同定位的块的运动字段信息而被实现，并且在填充有可用的相邻/共同定位的块的运动字段信息的运动字段候选列表的列表之中用信号通知所使用的运动字段信息。

在典型的视频编解码器中，运动补偿后的预测残差首先利用变换内核(如DCT)被变换，然后被编码。这样做的原因是，残差之中通常仍然存在某种关联，并且在许多情况下变换可以帮助减少该关联并提供更有效的编码。

典型的视频编码器利用拉格朗日成本函数来找到最佳的编码模式，例如针对块和相关联运动向量的期望编码模式。这种成本函数使用权重因子λ将由于有损编码方法导致的(精确或估计的)图像失真与表示图像区域中的像素值所需的(精确或估计的)信息的量联系在一起：

C＝D+λR， (1)

其中C是要被最小化的拉格朗日成本，D是考虑了模式和运动向量的图像失真(例如均方误差)，并且R是表示在解码器中重构图像块所需数据所需的比特数(包括表示候选运动向量的数据的量)。

视频编码标准和规范可以允许编码器将编码图片划分为编码切片等。图片内预测通常跨切片边界被禁用。因此，可以将切片视为将编码图片拆分为可独立解码的片的方式。在H.264/AVC和HEVC中，可以跨切片边界禁用图片内预测。因此，可以将切片视为将编码图片拆分为可独立解码的片的方式，因此通常将切片视为用于传输的基本单位。在许多情况下，编码器可以在比特流中指示跨切片边界关闭哪些类型的图片内预测，并且例如在推断哪些预测源可用时，解码器操作会将该信息考虑在内。例如，如果邻近CU驻留在不同切片中，则来自邻近CU的样本可以被认为对于帧内预测不可用。

以用于H.264/AVC或HEVC编码器的输出以及H.264/AVC或HEVC解码器的输入的基本单位分别是网络抽象层(NAL)单元。为了在面向分组的网络上传输或存储到结构化文件中，可以将NAL单元封装到分组或类似结构中。在H.264/AVC和HEVC中已经指定了针对不提供帧结构的传输或存储环境的字节流格式。字节流格式通过在每个NAL单元的前面附加起始代码来将NAL单元彼此分离。为了避免错误检测NAL单元边界，编码器运行面向字节的起始代码仿真防止算法，如果起始代码会以其他方式出现，则该算法会将仿真防止字节添加到NAL单元有效载荷。为了使面向分组和面向流的系统之间能够直接进行网关操作，无论字节流格式是否在使用中，始终可以执行起始代码仿真防止。NAL单元可以被定义为语法结构，包含要遵循的数据类型的指示以及包含该数据的字节，该字节以RBSP的形式在必要时散布有仿真防止字节。原始字节序列有效载荷(RBSP)可以被定义为包含封装在NAL单元中的整数数目的字节的语法结构。RBSP为空或具有包含语法元素的数据位的字符串的形式，其后是RBSP停止位，然后是等于0的零个或多个后续位。

NAL单元包括报头和有效载荷。在H.264/AVC和HEVC中，NAL单元报头指示NAL单元的类型。

在HEVC中，两字节的NAL单元报头用于所有指定的NAL单元类型。NAL单元报头包含一个保留位、六位NAL单元类型指示、用于时间级别的三位nuh_temporal_id_plus1指示(可能需要大于或等于1)和六位nuh_layer_id语法元素。可以将temporal_id_plus1语法元素视为针对NAL单元的时间标识符，并且可以如下导出基于零的TemporalId变量：TemporalId＝temporal_id_plus1–1。缩写TID可以用于与TemporalId变量互换。等于0的TemporalId对应于最低的时间级别。为了避免涉及两个NAL单元报头字节的起始代码仿真，要求temporal_id_plus1的值非零。通过排除具有大于或等于所选值的TemporalId的所有VCLNAL单元并且包括所有其他VCL NAL单元而被创建的比特流保持合规。因此，具有等于tid_value的TemporalId的图片不使用具有大于tid_value的TemporalId的任何图片作为帧间预测参考。子层或时间子层可以被定义为时间可缩放比特流的时间可缩放层(或时间层TL)，其包括具有TemporalId变量的特定值的VCL NAL单元和相关联的非VCL NAL单元。nuh_layer_id可以被理解为可缩放性层标识符。

NAL单元可以被分类为视频编码层(VCL)NAL单元和非VCL NAL单元。VCL NAL单元通常是编码的切片NAL单元。在HEVC中，VCL NAL单元包含表示一个或多个CU的语法元素。

在HEVC中，针对图片类型的缩写可以被定义如下：尾随(TRAIL)图片、时间子层访问(TSA)、逐步时间子层访问(STSA)、随机访问可解码前导(RADL)图片、随机访问跳过前导(RASL)图片、断开链接访问(BLA)图片、即时解码刷新(IDR)图片、干净随机访问(CRA)图片。

在独立层中也可以称为帧内随机访问点(IRAP)图片的随机访问点(RAP)图片仅包含帧内编码切片。属于预测层的IRAP图片可以包含P、B和I切片，不能够使用来自同一预测层中的其他图片的帧间预测，并且可以使用来自其直接参考层的层间预测。在HEVC的当前版本中，IRAP图片可以是BLA图片、CRA图片或IDR图片。包含基础层的比特流中的第一图片是基础层处的IRAP图片。只要必要的参数集在需要被激活时可用，就可以正确解码按照解码顺序的独立层处的IRAP图片和独立层处的所有后续非RASL图片，而无需执行在按照解码顺序的IRAP图片之前的任何图片的解码过程。当需要被激活时必要参数集可用时以及当已初始化预测层的每个直接参考层的解码时，可以正确地解码属于预测层的IRAP图片以及在同一预测层内按照解码顺序的所有后续非RASL图片，而无需执行按照解码顺序的IRAP图片之前的同一预测层的任何图片的解码过程。在比特流中可能存在图片，其仅包含不是IRAP图片的帧内编码切片。

非VCL NAL单元可以是例如以下一个类型：序列参数集、图片参数集、补充增强信息(SEI)NAL单元、访问单元定界符、序列NAL单元的末尾、比特流NAL单元的末尾、或填充数据NAL单元。重建解码图片可能需要参数集，而重建解码样本值不需要许多其他非VCL NAL单元。

保持不变通过编码视频序列的参数可以被包括在序列参数集中。除了解码过程可能需要的参数之外，序列参数集还可以可选地包含视频可用性信息(VUI)，视频可用性信息包括对于缓冲、图片输出定时、渲染和资源保留可能很重要的参数。在HEVC中，序列参数集RBSP包括可以由一个或多个图片参数集RBSP或包含缓冲时段SEI消息的一个或多个SEINAL单元参考的参数。图片参数集包含这样的参数，其在若干个编码图片中可能不变。图片参数集RBSP可以包括可以由一个或多个编码图片的编码切片NAL单元参考的参数。

在HEVC中，视频参数集(VPS)可以被定义为如下语法结构，该语法结构包含应用于零个或多个完整编码视频序列的语法元素，如由在如下PSS中找到的语法元素所参考的SPS中找到的语法元素的内容所确定的，上述PSS由在每个切片分段报头中找到的语法元素参考。

视频参数集RBSP可以包括可以被一个或多个序列参数集RBSP参考的参数。

视频参数集(VPS)、序列参数集(SPS)和图片参数集(PPS)之间的关系和分层可以描述如下。VPS在参数集分层中以及可缩放性和/或3D视频的上下文中驻留在SPS之上一级。VPS可以包括对于整个编码视频序列中的跨所有(可缩放性或视图)层的所有切片通用的参数。SPS包括对于整个编码视频序列中的特定(可缩放性或视图)层中的所有切片通用的参数，并且可以被多个(可缩放性或视图)层共享。PPS包括对于特定层表示(一个访问单元中的一个可缩放性或视图层的表示)中的所有切片通用的参数，并且可能由多层表示中的所有切片共享。

VPS可以提供关于比特流中的层的依赖性关系的信息以及适用于整个编码视频序列中的跨所有(可缩放性或视图)层的所有切片的许多其他信息。VPS可以被认为包括两个部分，即基础VPS和VPS扩展，其中VPS扩展可以可选地存在。

带外传输、信令或存储可以附加地或备选地用于除了容忍传输误差之外的其他目的，诸如易于访问或会话协商。例如，符合ISO基础媒体文件格式的文件中的轨的样本条目可以包括参数集，而比特流中的编码数据被存储在文件或另一文件中的其他位置。短语沿着比特流(例如沿着比特流指示)可以在权利要求和所描述的实施例中用于以带外数据与比特流相关联的方式指代带外传输、信令或存储。短语沿着比特流解码等可以指代解码与比特流相关联的所参考的带外数据(其可以从带外传输、信令或存储获得)。

SEI NAL单元可以包含一个或多个SEI消息，其对于输出图片的解码来说不是必需的，但是可以辅助相关过程，诸如图片输出定时、渲染、误差检测、误差隐藏和资源保留。在H.264/AVC和HEVC中指定了若干SEI消息，并且用户数据SEI消息使组织和公司能够指定SEI消息供自己使用。H.264/AVC和HEVC包含所指定的SEI消息的语法和语义，但是未定义用于在接收方中处置消息的过程。因此，编码器在创建SEI消息时需要遵循H.264/AVC标准或HEVC标准，并且分别符合H.264/AVC标准或HEVC标准的解码器不被需要来处理SEI消息以用于输出顺序一致性。在H.264/AVC和HEVC中包括SEI消息的语法和语义的原因中的一个原因是为了允许不同的系统规范同样地解释补充信息并且因此互操作。预计系统规范可能需要在编码端和解码端都使用特定的SEI消息，并且附加地，用于在接收方中处置特定SEI消息的过程可以被指定。

在HEVC中，存在两种类型的SEI NAL单元，即，后缀SEI NAL单元和前缀SEI NAL单元，具有彼此不同的nal_unit_type值。后缀SEI NAL单元中包含的(多个)SEI消息与VCLNAL单元相关联，该VCL NAL单元以解码顺序在后缀SEI NAL单元之前。前缀SEI NAL单元中包含的(多个)SEI消息与VCL NAL单元相关联，该VCL NAL单元按解码顺序在前缀SEI NAL单元之后。

编码图片是图片的编码表示。

在HEVC中，可以将编码图片定义为包含图片的所有编码树单元的图片的编码表示。在HEVC中，访问单元(AU)可以被定义为如下NAL单元的集合，NAL单元根据所指定的分类规则彼此相关联，按照解码顺序连续，并且包含具有nuh_layer_id的任何指定值的最多一个图片。除了包含编码图片的VCL NAL单元之外，访问单元还可以包含非VCL NAL单元。所述指定的分类规则可以例如将具有相同输出时间的图片或图片输出计数值关联到同一访问单元中。

比特流可以被定义为NAL单元流或字节流的形式的比特序列，其形成如下编码图片和相关联数据的表示，该编码图片和相关联数据形成一个或多个编码视频序列。在相同逻辑信道中，诸如在相同文件中或在通信协议的相同连接中，第一比特流之后可以是第二比特流。基本流(在视频编码的上下文中)可以被定义为一个或多个比特流的序列。第一比特流的末尾可以由特定的NAL单元指示，该NAL单元可以被称为比特流(EOB)NAL单元的末尾并且是比特流的最后一个NAL单元。在HEVC及其当前的草案扩展中，要求EOB NAL单元的nuh_layer_id等于0。

编码视频序列可以被定义为按解码顺序的编码图片的这样的序列，其独立地被解码，并且随后是另一编码视频序列或比特流的末尾或序列NAL单元的末尾。

在HEVC中，当特定的NAL单元(可以称为序列末尾(EOS)NAL单元的末尾)出现在比特流中并且具有nuh_layer_id等于0时，编码视频序列可以附加地或备选地(根据上述规范)被指定为结束。

可以如下定义图片组(GOP)及其特性。不管是否解码了任何先前图片，都可以对GOP解码。开放GOP是这样的图片组，其中当解码从开放GOP的初始帧内图片开始时，按照输出顺序在初始帧内图片之前的图片可能无法正确解码。换言之，开放GOP的图片可以指代(在帧间预测中)属于先前GOP的图片。HEVC解码器可以识别开始开放GOP的帧内图片，因为特定的NAL单元类型、CRA NAL单元类型可以用于其编码切片。封闭GOP是这样的图片组，其中当解码从封闭GOP的初始帧内图片开始时，所有图片都可以被正确解码。换言之，封闭GOP中没有图片是指先前GOP中的任何图片。在H.264/AVC和HEVC中，封闭GOP可以从IDR图片开始。在HEVC中，封闭GOP也可以从BLA_W_RADL或BLA_N_LP图片开始。与封闭GOP编码结构相比，开放GOP编码结构在压缩方面可能更有效，这是因为选择参考图片的灵活性更大。

图片结构(SOP)可以被定义为按解码顺序连续的一个或多个编码图片，其中按解码顺序的第一编码图片是最低时间子层处的参考图片，并且除了按解码顺序的潜在的第一编码图片之外没有编码图片是RAP图片。先前SOP中的所有图片都以解码顺序在当前SOP中的所有图片之前，并且下一SOP中的所有图片则以解码顺序在当前SOP中的所有图片之后。SOP可以表示分层且重复的帧间预测结构。术语“图片组(GOP)”有时可以与术语“SOP”互换使用，并且具有与SOP的语义相同的语义。

解码图片缓冲区(DPB)可以在编码器和/或解码器中使用。缓冲解码图片有两个原因，用于帧间预测中的参考以及用于将解码图片重新排序为输出顺序。由于H.264/AVC和HEVC为参考图片标示和输出重新排序提供了极大的灵活性，所以用于参考图片缓冲和输出图片缓冲的单独缓冲区可能会浪费存储器资源。因此，DPB可以包括用于参考图片和输出重新排序的统一的解码图片缓冲过程。当解码图片不再用作参考并且不需要用于输出时，可以将其从DPB中移除。

在H.264/AVC和HEVC的许多编码模式中，用于帧间预测的参考图片利用参考图片列表的索引而被指示。索引可以利用可变长度编码而被编码，这通常使较小的索引具有针对对应语法元素的较短值。在H.264/AVC和HEVC中，针对每个双向预测(B)切片的两个参考图片列表(参考图片列表0和参考图片列表1)被生成，并且针对每个帧间编码(P)切片的一个参考图片列表(参考图片列表0)被形成。

参考图片列表(诸如参考图片列表0和参考图片列表1)可以以两个步骤被构造：首先，生成初始参考图片列表。初始参考图片列表可以例如基于frame_num、POC、temporal_id、或关于预测分层的信息(诸如GOP结构)、或上述的任何组合而被生成。其次，可以通过参考图片列表重新排序(RPLR)语法(也称为参考图片列表修改语法结构)对初始参考图片列表重新排序，该参考图片列表重新排序语法可以被包含在切片报头中。可以通过参考图片列表修改语法结构来修改初始参考图片列表，其中可以通过列表的条目索引来标识初始参考图片列表中的图片。

许多编码标准(包括H.264/AVC和HEVC)可能具有解码过程以将参考图片索引导出到参考图片列表，该参考图片索引可以用于指示多个参考图片中的哪个参考图片被用于针对特定块的帧间预测。参考图片索引可以在一些帧间编码模式下由编码器编码到比特流中，或者例如可以在一些其他帧间编码模式下使用邻近块被导出(由编码器和解码器)。

可以针对单个预测单元导出若干个候选运动向量。例如，运动向量预测HEVC包括两个运动向量预测方案，即，高级运动向量预测(AMVP)和合并模式。在AMVP或合并模式中，针对PU导出运动向量候选的列表。存在两种候选：空间候选和时间候选，其中时间候选也可以称为TMVP候选。

例如，可以如下执行候选列表导出，同时应该理解，候选列表导出可能存在其他可能性。如果候选列表的占用不是最大，则空间候选(如果可用并且不是已经存在于候选列表中)首先被包括在候选列表中。此后，如果候选列表的占用尚未达到最大，则将时间候选包括在候选列表中。如果候选的数目仍未达到最大允许数目，则加入组合的双向预测候选(针对B切片)和零运动向量。在候选列表已经被构造之后，编码器例如基于速率失真优化(RDO)决策从候选决定最终运动信息，并且将所选择的候选的索引编码到比特流中。同样地，解码器从比特流解码所选择的候选的索引，构造候选列表，并且使用解码的索引从候选列表选择运动向量预测器。

运动向量锚位置可以被定义为图片区域内的这样的位置(例如水平和垂直坐标)，运动向量相对于该位置被应用。可以在切片报头、切片参数集、图块报头、图块参数集等中给出用于锚位置的水平偏移和垂直偏移。

利用运动向量锚位置的示例编码方法包括：将输入图片编码为编码组成图片；作为所述编码的一部分，重构与编码组成图片相对应的解码组成图片；将空间区域编码为编码图块，该编码包括：确定指示解码组成图片内的空间区域的分区域(region-wise)的锚位置的水平偏移和垂直偏移；对水平偏移和垂直偏移编码；确定编码图块的第一水平坐标和第一垂直坐标的位置处的预测单元相对于分区域锚位置被预测，其中第一水平坐标和第一垂直坐标分别是空间区域内的水平坐标和垂直坐标；指示预测单元相对于相对于分区域锚位置的预测单元锚位置而被预测；导出分别等于第一水平坐标和水平偏移之和以及第一垂直坐标和垂直偏移之和的预测单元锚位置；确定针对预测单元的运动向量；以及相对于预测单元锚位置应用运动向量以获得预测块。

其中使用运动向量锚位置的示例解码方法包括：将编码图块解码为解码图块，该解码包括：对水平偏移和垂直偏移解码；对如下指示解码，该指示是编码图块的第一水平坐标和第一垂直坐标的位置处的预测单元相对于相对于水平和垂直偏移的预测单元锚位置而被预测；导出分别等于第一水平坐标和水平偏移之和以及第一垂直坐标和垂直偏移之和的预测单元锚位置；确定针对预测单元的运动向量；以及相对于预测单元锚位置应用运动向量以获得预测块。

可缩放视频编码可以指编码结构，其中一个比特流可以例如以不同的比特率、分辨率或帧速率包含内容的多个表示。在这些情况下，接收器可以根据其特性(例如与显示设备最匹配的分辨率)提取期望的表示。备选地，服务器或网络元件可以根据例如接收器的网络特性或处理能力来提取比特流的要传输给接收器的部分。通过仅对可缩放比特流的某些部分解码，可以产生有意义的解码表示。可缩放比特流通常包括提供可用的最低质量视频的“基础层”和在与较低层一起被接收并且被解码时增强视频质量的一个或多个增强层。为了提高增强层的编码效率，该层的编码表示通常取决于较低层。例如，可以从较低层预测增强层的运动和模式信息。类似地，较低层的像素数据可以用于创建针对增强层的预测。

在一些可缩放视频编码方案中，视频信号可以被编码为基础层和一个或多个增强层。增强层可以增强例如时间分辨率(即，帧速率)、空间分辨率、或者仅增强由另一层或其一部分表示的视频内容的质量。每一层及其所有从属层都是视频信号的例如在某个空间分辨率、时间分辨率和质量水平下的一个表示，。在本文档中，将可缩放层及其所有从属层称为“可缩放层表示”。与可缩放层表示相对应的可缩放比特流的部分可以被提取并且被解码，以产生以某个保真度的原始信号的表示。

可缩放性模式或可缩放性维度可以包括但不限于以下各项：

-质量可缩放性：与增强层图片相比，基础层图片以较低的质量被编码，这可以例如在基础层中使用比增强层更大的量化参数值(即，用于变换系数目化的量化步长更大)来实现。如下所述，质量可缩放性还可以被分类为细粒或细粒度可缩放性(FGS)、中粒或中粒度可缩放性(MGS)、和/或粗粒或粗粒度可缩放性(CGS)。

-空间可缩放性：与增强层图片相比，基础层图片以较低的分辨率被编码(即，具有较少的样本)。空间可缩放性和质量可缩放性，尤其是其粗粒可缩放性类型，有时可以被视为相同类型的可缩放性。

-视图可缩放性，也可以称为多视图编码。基础层表示第一视图，而增强层表示第二视图。视图可以被定义为表示一个相机或视点的图片的序列。可以认为，在立体或两视图视频中，为左眼呈现一个视频序列或视图，而为右眼呈现平行视图。

-深度可缩放性，也可以称为深度增强编码。比特流的一个或一些层可以表示(多个)纹理视图，而其他一个或多个层可以表示(多个)深度视图。

应该理解，许多可缩放性类型可以组合并且一起应用。

术语“层”可以在任何类型的可缩放性的上下文中使用，包括视图可缩放性和深度增强。增强层可以指任何类型的增强，诸如SNR、空间、多视图和/或深度增强。基础层可以指代任何类型的基础视频序列，诸如基础视图、用于SNR/空间可缩放性的基础层或用于深度增强视频编码的纹理基础视图。

发送器、网关、客户端或另一实体可以选择可缩放视频比特流的传输层和/或子层。术语“层提取”、“层的提取”或“层下切换”可以指传输的层数少于发送器、网关、客户端或另一实体接收的比特流中可用的层数。层上切换可以指与发送器、网关、客户端或另一实体在进行层上切换之前传输的那些层相比传输(多个)附加层，即，重新开始传输先前在层下切换中已停止传输的一个或多个层。与层下切换和/或层上切换类似，发送器、网关、客户端或另一实体可以执行时间子层的下和/或上切换。发送器、网关、客户端或另一实体也可以执行层和子层的下切换和/或上切换。层和子层的下切换和/或上切换可以在同一访问单元等中执行(即，实际上同时)，或者可以在不同的访问单元等中执行(即，实际上在不同的时间)。

用于质量可缩放性(也称为信噪比或SNR)和/或空间可缩放性的可缩放视频编码器可以如下实施。针对基础层，可以使用传统的不可缩放视频编码器和解码器。基础层的重构/解码图片被包括在用于增强层的参考图片缓冲区和/或参考图片列表中。在空间可缩放性的情况下，可以在将重构的/解码的基础层图片插入针对增强层图片的参考图片列表之前对其进行上采样。可以将基础层解码图片插入到(多个)参考图片列表中，以用于与增强层的解码参考图片类似地对增强层图片编码/解码。因此，编码器可以选择基础层参考图片作为帧间预测参考，并且利用编码比特流中的参考图片索引来指示其使用。解码器从比特流(例如从参考图片索引)解码，将基础层图片用作针对增强层的帧间预测参考。当解码的基础层图片被用作针对增强层的预测参考时，其被称为层间参考图片。

虽然先前段落描述了具有两个可缩放性层(具有增强层和基础层)的可缩放视频编解码器，但是需要理解，可以将描述概括为具有多于两个层的可缩放性分层中的任何两个层。在这样的情况下，第二增强层可以在编码和/或解码过程中依赖于第一增强层，并且因此第一增强层可以被视为用于第二增强层的编码和/或解码的基础层。此外，需要理解的是，在增强层的参考图片缓冲区或参考图片列表中可能存在来自多于一层的层间参考图片，并且这些层间参考图片中的每个都可以被认为驻留在用于针对被编码和/或被解码的增强层的基础层或参考层中。此外，需要理解的是，除了参考层图片上采样之外，取而代之地或附加地可以进行其他类型的层间处理。例如，参考层图片的样本的位深度可以被转换为增强层的位深度和/或样本值可能会经历从参考层的颜色空间到增强层的颜色空间的映射。

可缩放视频编码和/或解码方案可以使用多环路编码和/或解码，其特性可以如下。在编码/解码中，基础层图片可以被重构/被解码以被用作在同一层内按编码/解码顺序的针对后续图片的运动补偿参考图片，或者被用作用于层间(或视图间或分量间)预测的参考。重构/解码的基础层图片可以被存储在DPB中。增强层图片同样地可以被重构/被解码，以用作在同一层内按编码/解码顺序的针对后续图片的运动补偿参考图片，或者被用作用于更高增强层(如果有的话)的层间(或视图间或分量间)预测的参考。除了重构/解码的样本值之外，基础/参考层的语法元素值或从基础/参考层的语法元素值导出的变量可以在层间/分量间/视图间预测中被使用。

层间预测可以被定义为以如下方式进行的预测，该方式取决于来自与当前图片的层(被编码或解码)不同的层的参考图片的数据元素(例如样本值或运动向量)。许多类型的层间预测存在，并且可以在可缩放视频编码器/解码器中被应用。层间预测的可用类型可以例如取决于编码简档，比特流或比特流内的特定层根据该编码简档被编码，或者在解码时，取决于比特流或比特流内的特定层被指示符合该编码简档的编码简档。备选地或附加地，层间预测的可用类型可以取决于正在使用的可缩放性的类型或可缩放编解码器或视频编码标准修正案(例如SHVC、MV-HEVC或3D-HEVC)的类型。

直接参考层可以被定义为如下层，该层可以被用于另一层的层间预测，该层是针对该另一层的直接参考层。直接预测层可以被定义为如下层，另一层是针对该层的直接参考层。间接参考层可以被定义为如下层，该层不是第二层的直接参考层但是是第三层的直接参考层，该第三层是第二层的直接参考层的直接参考层或间接参考层，该层是针对该第二层的间接参考层。间接预测层可以被定义为如下层，另一层是针对该层的间接参考层。独立层可以被定义为不具有直接参考层的层。换言之，不使用层间预测来预测独立层。非基础层可以被定义为除了基础层之外的任何其他层，并且基础层可以被定义为比特流中的最低层。独立的非基础层可以被定义为既是独立层又是非基础层的层。

类似于MVC，在MV-HEVC中，视图间参考图片可以被包括在正被编码或解码的当前图片的(多个)参考图片列表中。SHVC使用多环路解码操作(与H.264/AVC的SVC扩展不同)。SHVC可以被认为使用基于参考索引的方法，即，层间参考图片可以被包括在正被编码或解码的当前图片的一个或多个参考图片列表中(如上所述)。

针对增强层编码，可以在SHVC、MV-HEVC等中使用HEVC基础层的概念和编码工具。然而，可以在参考层中使用已经编码的数据(包括重构的图片样本和运动参数，又称为运动信息)来有效地编码增强层的附加层间预测工具可以集成到SHVC、MV-HEVC和/或相似的编解码器。

组成图片可以被定义为与整个输入图片的表示相对应的包围的(解码)编码图片的这样的部分。除了组成图片之外，包围的(解码)编码图片可以包括其他数据，诸如另一组成图片。

帧打包可以被定义为包括将多于一个输入图片(可以被称为(输入)组成帧或组成图片)布置为输出图片。通常，帧打包不限于任何特定类型的组成帧，或者组成帧不必彼此具有特定的关系。在许多情况下，帧打包用于将立体视频剪辑的组成帧布置为单个图片序列。布置可以包括将输入图片放置在输出图片内的空间上不重叠的区域中。例如，在并排布置中，两个输入图片被放置在彼此水平相邻的输出图片内。布置还可以包括将一个或多个输入图片分割为两个或多个组成帧分割，并将组成帧分割放置在输出图片内的空间上不重叠的区域中。可以将输出图片或经帧打包的输出图片的序列编码到比特流中，例如由视频编码器。比特流可以例如被视频解码器解码。解码器或解码之后的后处理操作可以从(多个)解码图片提取解码的组成帧以用于例如显示。

视频编码规范可以包含约束的集合，以用于将数据单元(例如H.264/AVC或HEVC中的NAL单元)关联到访问单元中。这些约束可以被用于从NAL单元的序列推断出访问单元边界。例如，在HEVC标准中指定了以下内容：

-访问单元包括nuh_layer_id等于0的一个编码图片、nuh_layer_id大于0的零个或多个VCL NAL单元以及零个或多个非VCL NAL单元。

-令firstBlPicNalUnit为nuh_layer_id等于0的编码图片的第一VCL NAL单元。firstBlPicNalUnit之前和firstBlPicNalUnit之前的最后一个VCL NAL单元之后的以下任何NAL单元中的第一NAL单元(如果有的话)指定新访问单元的开始：

-nuh_layer_id等于0(当存在时)的访问单元定界符NAL单元，

-nuh_layer_id等于0(当存在时)的VPS NAL单元，

-nuh_layer_id等于0(当存在时)的SPS NAL单元，

-nuh_layer_id等于0(当存在时)的PPS NAL单元，

-nuh_layer_id等于0(当存在时)的前缀SEI NAL单元，

-nal_unit_type在RSV_NVCL41..RSV_NVCL44范围内且nuh_layer_id等于0(当存在时)的NAL单元，

-nal_unit_type在UNSPEC48..UNSPEC55范围内且nuh_layer_id等于0(当存在时)的NAL单元。

firstBlPicNalUnit之前和firstBlPicNalUnit之前的最后一个VCL NAL单元(如果有的话)之后的第一NAL单元只可以是上面列举的NAL单元中的一个NAL单元。

-当在firstBlPicNalUnit之前且在firstBlPicNalUnit之前的最后一个VCL NAL之后(如果有的话)没有上述NAL单元时，firstBlPicNalUnit开始新的访问单元。

访问单元边界检测可以基于但可以不限于以下一项或多项：

-检测到基础层图片的VCL NAL单元是访问单元的第一VCL NAL单元，例如基于以下内容：

οVCL NAL单元包括块地址等，其是按解码顺序的图片的第一块；和/或

ο图片顺序计数、图片编号或类似的解码或输出顺序或定时指示符与先前的(多个)VCL NAL单元不同。

-检测到访问单元的第一VCL NAL单元，基于预定义的规则，例如基于nal_unit_type推断出在访问单元的第一VCL NAL单元之前并且在按解码顺序的先前访问单元的最后一个VCL NAL单元之后的非VCL NAL单元属于该访问单元。

在ISO/IEC 14496-15中针对H.264/AVC和HEVC指定的提取器使轨的紧凑形成成为可能，这些轨通过参考提取NAL单元数据。提取器是似NAL单元结构。可以将似NAL单元结构指定为像任何NAL单元一样包括NAL单元报头和NAL单元有效载荷，但是在似NAL单元结构中可能不会遵循起始代码仿真防止(这是NAL单元所需的)。针对HEVC，提取器包含一个或多个构造器。样本构造器通过参考从另一轨的样本中提取NAL单元数据。内嵌构造器包括NAL单元数据。当提取器由需要它的文件读取器处理时，该提取器在逻辑上被替换为按其出现顺序解析所包含的构造器时产生的字节。嵌套提取可能不被允许，例如样本构造器参考的字节应该不包含提取器；提取器不应该直接或间接参考另一提取器。提取器可以包含一个或多个构造器，以借助于类型‘scal’的轨参考从当前轨或从被链接至该提取器所驻留的轨的另一轨提取数据。提取器样本可以被定义为包括一个或多个提取器的样本。

所解析的提取器的字节为以下之一：

a)一个完整的NAL单元；要注意，在参考聚合器时，将同时复制所包括和所参考的字节

b)多于一个完整的NAL单元

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

样本构造器的字节仅从通过所指示的‘scal’轨参考所参考的轨中的单个所标识样本复制。对齐取决于解码时间，即，仅使用要采样时间表，然后是采样数目中的计数偏移。提取器是媒体级别的概念，因此在考虑任何编辑列表之前将其应用于目的地轨。然而，人们通常期待两个轨中的编辑列表相同。

可以使用以下语法：

语义可以定义如下：

-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(负一)是上一样本，依此类推。

data_offset：要复制的参考样本内的第一字节的偏移。如果提取器从该样本中的数据的第一字节开始，则偏移取值为0。可以在样本条目中提供LengthSizeMinusOne。

data_length：要复制的字节数。如果该字段取值为0，则可能需要data_offset以参考NAL单元长度字段的开头，并且复制完整的单个参考的NAL单元(即，要复制的长度是从data_offset参考的长度字段中获取的，在聚合器的情况下增加additional_bytes字段)。当data_offset+data_length大于样本的大小时，将从data_offset指向的字节到样本末尾(包括性的)的字节进行复制，即，data_length解析为(sample_size-data_offset)。提取器的分辨率可能会导致重构的有效载荷，针对该重构的有效载荷的字节少于该重构的有效载荷中的第一NAL的NALUnitLength中所指示的字节。在这样的情况下，可能要求读取器假设仅单个NAL单元被提取器重构，然后将该NAL的NALUnitLength重写为适当的值(即，重构的有效载荷的大小减去(LengthSizeMinusOne+1))。

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

class aligned(8)InlineConstructor(){

unsigned int(8) length；

unsigned int(8)inline_data[length]；

}

其中length是属于该字段之后的InlineConstructor的字节数，并且inline_data是解析内嵌构造器时要返回的数据字节。

图块轨可以被定义为包含编码比特流的一个或多个运动受限图块集的序列的轨。在没有比特流的其他图块轨的情况下对图块轨的解码可能需要专用解码器，例如可能需要在解码过程中跳过缺少的图块。ISO/IEC 14496-15中指定的HEVC图块轨能够存储一个或多个时间运动受限的图块集作为轨。当图块轨包含HEVC基础层的图块时，使用样本条目类型‘hvt1’。当图块轨包含非基础层的图块时，使用样本条目类型‘lht1’。图块轨的样本包括一个或多个完全切片分段中的一个或多个完全图块。图块轨独立于包括与该图块轨相同层的VCL NAL单元的任何其他图块轨。图块轨具有对图块基础轨的‘tbas’轨参考。图块基础轨不包括VCL NAL单元。图块基础轨使用对图块轨的‘sabt’轨参考来指示图块排序。可以通过按照轨参考的顺序从‘sabt’轨参考所指示的轨的时间对齐样本中收集编码数据来重构与图块基础轨中的样本相对应的HEVC编码图片。因此，可以理解，图块基础轨包括通过参考被参考的图块轨的编码视频数据。

根据ISO/IEC 14496-15的样本包括一个或多个长度字段定界的NAL单元。长度字段可以指的是NALULength或NALUnitLength。样本中的NAL单元并非以起始代码开头，而是使用长度字段来推断出NAL单元边界。长度字段定界的NAL单元的方案也可以称为长度前缀NAL单元。

子图片可以被定义为表示原始视频内容的空间子集的图片，该图片在内容产生侧在视频编码之前已经被拆分为空间子集。子图片比特流可以被定义为表示原始视频内容的空间子集的比特流，该比特流在内容产生侧在视频编码之前已经被拆分为空间子集。子图片轨可以被定义为与来自相同原始视频内容的(多个)其他轨具有空间关系并且表示子图片比特流的轨。子图片轨符合传统轨格式，诸如在ISO/IEC14496-15中为HEVC定义的‘hvc1’或‘hev1’。在生成子图片轨的方法中，在编码之前将源图片序列拆分为子图片序列。然后独立于其他子图片序列将子图片序列编码为单层比特流，诸如HEVC主简档比特流。编码的单层比特流被封装到子图片轨中。子图片轨的比特流可以用运动受限的图片编码，如稍后定义的。在生成子图片轨的另一方法中，用运动受限的图块集将源图片序列编码为比特流，并且例如通过切片报头修改和将所生成的比特流封装到轨中将MCTS序列转换为一致比特流，来生成子图片轨。通过这样的方式生成的子图片轨包括运动受限的图片。若干个比特流可以从相同的子图片序列被编码，例如针对不同的比特率。

收集器轨可以被定义为从其他轨隐式或显式地提取MCTS或子图片的轨。当由文件读取器解析时，收集器轨可以表示符合视频编解码器规范(诸如HEVC)的比特流。收集器轨可以例如提取MCTS或子图片以形成编码图片序列，其中MCTS或子图片被布置到网格。例如，当收集器轨提取两个MCTS或子图片时，它们可以布置为2x1网格的MCTS或子图片。图块基础轨可以被视为收集器轨，并且从其他轨提取MCTS或子图片的提取器轨可以被视为收集器轨。收集器轨也可以称为收集轨。作为用于向收集器轨提取的源的轨可以被称为收集项轨。

为了避免创建过多数目的提取器轨(例如避免为高分辨率和低分辨率图块的每个组合创建提取器轨)，可以用以下描述的机制来对作为备选以进行提取的轨分组。同样地，为了使相同的图块基础轨能够用于表示相同内容的不同比特率版本的共同定位的图块轨，可以使用以下机制。

文件写入器在文件中指示轨组(例如称为‘alte’轨组)包含作为可以备选地被用作以供提取的源的轨。

‘alte’组的标识符可以取自与轨标识符相同的编号空间。换言之，可能要求‘alte’组的标识符不同于所有轨标识符值。因此，‘alte’轨组标识符可以在传统上使用轨标识符的地方使用。具体地，‘alte’轨组标识符可以用作指示以供提取的源的轨参考。

由该盒形成的轨组的成员备选地被用作以供提取的源。track_group_type等于‘alte’的轨组的成员备选地被用作以供‘scal’或‘sabt’轨参考的源。等于track_ref_4cc的reference_type的TrackReferenceTypeBox可以列出(多个)‘alte’轨组的(多个)track_group_id值，除了轨ID值之外或替代轨ID值，其包含相同的alte_track_ref_4cc值。例如，除单独轨之外或代替单独轨，提取器轨可以通过‘scal’轨参考指向‘alte’轨组。‘alte’轨组中的任何单个轨都是合适的以供提取的源。以供提取的源轨可以在如下位置处被改变，轨被切换到的该位置处具有类型1或2的同步样本或SAP样本。

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

在许多视频通信或传输系统、传输机制和多媒体容器文件格式中，存在传输或存储与相同比特流的另一可缩放性层分离的可缩放性层的机制，例如传输或存储与(多个)增强层分离的基础层。可以认为将层存储在单独的逻辑信道中或通过单独的逻辑信道传输。例如，在ISOBMFF中，基础层可以存储为轨，并且每个增强层可以存储在另一轨中，可以使用所谓的轨参考将其链接至基础层轨。

许多视频通信或传输系统、传输机制和多媒体容器文件格式提供了将诸如不同轨或会话的单独逻辑信道的编码数据彼此关联的方式。例如，存在将同一访问单元的编码数据关联在一起的机制。例如，可以以容器文件格式或传输机制提供解码或输出时间，并且可以认为具有相同解码或输出时间的编码数据形成访问单元。

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

分块HTTP递送使服务器能够在多个部分中响应HTTP GET请求。然而，分块HTTP递送并不能移除通过创建独立影视片段而引起的固有编码和封装延迟。在IETF RFC 7230中指定了分块HTTP递送。

已经发起了用于HTTP上的自适应流式传输的若干商业解决方案，诸如平滑流式传输、/>自适应HTTP实时流式传输和/>动态流式传输，以及已经执行了标准化工程。自适应HTTP流式传输(AHS)在第三代合作伙伴计划(3GPP)分组切换流(PSS)服务的发行版9中首次标准化(3GPP TS 26.234发行版9：“透明的端到端分组切换流服务(PSS)；协议和编解码器”)。MPEG将3GPP AHS发行版9作为MPEG DASH标准的起点(ISO/IEC 23009-1：“HTTP上的动态自适应流(DASH)-部分1：媒体表示描述和分段格式，”国际标准，第二版次，2014)。3GPP继续致力于与MPEG通信的自适应HTTP流式传输，并发布了3GP-DASH(HTTP上的动态自适应流式传输；3GPP TS 26.247：“透明的端到端分组切换流服务(PSS)；HTTP上的渐进式下载和动态自适应流式传输(3GP-DASH)”。MPEG DASH和3GP-DASH在技术上彼此接近，因此可以统称为DASH。类似于MPEG-DASH的流系统包括例如在IETF RFC8216中指定的HTTP实时流式传输(也称为HLS)。为了对所述自适应流式传输系统进行详细描述，所有提供视频流式传输系统的示例，其中可以实施实施例，参照上述标准文档。本发明的各个方面不限于上述标准文档，而是针对一种可能的基础给出了描述，在此基础上可以部分或完全地实现本发明。

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

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

在DASH中，如下使用分层数据模型来构造媒体呈现。媒体呈现包括一个或多个时段的序列，每个时段包含一个或多个组，每个组包含一个或多个适应集，每个适应集包含一个或多个表示，每个表示包括一个或多个分段。组可以定义为预计不同时呈现的适应集的集合。适应集可以被定义为一个或若干个媒体内容部件的可互换编码版本集合。表示是媒体内容或其子集的备选选择中的一个选择，其通常因编码选择而不同，例如因比特率、分辨率、语言、编解码器等不同。分段包含某些持续时间的媒体数据以及用于解码和呈现所包括媒体内容的元数据。分段由URI标识，并且通常可以由HTTP GET请求请求。分段可以定义为与HTTP-URL和可选地MPD指定的字节范围相关联的数据单位。

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

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

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

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

用于DASH的端到端系统可以描述如下。媒体内容由原始服务器提供，该原始服务器可以是传统的web(HTTP)服务器。原始服务器可以与内容递送网络(CDN)连接，流内容通过该内容递送网络递送给边缘服务器并存储在边缘服务器中。MPD允许用信号通知内容的多个基础URL，这些URL可以用于宣布内容在不同边缘服务器中的可用性。备选地，内容服务器可以直接连接至互联网。Web代理可以驻留在DASH客户端与从其请求内容的原始服务器或边缘服务器之间路由HTTP业务的路径上。Web代理缓存HTTP消息，因此可以用缓存的内容满足客户端的请求。网络服务提供者通常使用它们，因为它们减少了从代理到原始服务器或边缘服务器所需的网络带宽。针对最终用户，HTTP缓存提供了较短的时延。DASH客户端通过访问网络(诸如移动蜂窝网络)连接至互联网。移动网络可以包括移动边缘服务器或移动边缘云，其操作类似于CDN边缘服务器和/或web代理。

当如上所述使用图块/子图片轨来封装媒体数据时，当使用精细的图块网格时，图块/子图片轨的文件格式样本的字节计数可以非常小，仅为几十字节。针对影视片段的文件格式(最为显著的TrackRunBox)元数据的开销可能很大。例如，当在视频轨中使用分层帧间预测时，TrackRunBox中同时存在sample_size和sample_composition_time_offset，因此TrackRunBox至少占用每样本8字节。

提取器轨用于以所得比特流符合基础视频格式(例如H.264/AVC或HEVC)的方式合并子图片轨。提取器轨中的样本大小可能很大，例如当使用精细的图块网格时，假定子图片轨的文件格式样本的字节计数可能非常小，只有几十字节，则每个提取的子图片轨需要10至20字节。

合并子图片轨的提取器轨中的样本通常包含以下内容：

-提取器的NAL单元报头：2字节

-按每个提取的图块/子图片轨：用于重写切片报头的内嵌构造器

-按每个提取的图块/子图片轨：样本构造器，例如针对2字节的长度和偏移字段可以为7字节

低时延实时流式传输的目标是最小化从捕获到显示的端到端延迟。在编码端，在创作MovieFragmentBox之前，必须编码影视片段的所有图片。因此，存在与编码端的影视片段持续时间相等的固有延迟。影视片段持续时间通常与DASH中的分段持续时间相同，即，通常的策略是具有恰好每分段一个影视片段。允许创建每分段多个影视片段，但这带来了字节计数开销成本。

每个自包含的影视片段处都存在以下盒：

-MovieFragmentBox：8字节

-MovieFragmentHeaderBox：16字节

-TrackFragmentBox：8字节TrackFragmentHeaderBox：16至40字节

-一个或多个TrackRunBox，可变大小大于或等于16字节

-零个或多个SampleGroupDesctiptionBox

-零个或多个SampleToGroupBox

-一个或多个MediaDataBox，每个具有8字节盒报头

因此，引入自包含(与扩展样本中的先前影视片段相比)的字节计数开销至少为8+16+8+16+16+8＝72字节，并且由于存在可选字段或盒而通常更多。如果影视片段针对每个图片被建立，并且图像速率为30Hz，则与具有每秒一个影视片段相比，最小比特率开销约为17kbps。当使用精细的图块网格时，这样的开销对于图块/子图片轨尤其重要。

现在介绍了一种用于减少开销的改进方法和相关装置。

如图5所示，根据一个方面的方法包括：在容器文件中写入至少一个样式，该至少一个样式指示样式中的每个样本的每样本元数据(500)；以及通过将相应媒体数据的样本与该样式的每样本元数据循环地关联，在分段元数据中指示至少一个样式中的哪个样式用于相应媒体数据(502)。因此，该文件包含每样本元数据的一个或多个样式，并且使紧凑的轨片段运行成为可能，该紧凑的轨片段运行给出对样式的参考，该样式被用于将每样本元数据循环地关联到轨片段运行的样本。

在一个示例中，每样本元数据样式具有表示为e₁、e₂、e₃的三个元素，并且轨片段运行具有表示为s₁、s₂、s₃、…、s₇的七个样本。每样本元数据被循环地指派给样本，即，s₁被指派有e₁、s₂被指派有e₂，s₃被指派有e₃，s₄被指派有e₁，s₅被指派有e₂，s₆被指派有e₃，并且s₇被指派有e₁。

每样本元数据可以包括但不限于以下一项或多项：

-示例标志集合，例如用于指示依赖性和/或同步样本

-用于指示样本大小的比特、半字节或字节数目

-定时信息，诸如但不限于

ο样本持续时间或指示解码时间或与先前样本的解码时间差的其他信息

ο样本合成时间偏移或指示合成时间或可能相对于解码时间的合成时间差的其他信息

如图6所示，根据一个方面的方法包括：从容器文件解析至少一个样式，该至少一个样式指示样式中的每个样本的每样本元数据(600)；从分段元数据解析至少一个样式中的哪个样式用于相应的媒体数据(602)；以及将相应媒体数据的样本与该样式的每样本元数据循环地关联(604)。

根据一个实施例，容器文件是根据ISOBMFF构造的，并且该方法还包括：在容器文件中写入一个或多个样式，该一个或多个样式包括TrackRunBox元数据和样本大小的比特/半字节/字节计数；以及在TrackRunBox中包括样本大小的每样本信令。

因此，在TrackRunBox之前提供每样本元数据的样式。用于每样本元数据的样式的容器可以包括但不限于MovieExtendsBox和MovieFragmentBox之一或两者。MovieExtendsBox可能是优选的，因为它可以在多个轨之间共享相同的样式和/或存在于DASH初始化分段中，因此在媒体分段之前被递送。

每样本元数据样式可以对应于图片的结构。例如，可以将包括第一数目的图片的分层的图片的结构指派给第一每样本元数据样式，并且可以将包括第二数目的图片的分层的图片的结构指派给第二每样本元数据样式，其中第一数目不同于第二数目。

在与每样本元数据样式和TrackRunBox相关的指示中，有若干个选项用于处置RAP图片(或同样地帧内编码图片)。选项包括但不限于以下内容：

-在每样本元数据样式中包括RAP图片，该图片还包括其他图片，例如图片的完全结构。由于该选项，可能需要指示针对相同其他图片的另一每样本元数据样式。

-在每样本元数据样式中包括RAP图片，该图片还包括其他图片，例如图片的完全结构，指示每样本元数据样式始于仅有条件地应用于轨运行的第一样本的图片，并针对轨运行(例如用TrackRunBox的特定盒标志)指示每样本元数据样式中的第一条目是否应用于轨运行的第一样本。在一个示例中，每样本元数据样式具有表示为e₁、e₂、e₃的三个元素，其中第一条目被指示为有条件地应用于轨运行的第一样本，并且轨片段运行具有表示为s₁、s₂、s₃、…、s₇的七个样本，并指示每样本元数据样式中的第一条目应用于轨运行的第一样本。每样本元数据被循环地指派给样本，除了第一样本的e₁之外，即，s₁被指派有e₁、s₂被指派有e₂，s₃被指派有e₃，s₄被指派有e₂，s₅被指派有e₃，s₆被指派有e₂，并且s₇被指派有e₃。

-在每样本元数据样式中包括RAP图片，该RAP图片不包含其他图片，并且在每次轨运行中恰好指示一个每样本元数据样式。由于该选项，可能需要指定仅包含RAP图片的轨运行。

-将RAP图片包括在不包含其他图片的每样本元数据样式中，允许指示应用于轨运行的初始样本一次的初始每样本元数据样式，并指示应用于轨运行的剩余样本的每样本元数据样式。可以例如通过TrackRunBox的特定盒标志来控制轨运行中的初始每样本元数据样式指示的存在。

-允许直接在TrackRunBox中指示针对轨运行的第一样本的样本元数据，并指示被应用于轨运行的剩余样本的每样本元数据样式。例如，可以通过TrackRunBox的特定盒标记来控制针对TrackRunBox中的第一样本的样本元数据的存在。因此，由于被文件创作器控制，轨片段运行可以从帧内编码图片开始，针对该帧内编码图片的元数据与图片样式的元数据分开地被给出。用于开始轨片段运行的帧的元数据可以在TrackRunBox之前被提供，优选地在MovieExtendsBox中被提供，但也可以在MovieFragmentBox中存在。

根据一个实施例，除了指示哪个每样本元数据样式应用之外，还指示或推测用于每样本元数据样式的开始索引。开始索引仅针对每样本元数据的循环指派的第一循环被应用于轨运行的样本。在一个示例中，每样本元数据样式具有表示为e₁、e₂、e₃的三个元素，并且轨片段运行具有表示为s₁、s₂、s₃、…、s₇的七个样本，并且在TrackRunBox中指示开始索引等于2。从e₂开始，每样本元数据被循环地指派给样本，即，s₁被指派有e₂、s₂被指派有e₃，s₃被指派有e₁，s₄被指派有e₂，s₅被指派有e₃，s₆被指派有e₁，并且s₇被指派有e₂。

根据一个实施例，容器文件包括默认提取器的至少一个样式，并且该方法还包括将提取器轨的样本循环地指派给至少一个样式，并将至少一个样式的样式中的默认提取器指派给提取器轨的样本的提取器。因此，紧凑的提取器轨成为可能。

如果若干个轨共享提取器样本的相同样式，则这些样式可以被包括在由若干个轨共享的语法结构中，诸如MovieExtendsBox。如果只有一个或少数轨共享提取器样本的相同样式，或者如果该样式的字节计数相对较小，则它们可以被包括在特定于轨的语法结构中，诸如TrackFragmentBox。

根据一个实施例，该方法还包括指示针对轨片段运行的样本偏移保持不变。例如可以在TrackRunBox的盒报头标志中携带该指示。因此，该指示使相同的样本数据被指派给轨片段运行的所有样本。例如，当相同的样本内容适于轨片段运行的所有提取器样本时，可以使用该实施例。

当被应用用于低时延实时流式传输时，该方法避免在能够传输影视片段之前对影视片段的所有媒体样本进行编码的需要。与创建非常短的影视片段相比，所呈现的方法避免了字节计数开销。下面描述用于低时延实时流式传输的方法的实施例。

根据一个实施例，该方法还包括编译流清单，该流清单指示针对分段报头和对应的分段有效载荷的单独URL。流清单(诸如DASH MPD)可以提供URL模板，或者附加MPD中所给定的基础URL的URL模板方案可以被指示是适用的。

根据一个实施例，流清单还可以指示分段有效载荷中的数据被紧密打包并且按解码顺序。分段有效载荷可以指的是例如MediaDataBox。紧密打包指属于视频比特流的分段有效载荷的所有字节，即，分段有效载荷包括视频比特流的连续字节范围。这样的指示可以被提供例如作为DASH MPD中的补充属性。分段有效载荷中的视频比特流可以是封装的视频比特流。例如，分段有效载荷可以包括ISOBMFF文件的视频轨的连续样本集合。

可以使用如上所述的每样本元数据样式来创作分段。分段报头的大小是基于分段持续时间估计的。应用于分段的第一样本的偏移的值对应地被生成，该偏移的值可以被指示为例如TrackFragmentHeaderBox中的base_data_offset。如果编码突然终止，则封装器可能需要在TrackFragmentBox的末尾写入(多个)FreeBox。

服务器实体可以使分段报头的初始字节范围可用于HTTP分块传输编码。初始字节范围指示应用于分段有效载荷的每样本元数据的样式。初始字节范围排除至少一些样本大小。初始字节范围可以例如包括MovieFragmentBox的初始部分，上至但不包括TrackRunBox中的样本大小列表。可以使分段有效载荷可用于HTTP分块传输编码，例如用于图片的每个分层结构。

在各个实施例中的服务器或服务器实体可以例如是但不限于以下之一：

-原始服务器

-内容递送网络(CDN)的边缘服务器

-代理服务器

-移动边缘云，例如在5G移动网络中操作

-媒体网关

-家庭服务器

-处理设备，诸如个人计算机或游戏机，其可以被连接至诸如头戴式显示器等视看设备

根据一个实施例，低时延播放器可以使用并行HTTP连接来分别获取分段报头和分段有效载荷。根据一个实施例，传统播放器可以使用传统URL来获取具有报头和有效载荷的完整分段。

当分别请求分段报头和有效载荷时，低时延服务器可以如下操作：

-通过仅在影视片段完成后才发送一个块中的初始字节范围，并发送TrackRunBox的其余部分，服务器将HTTP分块传输编码用于分段报头部分。

-服务器将HTTP分块传输编码用于分段有效载荷，例如图片的结构基础。

可以利用图7所示的协议序列图来描述客户端-服务器通信。服务器向客户端提供流清单(1)(诸如MPD)。客户端针对分段报头(2)和分段有效载荷(3)发送分别的HTTP GET请求。服务器通过发送分段报头的初始字节范围块(4)，并且其后发送分段有效载荷的对应块(5)，来响应于HTTP GET请求。因此，客户端(诸如低时延播放器)获得分段报头的初始字节范围，并且使用轨片段运行模板来推断出针对样本的元数据(最为显著的是合成时间)。因此，分段报头不必在传输分段有效载荷的块之前完成，但是分段报头的剩余字节范围块可以稍后被发送(6)。

技术人员将了解，尽管图6的图将服务器示出为将MPD递送给客户端，但是可以从服务器之外的另一实体将MPD递送给客户端。

分段有效载荷被紧密打包的信息使得可以如下检测访问单元边界：MediaDataBox包括长度前缀NAL单元，因此可以从MediaDataBox的有效载荷可靠地标识NAL单元。由于NAL单元按照正确的解码顺序，因此H.264和H.265中指定的常规访问单元边界检测足以确定样本大小。因此，不需要从分段报头接收样本大小来解码和播放媒体数据。

本发明的另一方面涉及客户端操作。如图8所示，该操作可以包括：接收至少一个样式，该至少一个样式指示样式中的每个样本的每样本元数据(850)；接收媒体数据的字节范围和分段元数据的初始部分，该初始部分通过将相应媒体数据的样本与样式的每样本元数据循环地关联来指示至少一个样式中的哪个样式用于相应媒体数据(852)；接收一个或多个指示的集合，其指示字节范围包括连续的且以解码顺序出现的长度前缀媒体数据单元(854)；从长度前缀推断出字节范围内的媒体数据单元的边界(856)；使用访问单元边界检测来推断出媒体数据单元到访问单元的映射(858)；以及将推断出的访问单元与样式的每样本元数据循环地关联(860)。

本文描述的实施例可以有助于实现显著优点。例如，影视片段元数据的字节计数开销大幅度减少，至少有两个原因：所有循环重复的元数据仅被传输一次，而不是对每个样本重复，并且循环重复的元数据可能可以在若干个轨之中共享。换言之，跨许多轨使用相同的样本关联，诸如表示相同内容的所有图块或子图片轨。

而且，提取器轨的字节计数开销大幅度减少，至少有两个原因：所有循环重复的提取器样本仅被传输一次，而不是针对每个采样实例都具有单独的提取器样本，并且提取器样本的循环重复样式例如在相同内容的所有提取器轨表示360°内容的不同视图定向的情况下可能可以在若干个轨之中共享。

在低时延实时流式传输中，可以有利地避免在能够传输影视片段之前对影视片段的所有媒体样本编码的需要。在图9a和图9b中示意性地图示了在低时延实时流式传输中获得的优点，其中图7的协议序列图被扩展为包括编码和封装功能以及显示功能。图9a图示了根据本文描述的实施例的编码、封装和显示功能，并且图9b图示了根据传统编码和封装方法的编码、封装和显示功能。

在图9a中，可以观察到可以显示已递送的分段有效载荷块，而同一分段的剩余分段有效载荷块尚未被编码、封装和/或递送。

传统上，如图9b所示，在传输整个分段之前，先对其进行编码和封装。只有接收到整个分段，分段的媒体数据的显示才能开始。

与创建非常短的影视片段相比，本文描述的实施例避免了字节计数开销。

下面提供具有语法和语义的紧凑型TrackRunBox设计的示例实施例。该示例实施例落入以下类别：允许直接在TrackRunBox中指示轨运行的第一样本的样本元数据，并指示被应用于轨运行的剩余样本的每样本元数据样式。技术人员了解到，可以通过以不同的方式实施下面的一些特征来实现相同或类似的技术效果。

根据一个实施例，可以定义以下标志中的一个或多个：

-0x000100 SAMPLE_DURATION_PRESENT：指示样本都有自己的持续时间，否则使用默认值。

-0x000200 SAMPLE_SIZE_PRESENT：样本都有自己的大小，否则使用默认值。

-0x000400 SAMPLE_FLAGS_PRESENT；样本都有自己的标志，否则使用默认值。

-0x000800 SAMPLE_CT_OFFSETS_PRESENT；样本具有合成时间偏移(例如用于MPEG中的I/P/B视频)。

-0x000001 DATA_OFFSET_PRESENT；data_offset存在于TrackRunBox中

-0x001000 FIRST_SAMPLE_PRESENT；指示第一样本不是来自轨运行样式

-0x000004 FIRST_SAMPLE_FLAGS_PRESENT；当未设置FIRST_SAMPLE_PRESENT标志时，在TrackRunBox的版本1中应该为0。在TrackRunBox的版本1中为0时，指示第一样本使用默认标志。在TrackRunBox的版本1中为1时，指示给出针对第一样本的标志。

TrackRunPatternBox的语法可以指定如下。可以允许在MovieExtendsBox或MovieFragmentBox中携带TrackRunPatternBox。

/>

TrackRunBox的版本2和3的语法可以指定如下。可能要求tr_flags中的SAMPLE_SIZE_PRESENT的值与TrackRunPatternBox标志中的SAMPLE_SIZE_PRESENT的值相同。

/>

在以上语法中，sample_flags[i]、sample_duration[i]、sample_size[i]和sample_composition_time_offset[i]分别提供了轨运行中的第i个样本的样本标志、样本持续时间、样本大小和样本合成时间偏移。当i在initSampleFlag到sample_count_minus_1的范围内时(包括性的)，sample_flags[i]、sample_duration[i]和sample_composition_time_offset[i]被推测为等于来自具有索引pat_idx(用于TrackRunBox语法的第i个环路条目的inPatternIdx的值)的轨样式运行的第inPatternIdx个条目的相应值。

在紧凑型TrackRunBox设计的另一示例实施例中，下面提供了语法和语义。该示例实施例落入允许指示在TrackRunPatternStruct中的轨运行的第一样本的样本元数据的类别。

/>

虽然通常不会在基于HTTP的流中在MovieBox中包括样本，而是将所有样本携带在影视片段中，但压缩MovieBox中所包括的样本大小和定时盒对于其他应用(诸如渐进式下载)可能很重要。可以通过提供样本大小、持续时间和合成时间偏移的样式并且指示例如基于块应用哪个样式来类似地应用实施例。在ISOBMFF的上下文中，块可以被定义为针对一个轨的连续样本集。可以针对由TrackBox描述的样本定义(多个)块。

所标识的媒体数据盒可能具有与MediaDataBox相同的语义，但是它附加地包含如下标识符，该标识符用于设置对所包含的媒体数据的数据参考。标识符例如可以是所标识的媒体数据盒所包含的第一元素。可以如下指定所标识的媒体数据盒的语法，其中imda_identifier是该盒的标识符。要注意的是，虽然在语法中使用类型为64位无符号整数的imda_identifier，但其他字段长度和其他基础数据类型(例如字符串)也类似地是可能的。

aligned(8)class IdentifiedMediaDataBox extends Box('imda'){

unsigned int(64)imda_identifier；

bit(8)data[]；//直到盒的末尾

}

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

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

extends FullBox('imdt',version＝0,flags){

unsigned int(64)imda_ref_identifier；

}

根据一个实施例，代替基于分段持续时间来估计分段报头的大小，所标识的媒体数据盒被使用。确定针对分段的所标识的媒体数据盒的标识符值，并且该标识符值被提供作为针对该分段的媒体数据的数据参考基础。

根据可以独立于其他实施例或与其他实施例一起应用的实施例，将用于所标识的媒体数据盒的标识符的模板方案定义为用作样本数据的数据参考，例如在DataReferenceBox中。模板方案可以基于但不限于影视片段序列号(诸如MovieFragmentHeaderBox的sequence_number字段)或轨片段解码时间(诸如TrackFragmentBaseMediaDecodeTimeBox的baseMediaDecodeTime字段)。需要理解的是，除了上述那些标识符之外或代替上述标识符，为影视片段或轨片段提供的任何标识符都可能应用于模板方案。在一个示例中，以下语法可以用于使用模板参考所标识的媒体数据盒来导出标识符：

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

extends FullBox('imdt',version＝0,flags){

}

DataEntryTfdtBasedImdaBox标识IdentifiedMediaDataBox，IdentifiedMediaDataBox包含通过与该DataEntryTfdtBasedImdaBox相对应的data_reference_index被访问的媒体数据。媒体数据偏移0指向具有imda_identifier等于TrackFragmentBaseMediaDecodeTimeBox的baseMediaDecodeTime的IdentifiedMediaDataBox的有效载荷的第一字节。使用64位imda_identifier值来携带baseMediaDecodeTime的64位值。如果使用的是32位baseMediaDecodeTime值，则64位imda_identifier的最高有效位可以被设置为0。针对自包含的影视片段，当所参考的数据参考条目是类型为DataEntryTfdtBasedImdaBox的数据参考条目时，IdentifiedMediaDataBox的imda_identifier需要等于TrackFragmentBaseMediaDecodeTimeBox的baseMediaDecodeTime。

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

根据一个实施例，例如在样本条目中提供针对提取器的语法元素的样式。作为样本条目的备选，可以在样本组中提供针对提取器的语法元素的样式。样式中给定的语法元素可以由内容创作器选择。

根据一个实施例，提供了单个样式，其可以被认为例如在样本条目中提供提取器的语法元素的默认值，因此从对样本条目参考的样本排除那些语法元素。下面提供了一个示例实施例，其中定义了称为HevcExtractorPatternBox的提取器。在该示例实施例中，恰好给出了默认提取器的一个样式，即，HevcExtractorPatternBox提供针对一个样本的默认提取器。需要理解的是，可以针对默认提取器的多于一个样式类似地实现该示例实施例，由此可以将多于一个样式循环地指派给样本。

HevcExtractorPatternBox的零个或一个实例可以存在于样本条目中(在一些实施例中)或样本组描述条目中(在一些实施例中)。当存在时，该盒包含参考该样本条目或样本组描述条目的每个样本的紧凑型提取器的样式以及针对该紧凑型提取器的语法元素的默认值。可以推断出，传统上格式化参考具有零个HevcExtractorPatternBox实例的样本条目或样本组描述条目的样本(例如本地可以包含NAL单元或传统提取器)。

例如，可以使用以下HevcExtractorPatternBox语法和相关语法结构：

/>

在以上语法中，default_presence_flags控制在DefaultHevcExtractorParametersBox内将哪些语法元素值作为常量默认值给出，以及在样本内的紧凑型提取器内提供哪些语法元素值。

default_constructor[cidx]提供第eidx个紧凑型提取器的第cidx个构造器，其参考该样本条目。

当存在时，default_track_ref_index、default_sample_offset、default_data_offset和default_data_length分别具有与SampleConstructor语法结构的track_ref_index、sampel_offset、data_offset和data_length相同的语义。

紧凑型提取器可以被定义为具有与提取器相同的语义和约束，不同之处在于，在DefaultHevcExtractorParametersBox中提供用于解析紧凑型提取器的一些语法元素值。

例如，以下语法和相关语法结构可以用于紧凑型提取器：

紧凑型提取器具有与提取器相同的语义和约束，不同之处在于，在HevcExtractorPatternBox中提供用于解析紧凑型提取器的一些语法元素值。为了解析包含(多个)紧凑型提取器的样本，在样本的开始将eidx的值设置为等于0。为了解析样本的第eidx个CompactExtractor，将default_presence_flags设置为HevcExtractorPatternBox的第eidx个DefaultHevcExtractorParametersBox的default_presence_flags。

解析提取器样本需要所有参考数据可用。当数据从其被提取的轨的数目相对较大时，轨中的至少一个轨的延迟传输可能会导致无法解析提取器样本，因此可能会导致回放中断。在一些情况下，提取器轨或用于提取的备选轨之间的客户端的选择可以是这样的，可能会偏好省略延迟并且继续不中断的回放的轨的数据。例如，延迟轨可以表示视口之外的内容，或者延迟轨的内容可以由其他提取的(多个)轨表示，诸如由提取器轨完全表示的内容的低分辨率版本。

根据一个实施例，提供了用于在提取器无法被解析的情况下替换提取器的备用在线数据。有利地，以不需要在样本中重复的方式来提供在线数据，但是以可以被多个样本(例如在样本条目或样本组描述条目中)参考的方式来提供。在线数据可以例如包括一个或多个VCL NAL单元，其仅包括跳过编码的编码树单元。跳过编码可以指的是推测或指示预测模式，诸如帧间预测切片中的合并模式，并且省略预测误差编码。针对跳过编码的块，不存在针对预测误差的语法元素。

该实施例至少提供了以下优点：客户端不需要自身能够推断出有效的VCL NAL单元数据，这可以涉及例如部分的编码器实施方式，该部分的编码器实施方式涉及例如CABAC编码器。而且，内容创作器可以指示省略对由提取器参考的数据的解码是否是可接受的客户端策略。

样本内的针对特定索引的提取器的备用在线数据应该用于解析样本，直到由该特定索引的实际提取器参考的(多个)轨包含同步样本或流访问点(SAP)为止。

根据一个实施例，HevcExtractorPatternBox被附加如下。

当存在时，针对特定eidx值的BackupInlineConstructorBox提供在线数据，作为解析第eidx个紧凑型提取器的备选，例如在紧凑型提取器的参考数据不可用的情况下。backup_inline_data提供了使用备份在线数据解析提取器时要返回的数据字节。

在可以在有或没有上述备份在线构造器实施例的情况下应用的实施例中，在解析参考提取器样式的提取器样本时，从其中一个被选择的提供多于一个备选提取器。基于预定义或所指示的条件选择备选。条件可以是但不限于以下之一：

-轨标识符(track_ID)：当‘scal’轨参考参考轨组时，将选择轨组中的轨中的一个轨作为以供提取的源。可以基于在轨组中选择哪个轨作为以供提取的源来选择备选提取器。

-轨参考索引：在特定类型的轨参考盒中(例如‘scal’或‘psex’，后者可能代表潜在的以供提取的源)，可以包括多个轨作为潜在的以供提取的源。可以基于所指示的潜在源中选择的参考来定义和选择备选提取器。特定类型的轨参考盒的轨参考索引可以用于指示备选提取器。

-同步和/或SAP样本类型：可以基于参考样本是同步样本还是特定类型的SAP样本来选择备选提取器。例如，如果参考样本是类型1或2的同步样本或SAP样本，则可以选择第一提取器，否则可以选择第二提取器。

接下来，相对于较早的实施例，提供了一个示例实施例，该示例实施例使用用于备选提取器的轨参考索引和对潜在以供提取的源的‘psex’轨参考。可以为提取器样式中指定的每个提取器提供若干备选。盒标志中的一个盒标志(此处为default_presence_flags&32，其中default_presence_flags为DefaultHevcExtractorParametersBox的盒标志)可以用于指示哪个提取器参数集合是特定eidx值(即，提取器样式内的提取器的特定索引)的最后一个备选。如果提取器参数集合不是特定eidx值的最后一个，则提供指示给定提取器参数应用于'psex'轨参考盒的(多个)哪个索引的轨参考索引(此处为DefaultHevcExtractorParametersBox的ref_index[i])。可以使用以下语法：

用于降低流比特率的360°视频流的最新趋势可以称为视口相关流或视口自适应流，并且可以简要描述如下：覆盖主视口的360度视频内容的子集(即，当前视图定向)以最佳质量/分辨率进行传输，而剩余的360度视频则以较低的质量/分辨率进行传输。可以通过基于图块的编码和流式传输方法来实现视口自适应流。在基于图块的编码和流式传输的一种方法中，以所得的比特流包括运动受限的图块集的方式执行编码。使用运动受限的图块集对相同源内容的若干个比特流进行编码。从比特流中提取一个或多个运动受限的图块集(MCTS)序列，并且将每个提取的运动受限的图块集序列作为轨(例如HEVC图块轨或子图片轨)存储在文件中。客户端通过以下方式有选择地接收轨：与覆盖剩余的当前不可见视口的质量或分辨率相比，可以为当前视口接收质量更好或分辨率更高的MCTS轨。客户端将接收到的轨的内容合并，即，将接收到的MCTS合并到要解码的比特流中。由于查看定向可能随时间变化，所以所选轨和MCTS也可能随时间变化，并且附加地，合并图片内的相应MCTS的位置也可能从一个合并图片改变为另一合并图片。提取器轨可以由内容创作提供和/或可以由播放器处理以进行选择和/或合并MCTS，以进行视口相关的流式传输和/或回放。

除其他外，上述实施例在参考样本是RAP样本时能够使用第一提取器，而在参考样本是非RAP样本时能够使用第二提取器。全向视频流中的视口改变可能会导致需要请求先前未接收到的高质量或高分辨率MCTS序列的集合，而继续接收先前也接收到的高质量或高分辨率的MCTS序列子集可能是适当的。可以从携带那些MCTS序列的子图片或图块轨中的RAP图像开始接收先前未被接收的MCTS序列，而其他接收到的MCTS序列将有利地继续使用帧间预测。可以针对不同的RAP图片时段和/或不同的RAP图片时间位置创作共同定位子图片或图块轨的若干版本。有利地，共同定位的子图片或图块轨将被指示为播放器可以从中选择的备选。如果视口改变要求以前未以相同的分辨率或质量接收到的特定子图片或图块位置，则播放器可以从在适当位置(例如在开始下一分段时)具有RAP图片的备选中选择版本。由于RAP图片(或I切片)的切片报头可能与非RAP图片(或P/B切片)的切片报头不同，因此单个提取器可能不足以提取I切片或P/B切片，取决于播放器对以供提取的源的选择。因此，上述实施例适于视口相关的流式传输，并且能够以仅对MCTS的子集进行帧内预测而对其他MCTS继续进行帧间预测的方式实现视口改变，从而避免了比特率尖波并节省了流比特率。

在一个实施例中，第一子图片或图块轨和第二子图片或图块轨被指示为针对提取的备选，为第一轨和第二轨具有相同图片类型(例如没有前导图片的BLA)的样本创建第一提取器样式，并且为第一轨具有第一图片类型(例如没有前导图片的BLA)和第二轨具有第二图片类型(例如TRAIL)的样本创建第二提取器样式。例如，可以通过样本组指示针对特定提取器样本使用哪个提取器样式的选择。

作为HEVC的RAP图片，可以使用没有前导图片或具有可解码前导(RADL)图片的BLA或CRA图片。选择在BLA和CRA图片中指示的参考图片集，使其与其他比特流中的时间对齐的非RAP图片中的参考图片相同。由于图片类型(nal_unit_type)对于图片的所有VCL NAL单元可能都要求相同(例如在HEVC中)，因此使用RAP和非RAP图片作为备选以供提取的源的提取器样式可能会改变nal_unit_type来指示非RAP图片，诸如HEVC的TRAIL图片。

尽管上面相对于提取器样式描述了与备用在线构造器和备选提取器相关的实施例，但是需要理解的是，它们可以相对于提取器样本类似地实现，其中通过参考提取器样式，提取器样本可以是传统的(包括提取器本身而不是参考提取器样式)或紧凑型的(例如类似于上面的CompactExtractor格式化)。例如，可以在提取器样本中提供在线构造器的若干备选，并基于用作以供提取的源的track_reference_index进行选择。

图10示出了适于采用本发明的实施例的视频解码器的框图。图10描绘了两层解码器的结构，但是要了解的是，解码操作可以类似地用于单层解码器中。

视频解码器550包括用于基础层的第一解码器区段552和用于预测层的第二解码器区段554。框556图示了分用器，其用于将关于基础层图片的信息递送给第一解码器区段552并且将关于预测层图片的信息递送给第二解码器区段554。附图标记P’n代表图像块的预测表示。附图标记D’n代表重构的预测误差信号。框704、804图示了初步重构的图像(I’n)。附图标记R’n代表最终的重构图像。框703、803图示了逆变换(T^-1)。框702、802图示了逆量化(Q^-1)。框701、801图示了熵解码(E^-1)。框705、805图示了参考帧存储器(RFM)。框706、806图示了预测(P)(帧间预测或帧内预测)。框707、807图示了滤波(F)。框708、808可以用于将解码的预测误差信息与预测的基础层/预测层图像组合以获得初步重构图像(I’n)。可以从第一解码器区段552输出709初步重构和滤波的基础层图像，并且可以从第一解码器区段554输出809初步重构和滤波的基础层图像。

在本文中，解码器应该被解释为覆盖能够执行解码操作的任何操作单元，诸如播放器、接收器、网关、分用器和/或解码器。

图11是可以实施各种实施例的示例多媒体通信系统的图形表示。数据源1510提供模拟、未压缩数字或压缩数字格式或这些格式的任何组合的源信号。编码器1520可以包括预处理或与其连接，诸如数据格式转换和/或源信号的滤波。编码器1520将源信号编码为编码媒体比特流。应该注意的是，可以从实际上位于任何类型的网络内的远程设备直接或间接地接收要解码的比特流。附加地，可以从本地硬件或软件接收比特流。编码器1520可能能够编码多于一种媒体类型，诸如音频和视频，或者可能需要多于一个编码器1520来编码不同媒体类型的源信号。编码器1520还可以得到综合产生的输入，诸如图形和文本，或者它可能能够产生综合媒体的编码比特流。在下文中，仅考虑对一种媒体类型的一个编码媒体比特流的处理以简化描述。然而，应该注意的是，通常，实时广播服务包括若干个流(通常至少一个音频、视频和文本字幕流)。还应该注意的是，该系统可以包括许多编码器，但是在附图中仅表示了一个编码器1520以简化描述而不缺乏通用性。还应该理解的是，尽管本文包含的文本和示例可以具体描述编码过程，但是本领域技术人员将理解，相同的概念和原理也应用于对应的解码过程，反之亦然。

可以将编码媒体比特流传送到存储装置1530。存储装置1530可以包括任何类型的大容量存储器以存储编码媒体比特流。存储装置1530中的编码媒体比特流的格式可以是基本的自包含比特流格式，或者一个或多个编码媒体比特流可以被封装到容器文件中，或者编码媒体比特流可以被封装为适于DASH(或类似的流式传输系统)的分段格式并存储为分段序列。如果将一个或多个媒体比特流封装在容器文件中，则可以使用文件生成器(未在附图中示出)将一个或多个媒体比特流存储在文件中，并且创建文件格式元数据，也可以将其存储在文件中。编码器1520或存储装置1530可以包括文件生成器，或者文件生成器可操作地附接至编码器1520或存储装置1530。一些系统“实时”操作，即，省略存储并且将编码媒体比特流直接从编码器1520传送到发送器1540。然后，可以根据需要将编码媒体比特流传送到发送器1540(也称为服务器)。在传输中使用的格式可以是基本的自包含比特流格式、分组流格式、适于DASH(或类似的流式传输系统)的分段格式，或者可以将一个或多个编码媒体比特流封装到容器文件中。编码器1520、存储装置1530和服务器1540可以驻留在相同的物理设备中，或者它们可以被包括在单独的设备中。编码器1520和服务器1540可以用实时内容进行操作，在这样的情况下，编码媒体比特流通常不永久存储，而是在内容编码器1520和/或服务器1540中缓冲一小段时间以平滑消除处理延迟、传送延迟和编码媒体比特率的变化。

服务器1540使用通信协议栈发送编码媒体比特流。堆栈可以包括但不限于以下一项或多项：实时传输协议(RTP)、用户数据报协议(UDP)、超文本传送协议(HTTP)、传输控制协议(TCP)和互联网协议(IP)。当通信协议栈是面向分组的时，服务器1540将编码媒体比特流封装为分组。例如，当使用RTP时，服务器1540根据RTP有效载荷格式将编码媒体比特流封装为RTP分组。通常，每种媒体类型都有专用的RTP有效载荷格式。应该再次注意，系统可以包含多于一个服务器1540，但是为了简单起见，以下描述仅考虑一个服务器1540。

如果媒体内容被封装在用于存储装置1530或用于将数据输入给发送器1540的容器文件中，则发送器1540可以包括“发送文件解析器”或可操作地附接至“发送文件解析器”(未在附图中示出)。具体地，如果没有这样传输容器文件，而是封装了所包含的编码媒体比特流中的至少一个以通过通信协议进行传输，则发送文件解析器将定位要通过通信协议传达的编码媒体比特流的适当部分。发送文件解析器还可以帮助创建通信协议的正确格式，诸如分组报头和有效载荷。多媒体容器文件可以包含封装指令，诸如ISOBMFF中的提示轨，以在通信协议上封装所包含的媒体比特流中的至少一个。

服务器1540可以或可以不通过通信网络连接至网关1550，该通信网络例如可以是CDN、互联网和/或一个或多个访问网络的组合。网关也可以或备选地称为中间盒。针对DASH，网关可以是(CDN的)边缘服务器或web代理。要注意的是，该系统通常可以包括任何数目的网关等，但是为了简单起见，以下描述仅考虑一个网关1550。网关1550可以执行不同类型的功能，诸如根据一个通信协议栈将分组流平移到另一通信协议栈，数据流的合并和分支以及根据下行链路和/或接收器能力操纵数据流，诸如根据主要的下行网络条件控制转发流的比特率。在各种实施例中，网关1550可以是服务器实体。

该系统包括一个或多个接收器1560，其通常能够接收、解调和解封装所传输的信号为编码媒体比特流。可以将编码媒体比特流传送给记录存储装置1570。记录存储装置1570可以包括任何类型的大容量存储器以存储编码媒体比特流。记录存储装置1570可以备选地或附加地包括计算存储器，诸如随机存取存储器。记录存储装置1570中的编码媒体比特流的格式可以是基本的自包含比特流格式，或者可以将一个或多个编码媒体比特流封装到容器文件中。如果存在彼此关联的多个编码媒体比特流，诸如音频流和视频流，则通常使用容器文件，并且接收器1560包括或附接至容器文件生成器，该容器文件生成器从输入流产生容器文件。一些系统“实时”操作，即，省略记录存储装置1570，并且将编码媒体比特流从接收器1560直接传送到解码器1580。在一些系统中，仅记录流的最近部分(例如记录流的最近10分钟的摘录)维持在记录存储装置1570中，而从记录存储装置1570中丢弃任何较早的记录数据。

编码媒体比特流可以从记录存储装置1570传送给解码器1580。如果存在许多编码媒体比特流(诸如音频流和视频流)彼此关联并且封装到容器文件中或者单个媒体比特流封装在容器文件中，例如为了更易于访问，则使用文件解析器(未在附图中示出)从容器文件中解封装每个编码媒体比特流。记录存储装置1570或解码器1580可以包括文件解析器，或者文件解析器附接至记录存储装置1570或解码器1580。还应该注意，系统可以包括许多解码器，但是此处仅讨论一个解码器1570以简化描述而不缺乏通用性。

编码媒体比特流还可以由解码器1570处理，其输出是一个或多个未压缩的媒体流。最后，渲染器1590可以例如利用扬声器或显示器来再现未压缩的媒体流。接收器1560、记录存储装置1570、解码器1570和渲染器1590可以驻留在同一物理设备中，或者它们可以被包括在单独的设备中。

发送器1540和/或网关1550可以被配置为在不同表示之间执行切换，例如以在360度视频内容的不同视口之间进行切换，视图切换，比特率适应和/或快速启动，和/或发送器1540和/或网关1550可以被配置为选择所传输的(多个)表示。可能出于多种原因而在不同表示之间进行切换，诸如响应于接收器1560的请求或在其上传达比特流的网络的主要条件(诸如吞吐量)。换言之，接收器1560可以发起表示之间的切换。来自接收器的请求可以是例如来自与先前不同的表示的分段或子分段的请求、改变所传输的可缩放性层和/或子层或者改变与上一个相比具有不同能力的渲染设备的请求。对分段的请求可以是HTTP GET请求。对子分段的请求可以是具有字节范围的HTTP GET请求。附加地或备选地，例如可以使用比特率调整或比特率适应来在流服务中提供所谓的快速启动，其中传输流的比特率低于启动或随机访问流之后的信道比特率，以便立即开始回放，并且实现缓冲占用水平，其容忍偶尔的分组延迟和/或重传。比特率适应可以包括以各种顺序发生的多个表示或层上切换以及表示或层下切换操作。

解码器1580可以被配置为在不同表示之间执行切换，例如以在360度视频内容的不同视口之间进行切换，视图切换，比特率适应和/或快速启动，和/或解码器1580可以被配置为选择所传输的(多个)表示。可能出于多种原因而在不同表示之间进行切换，诸如以实现更快的解码操作或适应所传输的比特流，例如在比特率、在其上传达比特流的网络的主要条件(诸如吞吐量)方面。例如，如果包括解码器1580的设备是多任务的并且将计算资源用于除了解码视频比特流之外的其他目的，则可能需要更快的解码操作。在另一示例中，当以比正常回放速度更快的速度回放内容时，例如比传统的实时回放速率快两倍或三倍，可能需要更快的解码操作。

在上文中，已经参照和/或使用HEVC的术语描述了一些实施例。需要理解的是，实施例可以用具有其他编解码器的相应术语的任何视频编码器和/或视频解码器类似地实现。例如，可以用H.264/AVC的矩形切片组来实现实施例而不是图块或图块集合。

在上文中，已经参照分段描述了一些实施例，例如如MPEG-DASH中所定义的。需要理解的是，实施例可以类似地用子分段来实现，例如如MPEG-DASH中所定义的。

在上文中，已经关于ISOBMFF描述了一些实施例，例如当涉及分段格式和/或影视片段格式时。需要理解的是，实施例可以用具有与ISOBMFF中类似的概念和/或能力和/或结构的任何其他文件格式(诸如Matroska)类似地实现。

在上文中，已经参照术语“提取器轨”描述了一些实施例。需要理解的是，实施例可以用任何类型的收集器轨而不只是提取器轨来实现。更具体地，可以利用图块基础轨而不是提取器轨来实现实施例。而且，可以通过同时使用提取器轨和图块基础轨来实现实施例，例如在同一文件中或针对同一MPD中所包括的不同表示。

在上文中，在已经参照文件写入或创作描述了示例实施例的情况下，需要理解的是，所得到的文件和文件解析器或读取器可以在其中具有对应的元素。同样地，在已经参照文件解析或读取描述了示例实施例的情况下，需要理解的是，文件写入器或创作器可以具有用于生成要由文件解析器或读取器解析的文件的结构和/或计算机程序。

在上文中，在已经参照编码器描述了示例实施例的情况下，需要理解的是，所得到的比特流和解码器可以在其中具有对应的元素。同样地，在已经参照解码器描述了示例实施例的情况下，需要理解的是，编码器可以具有用于生成要由解码器解码的比特流的结构和/或计算机程序。

上面描述的本发明的实施例就单独的编码器和解码器装置来描述编解码器，以辅助理解所涉及的过程。然而，要了解的是，该装置、结构和操作可以被实施为单个编码器-解码器装置/结构/操作。此外，编码器和解码器可能可以共享一些或所有公共元素。

尽管以上示例描述了在电子设备内的编解码器内操作的本发明的实施例，但是要了解的是，如权利要求中所定义的本发明可以被实施为任何视频编解码器的一部分。因此，例如，本发明的实施例可以在视频编解码器中实施，该视频编解码器可以在固定或有线通信路径上实施视频编码。

因此，用户装备可以包括诸如上面在本发明的实施例中描述的视频编解码器。应该了解，术语“用户装备”旨在覆盖任何合适类型的无线用户装备，诸如移动电话、便携式数据处理设备或便携式web浏览器。

此外，公共陆地移动网络(PLMN)的元件还可以包括如上所述的视频编解码器。

通常，本发明的各种实施例可以实施在硬件或专用电路、软件、逻辑或其任何组合中。例如，一些方面可以实施在硬件中，而其他方面可以实施在可以由控制器、微处理器或其他计算设备执行的固件或软件中，尽管本发明并不限于此。尽管本发明的各个方面可以被图示和描述为框图、流程图或者使用一些其他图形表示，但是要充分理解的是，本文描述的这些框、装置、系统、技术或方法可以作为非限制性示例实施在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备或其某种组合中。

本发明的实施例可以通过由移动设备的数据处理器(诸如在处理器实体中)可执行的计算机软件，或者通过硬件，或者通过软件和硬件的组合实施。进一步地，在这方面，应该注意的是，附图中的逻辑流程的任何框可以表示程序步骤或者互连的逻辑电路、框和功能或者程序步骤和逻辑电路、框和功能的组合。软件可以存储在作为存储器芯片的这样的物理介质、或者实施在处理器内的存储器块、诸如硬盘或软盘等磁性存储器以及诸如例如DVD及其数据变型CD等光学存储器上。

存储器可以是适于本地技术环境的任何类型，并且可以使用任何合适的数据存储技术实施，诸如基于半导体的存储器设备、磁性存储器设备和系统、光学存储器设备和系统、固定存储器和可移除存储器。数据处理器可以是适于本地技术环境的任何类型，并且作为非限制性示例，可以包括以下一项或多项：通用计算机、专用计算机、微处理器、数字信号处理器(DSP)和基于多核处理器架构的处理器。

本发明的实施例可以实践在诸如集成电路模块等各种部件中。集成电路的设计大体上是高度自动化的过程。复杂且功能强大的软件工具可用于将逻辑级设计转换为准备在半导体衬底上蚀刻和形成的半导体电路设计。

程序(诸如由加利福尼亚州山景城的Synopsys公司和加利福尼亚州圣何塞的Cadence Design提供的程序)使用完善的设计规则以及预存储设计模块库自动对导体进行路由并在半导体芯片上定位部件。一旦完成了半导体电路的设计，就可以将标准化电子格式(例如Opus、GDSII等)的所得设计传输给半导体制造设施或“fab”以进行制造。

前述描述通过示例性且非限制性示例提供了对本发明的示例性实施例的完整且信息丰富的描述。然而，鉴于前述描述，在结合附图和所附权利要求阅读时，各种修改和改编对于相关领域的技术人员来说可能是显而易见的。然而，本发明的教导的所有这样的和类似的修改仍将落入本发明的范围内。

Claims (12)

1.一种处理媒体数据的方法，包括：

执行操作，作为经编码视频比特流的文件封装过程的一部分，所述操作包括：

在容器文件中写入与所述经编码视频比特流对应的所标识的媒体数据元素；

将第一标识符包括在所述所标识的媒体数据元素中，以作为针对所述所标识的媒体数据的参考由其他元素使用，其中所述第一标识符是第一影视片段序列号；

将数据参考元素包括在所述容器文件中，所述数据参考元素在被参考时，从所述第一影视片段序列号导出第二标识符，并且所述第二标识符指示包括与所述第二标识符相等的所述第一标识符的所述所标识的媒体数据元素；

将参考所述数据参考元素的第一样本条目包括在所述容器文件中；

将影视片段包括在所述容器文件中，所述影视片段包括轨片段并且包括所述第一影视片段序列号；

将样本描述索引包括在所述轨片段中，所述样本描述索引标识要用于所述轨片段的所述第一样本条目并且指示所述所标识的媒体数据元素包括针对所述轨片段的媒体数据；以及

向大容量存储器至少存储所述容器文件以供后续传输。

2.根据权利要求1所述的方法，其中所述容器文件是根据ISOBMFF构造的，所述方法还包括：

在所述容器文件中写入所述所标识的媒体数据元素作为IdentifiedMediaDataBox；以及

将定义所述第一标识符的imda_identifier包括在所述IdentifiedMediaDataBox中。

3.根据权利要求1所述的方法，还包括：

在所述容器文件中写入所述第一标识符作为所述所标识的媒体数据元素的第一元素；以及

借助于所述数据参考元素参考所述所标识的媒体数据元素。

4.一种用于处理媒体数据的装置，执行操作，作为经编码视频比特流的文件封装过程的一部分，所述装置包括：

用于在容器文件中写入与所述经编码视频比特流对应的所标识的媒体数据元素的部件；

用于将第一标识符包括在所述所标识的媒体数据元素中以作为针对所述所标识的媒体数据的参考由其他元素使用的部件，其中所述第一标识符是第一影视片段序列号；

用于将数据参考元素包括在所述容器文件中的部件，所述数据参考元素在被参考时，从所述第一影视片段序列号导出第二标识符，并且所述第二标识符指示包括与所述第二标识符相等的所述第一标识符的所述所标识的媒体数据元素；

用于将参考所述数据参考元素的第一样本条目包括在所述容器文件中的部件；

用于将影视片段包括在所述容器文件中的部件，所述影视片段包括轨片段并且包括所述第一影视片段序列号；

用于将样本描述索引包括在所述轨片段中的部件，所述样本描述索引标识要用于所述轨片段的所述第一样本条目并且指示所述所标识的媒体数据元素包括针对所述轨片段的媒体数据；以及

用于向大容量存储器至少存储所述容器文件以供后续传输的部件。

5.根据权利要求4所述的装置，其中所述容器文件是根据ISOBMFF构造的，所述装置还包括：

用于在所述容器文件中写入所述所标识的媒体数据元素作为IdentifiedMediaDataBox的部件；以及

用于将定义所述第一标识符的imda_identifier包括在所述IdentifiedMediaDataBox中的部件。

6.根据权利要求4所述的装置，还包括：

用于在所述容器文件中写入所述第一标识符作为所述所标识的媒体数据元素的第一元素的部件。

7.根据权利要求4所述的装置，还包括

用于借助于数据参考元素参考所述所标识的媒体数据元素的部件。

8.一种处理媒体数据的方法，执行操作，作为针对经编码视频比特流的文件解封装过程的一部分，包括：

从容器文件解析第一标识符，其中所述第一标识符是第一影视片段序列号；

从所述容器文件解析数据参考元素，并且参考所述数据参考元素，在参考时，所述数据参考元素从所述第一影视片段序列号导出第二标识符，并且所述第二标识符指示所标识的媒体数据元素；

在所述所标识的媒体数据元素中使用所述第一标识符作为针对所述所标识的媒体数据的参考；

从所述容器文件解析参考所述数据参考元素的第一样本条目；

从所述容器文件解析影视片段，所述影视片段包括轨片段并且包括所述第一影视片段序列号；

从所述轨片段解析样本描述索引，所述样本描述索引标识要用于所述轨片段的所述第一样本条目并且指示所述所标识的媒体数据元素包括针对所述轨片段的媒体数据；以及

对从所述容器文件解封装的视频比特流进行解码。

9.一种用于处理媒体数据的装置，执行操作，作为针对经编码视频比特流的文件解封装过程的一部分，所述装置包括：

用于从容器文件解析第一标识符的部件，其中所述第一标识符是第一影视片段序列号；

用于从所述容器文件解析数据参考元素并且参考所述数据参考元素的部件，在参考时，所述数据参考元素从所述第一影视片段序列号导出第二标识符，并且所述第二标识符指示所标识的媒体数据元素；

用于在所述所标识的媒体数据元素中使用所述第一标识符作为对所述所标识的媒体数据的参考的部件；

用于从所述容器文件解析参考所述数据参考元素的第一样本条目的部件；

用于从所述容器文件解析影视片段的部件，所述影视片段包括轨片段并且包括所述第一影视片段序列号；

用于从所述轨片段解析样本描述索引的部件，所述样本描述索引标识要用于所述轨片段的所述第一样本条目并且指示所述所标识的媒体数据元素包括针对所述轨片段的媒体数据；以及

用于对从所述容器文件解封装的视频比特流进行解码的部件。

10.根据权利要求9所述的装置，其中所述容器文件是根据ISOBMFF构造的，所述装置还包括：

用于从所述容器文件解析所述第一标识符作为imda_identifier的部件；以及

用于在IdentifiedMediaDataBox中使用所述第一标识符作为对所述所标识的媒体数据的参考的部件。

11.根据权利要求9所述的装置，还包括：

用于从所述容器文件解析所述第一标识符作为所述所标识的媒体数据元素的第一元素的部件。

12.根据权利要求11所述的装置，还包括

用于借助于数据参考元素解析所述所标识的媒体数据元素的部件。