OverView of HEVC Standard

介绍
HEVC 编码设计和功能亮点
高级语法
HEVC 视频编码技术
Profiles, Tiers And Levels
- A) Profile, Level, and Tier Concepts
- B) The HEVC Profile and Level Definitions
历史与标准化进程
结论

HEVC 是 ITU-T 视频编码专家组和 ISO/IEC 运动图像专家组的最新视频编码标准。HEVC 标准化工作的主要目标是相对于现有标准，在 50% 的比特率降低范围内显著提高压缩性能，以获得相同的感知视频质量。本文概述了 HEVC 标准的技术特性和特点。

介绍

HEVC 标准是 ITU-T 视频编码专家组(VCEG)和 ISO/IEC 运动图像专家组(MPEG)标准化组织的最新联合视频项目，它们在一个称为视频编码联合协助小组(JCT-VC)的伙伴组织关系中共同工作。HEVC 标准的第一版预计将于 2013 年 1 月定稿，最终形成一份由 ITU-T 和 ISO/IEC 共同发布的统一文本。后续会有更多工作，以扩展该标准，从而支持多个其他应用场景，包括具有增强精度和颜色格式支持的扩展范围使用、可伸缩视频编码和三维/立体/多视图视频编码。在 ISO/IEC 中，HEVC标准将成为 MPEG-H 第 2 部分(ISO/IEC 23008-2)，在 ITU-T 中，它很可能成为 ITU-T 建议 H.265。

视频编码标准主要通过注明的 ITU-T 和 ISO/IEC 标准的发展而起来的。ITU-T 生产了 H.261 和 H.263，ISO/IEC 生产了 MPEG-1 和 MPEG-4视频，这两个组织联合生产了 H.262/MPEG-2视频和 H.264/MPEG-4 AVC 标准。这两项联合制定的标准产生了特别强烈的影响，并已被广泛应用于我们日常生活中日益流行的各种产品中。在这一演变过程中，不断努力最大限度地提高压缩能力，并改进其他特性，如数据丢失鲁棒性，同时考虑到在预期部署每个标准时，产品中实际使用的计算资源。

HEVC 之前的主要视频编码标准是 H.264/MPEG-4 AVC，它最初是在 1999 年至 2003 年期间开发的，然后在 2003 年至 2009 年期间以几种重要方式进行了扩展。H.264/MPEG-4 AVC 是数字视频的一种使能技术，几乎涵盖了 H.262/MPEG-2 视频之前未涵盖的所有领域，并在其现有应用领域中基本上取代了旧标准。它广泛应用于许多应用，包括通过卫星、有线和地面传输系统广播高清(HD)电视信号、视频内容采集和编辑系统、摄像机、安全应用、互联网和移动网络视频、蓝光光盘以及视频聊天等实时对话应用，视频会议和远程呈现系统。

然而，服务的日益多样化、高清视频的日益普及以及超高清格式(如4kx2k 或 8kx4k分辨率)的出现，对编码效率的需求甚至超出了 H.264/MPEG-4 AVC 的能力。当更高的分辨率伴随立体声或多视图捕获和显示时，这种需求更强烈了。此外，针对移动设备和平板电脑的视频应用程序所带来的流量，以及视频点播服务的传输需求，正在给当今的网络带来严峻挑战。在移动应用程序中，对更高质量和分辨率的需求也越来越强烈。

HEVC 旨在解决 H.264/AVC 的所有现有应用，并特别关注两个特别问题：提高视频分辨率，增加并行处理框架的使用。HEVC 的语法是通用的，通常也适用于上面没有特别提到的其他应用程序。

与过去所有的 ITU-T 和 ISO/IEC 视频编码标准一样，在 HEVC 中，只有比特流结构和语法是标准化的，并且对生产解码图片的比特流及其映射的约束也是标准化的。通过定义语法元素的语义和解码过程来给出映射，使得当给定符合标准约束的比特流时，符合标准的每个解码器将产生相同的输出。标准范围的这种限制允许以适合特定应用的方式(平衡压缩质量、实现成本、上市时间和其他考虑因素)最大限度地优化实现。然而，它并不能保证端到端的复制质量，因为它甚至允许有损失的编码技术被认为是合格的。

为了帮助行业社区学习如何使用标准，标准化工作不仅包括开发文本规范文档，还包括参考软件源代码，作为如何编码和解码 HEVC 视频的示例。在标准设计期间，参考软件草案已被用作委员会内部工作的研究工具，也可作为通用研究工具和产品基础，还正在开发标准测试数据套件，以测试是否符合该标准。

本文的组织结构如下：第二部分重点介绍 HEVC 编码设计的一些关键特性。第三部分解释了 HEVC 编码数据的高级语法和总体结构。第四部分将更详细地描述 HEVC 编码技术。第五部分解释了 HEVC 的 profile、tier 和 level 设计。由于编写像 HEVC 这样实质性的技术概述需要大量的总结，如有遗漏，请向读者咨询。第六部分讨论了 HEVC 标准化工作的历史。

HEVC 编码设计和功能亮点

HEVC 标准旨在实现多个目标，包括编码效率、易于传输系统集成和数据丢失恢复能力，以及使用并行处理架构的可实现性。下面小节简要描述了实现这些目标的设计关键要素，以及生成有效比特流的典型编码器操作。第三节和第四节提供了有关不同元素的相关语法和解码过程的更多细节。

A. 视频编码层

HEVC 的视频编码层采用自 H.261 以来所有视频压缩标准中使用的相同的混合编码方法(图像间/图像内预测和二维变换编码)。图 1 描述了可创建符合 HEVC 标准的比特流的混合视频编码器的框图。

产生符合 HEVC 的比特流的编码算法通常如下进行：每个图片被分割成块形区域，精确的块分割被传送到解码器。视频序列的第一幅图片(以及每个随机接入点处的第一幅图片到视频序列中)仅使用图片内预测进行编码(该预测使用同一图片内从区域到区域的空间数据预测，但不依赖于其他图片)。对于序列或随机接入点间的所有剩余图片，通常对大多数块使用图像间时间预测编码模式。用于画面间预测的编码处理包括：选择包含所选参考画面和运动矢量(MV)的运动数据，以应用于预测每个块的样本。编码器和解码器通过使用 MV 和模式决策数据应用运动补偿(MC)来生成相同的图像间预测信号，这些数据作为边信息传输。

帧内或帧间预测的残余信号(即原始块与其预测之间的差值)，通过线性空间变换进行变换。然后对变换系数进行缩放、量化、熵编码，并与预测信心一起传输。

