第一次接触VTM6.0的人多半是冲着“H.266/VVC”这个名字来的。VTM是VVC Test Model的缩写也就是H.266/VVC视频编码标准的官方参考软件而VTM6.0是JVET在2019年7月发布的一个里程碑版本。如果你之前折腾过HEVC的HM或者对AV1、AVS3这类新一代编解码器有兴趣那VTM6.0是一个绕不开的学习样本。这篇博文就围绕VTM6.0从安装到实际编码测试全部走一遍顺便把我踩过的坑都摊开来讲。这个内容是什么简单说VTM6.0就是一套完整可编译的C工程编译后得到编码器EncoderApp和解码器DecoderApp可以用来把YUV原始视频编码成符合VVC草案标准的码流也可以把码流解码回YUV。它能做什么一是做学术研究和标准对比二是作为开发VVC编码器的起点代码三是用来验证各种新算法在实际编码中的效果。适合谁看适合刚接触VVC、想用参考软件跑通全流程的初学者也适合做编解码开发、想快速搭建测试环境的技术人员。写这篇文章的时候我特意按“概念—环境—编译—使用—排错”的顺序整理了一遍。你可以直接跳到自己需要的部分但如果你是想完整跑通VTM6.0我还是建议从头到尾过一遍因为很多问题会串在一起。1. 关于VVC和VTM6.0先搞明白它是什么1.1 VVC到底是什么和HEVC、AV1比强在哪VVC全称Versatile Video Coding也就是多功能视频编码也就是H.266。这个“Versatile”是有讲究的它不光面向传统的视频传输和存储还试图覆盖屏幕内容、HDR、360度视频、自适应分辨率这些更复杂的场景。VVC的目标很直接在同等主观质量下比HEVC/H.265再节省大约30%到50%的码率。这个目标在VTM6.0的官方测试结果里已经基本兑现了随机访问配置下相比HM16.20的BD-rate降低约37%左右主观质量也有明显改善。那VVC是怎么做到这一点的核心还是那些传统混合编码框架的改动但每一步都抠得很细。比如它的块划分引入了更灵活的QTMT四叉树加多类型树结构编码单元可以不是正方形帧内预测把角度预测模式从HEVC的33种扩到65种还加了Planar和DC的细化和位置相关帧内预测组合帧间预测引入了仿射运动模型、基于历史的运动向量预测、光流修正这些工具变换部分除了DCT-II还加入了DST-VII和DCT-VIII多种变换核以及低频不可分离变换。这些改动堆在一起复杂度也肉眼可见地翻了好几倍。AV1那边也做了类似的事像楔形分区、角帧内预测、全局运动补偿这些工具但VVC在标准化组织、专利池和产业链成熟度上更有优势。学习型编码器这几年也火但离落地还有距离。所以如果你想在传统编码方向上深耕VVC这块内容还是必修课而VTM就是理解VVC最直接的材料。1.2 VTM6.0在版本演进里处于什么位置为什么值得用它VTM是JVET联合视频专家组维护的参考软件名字变过好几次最开始叫BMSBenchMark Software后来才改为VTM。版本迭代非常频繁每年至少一两个大版本发布。VTM6.0是相对稳定的一个时间节点它对应的标准草案是VVC的第16次会议上冻结的很多核心工具在6.0版本已经定型。如果你去看VTM的提交记录会发现在VTM6.0之前很多工具还在频繁调整参数有的甚至会被删除或完全替换。而VTM6.0之后虽然也有新工具加入但整体框架已经基本稳定。对于刚接触VVC的初学者来说VTM6.0的代码量比后来的VTM12、VTM13少不少核心逻辑却已经很完整阅读起来维度没那么恐怖是个绝佳的切入点。后来的版本虽然性能持续提升但复杂度也水涨船高在普通机器上编译和运行要花更多时间调试也更费劲。加上大量早中期论文、毕业设计和开源项目都是基于VTM6.0做的网上能搜到的资料也最多。我做过一个简单的对比版本发布时间核心状态代码规模学习友好度推荐指数VTM 3.02020年早期探索工具初期图数量大而杂较小中一般VTM 6.02019年7月核心工具基本稳定中等偏大高强烈推荐VTM 9.02020年7月新增了部分工具和细化较大中可以VTM 12.02021年下半年几乎是标准成熟版更大低不推荐入门用1.3 VTM6.0解决的实际问题和它背后整套工具链VTM6.0本身只是一个参考实现但它解决的问题很务实。第一它是标准制定过程中的锚点任何提案都要在这上面跑实验用BD-rate数据说话。第二它为工业界提供了算法原型开源社区里很多VVC硬件编码器、软件优化实现都参考了VTM的代码结构。第三它是学术研究的基线你写论文说“相比VTM6.0我的方法省了5%码率”审稿人一看就懂。但要真正把VTM6.0用起来你还需要一套工具链配合。最基本的几样编译器Windows下Visual StudioLinux下GCC或Clang、CMake构建工具、Git版本管理工具以及一个能处理YUV视频的播放器或转码工具。另外我强烈建议安装FFmpeg因为从网上找的视频素材通常都是MP4之类封装格式需要先转成VTM能读的YUV裸流这一步用FFmpeg最方便。还有一点要提前说VTM6.0的编码速度非常慢慢到什么程度呢在主流桌面CPU上编码一个1080p序列随机访问配置下通常只能跑到每秒0.1到0.5帧左右也就是编一秒钟的视频可能要等几分钟。这不是bug参考软件本身就不追求编码速度它追求的是编码效率的验证精确度绝大多数模块都跑一遍全搜索。所以后面我建议你先用短序列、低分辨率做功能验证。2. 环境准备与工具选型硬件不够真的会卡到怀疑人生2.1 硬件配置要求内存比CPU更重要很多人上来就编译VTM6.0结果要么编译到一半编译器进程挂了要么编码的时候直接内存爆掉。这里我得先把硬件要求讲清楚免得你白折腾一场。先说CPU。VTM6.0编译本身对CPU多核支持得很好预编译阶段和多文件并行编译都能把多核用满。编码阶段理论上也有多线程配置但参考软件对线程调度做得并不极致实际加速比远不如x265那种工程级复用。我的经验是8核心16线程以上的CPU体验会好很多低于四核的机器建议直接放弃编译完整工程或者只用低分辨率的序列来做测试。内存方面编译阶段至少需要8GB可用内存编码1080p序列建议16GB以上如果是4K分辨率32GB甚至64GB才安心。VTM编码器的内存消耗大头在参考帧缓冲区、重构图像缓冲区和各种搜索候选列表上分辨率越高内存翻倍涨这一点和H.265的HM完全一样。所以如果你只有8GB内存老老实实编CIF、720p级别就够了。硬盘和散热其实也是隐藏瓶颈。VTM编码时会产生大量中间文件尤其开启码流输出、重建图像输出、日志记录时几十分钟跑下来几十GB很常见。同时长时间满负荷运行会让CPU温度飙升笔记本用户尤其要注意散热否则降频后一帧编码时间可能翻两三倍。2.2 操作系统和编译器选择Windows和Linux都要说VTM6.0在Windows和Linux下都能编译运行我两个平台都试过各自有一些坑。Windows平台最省事的组合是Visual Studio 2019加CMake。VS2017也能编译但部分C11/14特性的处理没有2019干净。VS2015相对勉强除非你公司环境锁死了版本否则不推荐。我用CMake生成VS工程时一般选择x64平台Release配置生成之后可以直接在VS里CtrlF5运行也可以用命令行调用。需要注意一点源码路径和生成目录都别带中文和空格否则CMake解析阶段就可能出错。Linux平台相对简单用GCC 9或更高版本基本没压力Clang 12以上也能编译。我常用的一条命令是sudo apt install build-essential cmake gitVTM6.0对CMake版本要求不高3.10以上都行如果你的系统自带版本太老也可以用pip直接装现代版CMake或者下载源码安装。Linux下编译最关键的参数是Release模式因为Debug模式生成的二进制慢得离谱参考软件本来就不快Debug版本更是没法用来跑数据。2.3 FFmpeg和YUV播放器视频素材预处理的两大神器VTM6.0只接受YUV裸流输入不接受MP4、MOV这类封装格式。所以你需要先把普通视频转换成YUV格式传统做法就是用FFmpeg。安装FFmpeg在Windows下可以去官网下载预编译版本Linux下直接apt install ffmpeg就行。转换命令我后面详细演示。另外还需要一个能播放YUV的播放器Windows下推荐YUV Player Deluxe开源免费支持多种YUV格式和位深Linux下可以用YUView这是JVET官方也在用的YUV序列分析工具还能直接查看码流信息的细节我强烈推荐。YUView其实是学习VVC的一个隐藏神器它不仅能播放YUV还能解析VTM编码出来的码流逐帧显示帧类型、QP、块划分配合编码器的日志一起看基本能还原每一帧内部发生了什么。你要是研究算法YUView比什么实效播放器都靠谱。3. VTM6.0编译安装全流程一步步抄作业就行3.1 获取源码git拉取还是下载快照获取VTM6.0源码的官方渠道是Fraunhofer HHI自建的GitLab仓库地址是vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM。这个仓库对VTM版本管理做得比较规范主干上每次会议结束都会更新版本号同时保留了历史tag。如果你熟悉Git可以用命令直接拉取git clone https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM.git cd VVCSoftware_VTM git tag -l VTM-6* git checkout VTM-6.0tag列表里会有VTM-6.0或者VTM-6.0rc1这类标签具体以仓库里实际情况为准。如果网络条件不理想也可以直接在网页上找到对应tag的快照打包下载ZIP到本地解压。要注意的是官方仓库会持续更新如果直接clone主干而不切换到tag可能拿到的是VTM12甚至更新的代码那编译参数和功能就和本文对不上了所以一定要记得切版本。如果你在下载速度上有困难也可以从一些镜像站点找VTM6.0的压缩包但我还是建议优先官方源毕竟安全性和完整性有保障。代码量大概几十MB下载难度不大。3.2 Windows下用CMake生成工程详细到每一步Windows下我推荐用CMake GUI生成Visual Studio工程可视化界面清楚不容易漏选项。操作流程如下解压源码到某个目录比如D:\code\VVCSoftware_VTM-6.0注意路径别带空格和中文。打开CMake GUI在“Where is the source code”里填源码根目录注意是根目录里面必须包含CMakeLists.txt这个文件。在“Where to build the binaries”里填一个build目录比如D:\code\VTM6.0-build让CMake自动创建。点击“Configure”如果第一次配置会弹窗要求选择生成器选“Visual Studio 16 2019”平台选x64。等待配置完成中间可能会输出一些警告只要不是红色错误一般不用管。配置完之后把CMAKE_CONFIGURATION_TYPES里不用的Debug去掉也行留着也无所谓。确认CMAKE_BUILD_TYPE保持默认。点击“Generate”生成VS解决方案。之后到build目录下打开后缀为.sln的解决方案文件比如VTM.sln或者VVCSoftware_VTM.sln。在VS里把解决方案配置切换成Release然后在“生成”菜单里选“生成解决方案”。首次编译需要下载一些依赖并编译很多源文件我这边大概耗时5到10分钟具体看机器性能。编译完成后在build\bin\Release目录下就能看到EncoderApp.exe和DecoderApp.exe。小技巧如果你命令行用惯了其实生成完工程之后可以直接在PowerShell里执行cmake --build . --config Release这样免去打开VS的步骤也避免VS后台各种插件拖慢编译速度。3.3 Linux下用命令行编译一条龙走起Linux下编译VTM6.0非常清爽把源码放进某个目录比如cd ~/code git clone https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM.git cd VVCSoftware_VTM git checkout VTM-6.0 mkdir build cd build cmake ../source -DCMAKE_BUILD_TYPERelease make -j$(nproc)这里有个非常关键的细节CMake配置时指定的源码目录是../source而不是整个仓库的根目录。VTM的CMakeLists.txt放在source子目录下面很多第一次接触的人直接用cmake ..会直接报错说找不到CMakeLists.txt这一点我身边已经有不少同事踩过。编译完成后可执行文件会在build/source/App/EncoderApp和build/source/App/DecoderApp下面也有可能在build/bin下具体看你CMake生成的目录结构。找不到就在build目录下用find . -name EncoderApp搜一遍。Linux下的常见坑是GCC版本太旧。VTM6.0代码用了一些C11和C14特性GCC 5.x之前会遇到语法不兼容建议Ubuntu 18.04以上系统或者手动升级GCC。另一个坑是多核编译时内存不够make -j$(nproc)会非常激进8核机器上编译内存经常飙到十几GB如果你内存小于16GB建议改成make -j4。3.4 编译输出解读EncoderApp和DecoderApp分别是什么编译完你会发现有两个核心可执行文件EncoderApp是编码器主程序负责把YUV编码成码流DecoderApp是解码器主程序负责把码流解码成YUV。这两个程序是VTM最常用的两个入口。除了这两个主程序编译过程中还会生成一个动态库libCommonLib.so或静态库它包含VTM的核心编码算法比如帧内预测、帧间预测、变换量化、熵编码这些模块。这些库文件是给开发者做二次集成用的一般命令行使用用不到。另外build目录下会有一堆.o和中间文件那是编译过程的中间产物不用管。如果你在VS里编译还会看到很多项目名比如CommonLib、EncoderApp、DecoderApp、libmd5等等。它们之间有依赖关系VS会自动处理。我建议把所有项目的平台都设为x64因为x86编译出来的程序寻址空间受限后面编码高分辨率YUV容易内存溢出。4. 编码测试与核心参数解析把VTM6.0真正用起来4.1 准备测试序列用FFmpeg把MP4转成YUV裸流VTM输入必须是YUV格式最常见的配置是YUV420、8bit、逐行扫描。首先找一个测试视频比如你手上有段1080p的MP4可以这样转ffmpeg -i input.mp4 -pix_fmt yuv420p -s 1920x1080 -r 30 -frames 100 -f rawvideo input_1920x1080_30fps_100f.yuv各参数含义-pix_fmt yuv420p指定像素格式为YUV420-s指定分辨率-r指定帧率-frames指定编码帧数-f rawvideo强制输出裸流。这里我把帧数限制在100帧测试够用了因为VTM编码实在是慢。如果你手头没有现成的4K序列又想感受一下VVC在高分辨率下的性能可以去找JVET官方测试序列像BasketballDrive、BQTerrace、Cactus这些都是常用序列网上很多教学资源也会提供裁剪好的短版本。通常YUV文件大小计算公式是宽×高×1.5YUV420字节每帧比如1920×1080×1.5约3MB每帧100帧就是300MB左右提前预留空间。4.2 一条完整的编码命令逐项解释每一段假设你现在已经拿到了测试序列BasketballDrive_1920x1080_50.yuv在Windows下进入build\bin\Release目录执行EncoderApp.exe -c cfg\encoder_randomaccess_vtm.cfg -c cfg\per-sequence\BasketballDrive.cfg -i BasketballDrive_1920x1080_50.yuv -q 32 -f 50 -b output.bin -o recon.yuvLinux下把EncoderApp.exe换成./EncoderApp路径斜杠方向反一下其他逻辑一样。这条命令的完整含义是读取随机访问Random Access主配置文件再读取BasketballDrive序列的分辨率、帧率等配置输入YUV文件设置QP为32编码50帧输出码流output.bin和重建图像recon.yuv。这里要注意-c参数可以出现多次每次加载一个配置文件后面的配置会覆盖前面的同名参数。-i是输入文件路径-q是量化参数-f是编码帧数-b是码流输出路径-o是重建YUV输出路径。编码完成后控制台会输出每帧的编号、帧类型、比特数等信息最后汇总显示总共的码率、PSNR和编码用时。4.3 核心参数详解配置文件里那些选项都代表什么VTM6.0的参数非常多但实际测试时你主要关注这几个参数含义参考值说明-c配置文件路径cfg\encoder_randomaccess_vtm.cfg可重复使用后者覆盖前者-i输入YUV路径自定义必填-wdt宽度1920与YUV实际分辨率一致-hgt高度1080与YUV实际分辨率一致-fr帧率30/50/60影响码率计算和时间戳-f编码帧数16/50/100建议测试先选短序列-qQP值22/27/32/37越小越清晰码率越高-b码流输出路径output.bin必填-o重建YUV输出路径recon.yuv可填可不填--InputBitDepth输入位深8或10与YUV实际位深一致--InputChromaFormat色度格式420常见为420配置文件本身里还有很多开关比如EncoderSearchRange、FastME、UseBDOF这些对应编码效率与复杂度的权衡。默认配置一般就够了初学者不用急着调这些等把主流程跑通再逐个研究不迟。补充一个关键点QP和码率的关系不是绝对固定的。相同序列、相同配置下QP越大码率越低图像质量也越低。想对比不同码率下的RD性能就固定其他参数只改变-q值跑22、27、32、37四个点后面看BD-rate趋势。4.4 编解码全流程验证输出结果怎么看、怎么验证正确性编码完成之后我们还需要把码流解码回来这一步验证编码器生成的码流是否正确。执行DecoderApp.exe -b output.bin -o dec.yuv解码器会将output.bin解码成dec.yuv。然后你可以把dec.yuv和原始input_1920x1080_30fps_100f.yuv做对比用PSNR工具或YUView目测图像质量。更严谨的做法是计算重建文件recon.yuv和解码文件dec.yuv的哈希值两者应该完全一致因为编码器内部重建图像和解码器输出的图像在无错误情况下是同一份数据。Linux下直接md5sum dec.yuv recon.yuv对比Windows下可以用fc /b或者Get-FileHash。编码器最终输出的总码率单位一般是kbps同时会输出Y、U、V三个分量的PSNR。比如我的实测结果中BasketballDrive序列在QP37时码率大约是1200kbpsY-PSNR约33dB。听到这个数据也许你觉得码率有点高但这是参考软件未做码率优化下的结果工业级编码器会在类似质量下压得更狠。如果你需要精确计算BD-rateVTM源码里自带了BD-rate计算脚本位置在python目录下用Python运行即可。不过这个脚本对Python环境和输入文件格式有点要求我一般是用Excel或者一个小脚本自己算公式网上也有很多。5. 常见问题与排查技巧实录这些坑我基本都踩过5.1 编译阶段的问题内存爆掉和路径坑最让人头大编译过程中最常见的问题是C1083或internal compiler error这类说白了就是编译器内存不够。VS在编译大型项目时进程占用经常超过2GB加上并行编译内存小的机器非常容易崩。我的处理方法是在VS里把“最大并行项目数”调小或者直接用命令行串行编译。Linux下用make -j2替代make -j$(nproc)慢一点但至少不会崩。路径问题也很常见。VTM源码目录和build目录如果放在带中文或空格路径下CMake配置阶段可能不会立刻报错但到了编译阶段就会出现找不到头文件、无法打开PDB文件这种诡异问题。宁可把整个工程放在D:\code这种干净目录下也别图方便放桌面。还有一类问题是拉取源码后没有切换tag直接拿主干来编译。主干代码已经不叫VTM6.0了编译产物的参数定义和本文对不上出问题后网上搜到的解决方案往往也不适用。我建议你自己在仓库里切回VTM-6.0的tag或者从官方发布的快照包解压确保版本一致。5.2 运行时的问题配置文件找不到和编码中途崩溃运行时第一个高频错误是“找不到配置文件”。VTM运行程序时不会自动定位到cfg目录所以-c cfg\encoder_randomaccess_vtm.cfg这个相对路径是相对于当前工作目录的。如果你在build\bin\Release下执行而cfg目录在源码根目录下路径就要写成-c D:\code\VVCSoftware_VTM-6.0\cfg\encoder_randomaccess_vtm.cfg或者先把cfg文件夹复制到当前目录。Linux下同理。编码中途崩溃十有八九是输入YUV文件大小和参数不匹配。比如你写了-f 100但YUV文件只有50帧的量编码器读到中途数据断层自然崩掉。这里有个排查技巧先看一眼输入文件大小算一下单帧字节数再用文件大小除以单帧字节数得到实际总帧数。比如1080p YUV420单帧是1920×1080×1.53110400字节文件3GB大概就是1000帧左右。还有一种崩溃是配置了10bit输入但YUV文件实际是8bit或者反过来。这种问题不会在开头就报错往往编码到某一帧突然出现异常值。所以输入位深这个参数一定要和转换FFmpeg时的-pix_fmt yuv420p对齐10bit就用yuv420p10le。5.3 编码速度太慢怎么办四招教你快速验证功能VTM6.0编码慢是正常状态但如果你怀疑“这也太慢了”可以试试这几个方法来加快速度。第一降低分辨率。跑CIF352×288或VGA序列比跑1080p快几十倍很多功能验证用低分辨率就够。第二减帧数。只编8到16帧能快速确认整套流程是否正常不用非等到100帧跑完。第三改配置。把encoder_randomaccess_vtm.cfg里的搜索范围调小或者把FastME1这种快速运动估计开关打开。参考软件其实也留了一些加速选项虽然是牺牲精度换速度但功能验证阶段足够用。第四串行改并行。VTM支持多线程配置在配置文件里设置Threads4或者更高能明显缩短编码时间。但我也要说句实话VTM的并行优化整体做得很保守和x265的帧级并行完全不是一个水平。就算你开满线程1080p也快不到哪儿去心态要摆正。5.4 配置文件参数调整技巧如何快速找出影响编码效率的开关有时候你想验证某个新工具到底有没有生效比如BDOF双向光流或者仿射运动补偿可以在编码命令后面加参数覆盖配置文件例如EncoderApp.exe -c cfg\encoder_randomaccess_vtm.cfg -c cfg\per-sequence\BasketballDrive.cfg -i seq.yuv --UseBDOF0 -f 32这样就不用改配置文件里原来的内容方便做对比实验。VTM的参数风格统一是--参数名值布尔类型一般填0或1整型就直接填数字。我个人习惯保留一份“最小测试配置”把IntraPeriod改小、只编几帧专门用来快速冒烟测试。等确认链路跑通再切回标准配置跑正式数据。这样的好处是平时编码新序列、改新算法能很快发现逻辑错误而不是被慢到极致的编码耗光耐心。6. 读完代码不算懂看懂VTM的工程结构才是关键编译和编码的流程跑通之后下一步自然就是读代码。VTM6.0的源码结构其实很清晰主程序入口在source/App/EncoderApp下的EncApp.cpp核心编码逻辑封装在EncoderLib库里source/Lib/CommonLib下面则是公共工具类和码流读写类。我建议的阅读路线是先看EncApp.cpp的main函数搞清楚命令行参数如何被解析并传给编码器再看EncoderLib里的EncGOP、EncSlice这些负责图像组划分和片级编码的类然后进入EncCu.cpp的xCompressCU函数这里就是VVC编码树单元压缩的核心递归过程也是整个编码器最复杂的地方。刚开始看代码不求全懂先抓主干比如从一帧YUV进来经过帧内/帧间预测、变换量化、重建环路滤波最后熵编码出码流这条流程对应了哪些函数和类。等你把这条主干摸清了再回头研究每个工具的具体实现比如仿射模型的参数推导、ALF滤波器的系数计算就容易得多。我个人在实际操作中的体会是VTM6.0是个很好的“学习标本”它的代码结构比HM复杂不少但又没有后来VTM12那么庞大臃肿非常适合用来建立对整个VVC框架的整体认知。学完VTM6.0再去看商业编码器代码或者硬件设计你会觉得顺畅很多。最后分享一个我自己的学习技巧把配置文件和输出日志配合着看。编码器每次运行结束都会打印详细的配置项和每一帧的统计信息这些信息能直接映射到代码里对应参数和模块。遇到不懂的参数就在源码里搜字符串很快就能定位到代码位置比对着源码目录海捞效率高得多。这个技巧在我后面读VTM代码、写算法改进实验时帮了大忙你也可以试试。