打开视频编码的技术资料，到处都在讲 H.264、H.265、AV1，偶尔冒出个 VVC/H.266。过去二十年，我们一直在跟 DCT、量化、熵编码这些“手写规则”打交道。最近几年方向有点变了：一批研究者开始让 Codec 自己“学习”——不是工程调参意义上的学，而是把整条压缩链路丢给神经网络去学。
如果你跟我一样常年混在视频传输、云转码、播放器优化这条线上，应该已经能感觉到：神经视频编码不再只是论文里的曲线图，它开始进入“能不能用、值不值得用、边界在哪”的工程讨论。这篇文章我就想从技术逻辑和工程边界两条线，把“当 Codec 开始学习”这件事掰开聊一聊——不为制造噱头，而是把底层原理、部署难点、坑位和排查方法放在一起，当作一份个人复盘笔记。
1. 先捋一捋经典 Codec：那些“手工规则”到底卡在哪
1.1 经典编码器的“七件套”流程
要理解神经视频编码在做什么，得先知道传统 Codec 的路径依赖。H.264/H.265/AV1 再怎么换壳，核心骨架还是那几件事：分块、预测、变换、量化、熵编码。视频帧进来，先切成各种尺寸的块，然后做帧内预测或帧间运动补偿，得到残差；残差再做离散余弦变换，把空间能量集中到低频；接着量化丢细节，最后熵编码把符号压成比特流。
这套流程当然有效，而且极其成熟。但你注意，它从头到尾都是人在定义规则——分块要按宏块/CTU 划分，变换用 DCT 还是 DST，量化步长大致怎么分配，拉格朗日乘子怎么折中码率和失真。这些规则经过了几十年打磨，任何一步都有极致优化的查表法、快速算法和汇编指令集。它的问题不在工程实现，而在抽象层：传统 Codec 对视频内容的理解是“统计学意义上”的，它不知道画面里是足球还是人脸，也不知道观众最在意哪块细节。
举个例子，一段 1080p 的视频，画面左半边是静止的蓝天，右半边是快速运动的观众席。传统编码器照样按宏块模式扫描，按固定策略分码率。运动大的残差大，自然分到更多比特；蓝天部分只需要很少比特。听起来合理，但如果用户真正关心的是画面边缘的文字或者暗部噪声，编码器并不懂，它只会用一套固定模型猜。这就是“手工规则”的第一重卡点：规则写得再好，也覆盖不了内容的长尾情况。
1.2 传统模型的三块天花板
细说下来，传统 Codec 的天花板大致有三块。
第一块是内容相关性的浪费。同一个视频里，不同镜头、不同场景的统计特性差异很大。经典编码器当然有自适应机制，比如 rate control、lookahead、场景切换检测，但这些都是“启发式规则”。你让编码器针对同一段画面反复“琢磨”哪些比特该花、哪些不该花，它会受到实时性约束，基本做不到；或者说得直白点，编码器把画面看成信号，而不是内容。
第二块是失真度量太粗糙。绝大多数编码器优化的都是 MSE、PSNR 这类简单误差。就算加了 SSIM 或者感知量化矩阵，也只是“加权 MSE”。人眼对语义信息的敏感度极高：文字糊了、人脸轮廓崩了、物体边缘出现振铃，这些在 MSE 数值上可能只差零点几个 dB，但主观体验差距极大。神经网络擅长学“什么是看起来更舒服”，这正是传统 DCT 系数的硬伤。
第三块是演进节奏太慢。H.264 到 H.265 花了十来年，H.265 到 VVC 又花了快十年，中间还有 AV1 这样的开源阵营自己搞一套。每一代标准一落地，硬件芯片、播放器、封装格式、工具链全要跟着变。如果你想把新的编码工具组合起来做定制优化，标准本身不给你太多自由度。反而是神经 Codec 这种“算法即模型”的形态，可以在不改容器的前提下更新网络权重——这种灵活性让很多工程团队心痒。
2. 神经视频编码在做一件不同的事
2.1 从“模块拼接”到“端到端失真率优化”
传统 Codec 是把一个个模块串起来，每个模块单独优化，最后通过率失真优化把候选模式筛一遍。神经视频编码的思路则是：别分模块了，直接把“输入视频”到“输出比特流”再到“重建视频”的整个链路做成一个可微分的网络，训练目标就是最小化码率和失真的联合函数。
说得再白一点，网络结构里通常会有一个编码器网络，把当前帧或残差映射成 latent 表征；然后一个量化模块把连续值变成离散值，这步是训练中的难点，因为量化不可导，常用技巧是用噪声替代量化来近似梯度；接着一个熵编码模块估计这些离散值的概率分布，概率估计得越准，实际压缩率越接近理论极限；最后解码器网络把离散表征映射回重建图像/视频。整体优化的目标函数就是经典的率失真权衡：
loss = R + λ * DR 是估计码率，D 是重建失真，λ 控制压缩率优先还是质量优先。这跟传统编码器的率失真模型在形式上类似，但本质不同：传统编码器是在一堆离散模式里做选择，神经编码器是直接让卷积网络学习更好的变换和熵模型，把“什么样的特征应该保留”这件事交给数据去决定。
刚开始读神经压缩论文，我第一次感觉别扭的地方就是训练完之后，latent 里没有任何“DCT 系数”或“运动矢量”的概念，只有一堆高维特征。它可能在某个通道里隐式表达纹理结构，另一个通道里表达亮度边缘，但这些表达没有人工语义标签，纯粹为了压缩效率长出来的。这种“说不清楚但结果更好”的状态，其实才是端到端学习的常态。
2.2 超先验、自回归上下文与熵模型
神经 Codec 真正拉开差距的地方，除了变换编码，还有熵模型。传统熵编码中的 CABAC 依赖精心设计的上下文模型，但上下文怎么选、概率表怎么更新，都是人肉定义的。神经编码里的熵模型是另一个神经网络，可以边看边学：先用“超先验”网络提取出潜变量本身的统计结构，再用自回归方式逐块预测当前 latent 的分布。
打个比方：传统编码器就像一个用固定表心算概率的会计；神经 Codec 则边记账边学，看完前面几百个数字，大概能猜到下一个数字落在哪个区间。概率估计越精确，熵编码越接近信息论极限，省下的码率就越多。早期论文里这个“变分自编码 + 超先验”的框架，让压缩效率在图像压缩上一度比 JPEG 2000 高出一截，后来一路爬到了接近甚至超过 VVC 的水平。
视频端就更明显。帧与帧之间有时间冗余，传统方法靠运动估计和残差编码，神经方法则可以是“条件编码”——让当前帧的网络不仅看当前画面，也参考前一帧的重建结果或者运动隐表征。常见做法是预测 latent 域的残差，或者在解码端用循环网络传播信息。相当于整个 Codec 的内存和上下文都在网络权重里，学习空间比手工设计的参考帧列表大多了。
2.3 内容自适应：编码器终于能“看”视频了
我最看重的一点，是神经 Codec 具备“针对内容微调”的可能性。训练一个基础模型之后，如果某条视频内容特殊，比如全是高速运动、大量文字字幕、或者长时间静态监控画面，你可以用这条视频自身做若干轮微调。学术上管这叫“每视频过拟合”，听起来像作弊，但在工程上它可能是杀手锏——因为你的编码器终于知道“现在压的是一部游戏录像，动作块很多，但 UI 元素基本不变”，于是码率分配策略可以完全个性化。
这种能力传统 Codec 做不到，因为规则一旦写成标准，解码端就必须支持。神经 Codec 理论上可以更新权重，但这带来一个巨大的工程代价：解码端也得跟着变。就在这个点上，技术逻辑开始跟工程现实打架。
3. 把神经 Codec 摆上工程台面：真实边界
3.1 编码成本不能只看“GPU 跑得多快”
论文喜欢报省了多少码率，工程团队首先问的是跑得动吗。传统编码器对硬件极度友好：H.264 在移动端的硬解芯片几乎零功耗，编码器也有大量 ASIC 加速。神经 Codec 首先是神经网络推理，通常得跑在 GPU 或 NPU 上；要拿到最好质量，甚至需要反复迭代 latent 做率失真优化，一次编码可能要在 GPU 上推理几十遍。
这还不是最麻烦的。麻烦的是“复杂度不确定性”。传统编码器虽然计算量大，但每个模块的计算量相对可预估，视频服务器可以按帧估算 CPU/GPU 占用。神经网络模型的浮点计算量是固定的，可一旦加入内容自适应微调，不同片段需要迭代的次数天差地别。运营一台大规模转码集群，你不可能让每个任务都“看心情”消耗算力。我实际观察到的妥协方案是：只在高价值内容（比如头部影视剧、云游戏录制流）上跑完整神经编码，其余长尾内容维持传统编码。
3.2 解码端并行、随机访问与容错问题
工程里真正的硬骨头其实是解码端。视频播放器要能做到随机访问，你拖进度条得快速跳到关键帧附近；要支持并行解码，你得有清晰的参考帧依赖关系；要容忍网络丢包，还得保证一帧损坏不无限传播误差。传统编码器的 I 帧、P 帧、B 帧结构，配合参考帧管理机制，把这些问题控制得很好。
神经视频编码目前很多方案是自回归式的逐块解码，意思是解码某一位置必须依赖同一帧的“previous块”的预测结果。这天然是序列解码，并行度极低。随机访问要么频繁插入帧内编码的参照帧，而参照帧又牺牲大量码率；要么把参考帧缓存做成关键帧结构，但模型复杂度随之上升。更别说丢包或者比特流出现一个错误位，神经网络解码器可能直接把画面重建得一团糟，而且这个错误会顺着时序污染后续帧。传统解码器也有错误蔓延，但工程上已经积累了几十年错误掩盖手段，神经 Codec 在这方面几乎是空白。
所以每当我看到论文里 PSNR 曲线拉满，都会下意识问一句：有没有做随机访问测试？有没有模拟丢包？有没有考虑不同 GPU 型号之间的浮点一致性？这些不是算法问题，却是让算法活下来的条件。
3.3 混合形态：先别急着替代，更要学会“插进去”
纯神经视频编码要一步到位替换 H.265/VVC，我目前持保留态度。真正务实的产品路径是混合形态：传统 Codec 依旧负责主干编码，神经模块则在几个特定环节发光发热。
我见到的落地方向有几种。第一种是神经增强后端：用传统编码器压一个略高码率的版本，解码后再用超分辨率或去压缩伪影网络做后处理，等效于在相同存储/带宽条件下获得更高主观质量。第二种是区域自适应编码：先用视觉模型识别画面中的语义区域，再把这些区域信息喂给传统编码器的码率分配决策，让面部区域分更多码率，背景分更少。第三种是神经滤波：在传统编码器的环路里加入 CNN 滤波，替代或者叠加原有的去块滤波、样品自适应偏移，VVC 已经在参考软件里试过基于神经网络的环路滤波并大幅改善主观质量。
这几种方式的共同点是：神经网络只在局部替代某些模块，不需要颠覆整个码流结构。回报高、风险低，我是相当看好这类混合路线的。它赌的不是“明年就能全链路替换”，而是“在现有硬件生态里一点点把压缩效率薅出来”。
| 对比维度 | 传统 Codec | 纯神经 Codec | 混合形态 |
|---|---|---|---|
| 编码端硬件 | CPU/ASIC，生态成熟 | GPU/NPU，成本高 | GPU 辅助，主力仍传统 |
| 解码端分布 | 几乎所有设备支持 | 尚无统一标准，部署困难 | 普通设备原生支持 |
| 压缩率潜力 | 已接近天花板 | 公开实验常有明显收益 | 提升有限但稳定 |
| 随机访问/容错 | 成熟工具链 | 并行访问难，容错差 | 继承传统框架 |
| 定制化能力 | 规则僵化，难针对内容微调 | 可以针对内容微调 | 可做局部内容感知 |
3.4 部署时要给自己留的后路
我建议所有想试神经 Codec 的团队都按这个顺序走：先离线单机验证质量，再跑一批真实业务数据做主观评测，最后才是架构改造。不可直接拿论文里公开数据集的 BD-Rate 数值推导业务成本账，因为公开测试集和你的内容分布完全不同。另外一定要明确“质量”指标：是追求 PSNR，还是关注文字边缘、动画色带、皮肤纹理。传统编码器和神经 Codec 在这些细项上的得分常常不一致，有的神经模型 PSNR 高但文字糊，有的主观很讨喜但指标一般。你选错了优化目标，上线后用户就会用脚投票。
4. 别让“Codec”这个词在字节层面坑了你
4.1 一个真实翻车现场：GBK 下的 Unicode 编码错误
聊完算法边界，我插一段跟“Codec”本身相关的野史。搜神经视频编码资料时，很多人会顺手搜到一个完全不相关的报错：
UnicodeEncodeError: 'gbk' codec can't encode character '\ue687' in position 0: illegal multibyte sequence这其实是 Python 在 Windows 中文环境下跑脚本时的经典问题。默认编码是 GBK，而字符串里出现了 GBK 无法表示的字符。为什么会跟视频编码扯上关系？因为现在的视频处理脚本越来越依赖神经网络模型输出字段，比如模型跑完自动生成带特殊符号的文件名、字幕轨道里包含冷僻字或特殊字符、日志里写入 emoji 作为分级标记。Windows 下 Python 的文件写入操作默认使用区域编码，一遇到特殊字符就爆雷。
拿我自己踩过的例子来说：当时在批量渲染一批带水印的测试视频，每转完一条就追加一行结果到report.txt，里面包含一个用特殊 Unicode 字符表示质量等级的标记。在中心化 Linux 服务器上跑没问题，挪到本机 Windows 复现时，第一条就报gbk codec can't encode。原因就是open()没指定编码，Python 在 Windows 上默认走了 GBK。
修法非常简单，文件写入时显式指定encoding="utf-8"，同时把读取也设为 UTF-8：
with open("report.txt", "w", encoding="utf-8") as f: f.write(frame_info + quality_mark + "\n")如果是批量脚本，最好在项目入口统一设置环境变量：
set PYTHONUTF8=1或者写代码时直接改默认编码策略，用sys.stdout.reconfigure(encoding="utf-8")把标准输出也切过去。这类问题不大，但常常在交付脚本时成为“最后一公里”的拦路虎，尤其是跨平台跑视频预处理流水线的同学，一定要记得这一步。
4.2 字幕、日志和文件名：视频工程里的字符契约
神经视频编码因为要处理的内容更杂，输入输出端的字符问题会被放大。我归纳成三类：一是日志文件，用于记录各帧码率、失真和耗时统计；二是字幕轨或元数据，里面可能出现各种语言的 Unicode 字符；三是由模型推理结果拼接出来的输出文件名。三者都建议统一使用 UTF-8 编码，而不要依赖运行环境的默认值。
另外还要注意控制台显示问题。很多人在 Windows 终端跑 FFmpeg 或者 Python，看到输出乱码，第一反应是“编码坏了”，其实更常见是终端代码页不对。把代码页切到 UTF-8 通常能解决，但如果你只是跑脚本、不依赖终端输出，代码层面强制 UTF-8 才是更稳的方案。这里也顺便回应一下不少新手搜过的问题：“Codec 语言程序怎么运行”——其实很多人问的是怎么让 IDE 里的 C/C++ 或者 Python 程序在特定语言环境下正常运行。这个问题核心不是编译器，而是运行时区的字符编码和终端显示设置；把源码文件、编译选项、运行终端的编码统一起来，绝大多数“程序跑起来乱码”的困惑都会消失。
5. 自己动手：把神经视频编码拉起来跑一遍
5.1 最小运行路径：先从图像压缩热身
如果你之前只接触过 FFmpeg，建议不要直接挑战视频模型，先跑图像压缩更容易建立手感。CompressAI这类库把一堆论文模型封装好了，安装后就能在测试图片上比较不同模型的效果。基本路径是：准备一批 PNG 图片、加载预训练权重、设置不同质量级别参数、输出码流和重建图、计算 PSNR 和 MS-SSIM。
跑通图像后，再去看视频模型。视频神经 Codec 的参考实现往往内存占用惊人。我的经验是先从低分辨率试起，比如 256x256 或者 512x512 的短视频段，固定帧数，观察每帧编码耗时和显存峰值。不要一上来就整 1080p 长视频，模型不一定崩，但你的耐心一定崩。
5.2 指标对比别只看一个数
评估神经 Codec 时，业内常用 BD-Rate，意思是同等质量下码率节省百分比。注意，这个指标是经过拟合曲线算出来的，至少需要 4 到 8 个不同码率点的数据，不能只拿一个点说“省了 30%”。另外要区分 PSNR 和主观质量：我见过某模型在 PSNR 上领先 VVC 不少，但实际播放时轻微纹理被抹平，人脸皮肤显得像塑料。最后要测不同分辨率下的表现，很多神经模型对训练分辨率高度敏感，换到 4K 直接效果崩掉。
建议记录一个表格，包含模型名、训练分辨率、测试分辨率、码率、PSNR、MS-SSIM、编码耗时、显存占用。一次对比跑下来，哪些模型能进生产线，心里基本有数。比只看论文曲线靠谱得多。
5.3 实践中容易踩的几个坑
第一个坑是量化感知训练。很多开源实现没有做严格的量化代理，模型在浮点推理时性能不错，一旦真按整数量化压缩码流，质量掉得很快。解决办法是选择带量化感知训练的模型，或者自己把量化噪声模拟加进验证流程。
第二个坑是帧间累积误差。视频模型如果参考前一帧重建结果，训练时没做 long-term 推理，推理时间一长就容易漂移。表现就是前几十帧质量很好，后面慢慢变糊、颜色偏移。跑测试时一定要压一个几百帧的片段看后段，不能只看前几帧。
第三个坑是算力评估错误。很多模型为了刷指标，在编码端做了十几次迭代优化，部署时你才发现实际编码时间远超预算。我的建议是换一个思路：先确定你能接受的最大编码耗时，再倒推哪些模型方案可行。不要先看质量再考虑能不能跑。
6. 最后补几句实在话
神经视频编码目前处在“学术价值已经证明，工程价值还要再挤一挤水分”的阶段。我个人在实际接触中最大的体会是：不要指望某个模型能一步登天替换全链路，而是要把精力放在跟现有工具链的衔接上。找到合适的混合点，比如增强滤波、区域码率分配、离线转码场景，神经 Codec 的收益是立竿见影的。
另外一个小技巧：所有跑神经编码的实验脚本，统一在代码里强制 UTF-8 读写，跨 Linux 和 Windows 平台都能省去一堆烦心事。也不要忽略数据集的字符过滤，尤其是用模型自动生成输出文件名时，提前把特殊 Unicode 字符白名单化，后面排查问题会轻松很多。
这个领域的变化非常快，今天的最优模型可能半年后就进不了前三名。但有一点我觉得是确定的：传统 Codec 的“手工规则”不是被推翻，而是会越来越多地跟神经网络共存。谁更早掌握这套共存的语言，谁就能在下一次视频基础设施升级中占到先手。
