如何从H.265视频编码器升级到H.266？

现在H.265软件编码器的压缩性能已经基本卷不动了吧，是否也该考虑考虑从下一代的H.266编码上来拿到更高的压缩收益了呢？

那从已有的H.265视频编码器升级到H.266视频编码器，能不能做到丝滑过渡呢？

除了直接花钱买别人的编码器以外，如果想搞自研编码器，无非有以下3条路：从头重写一个H.266编码器；优化开源VTM或者VVenc编码器；在已有的H.265编码器基础上保持框架基本不变，尽可能复用H.265的代码，实现H.266算法和工具。

第一种方式是属于真正的“从0到1”实现软件编码器，需要把数据流和结构以及绝大多数代码重新设计并且从头开始写。即需要重头打地基盖房子，比如开源编码器vvenc等。

第二种方式是大多数公司会采用的方式，直接在已有的开源编码器基础上进行魔改和优化，相当于在拿到毛坯房以后自己搞装修，最后在宣传时也可以说成是自己平地起高楼。

第三种方式可能不多见，但H.266的参考软件VTM，其实就是走的这个路子。也有一些公司在抢先布局新标准且官方标准文本还没发布这段时间内，捣鼓出的软件编码器，实际也算是这种方式。

下面就简单来回顾一下H.266/VVC的参考软件VTM发展历程。大概是从2014年的HM14.0版本开始的，这时用的就是H.265标准的参考软件HM。

起初的软件代码名叫HM-KTA，这里KTA是Key Technology Areas的缩写。

在2.0版本以后又在HM16.6的基础上，软件名改成了JEM，如下图所示：

https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/branches/

而这个JEM就是Beyond HEVC的临时版本软件编码器。它在HEVC视频编码器的基础上来研究和实现H.266视频编码标准的工具和算法。

如上图所示，JEM一共发布了7个版本。

然后在2018年4月JVET第10次会议上，新一代视频编码标准定名为VVC，并发布了第一个参考软件VTM-1.0，代码见：

https://jvet.hhi.fraunhofer.de/svn/svn_VVCSoftware_VTM/tags/

VTM1.0的代码下载方式和HM以及之前的JEM相同，都是用SVN进行版本管理的。

从VTM-2.0开始，官方参考软件从SVN迁移到了GitLab上面，地址见：

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM.git

所以，H.266的参考软件VTM的历程是，从H.265的参考软件HM14.0到HM-KTA，再从HM-KTA到JEM7.1，最后从JEM到今天的VTM。

当然，除了H.266参考软件VTM是从H.265的代码上发展而来外，还有一个H.266编码器的开源软件也是走的这个路子，那就是uvg266，这个是从他们自己的H.265软件编码器Kvazaar发展而来的。

本号也曾介绍过一些有关Kvazaar编码器的内容，有感兴趣的可以搜搜。今天本文主要是学习他们从Kvazaar这个H.265软件编码器升级到uvg266这个H.266软件编码器的思路和方法。

首先从宏观来看，H.265和H.266视频编码标准之间存在内容上的继承关系，H.265可以看成是H.266的一个子集，如此一来，在H.265软件编码器里已经实现的编码数据流，编码工具和算法等，可以考虑最大程度的重复利用。

其次，H.266和H.265都是使用基于分块的混合编码框架，如下图所示：

在编码框架一致的前提下，子模块的划分也将存在相似性。为了将H.265编码器升级为H.266编码器，首要的事，就是对比和评估两个视频编码标准里各自工具的性能和算法异同！其实每个新标准编码器的开发和优化都要先做这件事。

本号在去年曾以万帅老师的H.266新书为参考，通过数篇文章介绍过H.266视频编码标准里面的工具和算法。从H.265标准出发来学习新的H.266标准，难度还算可以。

比如块划分，H.266里保留了H.265的四叉树结构，但同时又增加了二叉树和三叉树等新的划分方式。再比如帧内预测IP模块，DC和Planar预测和H.265基本相同，同时把角度预测从33增加到了65个。变换模块H.265和H.266的处理很像，但H.266新增了DCT8和DST7等变换，最大变换块也从32×32增大到64×64，等等。

对H.265和H.266所共有的模块和工具，在H.265基础上以H.266标准来做扩展和升级即可。而那些在H.265里没有，但在H.266有的，则需要新增，比如像ALF(虽然代码量不少，但它独立于编码环路，可以直接实现)，LMCS等。

H.265和H.266这两个标准里各个编码模块的差异具体看下图吧。

想要快速开发一个最简单且能编码H.266标准码流的H.266软件编码器，可以考虑选择H.266的一部分工具来实现即可。

通常是先从帧内编码功能开始实现。毕竟从软件实现复杂度上来看，帧内预测比帧间预测要简单容易实现。此外，再简单的H.266编码器，像参数集SPS/PPS这些高层语法要有，其次H.266的CABAC熵编码器也必须得有，这样才能产生符合标准的比特码流。

同时，在H.265的变换基础上去实现H.266变换难度也算可以，而量化模块它的实现也较简单。至于SAO滤波，H.265和H.266是一样的，直接复用就行了。还有就是大部分的指令集优化(如计算SAD，SSE)和多线程模块，也是可以拿来复用。

在H.266编码器所需要的编码模块确定了以后，每个模块里面的那些工具该如何选择呢？

根据Rate Distortion Complexity (RDC)的性能测试结果来确定就好。像那些性能好复杂度不高的工具肯定是优先选择，而那些性能好复杂度较高次优选择。那些压缩性能增益少复杂度又高的工具，就可以考虑先不支持了。而这里所说的这些工具的性能数据，都可以通过对VTM参考软件进行tool on/off测试来拿到。至于如何判定一个工具的压缩性能是高还是低，就看你们老板怎么定了。

在编码器需要的模块和工具确定了以后，剩下就是代码开发和软件实现工作。从软件开发角度，也需要进行子模块的划分，以及模块间交互接口的总体设计，而这个工作可能需要有较多经验的编解码算法工程师来统筹把控。然后就是安排每个人来负责一些不同子模块进行代码的实现，大家一起进行团队协作开发了。

下图是kvazaar编码器和uvg266编码器代码目录结构对比，模块名基本一致。

​