【视频编码学习】H.266/VVC参考软件VTM配置运行(VTM-6.0版本)

运行环境、软件版本等说明：

VTM：6.0版本

操作系统：Win10 64位操作系统

IDE：Visual Studio 2017

编译器：Cmake

1、VTM下载地址

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

左侧点击Files，然后中间下拉列表可以选择VTM的不同历史版本进行下载，这里我选择的是6.0版本，然后点击右侧的下载按钮即可根据自己的要求下载不同压缩格式的代码。

 

2、解压缩后首先打开文件夹内readme.md文件查看编译方法

win系统下给了一个VS2015的编译运行方法，需要使用cmake在build文件夹的目录下通过控制台输入指令编译，如下图：

3、根目录下没有build文件夹，新建一个新的，存放编译好的程序：

4、系统中缺少cmake，安装过程如下图，下载一个win64可运行的msi文件自动安装即可：

安装过程中需要勾选一下把cmake加入系统Path中，这样在安装结束后，可以打开cmd输入cmake查看一下是否安装成功：

 

5、cmake成功安装后，有以下两种方法进行编译：

①在cmd中进入之前建立好的build文件夹下输入相关语句进行编译：

此时根据readme中的编译提示，经过上网查询后，发现6.0版本可以输入如下cmake指令进行编译（官方git上只提供了15VS版本的编译方式，15是该代码支持的最低VS版本，再低会出问题，但是用17的也没问题，17应输入下方第二句指令）：

cmake .. -G "Visual Studio 14 2015 Win64"

或

cmake .. -G "Visual Studio 15 2017 Win64"

 

补充：最新的VTM6.2及之后的版本已经支持19的VS，编译命令如官方Git上所示：

提示Generating done之后即编译成功，编译成功后的代码在build文件夹下可以找到，如下图所示：

 

②打开cmake-gui进行编译

第一步，其中source code处选择VTM整体项目的根目录即可，build后生成文件的地方选择之前建立的build文件夹即可。如下图：

补充坑点1：路径中一定不要带有中文，一定要保证全英文路径，养成好习惯，不论会不会出问题，以后都最好要全英文路径，确实是后面在运行的过程中发现BUG提示中的中文路径乱码，可能是导致运行失败的原因。

第二步点击左下角的configure按钮，首先选择对应的VS版本。

第三步选择生成的目标平台，如下图：

坑点2：之后第二个选项中选择x64，否则默认的是win32，特别坑这里，尝试的过程中最后运行莫名其妙报错尝试了很多地方，最后突然想起来是不是最初编译版本有问题。

 

点击finish即可，然后会产生如下图的情况，再点击generate就大功告成了：

 

6、编译成功后在build文件夹下可以看到如下文件，打开其中的sln解决方案即可：

在VS中可以看到该软件的项目结构：

 

7、下面测试encoder不加任何参数的情况下的默认启动运行情况，先修改默认启动项目：

 

8、重新生成一下encoder项目：

 

9、Ctrl+F5试运行，运行结果如下图所示，运行成功：

11、接下来再在本地进行一个较少帧数的测试，尝试将一个视频序列其中较少的一些帧数编码再解码并且比对编解码前后的视频序列是否一致，该如何进行操作：

在VTM根目录下有一个cfg配置文件夹，如下图：

 

 

打开后可以发现，cfg内的结果如下图所示：

最下面有四个cfg文件，分别为AI、RA、LDP、LDB，即全帧内(AI)、随机接入(RA)、低延时P和B帧(LDP和LDB)，根据自己视频编码的需要去选择并修改对应的cfg，以下的例子均使用AI（All Intra）模式。

上面的几个文件夹都是一些示例视频序列的配置例子，比如这个文件，是一个示例视频在cfg中的File I/O处的配置示例。

 

也是搜了好久找到了这个原视频，在网上一个HEVC的视频测试序列里找到了这个视频，存到了百度网盘里。

百度云链接：https://pan.baidu.com/s/1V2C35ieD9QNigI6LRC9T_Q

提取码：ocib

       下载下来之后，准备开始编解码测试，在此之前先在项目里建一个自己的测试文件夹，并用日期标注一下自己的测试时间，测试目的：

具体的相关路径见下图，然后把测试用的视频，还有AI模式的cfg配置文件全复制进去。然后通过notepad++等类似的软件打开cfg文件进行编辑：

 

如上图所示，在该文件IO和BitstreamFile之间，把之前那个文件夹里示例视频cfg的内容全部插入进去，插入结果如下图：

这里修改后的AI模式的cfg文件和它的源文件的区别就是：

1、把InputFile处，即视频的所在位置改成了实际存放的位置。

2、把FramesToBeEncoded（将要编码的帧数）进行了控制，原本是500，我改了一个较小的数字，只编码40帧，方便测试。

3、把下面的Quantization处的QP改成了37，查了下网上其他大佬的博客，有一位大佬说是改成37更快一些，原理还没弄懂，先这么改着，（0-51的区间范围均可），并在码流文件和重编码的文件的名称上标注不是默认的改成了37QP的。

 

 

 

准备工作基本就绪，接下来打开build文件夹下我们早编译生成好的sln文件：

1、首先生成编解码的exe文件。

       在调整成为release和x64这两个地方的情况下，点开生成-清理解决方案。然后再点击重新生成解决方案，等待完成。

完成后即可在下图对应的目录下找到Decoder和Encoder的exe文件。

将所用到的这两个文件复制到刚刚自己的测试文件夹中：

最后新建一个批处理文件，输入以下编解码指令：

EncoderApp.exe   -c D:\pku\VVCSoftware_VTM-VTM-6.0\1023FirstTest\encoder_intra_vtm.cfg   > Enc_Out.txt

DecoderApp.exe   -b str37.bin -o dec.yuv

pause

 

其中 -c 表示编码指令，-b表示解码指令，-o表示输出指令：

解释一下：第一行首先执行编码.exe文件，然后读取对应VTM文件目录下的cfg文件，按其中的配置进行编码，并输出编码结果的相关数据到Enc_Out.txt文件中。

第二行首先执行解码的.exe文件，然后把编码后得到的二进制码流（bin文件）进行解码。最后输出解码后的重建YUV文件。

最后一行的pause是为了不让cmd在执行完后自动退出，便于及时发现bug。

 

双击执行该批处理文件。执行过程如下图所示：

这里根据电脑实际环境和硬件配置的不同，可能编解码的时长会有所不同，如果cmd一直持续这个状态不退出，就证明正在运行，耐心等待即可。

 

成功执行完后，Enc_Out.txt文件和最终的cmd处打印出来的语句如下图所示：

（其中有个文件名当时测试的时候打错了是dec.yuv不是dev.yuv，无关紧要，就是dec是decode的缩写而已）

 

补充：Enc_Out.txt可以显示编码性能，里面记录了其中5帧码率、以及各YUV三个分量的PSNR（图像峰值信噪比）测试结果，最后一行还有5帧的平均性能指标。后面可以自己改写一些代码，然后通过这个输出文件可以将自己测试方案的性能和该软件原本的性能相比较，如果码率上升且PSRN降低，大致说明测试方案性能是降低的。反之，说明性能良好。但是如果同升同降则不好判断。

 

最终该测试文件夹下所有涉及到的、生成的文件，如下图所示：

12、最终为了证明编解码过程后，编码前和解码后的yuv视频一致，没有发生任何改变，可以通过Beyond Compare这个程序进行比较，二进制相同，没有任何差别之处，证明测试成功。