编码器复制解码器处理循环(参见图1中的灰色阴影框)，以便两者将为后续数据生成相同的预测。因此，量化变换系数通过逆缩放构造，然后逆变换以复制剩余信号的解码近似。然后将残差添加到预测中，并且该添加的结果随后可被反馈到一个或两个环路滤波器中以平滑由分块处理和量化引起的伪影。最终图片表示(即解码器输出的副本)存储在解码图片缓冲器中，以用于后续图片的预测。一般来说，图片的编码或解码处理顺序通常不同于它们从源到达的顺序，需要区分解码器的解码顺序(即比特流顺序)和输出顺序(即显示顺序)。

要由 HEVC 编码的视频材料通常应作为逐行扫描图像输入(由于源视频以该格式产生，或由编码前去交错)。HEVC 设计中不存在明确的编码特征，以支持隔行扫描的使用，因为隔行扫描不再用于显示，并且在分发中变得越来越步常见。然而，在 HEVC 中提供了元数据语法，以允许编码器通过将隔行扫描视频的每个字段(即，每个视频帧的偶数或奇数行)编码以单独图片来指示隔行扫描视频已被发送，或这其已通过将每个隔行扫描帧编码为 HEVC 编码图片来发送。这提供了一种对隔行视频进行编码的有效方法，而无需使解码器负担对其支持特殊解码过程的负担。

在下文中，使用 HEVC 的混合视频编码所涉及的各种特性如下所示。

1) Coding tree units and coding tree block(CTB) structure

在以前的标准中，编码层的核心是宏块，它包含 luma 采样的 16x16 宏块，在通常的 4:2:0 颜色采样情况下，chroma 采样有对应的 8x8 色度块；而 HEVC 中的类似结构是编码树单元(CTU)，其大小由编码器选择，可以大于传统宏块。CTU 由 luma CTB 和对应的色度 CTB 以及语法元素组成。luma CTB 的大小可以选择为 L=16、32或64个样本，较大的大小通常能够实现更好的压缩。HEVC 支持使用树结构和类似四叉树的信令将 CTB 划分为更小的块。

2）Coding units(CUs) and coding blocks(CBs)

CTU 的四叉树语法指定其亮度和色度 CBs 的大小和位置。四叉树的根与 CTU 关联。因此，luma CTB 的大小是 luma CB 支持的最大大小。CTU 分为 luma 和 chroma CBs 是联合发出的信号。一个 luma CB 和两个 sample CB，连同相关的语法，构成一个编码单元(CU)。一个 CTB 可以只包含一个 CU，或者可以分割成多个 CU，并且每个 CU 都有一个相关的分区为预测单元(PU)和变换单元树(TU)。

3）Prediction units and prediction blocks(PBs)

在 CU 级别决定是使用图像间预测还是图像内预测对图片区域进行编码。PU 分区结构的根位于 CU 级别。取决于基本预测类型决策，luma 和 chroma CBs 随后可以在大小上进一步分割并从 luma 和 chroma 预测块(PBs)预测。HEVC 支持从 64x64 到 4x4 样本的可变 PB 大小。

4）TUs and transform blocks

使用块变换对预测残差进行编码。TU 树结构的根位于 CU 级别。luma CB 残差可以与 luma 变换块(TB)相同，或者可以进一步分割成更小的 luma TB。这同样适用于 chroma TBs。对于 4x4、8x8、16x16 和 32x32 的正方形 TB，定义了与DCT 类似的整数基函数。对于 luma 图像内预测残差的 4x4 变换，可选指定从 DST 形式导出的整数变换。

5）Motion vector signaling

使用AMVP(Advanced motion vector prediction)，包括基于来自相邻 PBs 和参考图片的数据导出几个最可能的候选。还使用 MV 编码的合并模式，允许 MV 从时间上或空间上相邻的 PBs 继承。此外，与 H.264/AVC 相比，还指定了改进的 skipped 和直接运动推断。

6）Motion compensation

MVs 使用四分之一采样精度，分数采样位置的插值使用 7 抽头或 8 抽头滤波器(相比之下，H.264/AVC 中，半采样位置的六抽头滤波后，四分之一采样位置的线性插值)。与 H.264/AVC 类似，使用了多个参考图片。对于每个 PB，传输一个或两个运动矢量，分别表示单预测或双预测编码。如在 H.264/AVC 中一样，可以称为加权预测的方式对预测信号应用缩放和偏移操作。

7) Intrapicture prediction

相邻块的间边界样本，用作未执行帧间预测的区域中的空间预测的参考数据。图像内预测支持 33 种方向模式(与 H.264/AVC 中的 8 种模式相比)，以及plus plannr 和 DC 预测模式。通过基于先前解码的相邻 PBs 的模式导出最可能模式(例如，预测方向)来编码所选择的画面内预测模式。

8) Quantization control

与 H.264/AVC 中一样，HEVC 中使用均匀重建量化(URQ)，量化缩放矩阵支持各种变换块大小。

9）Entropy coding

CABAC 用于熵编码。这类似于 H.264/AVC 中的 CABAC 方案，单经过几次改进以提高其吞吐量速度(特别是对于并行处理架构)和压缩性能，并降低其上下文内存需求。

10）In-loop deblocking filtering

与 H.264/AVC 中使用的去块滤波器类似去块滤波器，在图像间预测循环中操作。然而，该设计在决策和过滤过程方面得到了简化，并且对并行处理更加友好。

11）Sample adaptive offset(SAO)

在去块滤波器之后，在图像间预测环路中引入非线性振幅映射。它的目标是通过使用查找表更好地重建原始信号振幅，该查找表由几个附加参数描述，这些参数可以通过编码器端的直方图分析确定。

B. 高级语法体系结构

HEVC 标准新增的许多设计方面，提高了在各种应用程序和网络环境下操作的灵活性，并提高了数据丢失的鲁棒性。然而，H.264/AVC 标准中使用的高级语法体系结构通常被保留，包括以下特征。

1）Parameter set structure

参数集包含可共享的信息，用于解码解码视频的多个区域。参数集结构提供了用于传输解码过程所必需的数据的健壮机制。通过一种新的 VPS 结构，对 H.264/AVC 中的序列和图片参数集的概念进行了扩充。

2）NAL unit syntax structure

每个语法结构都被放入 NAL 单元的逻辑数据包中。使用两个字节 NAL 单元报头的内容，可以容易地识别相关有效负载数据的用途。

3）Slices

