1. 视频编码的十字路口从H.266到神经编码的路线之争视频编码这行有个很有意思的现象每隔几年就会冒出一个“下一代标准”宣称能比上一代省一半带宽然后大家兴冲冲地跟进结果发现编码复杂度翻了好几倍实际部署时又得在画质和速度之间反复妥协。H.266也就是VVCVersatile Video Coding就是这么来的2020年正式冻结标准的时候官方给出的数据是比H.265HEVC在同等主观质量下节省约50%的码率。这个数字很漂亮但真正做过编解码落地的人都知道这50%背后是编码复杂度大约10倍的增长解码复杂度也有2倍左右的提升。而最近两年神经编码Neural Coding这个词开始频繁出现在各种技术讨论里。它不走传统混合编码框架的老路而是直接用神经网络来做端到端的压缩。听起来很美好但实际落地情况如何这篇文章我想从一线从业者的角度把H.266和神经编码这两条路线掰开揉碎了聊一聊不吹不黑就说实际工程中遇到的那些事。如果你是在做视频传输、CDN优化、短视频平台转码或者单纯对下一代视频Codec的技术走向感兴趣那这篇内容应该能给你一些参考。我不会只讲概念会尽量把参数选择、复杂度权衡、实际部署的坑都带上。2. H.266/VVC到底强在哪核心工具拆解2.1 块划分与变换从四叉树到多类型树H.266最直观的变化是块划分方式。H.265用的是四叉树QT每个块要么不切要么切成四个等大的子块。H.266引入了多类型树MTT除了四叉树还支持二叉树BT和三叉树TT。这意味着一个128x128的CTU可以切成各种形状的组合比如1:2、1:4、3:1这种比例。为什么要这么改因为视频内容里有很多非正方形的纹理区域比如水平方向的边缘、垂直方向的条纹。用四叉树硬切的话要么切得不够细导致残差大要么切得太细导致头信息开销高。MTT让编码器可以根据内容自适应选择划分方式实测下来在纹理复杂的区域能省不少码率。但代价是什么编码器需要遍历的划分组合数量爆炸式增长。H.265的划分决策已经够慢了H.266更是把搜索空间扩大了一个数量级。这也是为什么VVC的参考软件VTM编码速度慢得令人发指一个1080p的序列用默认配置跑可能几帧每秒都不到。2.2 帧内预测65个方向模式加矩阵预测H.265有35个帧内预测模式H.266直接加到65个。方向更细了对于那种渐变纹理的预测精度确实有提升。但真正有意思的是新增的矩阵加权帧内预测MIP和跨分量线性模型CCLM。MIP的思路是用一个小矩阵对参考像素做线性变换来生成预测块相当于用神经网络的思想虽然是很浅的线性层来做帧内预测。CCLM则是利用亮度分量来预测色度分量因为人眼对色度没那么敏感色度块可以更大用亮度信息来辅助预测能省不少码率。实际调参的时候MIP和CCLM的开启与否对码率影响挺大的。我试过在某个监控场景的序列上关掉CCLM大概会损失3%到5%的码率节省。但开启这些工具会增加解码端的计算量移动端解码的时候得权衡。2.3 帧间预测仿射运动与解码端运动矢量细化帧间预测这块H.266加了仿射运动补偿Affine Motion Compensation。传统的平移运动模型只能描述整块平移但真实世界里有旋转、缩放、透视变形。仿射模型用四个或六个参数来描述这些变换对于那种镜头推拉摇移的场景效果很明显。另一个实用的工具是解码端运动矢量细化DMVR。它不需要额外传运动信息而是在解码端通过匹配参考块来 refine 运动矢量。这个思路很巧妙相当于把一部分计算从编码端转移到解码端省了码率但增加了解码复杂度。还有双向光流BDOF和预测细化光流PROF都是利用光流的思想来做像素级的运动补偿。这些工具叠加起来在运动剧烈的序列上能带来可观的增益但解码器的负担也相应增加。2.4 环路滤波去块、SAO与ALFH.266的环路滤波新增了自适应环路滤波器ALF。H.265有去块滤波DBF和样点自适应偏移SAOH.266在此基础上加了ALF用维纳滤波的思想对重建图像做自适应滤波。ALF的效果确实好尤其是在低码率下能明显减少块效应和振铃。但ALF的参数需要传到码流里而且计算量不小。实际部署时很多硬件解码器会选择性地关闭ALF或者用简化版本因为功耗和面积开销太大。3. 神经编码的底层逻辑端到端压缩怎么玩3.1 从自编码器到率失真优化神经编码的核心思路是用自编码器Autoencoder来做压缩。编码器网络把输入图像映射到一个潜在表示Latent Representation然后量化、熵编码解码器网络再从量化后的潜在表示重建图像。训练的时候损失函数通常是率失真损失失真项用MSE或者MS-SSIM率项用潜在表示的熵。通过调节拉格朗日乘子λ可以在不同码率点上训练出不同的模型。这和传统编码里的率失真优化是一个道理只是实现方式从手工设计变成了网络学习。但这里有个关键问题量化是不可导的。训练的时候需要用直通估计器Straight-Through Estimator或者加均匀噪声来近似。这个技巧在实际训练中很关键处理不好会导致训练不稳定或者率失真性能下降。3.2 熵编码从算术编码到超先验传统编码的熵编码用的是CABAC上下文自适应二进制算术编码H.266里叫CABAC的增强版。神经编码则通常用一个条件熵模型来估计潜在表示的概率分布然后用算术编码或者范围编码来生成码流。比较有代表性的是超先验Hyperprior结构用一个额外的网络来估计潜在表示的均值和方差作为条件来指导熵编码。这个思路在端到端图像压缩里已经被验证很有效视频编码里也有不少工作在借鉴。但神经编码的熵编码有个工程上的麻烦概率分布是连续值需要离散化才能做算术编码。而且网络推理出来的分布和实际分布可能有偏差导致编码效率下降。实际部署时通常需要把网络量化成定点数然后用查找表来实现概率估计这样才能满足实时性要求。3.3 运动补偿从块匹配到可变形卷积视频神经编码和图像神经编码最大的区别在于运动补偿。传统编码用块匹配加运动矢量神经编码则可以用可变形卷积Deformable Convolution或者光流网络来做运动补偿。可变形卷积的思路是让网络自己学习采样点的偏移相当于把运动估计和运动补偿融合到一个网络里。这样做的优势是可以处理复杂的非刚性运动但缺点是计算量大而且偏移量需要传到码流里增加了头信息开销。另一种思路是用光流网络估计稠密运动场然后做warping。光流的好处是像素级的运动描述但光流本身的估计和编码也是不小的开销。实际研究中很多方案会在块级和像素级之间做折中比如用块级运动矢量加残差光流。4. 两条路线的正面交锋复杂度、压缩率与落地难度4.1 压缩效率对比实验室数据 vs 实际场景先看数据。在JVET的通用测试条件下CTCVVC相比HEVC能节省约40%到50%的码率。神经编码方面比较有代表性的工作比如DCVC、DCVC-HEVC在相同PSNR下能比HEVC节省约20%到30%的码率但和VVC比还有差距。不过实验室数据和实际场景差距很大。VVC的测试序列是精心挑选的实际内容千奇百怪。我试过在一些低纹理的监控视频上VVC的增益会缩水到20%左右。神经编码在训练集分布内的内容上表现很好但遇到分布外的内容比如动画、屏幕内容就容易翻车。还有一个关键点神经编码的模型通常是针对特定码率点训练的要覆盖多个码率点就得训练多个模型或者用条件模型。VVC则是一套编码器通过调整QP来覆盖所有码率灵活性上传统编码还是有优势。4.2 计算复杂度编码端与解码端的博弈复杂度这块VVC的编码复杂度大约是HEVC的10倍解码复杂度约2倍。这个数字在PC端还能接受但在移动端就很吃力了。现在手机上的VVC硬解还没大规模普及软解的话功耗和发热都是问题。神经编码的复杂度分布不太一样。它的编码和解码复杂度相对对称主要取决于网络的大小。一个轻量级的神经编码网络可能只有几层卷积但一个高性能的网络可能有几十层推理一次的计算量也不小。实际部署时神经编码有个优势是可以针对特定硬件做优化比如用NPU来加速。VVC的编码工具是固定的硬件加速需要专门设计电路。但从另一个角度看VVC的标准化意味着不同厂商的编解码器可以互通神经编码目前还没有统一标准各家的模型不兼容。4.3 标准化与生态VVC的护城河VVC有完整的标准文档、参考软件、一致性测试芯片厂商可以按照标准来做硬解。神经编码目前还处于研究阶段MPEG和JVET虽然在探索神经编码标准化的可能性但离正式标准还有距离。生态这块VVC已经有不少产品落地了比如某些直播平台已经在用VVC做转码虽然普及速度比预期慢。神经编码的落地案例还很少主要在一些特定的场景比如云游戏、VR视频因为这些场景对压缩率要求极高愿意牺牲兼容性来换取带宽节省。5. 实操中的坑从编码参数到部署细节5.1 VVC编码参数调优实战如果你要用VVC做转码有几个参数是必须调的。首先是Qp这个和H.265类似但VVC的QP范围更宽从0到63。实际用的时候1080p内容一般在22到32之间调整。然后是IntraPeriod也就是I帧间隔。VVC的I帧比H.265更贵因为工具更多所以I帧间隔可以适当拉长。我一般设成48到96帧具体看场景。如果是直播可能得设短一点比如32帧方便快速切换。还有GOPSize也就是GOP长度。VVC支持更灵活的GOP结构可以用B帧做参考。实测下来GOPSize设成16或者32比较平衡再大收益就不明显了。# VVC参考软件VTM的典型配置示例 # 编码1080p序列QP27GOP32 EncoderApp -c encoder_intra_vtm.cfg -i input.yuv -w 1920 -h 1080 -fr 30 -f 300 \ -q 27 --IntraPeriod64 --GOPSize32 --DecodingRefreshType2 \ -b output.bin -o rec.yuv注意VTM的编码速度极慢生产环境一般用VVenC或者x266这类优化过的编码器。VVenC的速度比VTM快不少但压缩率会略低一点。5.2 神经编码的工程化挑战神经编码落地最大的坑是模型量化。训练的时候用浮点部署的时候得转成定点或者int8。量化误差会直接影响重建质量尤其是那些依赖精确概率估计的熵编码模块。另一个坑是内存占用。神经编码网络通常需要缓存多帧的特征显存占用比传统编码器高不少。在边缘设备上部署时得做模型剪枝和特征压缩。还有一点是错误恢复。传统编码有切片、条带这些机制来做错误恢复神经编码目前还缺乏成熟的错误恢复方案。一旦码流丢失或者损坏重建质量会急剧下降。5.3 常见问题速查表问题现象可能原因排查思路解决方法VVC编码速度过慢工具全开搜索范围过大检查--FastMode是否开启关闭部分工具用快速模式神经编码重建模糊量化步长过大或模型欠拟合检查量化参数和训练损失降低量化步长增加训练数据解码端功耗高ALF或DMVR计算量大用性能分析工具定位热点关闭部分滤波工具用简化版码流不兼容不同编码器实现差异检查是否符合标准一致性用标准参考软件验证神经编码泛化差训练集与测试集分布不一致对比训练和测试内容类型增加数据增强用混合训练6. 谁更先进场景决定答案6.1 实时通信场景VVC更务实在实时通信RTC场景里延迟是第一优先级。VVC的编码延迟可以通过调整GOP结构和关闭部分工具来控制虽然压缩率会下降但至少能跑。神经编码的推理延迟目前还很难做到端到端低于50毫秒尤其是在移动端。而且RTC场景对丢包很敏感VVC有成熟的错误恢复和重传机制神经编码在这方面还很不成熟。所以短期内RTC场景还是VVC的天下。6.2 点播与存储场景神经编码有潜力点播和存储场景对延迟不敏感可以容忍较高的编码复杂度。神经编码在这种场景下可以充分发挥压缩率优势尤其是对于特定类型的内容比如电影、电视剧可以用大量数据训练专用模型。但问题是点播平台的内容类型非常多样一个模型很难覆盖所有内容。而且点播平台通常需要支持多种分辨率和码率神经编码的多码率支持还不如传统编码灵活。6.3 未来走向混合方案可能是答案我个人觉得未来不会是神经编码完全取代传统编码而是两者融合。比如用神经网络来增强传统编码的工具像VVC里的MIP其实就有神经网络的影子。或者用传统编码做基础层神经编码做增强层兼顾兼容性和压缩率。MPEG已经在探索神经编码标准化的路径但标准化需要时间。在标准出来之前神经编码更多是在特定场景做试点比如云游戏、VR直播这些对带宽极度敏感的领域。7. 我踩过的那些坑和一点经验最后说几个实际踩过的坑。第一个是VVC的参考软件版本兼容性不同版本的VTM码流可能不兼容升级的时候一定要做回归测试。第二个是神经编码的模型更新每次重新训练模型后之前编码的码流可能无法用新模型解码版本管理很重要。还有一个经验是不要盲目追求最新的工具。VVC里有些工具在特定内容上收益很小但复杂度增加很多。实际部署时根据内容类型选择性地开启工具比全开更划算。神经编码也是一样不是网络越大越好得看实际场景的算力预算和压缩率需求。如果你现在要选型我的建议是如果做通用视频服务VVC是更稳妥的选择生态成熟工具链完善。如果做特定场景且对压缩率有极致要求可以试试神经编码但要做好踩坑的准备。两条路线都在快速演进保持关注但别急着 all in。