2026年7月24日，微软在其 Linux and Open Source 博客上宣布，将 ML Video Codec（MLVC）开源。代码托管在 github.com/microsoft/mlvc，采用 MIT 许可证，同时提供训练好的权重、训练脚本，以及面向不同 NPU 的转换工具。
支撑这次发布的论文 MLVC: Multi-platform Learned Video Codec for Real-World Deployment 于一个月前发表在 arXiv 上。
这不是在实验室 GPU 上跑过一次的研究演示。MLVC 是微软研究院自 2021 年起持续发表的 DCVC 系列的产品化版本，微软表示它已经在 Microsoft Teams 的点对点通话中逐步上线，配有线上遥测和 A/B 测试，并在硬件或网络跟不上时回退到传统编解码器。
这个宣传数字大到值得认真核实一遍，本文做的正是这件事：这些数字本身、它们实际测量的是什么、仓库里究竟有什么，以及这一切今年会不会触及流媒体链路。
如果你想先看简短版本，我们在流媒体词汇表中维护了一条关于 什么是 MLVC 的简明定义。
官方公布的数字
微软自己给出的对比，在主观画质相当的前提下：
| 分辨率 | 相对 H.264 节省的码率 | 相对 H.265 节省的码率 |
|---|---|---|
| 360p | 87.8% | 75.5% |
| 540p | 82.7% | 65.4% |
换成具体说法更好记：一路 360p、30 fps 的通话，用 H.264 需要 1 Mbps，用 MLVC 大约只需 122 kbps。差不多是八分之一的比特量，实时完成，跑在笔记本的 NPU 上。
接下来是附加条件，这部分相当关键。
这是人打的分，不是 PSNR
这些百分比基于 MOS，来自由真人观看者为片段打分的 ITU-T P.910 主观测试。素材是微软同样自建并开源的 Video Conferencing Dataset。也就是说，这是摄像头前的人物画面，360p 和 540p，靠肉眼判断的结果。
如果改用 PSNR，在论文更广的测试集上测量同一个编解码器，BD-rate 收益会落到 52% 附近。仍然是很大的数字，但不是 87.8%。
参照系是市面上最弱的 H.265
比较对象是 Intel Quick Sync 上的硬件 H.265，而不是用慢速预设精细调校过的 x265。受会议延迟约束的硬件编码器，代表的是 H.265 能力的下限，而非上限。
此外，论文中没有任何与 AV1 或 VVC 的对比。作者解释了原因：VTM 和 ECM 没有量产硬件实现，因此没有可以在实时条件下比较的对象，故予以排除。作为研究决定说得过去，但这也意味着还没有人把 MLVC 与现代 AV1 编码器放在一起展示过。
真正的成就是确定性，而非压缩率
这部分被码率数字盖住了，但从工程角度看更有意思。
在编码效率上，神经网络编解码器已经领先传统编解码器有一段时间了。它们之所以无法部署，是因为无法在与编码端不同的机器上可靠地解码。
熵编码要求编码器和解码器计算出完全一致的概率。把同一个网络分别跑在 Apple Neural Engine 和 Qualcomm Hexagon 上，浮点结果并不会一致：编译器选择的算子内核不同，算子融合方式不同，舍入方式也不同。于是码流会解码成一堆乱码。
论文给出了具体数字。不加约束的 DCVC-RT，在编码器与解码器位于同一平台时，BD-rate 改善约 69.6%。跨平台时，它的 BD-rate 是无穷大，这是"视频根本解不出来"的委婉说法。
他们是怎么解决的
MLVC 不再指望两端碰巧算出一样的结果。它通过 hyperprior 显式传输熵模型的尺度参数，让两端从码流中读取同一组数值，而不是各自计算。
围绕这一点，团队还移除了其他所有会产生分歧的因素。特殊激活函数被去掉，改用带 ReGLU 门控的 ReLU 和 LeakyReLU。INT8 量化被直接否决，因为 INT8 卷积在不同厂商之间不可复现，而较旧的苹果芯片本来就是用 FP16 模拟它的。整个模型以 FP16 运行。
这种克制是要付出实际压缩性能代价的。以感知目标训练的 DCVC-RT 能达到 81.9%，而 MLVC 是 75.5%。微软让出了约六个百分点的 BD-rate，换来一个能在自己并不拥有的硬件上解码的编解码器。
对任何真正把视频推上线过的人来说，这显然是划算的交换，而这也是学习型编解码器第一次做成这笔交换。
仓库里究竟有什么
值得直接去看一眼，因为仓库讲的故事和公告稍有出入。
仓库创建于 2026 年 1 月 28 日，此后六个月里除了一份许可证、一个 README 雏形和微软标准的治理文件之外别无他物。真正的代码是 7 月 22 日以一次名为 "Hello MLVC" 的提交进来的，推送者是论文第一作者 Tanel Pärnamaa。截至撰稿时，仓库共有 8 次提交、189 个星标、10 个复刻，且没有任何打了标签的发行版。
所以这是一次性投放的代码，而不是在公开场合开发出来的项目。这不是批评，只是应有的预期。四个未关闭的 issue 全部是针对 transformers、jupyterlab 和 cryptography 的 Dependabot 更新。迄今唯一被合入的外部贡献，是一行修复：在 EntropyCoder.h 中加入 #include <cstdint>，好让 C++ 熵编码器能在 GCC 13 及更新的 Clang 上构建。虽小，却是个好迹象：微软之外的人在几天内就尝试编译，而微软合入了这个补丁。
你能得到什么
- 四个检查点。1830 万参数的完整 MLVC 和 540 万参数的轻量版 MLVC-S，各自提供 PSNR 优化版和感知优化版。感知版使用 LPIPS 和人脸分割掩膜训练，这直接说明了它们是为什么场景打造的。
- 完整的训练流水线。涵盖图像模型和视频模型，通过 YAML 配置驱动。微软还记录了训练数据的采集方式，这一点比多数开源发布做得更多。
- 导出工具。可在固定输入尺寸下把模型转换为面向苹果的 CoreML、面向 Intel 与 OpenVINO 的 ONNX，以及面向高通的 QNN。支持的运行时包括 CPU 与 GPU 上的 ONNX Runtime、ONNX Runtime QNN、OpenVINO 和 Windows ML。
- C++ 实现的 rANS 熵编码器。位于
packages/msrtc_rans，附带 Python 绑定，另有可计算 BD-rate、MS-SSIM、LPIPS、VIF 和 DeQA 的基准测试工具。
你得不到的是一个可以链接进应用的 C++ 编解码器库。微软表示会在后续版本中提供。目前可用的接口是 Python，安装需要 Python 3.12 或 3.13 以及 uv。
帧率实际落在什么水平
速度才是这件事有意思的原因，所以分辨率阶梯很重要。论文给出的编码吞吐如下：
| 分辨率 | MLVC，Apple M3 Pro | MLVC，三家厂商均值 | MLVC-S，Apple M3 Pro |
|---|---|---|---|
| 360p | 129.5 fps | 103 fps | 未公布 |
| 540p | 65.7 fps | 49 fps | 未公布 |
| 720p | 33.8 fps | 未公布 | 83.8 fps |
| 1080p | 15.6 fps | 未公布 | 39.5 fps |
各档位上，解码都比编码慢几帧每秒。在 Intel Lunar Lake 上，1080p 的数字是 10.5 fps；受测的三家厂商分别是苹果 M3 与 M4、Intel Lunar Lake 和高通骁龙 X Elite。
如实总结：真正可交付的是三家厂商上的 540p 30 fps，且 NPU 占用不到一半。实时 1080p 只在精简模型上、只在苹果平台上、只在单向条件下成立。论文还指出，在单台设备上同时进行 1080p 及以上的编码与解码仍是难题，而双向通话需要的恰恰就是这个。
微软的路线图也照此推进：先稳定 540p 并改善抗丢包能力，再做 1080p 和更广泛的流媒体场景。
为什么还不能把它放进流媒体码率阶梯
在流媒体领域，决定一个编解码器命运的从来不是压缩效率，而是解码器。
我们专门写过一篇文章，讲 HEVC 为何没能成为它被许诺的那个未来，原因在于授权与设备支持，而不是编码工具。AV1 也是在 手机开始内置硬件解码器之后，才对实际部署产生意义。
格式就是权重本身
MLVC 面对的是这个问题更严苛的版本。不存在 MLVC 码流标准，因为训练好的权重就是格式。一路码流只能被持有编码时那个完全相同的模型、并且运行得足够接近以复现其算术的设备解出来。
没有一致性码流，没有 MIME 类型。没有封装方案，没有 DRM 方案，智能电视、机顶盒和浏览器里也没有任何东西能播放它。你的 CDN 可以把它送出去，而另一端没有任何东西能打开它。
那些内容不是你的内容
亮眼的数字来自低分辨率的静态人头画面，模型还借助人脸 ROI 掩膜在人脸上训练过。体育、胶片颗粒、快速摇镜和大幅运动，恰恰是传统编解码器靠启发式规则挣回身价的场景，而论文对此并未作出任何主张。
论文甚至量化了一个弱点：长期参考机制在剧烈场景切换时会让 BD-rate 损失约 2 个百分点，需要在部署阶段用镜头切换检测来缓解。而一部电影，大部分就是场景切换。
而且没人测过功耗
这是论文自己在结尾列出的局限。作者写道，实时性已经解决，因此功耗是下一个战场。在电池供电的设备上，为一部两小时电影的每一帧都在 NPU 上跑一次神经网络，和一个已经优化了十年的固定功能解码器完全不是一回事。
今天它在哪些场景说得通
凡是两端都是你自己掌控的计算机，且瓶颈在网络而非芯片的地方。
首先是视频会议，这也是 Teams 成为首发载体的原因。其次是上行链路较差的回传、远程制作、无人机、机器人和监控链路，以及云游戏或远程渲染。微软在公告中明确就上述所有方向征求协助，与流媒体和点播并列，同时也欢迎扩大 NPU 覆盖面的平台移植。
如果你正在现代硬件上做实时点对点的东西，现在就值得花一个下午。如果你在运营 OTT 服务，那还不到时候。
编解码器从业者真正该警惕的地方
不是那 75%，而是斜率。
微软声称，MLVC 的编码效率会随模型容量和训练算力一起提升，正如过去几年其他所有机器学习系统那样。
传统编解码器每一代大约提升 30% 到 50%，而一代需要将近十年的标准化工作，随后是数年等待硬件普及，再随后是围绕专利池的争论。如果一个学习型编解码器每次投入更多算力就会继续变好，而且跑在本来就无处不在的 NPU 上，那么这场竞争的形态就变了。
它采用 MIT 许可证，悄然移除了当年拖垮 HEVC 的另一个因素。而且它可以退化成一个普通的工程问题：你发布一个模型版本，像协商编解码器那样协商它，对端跑不动就回退。
这些今年都不会发生。从"在我的 M3 上能跑 540p"到"能在某人客厅那台五年前的电视上播放"，这中间的距离，是每一个编解码器都花了十五年才走完的距离。不过，压缩技术上一次有趣到值得读一篇论文，已经是挺久以前的事了，而这一篇值得花上一个小时。
那该怎么办
你的编码阶梯不需要任何改动。继续用 H.264 覆盖广泛设备，在设备支持的地方上 HEVC 和 AV1，等到下面三件事发生时再重新评估：
- 完整模型上的实时 1080p，而不只是苹果平台上的 MLVC-S。
- 一个真正能链接进产品的 C++ 库。
- 微软自家产品之外出现任何解码器。
有兴趣的话可以把仓库克隆下来，因为无论你将来是否会推出神经网络编解码器，它的训练流水线和跨平台分析都很有启发。关于 INT8 量化为何会在不同厂商间产生分歧的那份附录，把一个通常需要长篇解释的问题写得相当凝练。
常见问题
MLVC 可以免费使用吗？
可以。微软以 MIT 许可证发布，涵盖模型源码、训练好的权重和训练脚本。它不附带专利池，这是与 HEVC 的一个重要区别。
我能把 MLVC 推流到智能电视或浏览器吗？
不能。解码需要一台能运行该神经网络的设备，并且要有与编码时完全相同的模型。目前没有任何电视、机顶盒、手机或浏览器带有 MLVC 解码器，也不存在可供它们实现的码流标准。
MLVC 实际能省多少带宽？
微软给出的数据是：在 360p 下，相比 H.264 码率降低 87.8%，相比硬件 H.265 降低 75.5%，依据是 ITU-T P.910 下真人观看者的评分。若在更广的测试集上以 PSNR 衡量，节省幅度接近 52%。两个数字都是在视频会议内容上与硬件编码器的对比。
MLVC 需要什么硬件？
需要 NPU。微软测试了 M3 与 M4 上的 Apple Neural Engine、Intel Lunar Lake 和高通骁龙 X Elite，并称在三者上都实现了实时 540p 30 fps，且 NPU 占用不到一半。
MLVC 比 AV1 更好吗？
没有人公布过这个对比。论文只与 H.264 和 H.265 做了测量，排除了 AV1、VVC 和 ECM，理由是它们没有可在实时条件下比较的量产硬件实现。
MLVC 和 DCVC 有什么区别？
DCVC 是微软研究院自 2021 年起发表的神经网络编解码器系列。MLVC 是其产品化版本，以大约六个百分点的压缩效率，换来在不同厂商 NPU 上可靠解码的能力。
需要帮忙判断这对你的技术栈意味着什么吗？
编解码器一旦选错代价高昂，而且大部分成本要到几年后才在设备支持和授权上显现，而不是体现在码率上。我们的流媒体与广播专家大规模落地过编解码器、编码阶梯和分发链路，你可以就自己真正面临的问题直接向他们提出。