slice 是一种数据结构，在熵编码、信号预测和残差信号重建方面，可以独立于同一图片的其他 slice 进行解码。slice 可以是整个图片，也可以是图片中的一个区域。slice 的主要用途之一是在数据丢失时重新同步。在分组传输的情况下， slice 内有效负载比特的最大数量通常受到限制，并且 slice 中 CTU 的数量经常变化以最小化分组开销，同时将每个分组的大小保持在此范围内。

4）SEI 和 VUI

该语法元素支持各种类型元数据，比如 SEI 和 VUI。这些数据提供关于视频图片的定时、视频信号中使用的颜色空间的正确解释、三维立体帧打包信息、其他显示提示信息等的信息。

C. 并行解码语法与改进的 slice 结构

最后，HEVC 标准中引入了四个新的特性，以增强并行处理能力或修改 slice 数据的结构以实现打包。它们中的每一个在特定的应用环境中都可能有好处，并且通常由编码器或解码器的实现者来确定是否以及如何利用这些特性。

1） Tiles

Tiles 作为标准的可选项，它将图片分割为矩形区域。Tiles 的主要目的是增加并行处理能力，而不是提供错误恢复能力。Tiles 是图片的独立可解码区域，它使用一些共享头信息进行编码。Tiles 还可用于视频图片局部区域的空间随机访问。图片的典型 tile 配置将图片分割为矩形区域，每个 tiles 中的 CTU 数量大致相等。Tiles 提供了并行性的更粗粒度级别，并且线程的使用不需要复杂的同步。

2）Wavefront parallel processing(WPP)

当启动波前并行处理(WPP)时，一个 slice 被划分为若干行 CTU。第一行以普通方式处理，第二行可以在第一行仅处理两个 CTU 后开始处理，第三行可以在第二行仅处理两个 CTU 后开始处理，以此类推。每一行中熵编码器的上下文模型是根据前一行中具有两个 CTU 处理延迟的上下文模型推到出来的。WPP 在相当精细的粒度级别上提供了一种处理并行性的形式，即在一个 slice 内。WPP 通常可以提供比 Tiles 更好的压缩性能(并避免使用 Tiles 可能导致的一些视觉瑕疵)。

3）Dependent slice segments

一种称为 Dependent Slice Segment 的结构，允许在单独的 NAL 单元中携带与特定波前入口点或 Tiles 相关的数据，因此，与将数据全部编码在一个 slice 中相比，该结构有可能使该数据以更低的延迟提供给分片打包系统。波前入口点的 Dependent Slice Segments 只能在另一 slice 的解码过程的至少一部分已经执行之后进行解码。相关 slice 主要用于低延迟编码，其他并行工具可能会影响压缩性能。

接下来的两个部分中，将对主要功能进行更详细的描述。

高级语法

HEVC 的高级语法包含许多继承自 H.264/AVC NAL 的元素。NAL 提供将表示图片内容的视频编码层(VCL)数据映射到各种传输层(包括RTP/IP，ISO MP4 和 H.222.0/MPEG-2系统)的能力，并提供分组丢失恢复的框架。有关 NAL 设计的一般概念，如 NAL 单元、参数集、访问单元、字节流格式和分组格式，请参考[9]-[11]。

根据是否包含编码图片或其他相关数据，NAL 单元分为 VCL 和非 VCL NAL 单元。HEVC 标准中，包括几种用于识别用于解码器初始化和随机访问目的的图片类型的 VCL NAL 单元类型。表 I 列出了 HEVC 标准中的 NAL 单元类型及其相关含义和类型类别。

以下小节介绍了高级语法支持的新功能。

A) Random Access and Bitstream Splicing Features

HEVC 新设计支持特殊功能以实现随机访问和比特流拼接。在 H.264/AVC 中，比特流必须始终以 IDR 访问单元开始。IDR 访问单元包含独立编码的图片，即，可以在不解码 NAL 单元流中的任何先前图片的情况下解码的编码图片。IDR 访问单元的存在指示，比特流中的后续图片将不需要参考其包含的图片之前的图片以便被解码。IDR 图片在称为闭合 GOP(其中 GOP 代表图片组)的编码结构内使用。

新的 CRA(Clean Random Access) 图片语法指定在 RAP(Random Access Point)的位置处使用独立编码的图片。即，在比特流中解码器可以开始成功解码图片的位置处，而无需解码比特流中先前出现的任何图片，它支持一种称为开放 GOP 操作的高效时间编码顺序。对 RAP 的良好支持，对于启用通道切换、搜索操作和动态流媒体服务至关重要。按照解码顺序在 CRA 图像之后，按显示顺序在 CRA 图像之前的图片，可能包含对解码器处不可用的图片的帧间预测参考。因此，在 CRA 点开始解码过程的解码器，必须丢弃这些不可解码的图像。为此，此类不可解码图片被标识为 RASL（Random Access Skipped Leading）图片。来自不同编码比特流的拼接点位置可通过 BLA(Broken Link Access)图片指导。比特流拼接操作可以通过简单地将一个比特流中 CRA 图片的 NAL 单元类型更改为指示 BLA 图片的值，并将新比特流连接到另一个比特流中 RAP 图片的位置来执行。RAP 图像可能是 IDR、CRA 或 BLA 图像，并且 CRA 和 BLA 图像之后可以是比特流中的 RASL 图片(取决于用于 BLA 图片的 NAL 单元类型的特定值)。解码器必须始终丢弃与 BLA 图片相关联的任何 RASL 图片，因为它们可能包含对由于拼接操作而实际不存在于比特流中的图片的参考。另一种可以以解码顺序跟随 RAP 图片之后，并在以输出顺序在 RAP 之前的图片类型，是RADL(Random Access Decodable Leading)图片，其不能包含对以解码顺序在 RAP 图片之前的任何图片的参考。RASL 和 RADL 图片统称为 Leading Pictures.以解码顺序和输出顺序跟随在 RAP 图片之后的图像(称为 Trailing Picture)不能包含对用于图片间预测的 Leading Picture 的参考。

B) Temporal Sublayering Support

与 H.264/AVC 可伸缩视频编码(SVC)扩展中的时间可伸缩性特征类似，HEVC 在 NAL 单元报头中指定了时间标识符，其指示分层时间预测结构中的级别。这是为了实现时间可伸缩性，而无需解析除 NAL 单元以外的比特流部分。

在某些情况下，在一个编码视频序列的解码过程中，解码时间子层的数量是可以调整的。比特流中的点(此点位置是发生子层切换，可以开始解码一些更高级时间层的点)可以通过TSA(Temporal Sublayer Access)图片和STSA(StepWise TSA)图片的存在来指示。在 TSA 图像的位置，可以从解码较低的时间子层切换到解码任何较高时间子层；在 STSA 图像位置，可以从解码较低时间子层切换到仅解码一个特定较高时间子层(但不包括上面的其他层，除非它们还包含 STSA 或 TSA 图像)；

