网络抽象层单元头中的网络抽象单元层类型类

摘要

一种对视频序列进行解码的方法和装置包括：对固定长度二进制编码的网络抽象层单元NALU类类型进行解码，所述NALU类类型包括在NALU头中。对NALU头中的NALU类型进行解码。重建图片，并且所述图片的类型通过NALU类类型和NALU类型的组合来进行识别。

说明书

交叉引用

本申请根据35 U.S.C.§119要求在美国专利商标局于2018年12月14日提交的第62/780,148号美国临时申请、2018年12月14日提交的第62/780,154号美国临时申请、2019年1月2日提交的第62/704,039号美国临时申请和2019年5月6日提交的第16/403,786号美国申请的优先权，其全部内容通过引用结合在本文。

技术领域

所公开的主题涉及视频编码和解码，并且更具体地，涉及NALU类型类的网络抽象层(NAL：Network Abstraction Layer)单元(NALU：Network Abstraction Layer Unit)头的编解码。

背景技术

使用具有运动补偿的图片间预测的视频编码和解码已经有几十年了。未压缩的数字视频可以由一系列图片组成，每个图片具有例如1920x1080个亮度样本和相关联的色度样本的空间维度。该系列图片可以具有固定的或可变的图片速率(通俗也称为帧速率)，例如每秒60张图片或60Hz。未压缩的视频具有非常高的比特率要求。例如，每样本8比特的1080p60 4:2:0视频(以60Hz帧速率的1920x1080亮度样本分辨率)需要接近1.5Gbit/s的带宽。一个小时的此类视频需要超过600GB的存储空间。

视频编码和解码的一个目的是通过压缩减少输入视频信号中的冗余。视频压缩可以帮助降低上述带宽或存储空间要求，在某些情况下可以减少两个数量级或更多。可以采用无损压缩和有损压缩，以及它们的组合。无损压缩是指可以从压缩的原始信号中重建原始信号的精确副本的技术。当使用有损压缩时，重建信号可能与原始信号不同，但是原始信号与重建信号之间的失真足够小，从而使得重建信号可用于预期应用。在视频的情况下，广泛采用有损压缩。容许的失真量取决于应用程序；例如，相比于电视贡献(contribution)应用程序的用户，某些消费流媒体应用程序的用户可以容忍更高的失真。可实现的压缩比可以反映出：较高的可允许/可容许失真可以产生较高的压缩比。

视频编码器和解码器可利用来自若干广泛类别的技术，包括(例如)运动补偿、变换、量化及熵编解码，其中的一些将会在下文中介绍。

在ITU-T Rec.H.264.中引入了网络抽象层的概念。可以将已编码的视频码流划分为单独的单元，称为网络抽象层(NAL-：Network Abstraction Layer)单元。每个NAL单元可以具有头，无需遵循起始码防止竞争(emulation prevention)对该头进行解释(否则，可能需要在NAL单元的其他部分中以可能高昂的实现和计算成本来遵守起始码防止竞争)。H.264(101)中的NAL单元头被设计为仅包括固定长度码字，如图1所示。对于nal_unit_type(102)的某些值，通过添加第二个并且有时第三个八位字节(octet)，可以对NAL单元头(103)进行某些扩展，其中每个八位字节还包含固定长度码字。媒体感知网络单元(MANE：Media Aware Network Element)、MCU、文件重写器等可以利用这些固定长度码字来有效地裁剪码流，而不需要进行完全的代码转换，并且也不需要受到起始码防止竞争的约束。

在H.265中，选择了稍微简化的设计。H.265NAL单元头(104)在两个八位字节处是固定长度的，并且包括NAL单元类型(105)、空间/SNR层ID(106)和时间层ID(107)。不存在扩展机制。与H.264设计相比，此设计具有一定的编解码效率损失，因为与可变长度相比，头的长度总是2个八位字节，而H.264设计通常是1个八位字节长度。另一方面，大大简化了可伸缩和多视图扩展的支持，从而允许可伸缩/多视图与不可伸缩/多视图传统编码之间的某种后向兼容性。

此外，将已编码的视频码流划分成包(packets)以在分组网络上传输的概念已经使用了几十年。早期，视频编解码标准和技术大多数针对面向比特的传输和定义的码流进行优化。打包(packetization)发生在例如以实时传输协议(RTP：Real-time TransportProtocol)有效载荷格式指定的系统层接口中。随着因特网上适合于大量使用视频的因特网连接性的出现，视频编解码标准通过视频编解码层(VCL：video coding layer)和网络抽象层(NAL：Network abstraction layer)的概念区分反映了这一突出的用例。NAL单元在2003年被引入H.264中，并且此后仅做了细微的修改就被保留在某些视频编解码标准和技术中。

在许多情况下，NAL单元可以被视为解码器可作用的最小实体，而不必对已编码视频序列的所有先前的NAL单元进行解码。在此范围内，NAL单元使得某些差错恢复技术以及某些码流处理技术能够包括由媒体感知网络单元(MANE：Media Aware Network Elements)(诸如选择性转发单元(SFU：Selective Forwarding Units)或多点控制单元(MCU：Multipoint Control Units))进行的码流修剪(bitstream pruning)。

图1描绘了根据H.264(101)和H.265(104)的NAL单元头的语法图的相关部分，在这两种情况下都没有它们各自的任何扩展。在这两种情况下，forbidden_zero_bit(108，109)是用于在某些系统层环境中起始码防止竞争的零比特。nal_unit_type(102，105)语法元素是指NAL单元携带的数据的类型，其可以是例如某些条带类型、参数集类型、补充增强信息(SEI：Supplementary Enhancement Information)消息等中的一种。H.265NAL单元头进一步包括nuh_layer_id(106)和nuh_temporal_id_plus1(107)，用于指示NAL单元所属的已编码图片的空间/SNR和时间层。

可以观察到，NAL单元头仅包括可容易解析的固定长度码字，其对码流中的其它数据，例如其它NAL单元头、参数集等不具有任何解析依存性。由于NAL单元头是NAL单元中的第一个八位字节，因此MANE可以轻松地提取它们、解析它们，并对它们执行操作。相反，其它高级语法元素，例如条带(Slice)或图块(Tile)头，则不太容易被MANE存取，因为它们可能需要保持参数集上下文和/或处理可变长度或算术已编码的码点。

进一步可以观察到，如图1所示的NAL单元头不包括能够将NAL单元关联到已编码图片的信息，所述已编码图片由多个NAL单元(例如，包括多个图块或条带，它们的至少一些被分组在单独的NAL单元中)组成。

某些传输技术，诸如RTP(RFC 3550)、MPEG系统标准、ISO文件格式等，可能包括某些信息，通常是以定时信息的形式，诸如呈现时间(在MPEG和ISO文件格式的情况下)或捕获时间(在RTP的情况下)，这些信息可由MANE轻松存取，并有助于将它们相应的传输单元与已编码图片相关联。然而，这些信息的语义可能因传输/存储技术的不同而不同，并且可能与视频编解码中使用的图片结构没有直接关系。因此，这些信息至多可能是启发式的，并且也可能不特别适合于识别NAL单元流中的NAL单元是否属于相同的已编码图片。

此外，在图像或视频编解码中，分量可以指通常在x和y维度上以一定分辨率在二维矩阵中正常排列的样本值的集合。在较早的图像和视频编解码技术中，分量通常与颜色原色相关联。例如，在诸如H.261或JPEG的一些较早的视频或图像压缩标准中，使用YCrCb颜色模型，其中Y、CR和Cb正好是共同构成三个分量的三个颜色原色。使用称为4:2:0的采样结构，亮度Y分量的分辨率在x和y维度上分别是颜色Cr和Cb分量的分辨率的两倍。这些关系被硬编码到上述较早的标准和技术中。即使在这些较早的标准和技术中，某些分量在没有其它分量的情况下也是有用的。例如，Y分量在被单独解码和显示时表示从黑白照片、电影和电视中获知的图像和视频的类型。

更现代的图像和视频编解码技术和标准(诸如MPEG-2和H.264)可以支持更多和其它颜色原色和附加的采样结构，从而需要高级语法结构(诸如用于描述使用哪些分量和采样结构的序列头和参数集)中的码点。

甚至最近，诸如下一代视频编解码(VVC：Versatile Video Coding)、点云编解码(PCC：point cloud coding)、(表面)光场等的某些技术开始出现。在这些即将到来的标准和技术中，除了颜色分量之外的分量变得重要起来。这些其它分量的示例包括透明度、反射率、吸收、3D几何信息(XYZ)、占用映射、表面法矢量、辅助信息、深度映射，并且在某些3D格式中，对于3D空间中的给定样本，颜色分量可能不同，这取决于观察者的视点。

发明内容

根据本公开的一方面，一种用于对视频序列进行解码的方法包括：对固定长度二进制编码的网络抽象层单元NALU类类型进行解码，所述NALU类类型包括在NALU头中；对所述NALU头中的NALU类型进行解码；以及重建图片，所述图片的类型通过所述NALU类类型和所述NALU类型的组合来进行识别。

