第一次被 Codec 这个词砸到脸上通常不是在研究压缩算法而是在终端里撞上 UnicodeEncodeError。某个古灵精怪的字符突然出现然后把 GBK 编解码器当场气死报错行里那个 codec 参数让不少人第一次意识到编码解码器这东西到处都是。同样是 Codec视频编码领域正在发生一件更激进的事——神经视频编码Neural Video Coding想让 Codec 学会“学习”。H.264、H.265、AV1 这些传统标准本质上是人写死的一套复杂规则编码器按规则执行而神经视频编码把这些规则替换成神经网络用海量视频帧训练出一个能自己总结压缩规律的模型。我下面要讲的就是这件事背后的技术逻辑以及真正落地时绕不开的工程边界。如果你正在接触视频编码、想从传统 Codec 往神经方法这边探一眼或者只是好奇“AI 压缩视频”到底是怎么个“AI”法这篇文章会很对胃口。1. 从“压缩工具”到“学习系统”神经视频编码到底在学什么1.1 传统 Codec 是怎么干活的先回到老本行。H.264、H.265 这类传统编码器内部都是几个固定模块的组合帧内预测、帧间预测、变换、量化、熵编码。预测模块负责去掉空间和时间上的冗余变换模块把残差从像素域转到频域量化模块把高频细节丢掉熵编码模块再把剩下的符号压缩成比特流。每一步都是人类工程师按照率失真理论精心设计的。比如 H.265 里编码一棵编码树要遍历不同的块划分方式对每种划分算一个代价码率加上质量损失乘上一个拉格朗日因子。所有模块的规则清清楚楚写在标准文档里编解码器厂商照着实现就行。打个比方传统 Codec 像一本极其详尽的菜谱。厨师编码器严格按菜谱做菜加多少盐、切多薄的丝全是死规定。菜谱好不好取决于写菜谱的人有多懂食材。传统视频编码发展了三十年菜谱已经厚到没人能完全背下来但本质上它还是“人手写规则”的产物。1.2 神经 Codec 替换掉的不是某个环节而是整条链路神经视频编码的思路完全不同。它不再分别设计预测、变换、量化、熵编码而是把这些模块全打包进一个端到端的自编码器网络里。输入一帧图像或者一个视频帧组编码端网络把它映射到一个隐表示latent representation这个隐表示经过量化后送入熵编码器解码端网络再从量化后的隐表示还原出图像。训练的时候损失函数由两部分构成一部分是码率估计另一部分是重建质量损失。网络自己去权衡怎么分配比特、怎么提取特征没人告诉它“应该先做运动估计再做残差编码”。所以严格说神经 Codec 不是“替代”了哪个传统模块而是把整条编码链路重构成一个可微分的函数。传统编码器里的预测、变换模块在神经编码器里对应的是网络卷积层的某种隐式行为。这套路有点像深度学习在其他领域的胜利与其人肉设计特征不如让网络自己学特征。这里最关键的一个词是“可微分”。传统编码器里的量化是硬性的梯度传不过去所以没法用反向传播端到端优化。神经编码器通过一些技巧加噪声模拟量化、直通估计器等绕开了不可导问题让整个系统能够被梯度下降优化。这一下就把“视频压缩”从手工调优变成了一个损失函数优化问题。1.3 “学习”发生在什么时候这是个关键问题标题里那个“学习”是带引号的我得解释一下。神经视频编码的学习发生在离线训练阶段。成千上万帧视频喂进去网络不断调整权重最终学会提取有效的压缩特征。但是在线上推理阶段编码器做的依然是前向计算没有“边压边学”这回事。这个区别很重要。传统 Codec 升级标准比如从 H.264 升到 H.265需要制定新协议、开发新芯片、推进播放生态。神经 Codec 升级模型理论上只要换一套权重。听起来很轻松对吧但这里藏着一个大坑解码端也必须用同一套权重。你拿着新模型压出来的比特流放到旧模型的解码器上什么都解不出来。这就像两个人用暗号交流换了一本密码本之后另一个人手里的旧本子就完全失效了。后面讲工程边界的时候你会看到就是这种“编解码两端必须绑定同一种模型”的特性成了神经视频编码落地最大的拦路虎。2. 技术架构拆解一个神经 Codec 到底由几块积木搭成2.1 主干自编码器从像素到隐表示再回来先看最朴素的框架。给定一帧图像 x编码端网络 E 做分析变换输出隐表示 yy 经过量化变成 ŷ这个 ŷ 一方面被算术编码器写进比特流另一方面喂给解码端网络 DD 做合成变换输出重建图像 x̂。E 和 D 通常带有残差块、下采样/上采样层。输入一张高分辨率图像经过几次下采样后y 的空间尺寸比原图小很多通道数却更深。比特量取决于 y 里有多少个元素、以及每个元素花多少比特来编码。量化这一步必可少因为连续数值没法高效熵编码量化到有限集合上才能写成二进制。训练时如果直接用量化梯度就断了常用的做法是在前向时做四舍五入反向时用“直通估计器”让梯度近似穿过量化器。这个自编码器结构本身就是神经 Codec 最基础的一层积木。它解决的核心问题是怎么把图像信息浓缩到一个紧凑的隐表示里同时让解码端能尽量高质量地恢复出来。你可以把 y 理解成“带噪的摘要”压缩性能好不好就看网络能不能用更短的摘要装下更多的关键信息。2.2 超先验与自回归上下文给熵编码配上“第二大脑”光有自编码器还不够。算术编码器要把每个元素的概率估计出来才能按概率分配比特。概率越准编码越省。传统视频编码用精心设计的上下文模型来估计概率神经 Codec 则需要另一个网络来产出概率。这里有个很漂亮的设计叫超先验hyperprior。编码端把 y 再喂给一个小网络生成一个超隐表示 zz 也被量化后单独传输。解码端通过 z 来推算 y 每个元素的概率分布参数均值和方差。相当于在主干之外再加了一条旁路专门传递“如何理解 y 的说明书”。更进一步还有自回归上下文模型。它让 y 的概率估计依赖之前已经解码出来的元素像猜词游戏一样越往后面猜越准。这类方法大幅提升了压缩率但也带来一个工程痛点必须逐元素串行解码并行度被砍得很厉害。你在论文里看到那些“mbt2018”“cheng2020”之类的名字大多就是这些模块的不同组合方式。可以说超先验和自回归上下文是神经 Codec 在“熵模型”这件事上对传统标准降维打击的核心。传统标准用人工规则捕捉概率分布神经 Codec 用网络无缝拟合任意复杂的分布这也是它能比 H.265 多省出百分之二三十码率的重要来源。2.3 率失真损失训练时的天平砝码整个网络训练的时候损失函数长这样L R λDR 是估计出来的码率D 是重建质量损失通常是 MSE 或 MS-SSIMλ 是拉格朗日乘子。λ 大模型就偏向省码率质量差一点也能忍λ 小模型就偏向保质量哪怕多用点比特也无所谓。你没看错神经 Codec 的训练就是一个大号的率失真优化只不过传统编码器是在编码时对每一个块做这个优化而神经 Codec 是在训练时对整个网络做这个优化。传统编码器一次编码要遍历几百种划分方式神经编码器只要跑一次前向所有块的“划分决策”都被网络权重直接算出来了。但这也暴露了一个问题你想得到不同码率的输出怎么办传统编码器直接调整 QP 或目标码率就行神经编码器通常得训练好几个不同 λ 的模型或者用条件编码、超网络来动态调整。实际工程中码率控制不起来是神经视频编码被吐槽最多的一点。3. 工程边界的“硬碰硬”为什么还没全面替代 H.2653.1 速度与算力门槛编码快没用解码慢一样不行学术论文里报压缩率的时候大家喜欢举 BD-Rate 降低百分之三十、四十的例子。但真正动手跑过的人都知道神经视频编码目前的计算开销大得让人皱眉。编码端一次前向在 V100、A100 这类数据中心显卡上处理单帧可能只需要几十毫秒但面对 1080p 甚至 4K 视频帧率很难跑满实时。更要命的是解码端。视频传输场景下编码可以慢解码必须快不然用户端永远在看转圈。而神经解码器同样是一个神经网络哪怕比编码端小也得靠 GPU 或者专门的 NPU 才能跑得动。显存占用同样是个麻烦。高分辨率视频帧往往要切成 patch 分块处理切得太大显存爆掉切得太小又损失压缩效率。我见过不少人在落地神经编码时第一道坎不是效果不如预期而是工程机上显存不够用不得不把已经训好的模型重新调成更小的 patch 尺寸。3.2 解码器生态的“冷启动”困境这可能是所有问题里最无解的一个。H.264 之所以无处不在是因为从硬件芯片到操作系统到浏览器播放器整个生态都内置了对应的解码器。即使你自己写一个码流只要能封装成标准格式任何设备都能放。神经视频编码不存在“标准格式”。每一个模型压出来的比特流只有用同一个模型的解码器才能解析。你没有一套统一的“H.266 神经标准”有的只是一个个互不兼容的模型快照。想让浏览器支持你的格式几乎等于让所有用户先安装一个解码插件这在移动端生态里几乎不可接受。所以你会看到神经视频编码目前能落地的场景基本都集中在“编解码两端都受控”的环境里。服务器端编码服务器端也能解码中间只需要传输比特流。一旦牵扯到公网分发、多端播放这套方案的工程复杂度就指数级上升。3.3 已经能用和暂时别碰的落地场景根据我自己的观察和一些团队的实践目前相对能落地的场景有这三类一是视频监控归档。摄像头每天产生海量视频存储成本很高这个场景的特点是编码一次、解码很少而且播放环境完全可控。把 H.265 换成一个压缩率更高的神经 Codec哪怕解码需要一台 GPU 服务器做转码整体成本也可能划算。二是云剪辑和代理文件。云端先把原始素材用神经 Codec 压成低码率代理文件剪辑师在代理文件上操作最终输出时再拉取原始画质。这类“中间态存储”场景对解码兼容性要求不高对压缩率极度敏感。三是影视素材母版备份。原始素材不差码率但体积大得惊人用神经编码做长期归档保留的信息量比传统编码更高后期重采样、调色时更稳。暂时别碰的场景我也要说清楚实时音视频通话、直播推流、用户上传视频平台。这些场景对延迟、硬件解码兼容性、码率实时波动的要求太苛刻神经视频编码目前的成熟度还远撑不起来。不是说它未来不行而是现在强行切入成本收益大概率是负的。4. 实操视角跑通一个神经视频编码任务需要准备什么4.1 模型与框架选型如果你第一次上手我建议别从论文复现开始直接用开源库和预训练权重去跑评估。图像压缩方向可以用 CompressAI视频压缩方向有 DVC、DCVC 等经典模型的开源实现。选模型前先想清楚你要做的是图像压缩还是视频压缩——这两个问题难度差一倍。图像压缩相对简单单帧独立处理模型复现也容易。视频压缩则多了“帧间冗余”这一大块编码端通常要估计运动信息光流再把运动矢量和残差一起编码。DVC 这类模型就把运动估计网络、运动补偿网络和残差编码网络放在一个框架里联合训练复杂度明显上了一个台阶。我的建议很直接刚开始先跑通一个图像压缩模型把熵模型、量化的细节摸透再往视频方向延伸。一上来就追 DCVC很容易被一堆组件之间的配合搞到怀疑人生。4.2 训练数据、预处理与超参数数据集方面图像压缩常用 Vimeo-90K、CLIC视频压缩常用 UVG、REDS4 这类视频序列。训练前要切块一般切成 256×256 或 512×512 的 patch带随机翻转和裁剪做数据增强。遇到高分辨率真实视频先做下采样再训练和评估不然显存会先受不了。训练超参数里batch size 和 λ 是最关键的。batch size 太小率失真曲线不稳定λ 的选择则直接决定模型是偏省码率还是偏保质量。我自己的习惯是先用一个中等 λ 试跑几十个 step盯着训练 loss 是否平滑下降确认代码没问题后再正式训练。一个模型从零训练到收敛单卡通常要两三天到一周这个成本你要有心理准备。强烈建议在训练脚本里加上日志记录把每个 step 的 R、D、整体 loss 都存下来。看训练曲线时重点不是 loss 降得多快而是 R 和 D 是否出现震荡。如果震荡剧烈大概率是量化模拟或者学习率出了问题。4.3 评估指标与码率计算跑通模型后怎么判断它好不好业内最常用的指标是 PSNR、MS-SSIM 和 BD-Rate。PSNR 是像素级失真MS-SSIM 更贴近人眼感知BD-Rate 用来对比不同编码方案在同等质量下能省多少码率。注意 BD-Rate 是负值代表节省别算反了。码率的单位一般用 bppbits per pixel。对于一帧 1920×1080 的图如果总比特数是 3 Mbit那 bpp 就是 3×10^6 / (1920×1080) ≈ 1.45。视频压缩里也经常用 kbps但 bpp 在论文对比中最直观。评估脚本大概是这个流程# 伪代码神经视频编码评估流程 for frame in test_video_frames: # 参考帧处理视频压缩通常有帧间依赖 y encoder(frame, ref_features) # 分析变换 运动信息 y_hat, z_hat quantize(y, hyperprior) # 量化 bits arithmetic_coding(y_hat, prob) # 熵编码统计比特 reconstruction decoder(y_hat, ref) # 合成变换 psnr_list.append(calculate_psnr(frame, reconstruction))画率失真曲线时拿多个不同 λ 的模型在测试集上打分横轴是码率纵轴是质量然后把点连成线。对比传统编码器时也把 H.264、H.265 在多个 QP 下的点画在同一个坐标系里再做 BD-Rate 计算。这里有个实操心得光看平均 PSNR 会骗人。神经编码对高纹理区域、快速运动、文字字幕这些内容特别容易崩。评估一个模型好不好用一定要找几段“刁钻”的测试视频比如树叶晃动、水波纹、体育比赛快镜头把失败案例截图出来一张张看。很多时候平均指标好看但某一帧糊成一片这个方案就根本没法上线。5. 常见问题与排查技巧实录5.1 显存不够怎么办这是第一名的问题。训练阶段处理高分辨率帧显存直接爆给编码器看。我的处理思路按优先级排列先降 patch 尺寸从 512 降到 256观察率失真损失变化然后开混合精度训练显存能省接近一半再不行就用梯度检查点。如果还爆就得换更大显存的卡或者重新设计网络下采样倍数。评估阶段显存爆了通常是因为一次性喂了整帧。这时候把长视频拆成短序列逐帧处理或者控制 batch size 为 1。别小看这一条我见过不少同学模型训得挺好评估时却因为显存限制不得不降低分辨率结果测出来的指标虚低。5.2 量化后质量暴跌训练时用了加噪声模拟量化但推理时换成真实四舍五入两者分布一错位重建质量可能掉一大截。常见的解法是在训练末尾做微调把模拟量化替换成真实量化用小学习率继续训几个 epoch。这类“量化感知微调”能显著减少训练和推理之间的差距。另外一个容易忽略的问题是熵模型的精度。推理时算术编码器需要非常精确的概率累积分布如果熵模型输出概率过大或过小算术编码可能出现数值溢出。我建议在编码时对概率做截断或平滑避免极端值。5.3 码率控制不精准神经编码不像 H.265 那样能直接指定目标码率。很多模型属于“固定质量、浮动码率”同一段视频在不同场景下码率波动很大。如果你需要严格控制码率上限一个工程化做法是用多个 λ 的模型作为锚点根据当前帧的复杂度动态选择模型或者在后端做二次转码。另一种思路是调整任务目标。比如监控存储场景你其实关心的是质量下限而不是码率上限那直接用固定质量模式反而更方便。想清楚业务到底卡码率还是卡质量能让选型简单不少。5.4 常见问题速查表现象可能原因解决建议训练 loss 震荡不收敛学习率过大或量化模拟失效降低学习率检查量化噪声强度测试集 PSNR 高但主观质量差MSE 优化偏向平滑损失函数加入 MS-SSIM 项解码端文件打不开编解码模型版本不一致固定权重版本验证哈希高分辨率视频显存爆patch 设置太大减小 patch分段编码码率波动大单 λ 模型无法覆盖复杂度多模型切换或引入质量控制模块自回归解码极慢逐元素串行扫描加速方案通道级并行或分批解码5.5 容易被忽略的“小坑”最后分享几个冷门但很要命的细节。第一熵编码器在长序列上做算术编码时要注意整数精度问题尤其用 CDF 查表法时概率累积值一旦溢出整个码流全乱。第二视频压缩的参考帧管理很关键解码端重建的参考帧和编码端参考帧必须完全一致任何数值误差都会在时序上传导放大。第三模型权重文件一定要带上网络结构和预处理细节一起归档不然几个月后你自己都可能找不到对应版本。我做神经视频编码实验踩过最大的坑是训练时没有锁随机种子导致某个增强操作给验证集也加了噪声最后跑出来的 BD-Rate 虚高一开始我还以为模型效果起飞了。所以强烈建议训练脚本里固定随机种子验证集坚决不做随机增强。我自己在实验室把神经视频编码这一套跑通之后最大的感受是这个方向确实已经能顶开传统编码逼近极限后剩下的一块天花板但离“随手拿来就用”还很远。如果你正在评估要不要上神经编码我的建议是先找到两端环境可控、解码端能接受 GPU 开销的场景把压缩率收益和转码成本摊开算清楚。别急着喊替代先让它在你手里跑起来跑通了你自然知道边界在哪。