C) Additional Parameter Sets

VPS 已添加为元数据，已描述编码视频序列的总体特征，包括时间子层之间的依赖关系。其主要目的是实现标准在系统层的信令方面的兼容扩展性，例如，当未来扩展的可伸缩或多视图比特流的基本层需要由传统解码器解码时。但是，对于这种情况，只与高级解码器相关的关于比特流结构的附加信息将被忽略。

D) Reference Picture Sets and Reference Picture Lists

对于多参考图片管理，解码图片缓冲区(DPB)中需要存在一组特定的先前解码图片，用于解码比特流中的其余图片。为了标识这些图片，在每个片头中传输图片顺序计算(POC)标识符的列表。保留的参考图片集称为 RPS。图2示出了用于示例性时间预测结构的 POC 值、解码顺序和 RPS。

与 H.264/AVC 中一样，有两个列表被构造为 DPB 中的图片列表，它们被称为参考图片列表 0 和列表 1。称为参考图片索引的索引用于识别这些列表之一中的特定图片。对于单预测，可以从这些列表中选择图片。对于双向预测，将从每个列表中选择两张图片。当列表仅包含一个图片时，参考图片索引隐士地具有值 0，并且不需要在比特流中传输。

与先前的 H.264/AVC 设计相比，用于识别 RPS 和建立用于画面间预测的参考图片列表的高级语法对数据丢失更为鲁棒，并且更适于诸如随机访问和技巧模式操作之类的操作(例如，快进、平滑倒带、搜索和自适应比特流切换)。这些改进的一个关键方面是语法更加明确，而不是依赖于解码过程中存储的内部状态的推断，因为它逐帧解码比特流。此外，设计的这些方面的相关语法实际上比 H.264/AVC 更简单。

HEVC 视频编码技术

与 H.261 以来所有先前的 ITU-T 和 ISO/IEC JTC 1 视频编码标准一样，HEVC 设计遵循经典的基于块的混合视频编码方法(如图1所示)。基于信源编码算法是利用时间统计相关性的帧间预测、利用空间统计相关性的帧内预测和利用空间统计相关性的预测残差信号的变换编码的混合。与先前的视频编码标准相比，HEVC 设计中没有一个编码元素能够显著提高压缩效率。更确切地说，是多个较小的改进增加了显著的收益。

A) Sampled Representation of Pictures

为了表示彩色视频信号，HEVC 通常使用具有4:2:0 采样的 YCbCr 颜色空间(尽管扩展到其他采样格式很简单，计划在后续版本中定义)。这将颜色表示为三个组件，分别称为Y、Cb 和 Cr。Y 组件也称为亮度，表示亮度。两个色度分量Cb 和 Cr 分别表示颜色从灰色向蓝色和红色的偏离程度。由于人类视觉系统对亮度比色度更敏感，因此通常使用4：2：0采样结构，其中每个色度分量具有亮度分量样本数的四分之一(水平和垂直维度样本数的一半)。每二个组件的每个样本通常以 8 或 10 bit的精度表示，8 bit的情况更为典型。在本文的其余部分中，我们将重点放在典型用途上:YCbCr 组件具有4：2：0采样和 8bit 每个采样，用于表示编码输入和解码输出视频信号。

视频图像通常以矩形图片大小WxH逐步采样，其中 W 是宽度，H 是 luma 样本中图片的高度。采用4：2：0采样的每个色度分量阵列为W/2xH/2。给定这样的视频信号，HEVC 语法进一步划分图片，如下所述。

B) Division of the Picture into Coding Tree Unit

图片被划分成编码树单元(CTU)，每个单元包含亮度 CTB 和色度 CTB。亮度 CTB 覆盖亮度分量的 LxL 样本的矩形图像区域，相应的色度 CTB 覆盖两个色度分量中每个分量的 L/2xL/2 样本。L 的值可以是 16、32、64，由 SPS 中指定的编码语法元素确定。与传统宏块相比，HEVC 支持根据编码器在内存和计算需求方面的需求，选择可变大小的 CTB。而从 H.261 以来所有先前的 ITU-T 和 ISO/IEC JTC 视频编码标准中，宏块使用固定阵列大小的 16x16 luma 样本。在编码高分辨率视频内容时，支持以前的标准更大的 CTB 尤其有益。luma CTB 和两个色度 CTB 以及相关的语法构成了CTU。CTU 是标准中用于指定解码过程的基本处理单元。

C) Division of the CTB into CBs

指定为 luma 和 chroma CTB 的块可以直接用作 CB，或者可以进一步划分为多个 CB，划分是使用树形结构实现的。HEVC 中的树划分通常同时应用于亮度和色度，但当色度达到某些最小值时例外。

CTU 包含四叉树语法，该语法允许根据 CTB 覆盖区域的信号特征，将 CBs 划分为选定的合适大小。四叉树划分过程可以迭代，直到 luma CB 的大小达到所允许的最小luma CB 大小。该最小 luma CB 大小是编码器使用 SPS 中的语法元素指定选择的，它始终为 8x8 或更大(以 luma 样本为单位)。

图片的边界以允许的最小 luma CB 大小为单位定义。因此，在图片的右边缘和下边缘，一些 CTU 可能会覆盖部分位于图片边界之外的区域。解码器检测到这种情况，并根据需要隐士分割 CTU 四叉树，以将 CB 大小减小到整个 CB 将适合图片的位置。

D) PBs and PUs

根据 CU 使用的是画面内预测还是画面间预测，CU 的预测模式用信号表示为帧内预测或帧间预测。

当预测模式是帧内模式时，PU 大小（即建立图像内预测模式时的块大小）与所有块大小的 CB 大小相同。但比特流中允许的最小 CB 大小除外。对于后一种情况，存在一个标志，指示 CB 是否被分成四个 PB 象限，每个象限都有自己的帧内预测模式。允许这种分割的原因是为大小 4x4 的块启用不同的帧内预测模式选择。当亮度帧内预测使用 4x4 块进行操作时，色度帧内预测也使用 4x4 块(每个块覆盖与四个 4x4 亮度块相同的图片区域)。帧内预测操作时的实际区域大小(与建立帧内预测模式时的 PB 大小不同)取决于如下所述的剩余编码分区。