根据本公开的一方面，一种对视频序列进行解码的设备包括：至少一个存储器，用于存储程序代码；以及至少一个处理器，用于读取所述程序代码并且按照所述程序代码的指示进行操作，所述程序代码包括：解码代码，用于使所述至少一个处理器：对固定长度二进制编码的网络抽象层单元NALU类类型进行解码，所述NALU类类型中包括在NALU头中；以及对所述NALU头中的NALU类型进行解码；以及重建代码，用于使所述至少一个处理器重建图片，其中，所述图片的类型通过所述NALU类类型和所述NALU类型的组合来进行识别

根据本公开的一方面，一种存储指令的非易失性计算机可读介质，指令包括：至少一个指令，在由设备的至少一个处理器执行时，该指令使至少一个处理器：对固定长度二进制编码的网络抽象层单元NALU类类型进行解码，所述NALU类类型包括在NALU头中；对所述NALU头中的NALU类型进行解码；以及重建图片，所述图片的类型通过所述NALU类类型和所述NALU类型的组合来进行识别。

附图说明

从以下详细描述和附图，所公开的主题的其它特征、性质及各种优点将更加显而易见，其中：

图1是根据H.264和H.265的NALU头的示意图。

图2是根据实施例的通信系统的简化框图的示意图。

图3是根据实施例的通信系统的简化框图的示意图。

图4是根据实施例的解码器的简化框图的示意图。

图5是根据实施例的编码器的简化框图的示意图。

图6是根据实施例的使用NALU类型类的NALU头的示意图。

图7是根据实施例的示例方法的流程图。

图8是根据实施例的包括picture_id语法元素的NAL单元头的示意图。

图9是根据实施例的示例方法的流程图。

图10是根据实施例的携带各种分量或分量组的NAL单元的示意图。

图11是根据实施例的携带各种分量或分量组的NAL单元的示意图。

图12是根据实施例的系统选择性地转发具有不同分量类型的NAL单元的示意图。

图13是根据实施例的用于携带各种分量或分量组的NAL单元的语法图的示意图。

图14是根据实施例的计算机系统的示意图。

待解决的问题

H.264NAL单元头在许多情况下是紧凑的，但对某些应用来说还不够。H.265NAL单元头有效地支持可伸缩性和多视图，但是缺乏对某些其它技术(如360视频编解码)的支持，而且两个八位字节的长度对某些其它应用来说是不必要的长。因此，需要一种保持H.264NAL单元头的紧凑性同时提供对现代应用的有效支持的设计。

具体实施方式

图2图示了根据本公开的实施例的通信系统(200)的简化框图。系统(200)可以包括经由网络(250)互连的至少两个终端(210-220)。对于数据的单向传输，第一终端(210)可以在本地位置处对视频数据进行编码，以便经由网络(250)传输到另一终端(220)。第二终端(220)可以从网络(250)接收另一终端的已编码视频数据，对已编码数据进行解码并显示已恢复的视频数据。单向数据传输在媒体服务应用等中可能是常见的。

图2图示了第二对终端(230，240)，用于支持例如在视频会议期间可能发生的已编码视频的双向传输。对于数据的双向传输，每个终端(230，240)可以对在本地位置处采集的视频数据进行编码，以便经由网络(250)传输到另一终端。第三终端(230)和第四终端(240)还可以接收由其他终端传输的已编码视频数据，可以对已编码数据进行解码，并且可以在本地显示设备上显示已恢复的视频数据。

在图2的实施例中，终端(210-240)可为服务器、个人计算机和智能电话，但本申请公开的原理可不限于此。本申请公开的实施例适用于膝上型计算机、平板电脑、媒体播放器和/或专用视频会议设备。网络(250)表示在终端(210-240)之间传送已编码视频数据的任何数目的网络，包括例如有线(连线的)和/或无线通信网络。通信网络(250)可在电路交换和/或分组交换信道中交换数据。该网络可包括电信网络、局域网、广域网和/或互联网。出于本申请的目的，除非在下文中有所解释，否则网络(250)的架构和拓扑对于本申请公开的操作来说可能是无关紧要的。

作为实施例，图3示出视频编码器和视频解码器在流式传输环境中的放置方式。本申请所公开主题可同等地适用于其它支持视频的应用，包括例如视频会议、数字TV、在包括CD、DVD、存储棒等的数字介质上存储压缩视频等等。

流式传输系统可包括采集子系统(313)，所述采集子系统可包括数码相机等视频源(301)，所述视频源创建例如未压缩的视频样本流(302)。相较于已编码的视频码流，该样本流(302)被描绘为粗线以强调具有较高数据量，样本流(302)可由耦合至摄像机(301)的编码器(303)进行处理。编码器(303)可包括硬件、软件或软硬件组合以实现或实施如下文更详细地描述的所公开主题的各方面。与样本流相比，已编码的视频码流(304)被描绘为细线以强调具有较低数据量，已编码的视频码流(304)可被存储在流媒体服务器(305)上以供将来使用。至少一个流媒体客户端(306，308)可以访问流媒体服务器(305)，以检索已编码视频码流(304)的副本(307)和副本(309)。客户端(306)可以包括视频解码器(310)，其对已编码视频码流(307)的输入副本进行解码，并创建可以在显示器(312)或其它呈现设备(未示出)上呈现的输出视频样本流(311)。在一些流媒体系统中，视频码流(304，307，309)可以根据某些视频编码/压缩标准进行编码。这些标准的实施例包括ITU-T H.265。正在开发的视频编码标准通俗地被称为下一代视频编码或VVC(Versatile Video Coding)。所公开的主题可以用于VVC标准的上下文中。

图4可以是根据本公开的实施例的视频解码器(310)的功能框图。

接收器(410)可接收将由解码器(310)解码的一个或多个已编码视频序列；在同一实施例或另一实施例中，一次接收一个已编码视频序列，其中每个已编码视频序列的解码独立于其它已编码视频序列。可从信道(401)接收已编码视频序列，所述信道可以是通向存储已编码的视频数据的存储装置的硬件/软件链路。接收器(410)可接收已编码的视频数据以及其它数据，例如，可转发到它们各自的使用实体(未标示)的已编码音频数据和/或辅助数据流。接收器(410)可将已编码视频序列与其它数据分开。为了防止网络抖动，缓冲存储器(415)可耦接在接收器(410)与熵解码器/解析器(420)(此后称为“解析器(420)”)之间。而当接收器(410)从具有足够带宽和可控性的存储/转发装置或从等时同步网络接收数据时，也可能不需要配置缓冲存储器(415)，或可以将所述缓冲存储器做得较小。为了在互联网等业务分组网络上使用，也可能需要缓冲存储器(415)，所述缓冲存储器可相对较大且可具有自适应性大小。

视频解码器(310)可包括解析器(420)以根据已熵编码的视频序列重建符号(421)。这些符号的类别包括用于管理解码器(410)的操作的信息，以及用以控制显示装置(例如，显示屏(312))的潜在信息，所述显示装置不是解码器的组成部分，但可耦接到解码器上，如图3中所示。用于显示装置的控制信息可以是辅助增强信息(SupplementalEnhancement Information，SEI消息)或视频可用性信息(Video Usability Information，VUI)的参数集片段(未标示)的形式。解析器(420)可对接收到的已编码视频序列进行解析/熵解码。已编码视频序列的编码可根据视频编码技术或标准进行，且可遵循各种原理，包括可变长度编码、霍夫曼编码(Huffman coding)、具有或不具有上下文灵敏度的算术编码等等。解析器(420)可基于对应于群组的至少一个参数，从已编码视频序列提取用于视频解码器中的像素的子群中的至少一个子群的子群参数集。子群可包括图片群组(Group ofPictures，GOP)、图片、图块、切片、宏块、编码单元(Coding Unit，CU)、块、变换单元(Transform Unit，TU)、预测单元(Prediction Unit，PU)等等。熵解码器/解析器还可从已编码视频序列提取信息，例如变换系数、量化器参数值、运动矢量等等。

解析器(420)可对从缓冲存储器(415)接收的视频序列执行熵解码/解析操作，从而创建符号(421)。

取决于已编码视频图片或一部分已编码视频图片(例如：帧间图片和帧内图片、帧间块和帧内块)的类型以及其它因素，符号(421)的重建可涉及多个不同单元。涉及哪些单元以及涉及方式可由解析器(420)从已编码视频序列解析的子群控制信息控制。为了简洁起见，未描述解析器(420)与下文的多个单元之间的此类子群控制信息流。

除已经提及的功能块以外，解码器(310)可在概念上细分成如下文所描述的数个功能单元。在商业约束下运行的实际实施例中，这些单元中的许多单元彼此紧密交互并且可以彼此集成。然而，出于描述所公开主题的目的，概念上细分成下文的功能单元是适当的。

第一单元是缩放器/逆变换单元(451)。缩放器/逆变换单元(451)从解析器(420)接收作为符号(421)的量化变换系数以及控制信息，包括使用哪种变换方式、块大小、量化因子、量化缩放矩阵等。它可输出包括样本值的块，所述样本值可输入到聚合器(455)中。

在一些情况下，缩放器/逆变换单元(451)的输出样本可属于帧内编码块；即：不使用来自先前重建的图片的预测性信息，但可使用来自当前图片的先前重建部分的预测性信息的块。此类预测性信息可由帧内图片预测单元(452)提供。在一些情况下，帧内图片预测单元(452)采用从当前(部分重建的)图片(456)提取的已重建信息，生成大小和形状与正在重建的块相同的周围块。举例来说，当前图片缓冲器(456)缓冲部分重建的当前图片和/或完全重建的当前图片。在一些情况下，聚合器(455)基于每个样本，将帧内预测单元(452)生成的预测信息添加到由缩放器/逆变换单元(451)提供的输出样本信息中。

在其它情况下，缩放器/逆变换单元(451)的输出样本可属于帧间编码和潜在运动补偿块。在此情况下，运动补偿预测单元(453)可访问参考图片存储器(457)以提取用于预测的样本。在根据符号(421)对提取的样本进行运动补偿之后，这些样本可由聚合器(455)添加到缩放器/逆变换单元的输出(在这种情况下被称作残差样本或残差信号)，从而生成输出样本信息。运动补偿单元从参考图片存储器内的地址获取预测样本可受到运动矢量控制，且所述运动矢量以所述符号(421)的形式而供运动补偿单元使用，所述符号(421)例如是包括X、Y和参考图片分量。运动补偿还可包括在使用子样本精确运动矢量时，从参考图片存储器提取的样本值的内插、运动矢量预测机制等等。

聚合器(455)的输出样本可在环路滤波器单元(456)中被各种环路滤波技术采用。视频压缩技术可包括环路内滤波器技术，所述环路内滤波器技术受控于包括在已编码视频码流中的参数，且所述参数作为来自解析器(420)的符号(421)可用于环路滤波器单元(456)。然而，在其他实施例中，视频压缩技术还可响应于在解码已编码图片或已编码视频序列的先前(按解码次序)部分期间获得的元信息，以及响应于先前重建且经过环路滤波的样本值。

环路滤波器单元(456)的输出可以是样本流，所述样本流可输出到显示装置(312)以及存储在参考图片存储器(456)，以用于后续的帧间图片预测。

一旦完全重建，某些已编码图片就可用作参考图片以用于将来预测。一旦已编码图片被完全重建，且已编码图片(通过例如解析器(420))被识别为参考图片，则当前参考图片(456)可变为参考图片存储器(457)的一部分，且可在开始重建后续已编码图片之前重新分配新的当前图片缓冲器。

视频解码器(420)可根据记录在例如ITU-T H.265标准中的预定视频压缩技术执行解码操作。在已编码视频序列遵循视频压缩技术或标准的语法以及视频压缩技术或标准中记录的配置文件的意义上，已编码视频序列可符合所使用的视频压缩技术或标准指定的语法，如视频压缩技术文档或标准(特别是其中的配置文件)中指定的那样。对于合规性，还要求已编码视频序列的复杂度处于视频压缩技术或标准的层级所限定的范围内。在一些情况下，层级限制最大图片大小、最大帧率、最大重建取样率(以例如每秒兆(mega)个样本为单位进行测量)、最大参考图片大小等。在一些情况下，由层级设定的限制可通过假想参考解码器(Hypothetical Reference Decoder，HRD)规范和在已编码视频序列中用信号表示的HRD缓冲器管理的元数据来进一步限定。

在实施例中，接收器(410)可连同已编码视频一起接收附加(冗余)数据。所述附加数据可以是已编码视频序列的一部分。所述附加数据可由视频解码器(420)用以对数据进行适当解码和/或较准确地重建原始视频数据。附加数据可呈例如时间、空间或信噪比(signal noise ratio，SNR)增强层、冗余切片、冗余图片、前向纠错码等形式。

图5是根据本申请公开的实施例的视频编码器(303)的框图。

编码器(303)可以从视频源(301)(不是编码器的一部分)接收视频样本，该视频源可以采集将由编码器(303)编码的视频图像。

视频源(301)可提供将由视频编码器(303)编码的呈数字视频样本流形式的源视频序列，所述数字视频样本流可具有任何合适位深度(例如：8位、10位、12位……)、任何色彩空间(例如BT.601Y CrCB、RGB……)和任何合适取样结构(例如Y CrCb 4:2:0、Y CrCb 4:4:4)。在媒体服务系统中，视频源(301)可以是存储先前已准备的视频的存储装置。在视频会议系统中，视频源(303)可以是采集本地图像信息作为视频序列的相机。可将视频数据提供为多个单独的图片，当按顺序观看时，这些图片被赋予运动。图片自身可构建为空间像素阵列，其中取决于所用的取样结构、色彩空间等，每个像素可包括一个或多个样本。所属领域的技术人员可以很容易理解像素与样本之间的关系。下文侧重于描述样本。

根据实施例，编码器(303)可实时或在由应用所要求的任何其它时间约束下，将源视频序列的图片编码且压缩成已编码视频序列(543)。施行适当的编码速度是控制器(550)的一个功能。控制器控制如下文所描述的其它功能单元且在功能上耦接到这些单元。为了简洁起见，图中未标示耦接。由控制器(550)设置的参数可包括速率控制相关参数(图片跳过、量化器、率失真优化技术的λ值等)、图片大小、图片群组(group of pictures，GOP)布局，最大运动矢量搜索范围等。本领域技术人员可以容易地识别控制器(550)的其他功能，这些功能涉及针对某一系统设计优化的视频编码器(503)。

视频编码器(503)在本领域技术人员容易理解为“编码环路”中进行操作。作为简单的描述，编码环路可包括编码器(530)的编码部分(后续称为“源编码器”)(负责基于待编码的输入图片和参考图片创建符号)和嵌入于编码器(303)中的(本地)解码器(533)。编码器(303)重建符号以创建(远程)解码器也会创建的样本数据(因为在本申请所考虑的视频压缩技术中，符号与已编码视频码流之间的任何压缩是无损的)。将重建的样本流输入到参考图片存储器(534)。由于符号流的解码产生与解码器位置(本地或远程)无关的位精确结果，因此参考图片存储器(534)中的内容在本地编码器与远程编码器之间也是按比特位精确对应的。换句话说，编码器的预测部分“看到”的参考图片样本与解码器将在解码期间使用预测时所“看到”的样本值完全相同。本领域技术人员也熟知这种参考图片同步性基本原理(以及在例如因信道误差而无法维持同步性的情况下产生的漂移)。

“本地”解码器(533)的操作可与已在上文结合图4详细描述的“远程”解码器(310)相同。然而，另外简要参考图4，当符号可用且熵编码器(545)和解析器(420)能够无损地将符号编码/解码为已编码视频序列时，包括信道(412)、接收器(410)、缓冲存储器(415)和解析器(420)在内的解码器(310)的熵解码部分，可能无法完全在本地解码器(533)中实施。

此时可以观察到，除存在于解码器中的解析/熵解码之外的任何解码器技术，也必定以基本上相同的功能形式存在于对应的编码器中。出于此原因，本申请侧重于解码器操作。可简化编码器技术的描述，因为编码器技术与全面地描述的解码器技术互逆。仅在某些区域中需要更详细的描述，并且在下文提供。

在操作期间，源编码器(530)可执行运动补偿预测编码。参考来自视频序列中被指定为“参考帧”的一个或多个先前已编码帧，所述运动补偿预测编码对输入帧进行预测性编码。以此方式，编码引擎(532)对输入帧的像素块与参考帧的像素块之间的差异进行编码，所述参考帧可被选作所述输入帧的预测参考。

本地视频解码器(533)可基于源编码器(530)创建的符号，对可指定为参考帧的帧的已编码视频数据进行解码。编码引擎(532)的操作可为有损过程。当已编码视频数据可在视频解码器(图5中未示)处被解码时，重建的视频序列通常可以是带有一些误差的源视频序列的副本。本地视频解码器(533)复制解码过程，所述解码过程可由视频解码器对参考帧执行，且可使重建的参考帧存储在参考图片高速缓存(534)中。以此方式，编码器(503)可在本地存储重建的参考帧的副本，所述副本与将由远端视频解码器获得的重建参考帧具有共同内容(不存在传输误差)。

预测器(535)可针对编码引擎(532)执行预测搜索。即，对于将要编码的新帧，预测器(535)可在参考图片存储器(534)中搜索可作为所述新图片的适当预测参考的样本数据(作为候选参考像素块)或某些元数据，例如参考图片运动矢量、块形状等。预测器(535)可基于样本块逐像素块操作，以找到合适的预测参考。在一些情况下，根据预测器(535)获得的搜索结果，可确定输入图片可具有从参考图片存储器(534)中存储的多个参考图片取得的预测参考。

控制器(550)可管理视频编码器(530)的编码操作，包括例如设置用于对视频数据进行编码的参数和子群参数。