当预测模式是帧间时，指定亮度和色度 CBs 是否被分割成一个、两个或四个 PBs。仅当 CB 尺寸等于允许的最小 CB 尺寸时，才允许将 CB 分为四个 PBs，使用等效类型的拆分，否则可在设计的 CB 级而不是 PB 级执行拆分。当 CB 被划分为四个 PBs 时，每个 PB 覆盖 CB 的一个角；当 CB 被划分为两个 PBs 时，可能会出现六种不同的划分。图 3 描述了帧间预测的 CBs 的划分可能性。图中的上半部分说明了划分大小为 MxM 的 CB，将 CB 划分为大小为 MxM/2 或 M/2xM 的两个 PBs，将其划分为大小为 M/2xM/2 的四个 PBs 的情况。图 3 中下半部分的四种划分类型被称为非对称运动分区(AMP)，并且仅在 luma 的 M 为 16 或更大时才允许。不对称划分的一个 PB 的高度或宽度分别为 M/4 和 M，另一个 PB 的高度或宽度分别为 3M/4 和 M，填充 CB 的其余部分。每个帧间预测 PB 被分配一个或两个运动矢量和参考图片索引。为了最小化最坏情况下的内存带宽，不允许使用 luma 大小为 4x4 的 PBs 进行帧间预测，并且 luma 大小为 4x8 和 8x4 的 PBs 仅限于单预测编码。下面进一步描述帧间预测处理。

luma 和 chroma PBs，以及相关的预测语法构成 PU。

E) Tree-Structured Partitioning Into Transform Blocks and Units

对于残差编码，CB 可以递归地划分为 TBs(Transform Blocks)。划分由残差四叉树表示。

如图 4 所示，仅指定方形 CB 和 TB 分区，其中块可以递归地分割为四象限。对于给定大小的 MxM 的 luma CB，一个标志表示它是否被划分为大小为 M/2xM/2 的四个块。如果可以更进一步划分(SPS 中指示的残差四叉树的最大深度所示)，则为每个划分分配一个标志，指示是否将其继续拆分为四叉树。由残差四叉树产生的叶子节点，是通过变换编码进一步处理的变换块。编码器指示它将使用的最大和最小 luma TB 大小。当 CB 大小大于最大 TB 大小时，划分是隐士的。当划分会导致 luma TB 大小小于指定的最小值时，不再划分也是隐含的。chroma TB 大小是 luma TB 大小的一半，除非 luma TB 为 4x4，在这种情况下，单个 4x4 chroma TB 用于四个 4x4 luma TB 覆盖的区域。在帧内预测 CUs 情况下，最近相邻 TBs（在CB之内或之外）的解码样本被用作帧内预测的参考数据。

与之前标准不同，HEVC 设计允许一个 TB 跨越多个 PBs 用于帧间预测 CU，以最大限度地发挥四叉树结构 TB 分区的潜在编码效率优势。

F) Slices and Tiles

Slice 是按照光栅扫描顺序处理 CTU 序列的。如图5(a)所示，可以将图片分割成一个或多个 slices，使得图片是一个或多个 slice 集合。在给定SPS 和 PPS 参数集的情况下，slice 是自包含的，可以从比特流中解析它们的语法元素，并且可以正确解码 slice 表示的图片区域中的样本值(除了 slice 边缘附近的循环过程效果)，不使用来自同以图片中其他 slice 的任何数据。这意味着帧内预测(例如，帧内图片空间信号预测或运动向量预测)不会跨 slice 边界执行。然而，可能需要来其他 slice 的一些信息，跨 slice 的应用在 Loop Filter 中。每个 slice 可以使用不同的编码类型进行编码，如下所示。

1) I Slice: Slice 内的所有 CUs 单元只使用帧内预测编码。
2）P Slice: 除了 I Slice 的编码类型外，P Slice 中的一些 CUs 还可以使用每个 PB 最多一个运动补偿预测信号的帧间预测来编码(即，单预测)。P Slice 仅使用 RPS List0。
3）B Slice: 除了 P Slice 中可用的编码类型外，B Slice 中的一些 CUs 还可以使用每个 PB 最多两个运动补偿预测信号的帧间预测编码(即，双预测)。B Slice 可以同时使用 RPS List0 和 List1。

引入 slice 的目的是，在数据丢失后重新同步。此外，Slice 经常被限制使用最大位数，例如，用于分组传输。因此，根据视频场景中的不同，不同的 Slice 可能包含不同数量 CTU。除了 Slice 之外，HEVC 还定义了 Tiles，Tile 是图片中自包含且独立可解码的矩形区域。Tiles 的主要目的是支持使用并行处理架构进行编码和解码。多个 Tiles 可以在同一个 Slice内，共享头信息。对应的，同一个 Tile 也可以包含多个 Slices。如图 5(b) 所示，Tile 由一组矩形排列的 CTU 组成（通常，但不一定，所有 CTU 都包含大约相同数量的 CTU）。

为了辅助数据打包的粒度，还额外定义了相关 Slices。最后，使用 WPP，Slice 被划分为 CTU 行。在一行 CTU 中，只要做出了熵编码器的预测和自适应所需的一些决策，就可以开始同一行的解码。这样就可以在编解码中使用多线程，同时并行处理 CTU 行。图 5(c) 给出了示例。为了简化设计，不允许将 WPP 与 Tiles 结合使用(尽管原则上，这些功能可以在一起正常使用)。

G) Intrapicture Prediction

帧内预测根据 TB 大小进行操作，并且使用来自空间相邻 TB 的先前解码的边界样本来形成预测信号。针对从 4x4 到 32x32 的方形 TB 大小，定义了具有 33 种不同方向的方向预测。可能的预测方向如图 6 所示。除了方向预测外，还可以使用 Planar 预测(假设振幅表面有从边界导出的水平和垂直斜率)和 DC 预测(具有与边界样本的平均值匹配的值的平坦表面)。对于chroma 分量，水平、垂直、planar 和 DC 预测模式可以被显示地传递；或者 chroma 预测模式可以被指示为与 luma 预测模式相同(并且，作为避免冗余发信号的特殊情况，当指示前四个选择之一并且与 luma 预测模式相同时，帧内预测模式可以被指示为与 luma 预测模式相同)。

根据 slice 类型不同，每个 CB 可以由几种编码类型中的一种进行编码。与 H.264/AVC 类似，所有 slice 类型都支持图像内预测编码。HEVC 支持称为帧内预测编码的各种图像内预测编码方法，包括 Intra-Angular，Intra-Planar，和 Intra-DC。以下小节将对这些技术以及将共同应用的几种技术进行简要的进一步解释。