在熵编码器(545)中对所有上述功能单元的输出进行熵编码。熵编码器根据例如本领域技术人员熟知的霍夫曼编码、可变长度编码、算术编码等技术对各种功能单元生成的符号进行无损压缩，从而将所述符号转换成已编码视频序列。

传输器(540)可缓冲由熵编码器(545)创建的已编码视频序列，从而为通过通信信道(560)进行传输做准备，所述通信信道可以是通向将存储已编码的视频数据的存储装置的硬件/软件链路。传输器(540)可将来自视频编码器(530)的已编码视频数据与要传输的其它数据合并，所述其它数据例如是已编码音频数据和/或辅助数据流(未示出来源)。

控制器(550)可管理编码器(303)的操作。在编码期间，控制器(550)可以为每个已编码图片分配某一已编码图片类型，但这可能影响可应用于相应的图片的编码技术。例如，通常可将图片分配为以下任一种图片类型：

帧内图片(I图片)，其可以是不将序列中的任何其它帧用作预测源就可被编码和解码的图片。一些视频编解码器容许不同类型的帧内图片，包括例如独立解码器刷新(Independent Decoder Refresh，“IDR”)图片。所属领域的技术人员了解I图片的变体及其相应的应用和特征。

预测性图片(P图片)，其可以是可使用帧内预测或帧间预测进行编码和解码的图片，所述帧内预测或帧间预测使用至多一个运动矢量和参考索引来预测每个块的样本值。

双向预测性图片(B图片)，其可以是可使用帧内预测或帧间预测进行编码和解码的图片，所述帧内预测或帧间预测使用至多两个运动矢量和参考索引来预测每个块的样本值。类似地，多个预测性图片可使用多于两个参考图片和相关联元数据以用于重建单个块。

源图片通常可在空间上细分成多个样本块(例如，4×4、8×8、4×8或16×16个样本的块)，且逐块进行编码。这些块可参考其它(已编码)块进行预测编码，根据应用于块的相应图片的编码分配来确定所述其它块。举例来说，I图片的块可进行非预测编码，或所述块可参考同一图片的已经编码的块来进行预测编码(空间预测或帧内预测)。P图片的像素块可参考一个先前编码的参考图片通过空间预测或通过时域预测进行非预测编码。B图片的块可参考一个或两个先前编码的参考图片通过空间预测或通过时域预测进行非预测编码。

视频编码器(303)可根据例如ITU-T H.265建议书的预定视频编码技术或标准执行编码操作。在操作中，视频编码器(303)可执行各种压缩操作，包括利用输入视频序列中的时间和空间冗余的预测编码操作。因此，已编码视频数据可符合所用视频编码技术或标准指定的语法。

在实施例中，传输器(540)可在传输已编码的视频时传输附加数据。视频编码器(530)可将此类数据作为已编码视频序列的一部分。附加数据可包括时间/空间/SNR增强层、冗余图片和切片等其它形式的冗余数据、SEI消息、VUI参数集片段等。

在下文中，描述的重点将集中在视频编解码器的高级语法上，并且更具体地集中在NAL单元头(NUH)设计上。

由于NUH不仅可以由有望处理复杂语法的解码器进行解释，而且可以由MANE、文件重写器等(此后称为MANE)进行解释，因此其设计必须避免复杂的熵编解码方案，诸如可变长度代码(VLC：variable length codes)或算术编解码。另一方面，一定量的复杂度(包括语法元素的有条件存在)是可接受的，尤其是如果在那些语法元素中传达的信息需要被移到NUH之外并进入NAL单元有效载荷中。其原因可能是NAL单元有效载荷受到起始码防止竞争的保护，并且从实现和计算复杂性的角度来看，反转起始码防止竞争可能是一项繁琐的任务。

出于MANE易于处理的原因，NUH已进行八位字节对齐，这意味着它们的比特长度可以被8整除。由于可能需要至少一个比特(在H.264和H.265NUH中被称为forbidden_zero_bit)，因此为了在MPEG-2传输流信道上传输视频时的起始码防止竞争，NAL单元头的最小长度是8比特。理想情况下，对于最常见的NAL单元类型(NUT)，设计应保持在这8个比特内，但是对于更独特的和不常见的NUT，或者对于其中的头开销可以忽略不计的NUT，可能需要更多的比特，所述头开销作为已编码图片类型的百分比(例如，I图片及其派生或者以基本上未压缩的形式编码的图片)。

在H.265的开发期间，规定了大量的附加NUT(相对于H.264中的那些NUT)。此外，在H.265中，NAL单元头中的时间可伸缩性信令，被引入到基线配置文件(在H.265中被称为主配置文件)中，并且如今被广泛使用。对于未来的视频编解码标准(诸如VVC)，可以预期的是，NUT的数量和对时间可伸缩性的需求都不会消失。使用用于NUT的六个比特，一个比特用于forbidden_zero_bit，以及三个比特用于时间分层信息，由于八位字节对齐，一个到达10比特，，这导致H.265中的16比特NUH。

然而，从编解码效率的角度来看，对于诸如拖尾图片(trailing picture)(其可包括P图片/条带(slice)/图块组(tile group)、B图片/条带/图块组等)的最常见的NUT，仅使用单个八位字节的NUH将是合乎需要的。不太常用的NUT或为某些应用而设计的NUT可以使用较大的头。所公开的主题通过超出NAL单元头的第一个八位字节的语法元素的有条件存在(如由指示NAL单元类型类的至少一个专用NUT所指示)，和/或通过在解码可用且可解码的高级语法结构中的信息来实施此需求，其中，在使用扩展机制的第一NAL单元之前进行解码。

参考图6，示出了根据所公开的主题的NUH(601)。NUH(601)可以包括在基于MPEG-2传输流的系统中起始码防止竞争所需的forbidden_zero_bit(602)。NUH(601)可以进一步包括NAL单元类型类语法元素(603)，本文表示为NALU类和四比特长度。在与所描绘的NUH(601)相同的某些情况下，并且对于某些类型的NAL单元，尤其是预期为最常见的NAL单元(诸如P及B图片/图块组/图块/条带/GOB/…(此后称为P/B段))，可将该值解释为直接指示P/B段类型的NAL单元类型。时间层信息(604)可以类似于例如从H.265已知的信息，并且在该示例中可以占用3比特。

图6包括第二NUH(605)，还包括如前所述的forbidden_zero_bit(606)和时间层信息(608)。然而，对于某些其它类型的NAL单元(例如，不携带P/B段)，诸如随机存取段类型、前导图片段类型、切换图片段类型、参数集类型、各种码流标记等，NAL单元类型类语法元素(607)可以指示(609)诸如随机存取段类、前导图片类型类、参数集类型类、标记类等的段类型类。作为辅助信息，例如随机存取段类的值可以触发NUH中携带此类信息的至少一个附加八位字节的存在。在该示例中，添加了一个八位字节(610)(以粗体虚线轮廓表示)，其包括类(611)内的随机存取图片的NUT(本文：由3比特指示)，以及为将来的扩展以及保留八位字节对齐而保留(612)的多个比特。

以H.265的NUT为例，可以使用以下分类：

不包括在类中，而是直接发信号通知，因为它们在通用码流中可能相当常见，包括

TRAIL_N，TRAIL_R，PREFIX_SEI_NUT和SUFFIX_SEI_NUT，

指示这些需要四类NUT。另外，对于总共九个未保留或未指定的代码点，可以有五个类。

类1：前导图片

RADL_N，RADL_R，

类2：切换图片

TSA_N，TSA_R，STSA_N，STSA_R

类3：随机存取图片

BLA_W_LP，BLA_W_RADL，BLA_N_LP，IDR_W_RADL，IDR_N_LP，CRA_NUT

类4：参数集

(DPS_NUT)，VPS_NUT，SPS_NUT，PPS_NUT

类5：标记

AUD_NUT，EOS_NUT，EOB_NUT，FD_NUT。

如上公开或以类似形式引入的基于类的NUT信令，将允许为较不常见的NAL单元类型或与常见的大图片相关联的NAL单元类型花费额外的信令开销为代价(其中与已编码图片大小相关的附加开销可能不太重要)，以将NUH中的NUT字段减少到四比特，并且仍保留一些编号空间以供外部使用或未来扩展。

在某些环境中，还可以通过NAL单元头之外的机制来建立类。例如，在环境和行业中，遵循MANE中的参数集激活序列并不麻烦，可以通过参数集信息来触发类建立(更准确地说，本文是附加八位字节及其语法的存在)。这可能与视频码流中总是激活的那些参数集(称为解码器参数集的概念)特别相关。对配置文件或配置文件的生成的解析和/或上下文依赖性(在H.265中称为“配置文件空间”的概念)也是可接受的。在错误容错性不成问题的环境中，甚至NAL单元间头预测也是可能的。在这种情况下，第一NUH中的类ID可用作对第二NUH的解析依赖性，所述第二NUH在第一NUH之后。