1) PB Partitioning: 尺寸为 MxM 的帧内预测 CB 可能具有两种类型的 PB 分区之一，称为 PART-2Nx2N 和 PART-NxN，第一个表示 CB 未被拆分，第二个表示 CB 拆分为四个大相等的 PBs。从概念上讲，在这个符号中，N=M/2。然而，当前CB的尺寸大小最小CU尺寸时，可以通过使用四个较小的CB来表示由四个PBs指定的相同区域。因此，HEVC 设计只允许分区类型-当前CB尺寸等于最小CU尺寸时，使用 Part-NxN。这意味着，当使用帧内预测模式，对CB进行编码时，PB大小始终等于CB大小，并且CB大小不等于最小CU大小。尽管帧内预测模式是在PB级别建立的，但实际的预测过程对每个TB分别进行操作。

2) Intra_Angular Prediction:空域的帧内预测已经成功应用于 H.264/AVC 中。HEVC 的帧内预测同样在空域中运用，但它在 TB 的大小上有增加，在可选择预测方向的数量上有增加。与 H.264/AVC 的 8 个预测方向相比，HEVC 总共支持 33 个预测方向，使用 intra_angular[k]表示，其中 k 是从 2 到 34 的模式数。这些角度旨在为近水平和近垂直角度提供更密集的覆盖，为近对角线角度提供更粗糙的覆盖，以反映观察到的角度统计普遍性和信号预测处理的有效性。

当使用 Intra-Angular 模式，在使用该预测之前，会从重建(单尚未通过环路滤波器滤波)的空间相邻样本定向预测每个 TB。对于大小为 NxN 的 TB，总共 4N + 1 个空间上相邻的样本可用于预测，如图 6 所示。当从前面的间操作可用时，除了来自当前 TB 的左侧、上方和右侧上方 TB 的样本之外，来自左下 TB 的样本还可用于 HEVC 中的预测。Intra-Angular 模式的预测过程可涉及根据给定方向性从投影参考样本位置外推样本。为了消除在参考行和列缓冲区之间逐个采样切换(例如intra_angular[k] 其中 k 从2-17范围)，位于上列的样本作为位于左列的附加样本进行投影；当 k 从 18-34 范围内时，位于左列的样本被投影为位于上列的样本。

为了提高帧内预测的精度，以 1/32 的样本精度计算投影参考样本位置。双线性插值用于使用位于整数位置的两个最近参考样本获得投影参考样本的值。

Intra-Angular 模式的预测过程在所有块大小和预测方向上都是一致的，而 H.264/AVC 对其支持的 4x4、8x8 和 16x16 的块大小使用不同的方法。由于与 H.264/AVC 相比，HEVC 支持更多种类的 TB 大小和更多的预测方向数，因此这种设计一致性尤其令人满意。

3）Intra_Planar 和 Intra_DC Prediction: 除了 Intra_Angular Prediction 针对具有强方向性边缘的区域的角度预测，HEVC 支持两种可选的预测方法，即 Intra_Planar 和 Intra_DC 模式，H.264/AVC 中为其指定了类似模式。Intra_DC 预测使用参考像素的平均值进行预测；Intra_Planar 预测使用四个角度参考样本的两个线性预测的平均值以防止块边界出现不连续。HEVC 中的所有块尺寸都支持 Intra_Plannar 预测模式，而 H.264/AVC 仅在 luma PB 尺寸为 16x16 时才支持 plane 预测，其plane 预测的操作与 HEVC 中的 planar 预测有所不同。

4) Reference Sample Smoothing: 在 HEVC 中，用于帧内预测的参考样本有时由三抽头[1 2 1]/4 平滑滤波器，以类似于 H.264/AVC 中用于 8x8 帧内预测的方式进行滤波。HEVC 根据方向性、检测到的不连续量和块大小更自适应地应用平滑操作。与 H.264/AVC 中一样，平滑滤波器不适用于 4x4 块。对于 8x8 块，只有对角线方向，intra-angular[k] (k=2、18或34时的角度)使用参考样本平滑。对于 16x16 块，除了近水平和近垂直方向外，参考样品的大多数方向上进行过滤，k 在9-11和22-27范围内。对于 32x32 块，除完全水平(k=10)和完全垂直(k=26)方向外的所有方向，都是用平滑滤波器，并且当检测到的不连续量超过阈值时，应用来自三个相邻区域样本的双线性插值来形成平滑预测。

当块只存大于或等于 8x8 时，Intra-planar模式同样使用平滑滤波，但平滑并不用于 Intra-DC 模式。

H) Interpicture Prediction

I) Transform, Scaling, and Quantization

与先前标准的方式类似，HEVC 使用预测误差残差的变换编码。如 IV-E 节所述，残差块被分割为多个方形 TBs。支持的变换块大小为 4x4、8x8、16x16 和 32x32。

1) Core Transform: 二维变换通过在水平和垂直方向上应用一维变换来计算。核心变换矩阵的元素是通过近似于缩放的DCT基函数来推导的，其考虑因素包括限制变换计算所需的动态范围，以及当矩阵项被指定为整数值时最大化精度和接近正交性。

为简单起见，仅为 32 个点的长度指定了一个整数矩阵，并且对其他大小使用了二次抽样版本。例如，length-16 变换的矩阵如 H 的等式所示。

长度-8 和长度-4 的变换的矩阵可通过使用第0、2、4…、行的前八个条目导出。并使用第0、4、8…行的前四个条目。尽管该标准仅根据矩阵的值来指定变换，单选择矩阵中条目的值时，其关键对称特性使快速部分分解实现比普通矩阵乘法运算少得多，较大的变换可以通过使用较小的变换作为构建块来构建。

由于支持转换的大小的增加，限制转换第一阶段中间结果的动态范围非常重要。HEVC 在变换的第一个1-D 逆变换阶段(垂直逆变换阶段)后显式插入7-b右移和16-b裁剪操作，以确保所有中间值都可以存储在16-b内存中(用于8-b视频解码)。

2) Alternative 4x4 Transform: 对于 4x4 的变换块大小，使用变换矩阵，将从 DST 导出的替代整数变换应用于图像内预测模式的 luma 残差块。

DST 的基函数更好地拟合统计特性，即剩余振幅随着与用于预测的边界样本的距离变大而增加。就复杂度而言，4x4 DST 类型的变换在计算上的要求并不比 4x4 DCT 类型的变换高多少，并且它在图像内预测编码中提供大约 1% 的比特率降低。