在同一或另一实施例中，某些NAL单元类型类可不仅用于指示附加八位字节中NAL单元类型的存在，而且还可以用于指示同一或又一八位字节中的其它信息。例如，在某些应用中，在NAL单元类型中包括空间/SNR层ID、多视图层ID、图块(tile)id(例如，在图片中以解码顺序指示第n图块的整数)、分量类型id(例如，颜色平面的指示符、点云编解码中的属性等)、图片id(例如，指示图片顺序计数最低有效位(POC LSD：Picture Order CountLeast Significant Bit)的8比特，等等)可能是有用的。

考虑NUH(613)。所包括的是NAL单元类型类语法元素(614)，在所呈现的示例中，其可以指示具有附加信息的拖尾图片。这又可以触发(615)第一附加八位字节的存在，所述第一附加八位字节包括NAL单元语法元素的类型。在该示例中，该NAL单元类型语法元素的大小被选择为5比特，其分别被字母“A”至“E”标识，其中，第一比特A可以指示NAL单元是TRAL_N还是TRAIL_R，并且剩余的四个比特作为标志分别指示携带层id“B”、分量id“C”、图块id“D”和图片id“E”的附加语法元素的存在。所有这些附加的示例性语法元素是给定的、固定长度的二进制编码整数，并且它们可以被放置在由比特集指示的附加的八位字节中。在该示例中，第二个八位字节的剩余部分(616)包括layer_id的三个最高有效位(618)，所述layer_id如层ID存在比特设置为1所指示的，并且第三个八位字节的前三个比特包括layer_id的剩余三个比特(617)。假设将与分量id“C”和图块id“D”相关的比特设置为零，这就指示这些字段不存在。最后，在该示例中可以将比特“E”设置为1，并且可以指示(619)4比特图片id(620)；第三个八位字节(621)的剩余部分可以被设置为零以进行填充。

附加的八位字节的布局可以在不同类之间不同。例如，对于一些类，可以将附加的八位字节中的NUT的编号空间选择为大于或小于32(需要多于或少于5个比特)。在某些类中，与NUH(613)中的指示符比特相比，可能不需要指示符比特，或者需要更多或更少的指示符比特。NAL单元语法元素的类型之外的某些附加字段可能始终存在。

使用此种体系结构，可以将NUH设计为大于三个八位字节，从而引起起始码竞争问题。为了解决这些问题，每个第n个八位字节，例如从第三个八位字节开始的每第四个八位字节，可能需要设置或清除某些比特，并且相应地向后移位其它NUH字段，从而防止起始码竞争。

其它基于类的NUH体系结构也是可能的。例如，可以要求某些字段位于固定位置。当视频编解码技术或标准允许高度灵活的NUH时，这可能具有缺点，但可以简化MANE实现。

图7是描绘根据实施例的示例方法的流程图。如图7所示，该方法可以包括对固定长度二进制编码的NALU类类型进行解码，NALU类类型包括在网络抽象层单元(NALU)头中(框710)；对NALU头中的NALU类型进行解码(框720)；以及重建图片，其中，通过NALU类类型和NALU类型的组合来识别图片的类型(框730)。

参考图8，示出了类似于NUH(613)的示例性NAL单元头的语法图(801)。所公开的主题同样可与其它结构的NAL单元头一起使用，例如H.264、H.265、VVC或示例性NUH(605)的NAL单元头。在NAL单元头中，可以包括语法元素picture_id(802)。该包括可以以比特“E”的值为条件(803)，而比特“E”的存在又可以是对某个NAL单元类(805)的条件(804)。该picture_id可以是既易于视频编码器和解码器处理，也易于MANE处理的格式。作为示例而非限制，语法元素picture_id(802)由5比特无符号整数表示。5比特值提供32个值的编号空间，这可以允许唯一地识别32个图片中的一个。例如，如果对于被编码的每个图片，picture_id的值递增1，并且当达到32时回绕为零，则在NAL单元与图片的关联在易于出错的环境中中断之前，将需要丢失属于至少32个图片的NAL单元。

在同一或另一实施例中，语法元素picture_id(802)的大小可以大于或小于5比特。在大多数情况下，语法元素越大，NAL单元与图片的相关联的差错恢复性(errorresilient)越强，但以编解码效率为代价。

在同一或另一实施例中，picture_id(802)的大小可取决于NAL单元头中的其它语法元素。例如，视频编解码技术或标准可以使picture_id的大小取决于NAL单元类型或NAL单元类型类，如前所述。例如，某种NAL单元类型(例如等于1的NAL单元类型)可识别具有8比特picture_id大小的已编码图块组、图块或条带，而等于2的NAL单元类型可识别具有5比特picture_id大小的图块组、图块或条带。

在同一或另一实施例中，picture_id语法元素的大小可由其它高级语法元素确定，例如参数集。例如，序列参数集可以包括指示picture_id(802)语法元素的大小的语法元素，所述picture_id(802)语法元素在NAL单元所属的已编码视频序列的NAL单元头中。此类机制可能在已编码视频序列的NAL单元与参数集之间创建解析依赖性，这在某些情况下可能是不需要的。此外，MANE可能不仅需要解析所讨论的参数集，而且还以状态的形式保持其内容的至少一部分。这对于许多应用可能是不需要的，但是从编解码效率和码点使用的角度来看可能是有利的，并且在MANE可能不仅需要解析和解释参数集而且还需要复杂的可变长度语法结构(诸如图块组、图块或条带头)的当前情况下仍然是优选的。

以上，将设置picture_id(802)的值的一个选项，描述为已编码图片的循环计数器。设置值的更高级形式可能是有利的。例如，在同一或另一实施例中，picture_id(802)语法元素可由图片顺序计数(POC：Picture Order Count)值的n个最低有效位填充(populate)，图片顺序计数值由编码器和解码器维护。在这种情况下，可以通过上述用于确定picture_id(802)语法元素的大小的任何机制或任何其它合适的机制来确定N。使用POC的最低有效位可以具有某些优点。例如，在图片/帧速率是固定的情形下，(例如)如由固定帧速率标志所指示的，在已知编码器从不跳过图片的情况下，以及在通过例如接收编解码结构SEI消息或带外方法(out-of-band means)而已知编解码结构的情况下，使用POC可以提供除了解码顺序信息之外的隐式定时信息。

作为示例而非限制，以下概述了如何在H.265中使用POC。基于图片顺序计数创建或使用的唯一picture_id的其它形式(诸如参考图片选择和参考图片列表管理)可以同等地使用，并且意味着作为picture_id包括在POC的使用中，所述图片顺序计数是基于视频编解码技术创建的且出于内部目的而在那些视频编解码技术中使用的。

在H.265中，每个已编码图像与表示为PicOrderCntVal的图像顺序计数变量相关联。图像顺序计数可以用于识别图片、用于导出合并模式和运动矢量预测中的运动参数，以及用于解码器一致性检查。在给定的已编码视频序列(CVS：Coded Video Sequence)中，所有已编码图片的PicOrderCntVal值是唯一的。此外，图片顺序计数提供包括在CVS中的图片的相对输出顺序(即，来自已解码图片缓冲器，例如用于显示的)(即，在具有较高图片顺序计数的图片之前输出具有较低图片顺序计数的图片)。在ITU-T H.265中，PicOrderCntVal的值在-2

MaxPicOrderCntLsb＝2

其中，log2_max_pic_order_cnt_lsb_minus4的值应在0至12的范围内(包括0和12)。

ITU-TH.265规定PicOrderCntVal等于PicOrderCntMsb+slice_pic_order_cnt_lsb。slice_pic_order_cnt_lsb是根据该标准的第8.3.1节导出的。

在某些视频编解码标准和技术(包括(例如)H.265)中，POC的值包括于或可从某些语法元素(诸如条带头)导出。在同一或另一实施例中，当POC或其派生(如：POC的最低有效位)包括于NAL单元头中时，由于相同信息可能在同一NAL单元中出现两次，因此可能存在一定的冗余。视频编码技术或标准可通过以下选项中的至少一者解决这种冗余：通过添加的冗余来接受编解码损失，以便根据所公开的主题使条带头和NAL单元头两者的变化量最小化，或从条带头移除冗余信息。

设置picture_id的值的其它示例包括(例如)使用散列函数(hash function)，该散列函数基于图片识别信息结合可能在图片之间改变的值来计算的，所述图片识别信息例如可以是活动参数集的某些元素，所述可能在图片之间改变的值诸如样本值或POC值。此类机制除了将NAL单元与已编码图片相关联的能力之外，可能不携带任何独立有用的辅助信息，但是可以具有更好的抵抗比特错误的容错性的优势，因为在统计上，当相对于POC增加使用散列函数时，会有更多的比特变化。

编码器可以以类似于本领域技术人员已知的写入现有NAL单元头语法的方式，写入包括如上所述的填充的语法元素picture_id的NAL单元头。

解码器或MANE还可以以本领域技术人员已知的方式，从已编码视频码流解析NAL单元头——更确切地说，解析组成NAL单元头的语法元素，而不管picture_id的存在与否。然而，应当注意，在一些情况下，在不需要状态信息的情况下并且以可访问的熵编解码格式(例如固定长度的二进制码)对图片ID进行编码。在此范围内，根据所公开的主题解析NAL单元头可以不包括对解码器或MANE的附加繁重操作，所述解码器或MANE超出了语法元素picture_id本身的实际存在之外。