DST 类型变换的使用仅限于 4x4 luma 变换块，因为对于其他情况，包括额外变换类型的额外编码效率改进被发现是微不足道的。

3) Scaling and Quantization: 由于变换矩阵的行是正交 DCT 的均匀缩放基函数的值的近似值，因此在 HEVC 中不需要合并在 H.264/AVC 的去量化中的与缩放操作。这种避免频率特定基函数缩放的方法有助于减少中间存储器的大小，特别是当考虑到变换的大小可以高达 32x32 时。

对于量化，HEVC 使用与 H.264/AVC 中基本相同的由量化参数 QP 控制的 URQ 方案。QP 值的范围被定义为从0 到 51，并且将量化步长增加 6 倍，使得 QP 值到步长的映射近似为对数。同时，还支持量化缩放矩阵。

为了减少存储频率特定缩放值所需的内存，仅使用大小为 4x4 和 8x8 的量化矩阵。对于16x16 和 32x32 大小的较大变换，发送 8x8 缩放矩阵，并通过共享频率子空间中 2x2 和 4x4 系数组内的值来应用，但DC(零频率)位置的值除外，其发送和应用不同的值。

J) Entropy Coding

HEVC 只指定了一种熵编码方法，CABAC；而不是 H.264/AVC 中的两种。CABAC 算法的核心并没有改变，以下小节介绍了如何在 HEVC 设计中使用 CABAC 的几个方面。

1）Context Modeling

(上下文建模)context modeling的适当选择是提高 CABAC 编码效率的关键因素。在 HEVC 中，除了H.264/AVC 中使用的空间相邻语法元素外，还利用编码树或变换树的拆分深度来推导各种语法元素的上下文模型索引。

K) In-Loop Filters

在 HEVC 中，在将重建帧写入解码器的 DPB Buffer 之前，会对重建帧应用两个处理步骤，即 DBF(Deblocking Filter)和SAO Filter。DBF 旨在减少由于基于块的编码而产生的块效应。DBF 与 H.264/AVC 标准中的 DBF 类似，而 SAO 是 HEVC 中新引入的。DBF 仅应用于位于块边界处的样本，SAO 滤波器自适应地应用于满足特定条件(例如基于梯度)的所有样本。在 HEVC 的开发过程中，还考虑在 SAO 滤波器之后运行第三个处理步骤，称为自适应环路滤波器(ALF,adaptive loop filter)；但最终设计中未包含 ALF 功能。

1) Deblocking Filter:DBF 应用于与 PU 或 TU 边界相邻的所有样本，但如果PU 或 TU 边界也是图片边界除外，或者当 Deblocking 被 slice 或 tile 边界禁用时除外(这是可以由编码器发出的信号的选项)。值得注意的是，需要同时考虑 PU 和 TU 边界，因为在某些帧间预测的 CBs 情况下，PU 边界并不总是与 TU 边界对齐。SPS 和 slice header 中的语法元素控制着 DBF 是否跨过 slice 和 tile 边界。

与 H.264/AVC 中的 DBF 应用在 4x4 采样网格基础上不同，HEVC 仅将 DBF 应用在 8x8 采样网格上对齐的边缘，用于亮度和色度采样。这种限制降低了最坏情况下的计算复杂度，而不会显著降低视觉质量。它还通过阻止相邻过滤操作之间的级联交互来改进并行处理操作。

DBF 的强度由几个语法元素的值共同控制，类似于 H.264/AVC 中的方案，但仅使用三个强度，而不是五个强度。假设 P 和 Q 是两个相邻的块，具有共同的 8x8 网格边界，则当其中一个块在图像内被预测时，滤波器强度为 2。否则，如果满足以下任一条件，则指定滤波强度为 1。1）P 或 Q 有至少一个非零转换系数。2）P 和 Q 的参考指数不相等。3）P 和 Q 的运动矢量不相等。4）P 和 Q 的运动矢量分量之间的差值大于或等于一个整数样本。如果以上条件都不满足，则将滤波器强度指定为 0，折意味着不应用 Deblocking 过程。

根据 Filter 强度和 P与Q的平均量化参数，从预定义的表中确定两个阈值tc和β。对于 luma 样本，根据β从三种情况中选择一种，即无滤波、强滤波和弱滤波。请注意，为降低计算复杂性，使用第一行(列)和最后一行(列)所做的决策，在四个luma行或列中共享。

对于 chroma 分量，只有无滤波和正常滤波两种情况。仅当滤波器强度大于 1 时，才会应用正常滤波。然后使用控制变量tc和β执行滤波过程。

HEVC 中，DBF 的处理顺序被定义为首先对整个图像的垂直边缘进行水平滤波，然后对水平边缘进行垂直滤波。此特定顺序允许在并行线程中应用多个水平或垂直进行，或者仍然可以在一个 CTB 接一个 CTB 的基础上以较小的处理延迟来实现。

2) SAO Filter: SAO 过程发生在 DBF 之后，它基于编码器发送的查找表中的值，通过在每个采样点添加偏移值来修改解码样本。SAO 滤波基于每个 CTB 选择的滤波类型(sao-type-idx)，在区域基础上执行。sao-type-idx 的值为0，表示不会对CTB应用 SAO 滤波，值1和值2分别表示频带偏移和边缘偏移滤波类型的使用。

频带偏移模式(sao-type-idx 等于 1)时，所选偏移值直接取决于采样振幅。该模式下，将整个采样幅度范围均匀分割为 32 个称为频带的段，并且动过添加表示为频带偏移(可以是正的或负的)的传输值来修改属于其中四个频带(在 32 个频带内连续)的采样值。使用四个连续频带的主要原因是，在可能出现带状伪影的平滑区域，CTB 中的样本振幅往往集中在少数频带中。此外，使用四个偏移的设计选择与使用四个偏移值的边缘偏移操作模式相统一。

边缘偏移模式下(sao-type-idx 等于 2),语法元素 sao-eo-class 使用 0 到 3 个信号的值指示水平、垂直还是对角渐变方向之一用于 CTB 中的边缘偏移分类。图 10 描绘了这种模式下，用于sao-eo-class的四个梯度图案。通过比较位于某个位置的样本值 p 与位于相邻位置的两个样本值 n0 和 n1，将 CTB 中的每个样本分为五个 EdgeIdx 类型之一，如表 IV所示。每个样本的分类是基于解码的样本值，因此 EdgeIdx 分类并不需要额外的信息。根据采样位置的 EdgeIdx 类别，对于从 1 到 4 的 EdgeIdx 类别，传输的查找表中的偏移值将添加到采样值。对于类别 1 和类别 2，偏移值始终为正值；对于类别 3 和类别 4，偏移值始终为负值。因此，滤波通常在边缘偏移模式下具有平滑效果。