然而，根据所公开的主题，当与缺少所公开的主题所需的操作相比时，解码器或MANE可以毫不费力地将NAL单元与已编码图片相关联。参考图9，作为示例，解码器或MANE(此后称为解码器)可以解析并解码(901)包括第一语法元素picture_id的第一NAL单元头。作为不变量，该第一NAL单元头属于第一NAL单元，该第一NAL单元又属于第一已编码图片。

解码器可以进一步解析和解码包括第二语法元素picture_id的第二NAL单元头(902)，其中，第二NAL单元头属于第二NAL单元。

解码器可以对照第二picture_id(未示出)的值来检查第一picture_id的值。

如果这些值相同，则两个NAL单元属于同一已编码图片的可能性很高。可能性主要受到编码器用来输入picture_id的值和语法元素的大小的机制的影响。以上已经讨论了这两个因素。

解码器可以进一步解析和解码包括第三语法元素picture_id的第三NAL单元头(903)，其中，第三NAL单元头属于第三NAL单元。

再次，解码器可以对照第三picture_id检查(904)例如第一picture_id的值。如果这些值相同(905)，则第三NAL单元与第一NAL单元属于相同的已编码图片的可能性很高。然而，如果两个值不相同(906)，则可以确定第三NAL单元不属于与第一NAL单元相同的图片。

解码器或MANE可以以任何适当的方式利用根据所公开的主题所获得的信息，特别是picture_id以及NAL单元是否属于与另一在前的NAL单元相同的图片。例如，MANE可以跟踪picture_id中的POC最低有效位值，并将其与具有相关的编解码结构的现有知识相匹配。如果MANE(例如)由于其输出链路上的拥塞，而需要处置已编码视频序列的NAL单元，则MANE可将picture_id值与编解码结构中的位置进行匹配。一旦识别出适于处理的图片，它就可以去除该单个图片的所有NAL单元(但不一定是其它可以处理的图片的NAL单元，所述其它可以处理的图片可以在NAL单元头的其它字段中携带相同的信息)。类似地，观察CPU周期不足的解码器也可以采取类似的步骤。在任一情况下，对用户体验的负面影响可以是最小的，因为仅消除了单个可以处理的图片，并且MANE或解码器中的CPU负载也可以是最小的，因为操作是轻量级的——仅涉及NAL单元头中的固定长度码字。

根据实施例，在某些环境中，可裁剪已编码视频码流，以将某一分量或某一组分量(此后称为“分量”)隔离在某些NAL单元中。参考图10，在传统的图像和视频编解码标准中，与分量组有关的信息连同与所有分量有关的信息一起在同一NAL单元(1001)中进行编码，所述与分量组有关的信息诸如Y(1002)、Cr(1003)、Cb(1004)分量等，所述与所有分量有关的信息诸如NAL单元头(1005)和其它头信息(1006)等。某些技术和预测机制可以用于利用分量信号的可能相似性来获得压缩效率。例如，当在同一NAL单元中编码Y Cr Cb信号，覆盖条带、图块等时，即使涉及三个分量，也不需要多次地对“位置”信息(例如，重建图片中的条带/图块中的第一CU的位置)进行编码。还可以有许多更复杂的预测机制，其中在某些情况下，从亮度信息预测诸如色度运动矢量、块结构等的某些色度相关信息。

然而，在某些环境中，在其自己的NAL单元中对关于某个分量和某个图块(tile)或条带(slice)，或某个图块或条带的某个分量组的相关信息进行编码可能是有益的，即使在与单个NAL单元中对图块或条带的所有分量进行编码相比时，这可能意味着由于缺少预测而可能存在编解码效率的损失。

在同一或另一实施例中，可适当地标记此类NAL单元。有许多选项来标记NAL单元，包括将相关标记信息放置到NAL单元头、条带头、图块头、图块组头、与NAL单元相关联的SEI消息、在NAL单元之前或之后的SEI消息，或与NAL单元相关联的任何其它合适的头或非头信息中。有利地，标记可以是易于存取的形式，诸如：使用固定长度二进制码在NAL单元头中编码。作为示例而非限制，此后假设这种基于标记的NAL单元头。

在第一示例中，考虑使用Y Cr Cb颜色模型的传统分量编解码，在需要的地方，从亮度分量Y中修剪颜色分量(Cr和Cb)，从而生成黑白信号。在诸如H.264或H.265的视频编解码方案中，这样做将需要完全的代码转换步骤，因为Y、Cr和Cb信息可以相互预测，并且在宏块/CU级别上以交织方式进行编码。然而，在同一或另一实施例中，码流被构造，以使在空间域中的条带或图块或图块组或其它子图片分区(视情况而定)被分割成两个NAL单元。仍然参考图10，这两个NAL单元中的第一个(1010)可以包含NAL单元头(1011)，所述NAL单元头(1011)指示Y信息、其它头信息(1012)和亮度(Y)信息(1013)的存在。第二NAL单元(1020)可以包含与色度分量(Cr(1023)和Cb(1024))有关的信息，这基于这样的理解：与亮度分量不同，颜色分量不能单独使用。这两个分量可以形成分量组，该分两组可以是语义关系如此紧密的分量集合，使得从相应的应用程序的角度来看，将它们分开是不可取的。NAL单元(1020)还可以包含指示CR和CB信息两者的存在的NAL单元头(1021)，以及其它头信息(1022)。因为根据既定的实践，第一NAL单元和第二NAL单元应当在很大程度上是可独立解码的，并且当然不应当包含对彼此的解析依赖性，所以当将Y和Cr Cb信息分割为两个NAL单元时，可以遇到一定程度的编解码效率低下的情况。具体地，可禁止从亮度到色度分量信息的预测(例如，运动矢量预测、块形状预测、帧内方向预测等)，从而潜在地导致Cr和Cb信息所需较高比特速率。此外，其它头信息(1012)和(1022)可以分别包含重复信息。最后，每个NAL单元分别需要其自己的NAL单元头(1011)和(1021)，并且还可以期望这两个头比组合的NAL单元(1001)的单个头(1005)占用更多的比特。但是，在某些应用中，在没有完全代码转换的情况下，好处可能超过那些编解码效率损失，所述好处包括能够容易地从码流中去除某个分量或分量组的好处，或者避免对与分量或分量组相关的数据进行解码的好处(如果由解码器接收)。

在第二示例中，假定一种图像或视频编解码技术，所述技术支持除亮度和颜色之外的像素属性。图像或视频编解码技术必须得到广泛地解释，并且可以包括诸如立体、多视角、点云、光场等技术。作为早期的示例，除了以YCrCb、RGB或类似颜色格式编码的样本数据之外，某些支持的图像和视频编解码器还支持称为阿尔法通道的透明度信息。对于样本或样本组，阿尔法通道可以通过具有在码流中编码的透明度值(阿尔法)来表示。解码器可以像常规样本数据一样重建阿尔法图。渲染器可以使用阿尔法图来适当地对重建的样本数据和背景信息(如果有的话)进行加权，以创建透明度的错觉。

透明度只是样品颜色和亮度之外的许多可能属性中的一种。例如，某些编解码技术，特别是某些360度和点云编解码技术设想样本(或点云编解码中的点)除了亮度/颜色以及可能的透明度之外还包括反射率属性。此外，在点云编解码中，给定点可以基于观看方向(空间中的视点)，而具有相关联的不同属性值(亮度、颜色、透明度、反射率、表面法线、曲率以及可能的其它属性)。例如，当点云表示单向镜时，其在一个观看方向上是透明的，而在另一个观看方向上是不透明和反射的，因此透明度和反射率属性可能会因为视点而根本不同。单向镜也可稍微着色，这可基于方向和与反射镜表面上的点的距离而导致不同的颜色值。作为另一示例，视图相关颜色可用于实现从一系列视点对3D场景/对象进行照片真实感渲染，这对于诸如虚拟现实和增强现实的新兴应用是有用的。其它属性可包括人眼不可见，但与某些应用相关的波长。例如，某些面部识别传感器在低可见光条件下使用红外信号。甚至更高级的属性可能与极化有关。

考虑到上文列出的长属性，存在对高级信号的码流进行修剪的需求，该需求不是应用所必需的，并且由于视角、光照条件等或本文未列举的其它原因而不适用。

参考图11，示出了包括NAL单元头(1102)的第一NAL单元(1101)，所述NAL单元头(1102)用于指示Y和Y信息(1103)。此外，存在包括NAL单元头(1111)的第二NAL单元(1110)，所述NAL单元头(1111)指示色度(Cr Cb)信息。第三NAL单元(1120)包含指示透明度信息(阿尔法通道)(1121)和相关透明度信息(1122)的头。最后，还存在第四NAL(1130)单元，其包括指示反射率信息的NAL单元头(1131)和反射率信息(1132)。四个NAL单元可以属于图片的相同空间区域，所述图片可以由条带、图块、图块组等表示，或者四个NAL单元属于不同区域。然而，在后一种情况下，假设存在至少一个样本，其中，样本相关联的YCrCb、透明度和反射率信息包括在四个相应的NAL单元(1101，1110，1120，1130)中。在这种情况下，某些操作可能无需编解码就可能可以实现。