因此，对于 SAO 类型是 1 和 2，针对每个 CTB，会向解码器发送总共四个振幅偏移值。对于类型 1，符号也被编码。偏移值和相关的语法元素(sao_type_idx 和 sao_eo_class)由编码器确定，通常使用优化率失真性能的标准。可以使用合并标志指示 SAO 参数从左侧到上方的 CTB 继承，以使信号有效。总之，SAO 是一种非线性滤波操作，允许对重构信号进行额外的细化，并且它可以增强平滑区域和边缘周围的信号表示。

L) Special Coding Modes

HEVC 定义了三种特殊的编码模式，可在 CU 级或 TU 级调用。

1）在 I-PCM 模式下，预测、变换、量化和熵编码都被跳过，samples 之间由预定义的 bits 数表示。它的主要目的是避免在信号特性异常且无法通过混合编码正确处理时过度消耗比特。(类噪声信号)。

2）在无损模式下，影响解码图片的变换、量化和其他处理(SAO 和 Deblock 滤波)被跳过。来自帧内或帧间预测的残差信号被直接送入熵编码器(使用通常应用于量化变换系数的相同领域上下文)。这使得无需定义任何额外的编码工具即可实现数学上的无损重建。

3）在变换 skip 模式下，只有变换才会被跳过。这主要提升了某些类型视频内容的压缩，例如计算机生成的图像或相机视图内容混合的图形。此模式仅适用于 4x4 大小的 TBs。

SAO 和 Deblock 滤波不应用于无损模式区域，并且标志控制它们是否应用于 I-PCM 区域。

Profiles, Tiers And Levels

A) Profile, Level, and Tier Concepts

Profiles，Tiers 和 Levels 指定了一致性点，使得具有类似功能需求的各种应用程序以可互操作的方式实施标准。Profile 定义了一组可用于生成一致性比特流的编码工具或算法；Level 对比特流的某些关键参数施加约束，它对应于解码器处理负载和内存的能力。根据 DPB 的最大采样率、最大图片大小、最大比特率、最小压缩比和容量以及在解码之前保存压缩数据以用于数据流管理的编码图片缓冲器(CPB)来建立 Level 限制。在 HEVC 的设计中，一些应用程序，其要求仅在最大比特率和 CPB 容量方面存在差异。为了解决此问题，为某些 Level 指定了两个 Tiers—Main Tier 用于大多数应用程序，High Tier 用于要求更苛刻的应用程序。

符合特定 Tier 和 Level 的解码器需要能够符合解码所有符合同一 Level 或 Tier 或其下任何级别的比特流。符合特定 Profile 文件的解码器必须支持该 Profile 文件中的所有功能。与解码器不同，编码器并不需要使用 Profile 中支持的任何特定特征集，单需要生成一致性比特流，即符合规定约束的比特流，这些约束使一致性解码器能够对其进行解码。

B) The HEVC Profile and Level Definitions

预计到 2013 年 1 月，有三个针对不同应用要求的 Profiles(Main, Main10, Main Still Picture)将最终确定。最小化 Profile 文件的数量提供了设备之间最大程度的互操作性，并通过以下应用进一步证明了这一点：传统上独立的服务(如广播、移动、流媒体)正在汇聚到一个点，即大多数设备应可用于支持所有这些服务。这三个profile包括本文前面几节中描述的编码工具和高层语法，同时施加以下限制。

1) 只支持 4:2:0 chroma 采样格式。
2）当编码器使用多 Tiles 编码时，它不能使用 WPP，并且每个 Tile 必须至少 256 luma 采样宽度和 64 luma 采样高。
3）Main 和 Main Still Picture Profile，只支持 8 bit 采样精度的视频，Main10 Profile 支持 10 bps。
4) Main Still Picture Profile 中，整个视频只能包含一个编码图片(因此只支持帧内预测)。

如表 V 所示，13个级别的定义计划包含在第一版的 SPEC 中，范围从仅支持相对较小图片(如176x144的 luma 图片大小)的 Level 到 7680x4320 (通常称为8kx4k)的图片大小。图片的宽高均要求小于或等于 8xMaxLumaPs，其中 MaxLumaPs 是表 V 中展示的最大 luma 大小。

其中 8 个Levels(Level 4 以及更高)支持 2 个 Tiers。CPB 容量等于所有级别的最大比特率乘以 1s，但 level 1 除外，其(更高) CPB 容量为 350000B。对于每个 Level，当以该 Level 支持的最大图片大小操作时，每个 Level 中指定的最大 DPB 容量为 6 张图片(包括当前图片和解码器在任何时间点保留的用于参考或输出目的的所有其他图片)。当以小于该 Level 支持的最大图片大小的图片操作时，DPB 图片存储容量可以增加到多达 16 张图片(取决于特定的图片大小)。每张图片中水平和垂直使用的最大平铺数量，以及每秒使用的最大平铺数量指定了特定于 level 的约束。

历史与标准化进程

在 H.264/AVC High Profile 于 2004 年年中最终确认之后，ITU-T VCEG 和 ISO/IEC MPEG 一致在努力确定编码效率的下一个重大进步何时可以实现标准化。VCEG 于 2004 年开始研究潜在的进展，于 2005 年初开始确定某些关键技术领域进行研究，并为本文开发了一个通用的 KTA 软件代码库。使用 KTA 软件代码库提出并验证了各种技术，该代码是从 H.264/AVC 参考软件 JM 开发的。

结论

新兴的 HEVC标准由ITU-T VCEG 和 ISO/IEC MPEG 组织共同开发和标准化。HEVC 代表了视频编码技术的一系列进步。其视频编码层设计基于传统的基于块的运动补偿混合视频编码概念，但与先前的标准有一些重要区别。

如果能将各种特性很好的结合使用，新设计的功能将节省大约 50% 的码率，同时获得先前标准(尤其是高分辨率视频)相比的同等视觉质量。有关压缩性能的更多详细信息，请参阅[Comparison of the coding efficiency of video coding standards–Including High Efficiency Video Coding]。实现的复杂性分析超出了本文的范围，然而，使用现代处理技术，HEVC 整体的编码器实现复杂度不是主要负担(例如，相对于H.264/AVC)，并且编码器复杂度也是可管理的。有关实现复杂性的更多详细信息，请参阅[HEVC Complexity and implementation analysis]。

JCT-VC 文件管理系统中提供了有关该项目的更多信息和文件JCT-VC Document Management System。