简要地参考图12，考虑包括数据源(1201)的系统，该数据源包含码流，该码流包括所有三个NAL单元，以及可能更多的类似类型，即，YCrCb NAL单元、透明度NAL单元和反射率NAL单元。这些NAL单元被转发(1202)到服务器/媒体感知网络单元(此后称为MANE：MediaAware Network Element)(1203)。将箭头(1202)绘制为特别粗的线以强调所有三种信息类型所需的高比特率。三个客户端已经请求相同的媒体码流，但是具有不同的解码和/或渲染能力，和/或不同的连通性。复杂的客户端(1205)能够充分地接收、解码和呈现所有的三种信息类型、YCrCb、透明度和反射率。因此，MANE(1203)可以将所有三个NAL单元转发到客户端(1205)，需要与源(1201)和MANE(1203)之间的连接基本相似的网络容量(1204)。可能还存在第二客户端(1207)，本文由笔记本电脑表示。该客户端可能具有略微较少的解码能力和/或连通性，从而不允许对反射率信息进行解码或传输，或者用户可能选择不对(例如)反射率信息感兴趣。无论限制因素是什么，将反射率信息转发(1206)到该客户端将是不明智的。因此，MANE可从码流移除与反射率相关的NAL单元，从而产生较低比特率的码流。最后，可能存在由智能电话表示的第三客户端(1209)。该客户端可能缺乏解码能力和/或连通性，所述连通性为透明性和反射率信息之间的连通性，和/或该使用可能已经指示对其中一者或两者不感兴趣。因此，MANE(1203)可以决定仅将携带YCrCb信息的NAL单元转发(1208)到第三客户端(1209)。

假定在同一NAL单元中编码所有属性的信息的传统编解码技术，MANE(1203)可能需要完全的代码转换步骤来提取与每个客户端(1205，1207，1209)相关的信息。这样做在计算上可能是昂贵的，从而增加了MANE(1203)的成本。然而，过滤NAL单元可能是一个轻量级的过程，因为它可以基于NAL单元头，或者是专有的，或者是结合高级语法中的其它易于解析和易于存取的信息(诸如参数集、SEI消息、条带/图块/图块组头等)进行。

从MANE的角度来看，最好的解决方案可以是在NAL单元头中具有码流修剪所需的所有相关信息，而这是迄今为止所假设的。稍微更繁琐的可能是需要解码固定或可变长度码字，所述码字在NAL单元本身携带的信息中，有利地是在NAL单元头之后的NAL单元的最开始处(“其它头信息，例如图10中的(1002)或(1003))。可能有两种情形。在一个更有利的情形中，在确定NAL单元所携带的信息的类型所需的程度上，“其它头信息”可以是可解释的，而无需从其它NAL单元例如参数集NAL单元获得的上下文。在这种情况下，MANE的额外复杂性可以仅限于解析其他头信息的信息，其可包括可变长度代码等，并且因此可能比固定长度NAL单元头码点(codepoints)在计算上更加昂贵。甚至更有问题的是，NAL单元所携带的信息类型的确定，需要在参数集等的上下文中解释其它头信息(1002，1003)。在这种情况下，MANE将必须跟踪参数集以及某些其它任务的激活，这些任务实际上已经相当于对基本上所有的高层语法进行解码。虽然比完全代码转换步骤更容易，但是对于大多数MANE体系结构，基于参数集的上下文相关解码(context sensitive decoding)可能过于繁琐。

现在以示例而非限制的方式来描述用于表示NAL单元头中的分量或分量组类型的选项。所呈现的选项反映了H.265的NAL单元头设计的基本语法布局和体系架构。可能存在可更适合于给定NAL单元头体系架构的其它选项，所述给定NAL单元头体系架构可用于其它编解码技术和标准中。

参考图13，例如，在NAL单元(1301)的NAL单元头(1302)中，可以如下指示分量或分量组：

在同一或另一实施例中，在第一选项中，可使用NAL单元类型的编号空间在NAL单元头(1303)中指示分量或分量组(1304)。具体地，NAL单元类型可包括指示已编码条带、图块、图块组等的码字，所述已编码条带、图块、图块组等仅携带特定分量或分量组。隐含地，此类信令的子集存在于H.265中，因为对于分量组Y Cr Cb，存在由NAL单元类型的给定值指示的条带类型。然而，在可能的程度上，可通过固定编号空间中的未分配码点(由于NAL单元类型的固定长度码字)为其它分量或分量类型分配更多码字。视频编解码标准或技术可基于标准设置委员会的理解将至少一个可用的码字分配给分量类型，所述理解是指标准设置委员会在编写标准时认为在标准寿命期间，哪些分量或分量组可变得与码流修剪和其它应用相关的理解。使用此选项，无需改变NAL单元头中的语法。

在第二选项中，可以重新分配仅在特定配置文件中有意义的H.265型NAL单元头(1305)的某些现有字段，以指示分量类型。在图9中，先前由层ID字段(1306)使用的比特被用作分量类型字段，但是也可以重新分配NAL单元头的其它字段。这样做可能会在技术上对配置文件产生不良的解析和上下文依赖关系，这些依赖关系可能会编码在参数集中。然而，与大多数其它参数集值相比，配置文件ID被广泛地理解为，可通过诸如能力交换的机制，事先提供给MANE使用；因此，此类配置文件依赖性可能不像对参数集中的其它字段的解析和上下文依赖性那样麻烦。然而，第二选项可基于NAL单元头已编码的分量类型，排除同时使用(例如)分层或多视图编解码与码流修剪的。在第三选项中，可以以将比特添加到NAL单元头(1307)为代价来避免前述的所有缺点。具体地，字段分量类型(908)可以包括在NAL单元头中的固定位置处，例如在末端。虽然这个选项是最灵活的，但从编解码效率的角度来看它也是最不可取的。然而，应注意，分量类型(1308)的存在可能取决于某些配置文件的使用(且因此以虚线描绘)，从而减轻对配置文件的编解码效率影响，所述配置文件对基于分量类型的处理不感兴趣。可替换地或附加地，分量类型的存在也可能仅限于NAL单元类型字段的某些值。例如，可以想象，对于传统Y Cr Cb条带/图块/图块组，存在NAL单元类型，以及对于具有附加分量类型信令的条带/图块/图块组，存在用不同的NAL单元类型。虽然在已知的视频编解码标准或技术中还没有包括此类可选的NAL单元头信息字段，但是在编码器、解码器或MANE中实现它们的障碍要低于对参数集值具有的上下文依赖性，因此是优选的。当然，该机制可以从NAL单元类型编号空间中去除编号空间。

在第四选项中，语法可以(例如)遵循如前所述的可扩展的NAL单元头的设计原理，所述语法用于将分量信息包括在NAL单元头或可比较语法元素中。特别地，可以使用类似于在图片ID和图8的上下文中描述的机制。具体地，分量ID可以替换图片ID(802)。下文描述其它选项。对于不遵循上文假设的H.265的NAL单元头设计的NAL单元头设计，其它选项可能是明智的。

如果分量类型(1306，1308)在其自己的字段中进行编码(而不是在NAL单元类型中填充未使用的代码点)，则用于分量类型的编解码的某些选项变得可用。

仍参考图13，在同一或另一实施例中，分量类型(1320)可被解释为比特掩码。在所呈现的示例中，四比特分量类型由以下的每个比特填充一位：

亮度数据(Y)(921)

色度数据(Cr，Cb)(922)

透明度(阿尔法)(923)，以及

反射率(924)。

如果分量的数量相当小(例如：四到八)，则此类基于比特掩码的设计可能是有利的，从而将比特掩码的大小限制在合理的范围内。它还允许NAL单元内容的非常灵活的布局；例如，将覆盖Y Cr Cb或具有透明度的Y或具有透明度和反射率的Y Cr Cb的NAL单元包括进来(在同一视频码流中)是可能的。从应用的角度来看，是否需要此类灵活性可能是值得怀疑的，尽管灵活的NAL单元有效载荷布局肯定是受欢迎的，但是过度地利用编码器的灵活性可能导致出现MANE无法再去除不需要的分量的情形。

作为替换，分量类型也可以被解释为预定义分量或分量组的列表中的枚举器。

例如，分量类型(1330)可以是四比特无符号整数。比特字段的其它长度也是可能的，并且可以取决于配置文件或其它容易获得的信息，所述容易获得的信息包括如上所述的NAL单元类型中的信息。

四比特无符号整数值允许16个不同的分量或分量组。图13列举(1331)如下几个可能的选项：

0：Y Cr Cb

1：Y

2：Y Cr CB加上透明度

3；Y Cr Cb加上反射率

4：Y Cr Cb加上透明度和反射率

5：3D几何信息(XYZ)

6：深度映射

7：占用映射

8：表面法向矢量

9..15：未分配的

在此类情形下，分量类型中4的值可以指示(1332)NAL单元可以包含关于Y、Cr、Cb、透明度和反射率的信息。

在同一或另一实施例中，当通过上述机制中的任一机制指示此类分量类型时，NAL单元包含与某个分量类型相关的信息可能是必要条件，但不是充分条件。这可以类似于(例如)条带类型。例如，B条带可包含双向预测的编解码单元，但也可仅由帧内已编码的编解码单元组成。

在同一或另一实施例中，NAL单元可以包含与特定分量类型和特定视角相关的信息。视角可以由视图标识符(例如，左或右视图)或外部/内部相机参数集来识别。例如，分量类型(1330)可以是四比特无符号整数，并且可以具有以下选项之一：

0：Y Cr Cb加上对应于左摄像机的深度图(depth map)

1：Y Cr Cb加上对应于右摄像机的深度图

2：XYZ几何结构信息加上占用图(occupancy map)

3..15：未分配的

上面描述的网络抽象层单元头中的网络抽象单元层类型类的技术和/或网络抽象单元头中的图片参考的技术可以通过计算机可读指令实现为计算机软件，并且物理地存储在一个或多个计算机可读介质中。例如，图14示出了计算机系统(1400)，其适于实现所公开主题的某些实施例。

所述计算机软件可通过任何合适的机器代码或计算机语言进行编码，通过汇编、编译、链接等机制创建包括指令的代码，所述指令可由计算机中央处理单元(CPU)，图形处理单元(GPU)等直接执行或通过译码、微代码等方式执行。

所述指令可以在各种类型的计算机或其组件上执行，包括例如个人计算机、平板电脑、服务器、智能手机、游戏设备、物联网设备等。

图14所示的用于计算机系统(1400)的组件本质上是示例性的，并不用于对实现本申请实施例的计算机软件的使用范围或功能进行任何限制。也不应将组件的配置解释为与计算机系统(1400)的示例性实施例中所示的任一组件或其组合具有任何依赖性或要求。

计算机系统(1400)可以包括某些人机界面输入设备。这种人机界面输入设备可以通过触觉输入(如：键盘输入、滑动、数据手套移动)、音频输入(如：声音、掌声)、视觉输入(如：手势)、嗅觉输入(未示出)，对一个或多个人类用户的输入做出响应。所述人机界面设备还可用于捕获某些媒体，气与人类有意识的输入不必直接相关，如音频(例如：语音、音乐、环境声音)、图像(例如：扫描图像、从静止影像相机获得的摄影图像)、视频(例如二维视频、包括立体视频的三维视频)。

人机界面输入设备可包括以下中的一个或多个(仅绘出其中一个)：键盘(1401)、鼠标(1402)、触控板(1403)、触摸屏(1410)、数据手套(未示出)、操纵杆(1405)、麦克风(1406)、扫描仪(1407)、照相机(1408)。

计算机系统(1400)还可以包括某些人机界面输出设备。这种人机界面输出设备可以通过例如触觉输出、声音、光和嗅觉/味觉来刺激一个或多个人类用户的感觉。这样的人机界面输出设备可包括触觉输出设备(例如通过触摸屏(1410)、数据手套(未示出)或操纵杆(1405)的触觉反馈，但也可以有不用作输入设备的触觉反馈设备)、音频输出设备(例如，扬声器(1409)、耳机(未示出))、视觉输出设备(例如，包括阴极射线管屏幕、液晶屏幕、等离子屏幕、有机发光二极管屏的屏幕(1410)，其中每一个都具有或没有触摸屏输入功能、每一个都具有或没有触觉反馈功能——其中一些可通过诸如立体画面输出的手段输出二维视觉输出或三维以上的输出；虚拟现实眼镜(未示出)、全息显示器和放烟箱(未示出))以及打印机(未示出)。

计算机系统(1400)还可以包括人可访问的存储设备及其相关介质，如包括具有CD/DVD的高密度只读/可重写式光盘(CD/DVD ROM/RW)(1420)或类似介质(1421)的光学介质、拇指驱动器(1422)、可移动硬盘驱动器或固体状态驱动器(1423)，诸如磁带和软盘(未示出)的传统磁介质，诸如安全软件保护器(未示出)等的基于ROM/ASIC/PLD的专用设备，等等。

本领域技术人员还应当理解，结合所公开的主题使用的术语“计算机可读介质”不包括传输介质、载波或其它瞬时信号。

计算机系统(1400)还可以包括通往一个或多个通信网络的接口。例如，网络可以是无线的、有线的、光学的。网络还可为局域网、广域网、城域网、车载网络和工业网络、实时网络、延迟容忍网络等等。网络还包括以太网、无线局域网、蜂窝网络(GSM、3G、4G、5G、LTE等)等局域网、电视有线或无线广域数字网络(包括有线电视、卫星电视、和地面广播电视)、车载和工业网络(包括CANBus)等等。某些网络通常需要外部网络接口适配器，用于连接到某些通用数据端口或外围总线(1449)(例如，计算机系统(1400)的USB端口)；其它系统通常通过连接到如下所述的系统总线集成到计算机系统(1400)的核心(例如，以太网接口集成到PC计算机系统或蜂窝网络接口集成到智能电话计算机系统)。通过使用这些网络中的任何一个，计算机系统(1400)可以与其它实体进行通信。所述通信可以是单向的，仅用于接收(例如，无线电视)，单向的仅用于发送(例如CAN总线到某些CAN总线设备)，或双向的，例如通过局域或广域数字网络到其它计算机系统。上述的每个网络和网络接口可使用某些协议和协议栈。

上述的人机界面设备、人可访问的存储设备以及网络接口可以连接到计算机系统(1400)的核心(1440)。

核心(1440)可包括一个或多个中央处理单元(CPU)(1441)、图形处理单元(GPU)(1442)、以现场可编程门阵列(FPGA)(1443)形式的专用可编程处理单元、用于特定任务的硬件加速器(1444)等。这些设备以及只读存储器(ROM)(1445)、随机存取存储器(1446)、内部大容量存储器(例如内部非用户可存取硬盘驱动器、固态硬盘等)(1447)等可通过系统总线(1448)进行连接。在某些计算机系统中，可以以一个或多个物理插头的形式访问系统总线(1448)，以便可通过额外的中央处理单元、图形处理单元等进行扩展。外围装置可直接附接到核心的系统总线(1448)，或通过外围总线(1449)进行连接。外围总线的体系结构包括外部控制器接口PCI、通用串行总线USB等。

CPU(1441)、GPU(1442)、FPGA(1443)和加速器(1444)可以执行某些指令，这些指令组合起来可以构成上述计算机代码。该计算机代码可以存储在ROM(1445)或RAM(1446)中。过渡数据也可以存储在RAM(1446)中，而永久数据可以存储在例如内部大容量存储器(1447)中。通过使用高速缓冲存储器可实现对任何存储器设备的快速存储和检索，高速缓冲存储器可与一个或多个CPU(1441)、GPU(1442)、大容量存储器(1447)、ROM(1445)、RAM(1446)等紧密关联。

所述计算机可读介质上可具有计算机代码，用于执行各种计算机实现的操作。介质和计算机代码可以是为本申请的目的而特别设计和构造的，也可以是计算机软件领域的技术人员所熟知和可用的介质和代码。

作为实施例而非限制，具有体系结构(1400)的计算机系统，特别是核心(1440)，可以作为处理器(包括CPU、GPU、FPGA、加速器等)提供执行包含在一个或多个有形的计算机可读介质中的软件的功能。这种计算机可读介质可以是与上述的用户可访问的大容量存储器相关联的介质，以及具有非易失性的核心(1440)的特定存储器，例如核心内部大容量存储器(1447)或ROM(1445)。实现本申请的各种实施例的软件可以存储在这种设备中并且由核心(1440)执行。根据特定需要，计算机可读介质可包括一个或一个以上存储设备或芯片。该软件可以使得核心(1440)特别是其中的处理器(包括CPU、GPU、FPGA等)执行本文所述的特定过程或特定过程的特定部分，包括定义存储在RAM(1446)中的数据结构以及根据软件定义的过程来修改这种数据结构。另外或作为替代，计算机系统可以提供逻辑硬连线或以其它方式包含在电路(例如，加速器(1444))中的功能，该电路可以代替软件或与软件一起运行以执行本文所述的特定过程或特定过程的特定部分。在适当的情况下，对软件的引用可以包括逻辑，反之亦然。在适当的情况下，对计算机可读介质的引用可包括存储执行软件的电路(如集成电路(IC))，包含执行逻辑的电路，或两者兼备。本申请包括任何合适的硬件和软件组合。

虽然本申请已对多个示例性实施例进行了描述，但实施例的各种变更、排列和各种等同替换均属于本申请的范围内。因此应理解，本领域技术人员能够设计多种系统和方法，所述系统和方法虽然未在本文中明确示出或描述，但其体现了本申请的原则，因此属于本申请的精神和范围之内。