视频编解码标准体系全解析：从H.26x到AV1的提案实战指南

视频编解码标准体系这个词，听起来像是一堆躺在官网上的技术文档，实际上它是所有编码器、播放器、芯片和云端转码服务共同默认的那条暗线。我在音视频标准化组织里泡了几年，从最初只顾着跑运动搜索算法，到后来真正参与提案、审阅文本、做交叉验证，最大的感受是：这个领域没有任何一蹴而就的成果，所有的变化都是靠一轮又一轮的坚持堆出来的。今天我想把这些年摸出来的门道完整写下来，包括标准体系之间的差异、一个提案从出生到转正的完整流程，以及那些只会出现在会议间隙里的隐性规则。

下面按我实际做事的逻辑来展开。如果你是做编码器落地、视频云转码、硬件IP设计，或者正打算参与标准讨论，这篇应该能帮你省掉不少弯路。

1. 先看清家底：国际体系、开放联盟与本土序列各司其职

很多人把"国内外视频编解码标准体系"理解成一条垂直的时间线，觉得国际标准就是 H.264 到 H.265 再到 H.266，每过几年换一个大版本，国内标准跟在后面慢慢追。这么理解不算错，但会漏掉很大一块拼图。实际上的情况是几条线并行，各自有各自的节奏、侧重点和生态，它们共同构成了今天音视频领域的编码规则。

1.1 国际 H.26x 体系的十年一轮回

国际上的 H.264/H.265/H.266 这代标准，表面上给人的感觉是"每代只提升百分之五十的压缩率，为何要等这么久"。真参与进去才发现，大版本之间的沉寂期，内部从来没有安静过。

H.264 标准解决的核心问题，是从标清到高清时代对压缩效率和网络适应性的双重要求。它引入了多参考帧、CABAC 熵编码、去块滤波这些结构性的变化，至今仍是视频分发领域最常见的编码格式。H.265 标准则把目标对准了 4K 分辨率，编码树单元从小块的宏块升级成更大的 CTU 结构，帧内预测方向从 33 种扩充到 65 种，还加上了 SAO 样点自适应补偿。再到 H.266 这一代，重点转向 4K/8K、高动态范围、屏幕内容混编这些更复杂的场景，编码树划分变得更灵活，帧间预测也引入了仿射运动补偿、解码端运动修正等一大批新工具。

大版本之间拖上近十年，不是因为大家不努力，而是因为新一代标准要把前一代所有已知的短板都翻出来重新论证一遍。每一次工具改动都要经过提案、验证、回退、再提案的过程，时间就是这么花掉的。

1.2 开放联盟与本土序列并不只是"追赶者"

如果只看国际体系，会漏掉另外两股力量。一股是以 AV1 为代表的行业开放体系，它的参考实现完全开源，主要围绕互联网视频分发、浏览器播放和硬件加速场景推进，迭代速度比传统标准更快，也更贴近流媒体的真实分发链路。另一股是国内长期推进的本土标准序列，从早期面向数字电视应用的 AVS1，到面向超高清的 AVS2，再到近些年面向 8K/UHD 场景的 AVS3，工具框架同样是预测、变换、量化、熵编码和环路滤波这套混合编码架构，但在具体的工具取舍上有自己的侧重。

这里我不想去比较"谁比谁强"这种容易带偏的话题。真正参与过双线工作以后，我的体会是：不同体系之间的技术边界越来越模糊，大家互相参考已经是常态。比如本土标准在设计滤波器时，会仔细研究国际标准里 ALF 自适应环路滤波的增益来源；而国际标准在讨论屏幕内容编码工具时，也会借鉴其他体系在这类内容上的实测数据。标准演进不是赛跑，而是共同解决越来越复杂的视频场景问题。

1.3 标准能活下来，靠的不是文本而是生态

我见过一些技术上相当漂亮的标准文本，最终没有形成主流生态，原因不在编码效率，而是配套没跟上。一个标准真正活下来，需要的东西非常多：好用的编码器实现、广泛支持的解码器、封装格式的衔接、硬件 IP 的适配、测试向量的齐备、开源社区的维护。

这也是为什么标准化组织的工作绝不只是写文档。每一条语法规则背后，都要考虑到"别人能不能低成本实现""解码器会不会因为一个异常比特流失控""老设备是否要永远兼容"。很多技术讨论到最后，其实都是在为生态维护做妥协。

2. 一个编码提案从出生到转正，要闯过的关卡比想象中多

外面的人看标准化工作，总觉得是"开会、举手、投票"三件事。实际上一个技术提案从产生想法到写进标准文本，中间要经历非常完整的研发流程，而且每个环节都有明确的准入门槛。

2.1 起点是跟 Anchor 对齐：没有基线就别谈增益

每一代标准都会维护一个官方测试模型软件，记录当前已经被接受的所有工具。提案方要做的事情，是在这个模型的基础上加入自己的新工具，然后跟没有该工具的版本做对比。那个对比版本就是 Anchor。

刚开始参会时，我犯过一个典型错误：自己搭了一套自定义配置，跑出漂亮的数据就去投稿，结果被评审老师一句"测试条件不符合通用测试条件"直接打了回来。后来才明白，标准化组织的实验讲究的是可复现、可比对，所有提案都要在规定的测试序列上按规定的码率点、分辨率档位和编码配置跑。帧内配置、随机接入配置、低延迟配置，每一类都要覆盖，不能挑对自己有利的序列报数字。

这也是为什么老手拿到一份提案文档，先不看结论，先看实验条件。如果条件不干净，后面所有的 BD-Rate 数字都失去意义。

2.2 客观指标好看，还得过主观评测这一关

编码算法领域最常见的客观指标是 BD-Rate，它综合多个码率点计算平均码率节省。比如某提案声称 BD-Rate 下降 3%，意思是同等主观质量下码率平均节省了 3%。但客观指标再好，最终视频是给人看的，所以还要做主观评测。

我印象很深的一次讨论，是某个滤波器提案。客观指标非常亮眼，BD-Rate 节省超过百分之五，但拿到主观评测序列上一看，运动场景的边缘出现了明显的振铃和线条抖动。原因是这个滤波器过度依赖高频细节的锐化，在纯客观指标上拿分，却放大了人眼最敏感的运动边缘瑕疵。这个提案最后被主观测试组打了低分，只能回炉重造。

主观评测的方法也很讲究。常见的是成对比较法，让受试者在两个版本之间选一个更舒服的，而不是让他们打分；还有一种方法是给一段参考视频和多个候选版本，请受试者给出相对质量的评分。整个过程需要严格控制屏幕环境、观看距离、受试者人数，任何环节不规范都可能让数据作废。

提示：如果你的提案准备冲击标准，建议在提交文档之前自己先做一轮小规模主观测试。实验室里请五到八个同事，多看几段动态复杂的序列，往往能提前发现客观指标掩盖的问题。

2.3 交叉检查之后，真正的博弈在复杂度分析

提案过了客观和主观验证还不够，接下来是有名的一道关卡：交叉检查。提案方把实验配置完整公开，另一方或者独立第三方重新跑一遍，确认数据能复现。这个环节最能看出一个团队是否靠谱，因为很多实验在原始团队手里能跑出好结果，换一个环境就衰减甚至失效。交叉检查不通过，哪怕数据再好看，大概率也被搁置。

即便通过了验证，会议现场讨论的焦点也往往不是指标，而是复杂度。一个工具省了 2% 码率，但解码端要多占多少内存带宽？硬件实现要多加多少个处理单元？对低时延场景有没有影响？这些问题才是参会者真正关心的。

有一次，一个基于神经网络的滤波方案在指标上把传统滤波器压得很惨，正当提案人讲得兴致勃勃时，硬件实现团队的人问了一句："这个工具在 4K 解码时会让内存带宽增加多少？"提案方当场答不上来。结果大家很快达成共识：先挂起，等复杂度分析补齐后再议。这个场景我后来见过很多次，标准组织里的"裁判"其实一直没说出口的话是：每一项收益都要用成本来衡量。

提案从投稿到转正，大致会经过这样几个关卡：统一测试条件下的 Anchor 对比、主客观双重验证、独立交叉检查、复杂度与硬件实现成本评估、文本精读与语法定稿、最终投票。每一步都有人反对，每一步都需要用数据说话。

3. 编码效率之外的三个隐性战场：并行、语法留白与一致性

如果说提案机制解决的是"效率提升多少"的问题，那下面这三个战场解决的是"标准能不能被所有人用起来"的问题。很多刚入行的人只看 BD-Rate，但标准文本里动辄几十页的内容，恰恰是在这些不显眼的地方反复打磨。

3.1 解码并行与硬件友好性经常决定工具的生死

软件编码器里新增一个工具，可能只是多写几十行分支判断；到了硬件解码器里，同样的功能可能意味着多一组流水线、多一片存储、多几个周期的时序收敛。因此标准设计从一开始就要考虑并行度。

比如一个功能设计成整帧处理，在软件里没问题，在硬件 4K 解码时却会制造巨大的延迟。所以现代标准普遍支持把画面划分为多个片区域、多个瓦片，或者采用波前并行处理，让多核和多流水线可以同时干活。提案在引入新工具时，如果破坏了这些并行边界，哪怕压缩增益可观，也很难被接纳。

我自己的经验是，在看一份提案文档时，先问三个问题：这个工具是在解码端操作还是编码端操作？它是否需要保留整帧信息？它会不会打破现有的并行处理单位？只要有一个答案是"需要整帧信息"，提案的推进难度就会成倍上升。这些看似工程化的细节，在标准化讨论里拥有很高的话语权。

3.2 语法设计要做减法，因为标准几乎没有回头路

标准文本一旦发布，解码器就要永久支持里面的每一条语法。哪怕后来发现某个语法元素没有用、甚至带来安全隐患，也无法轻易删除，只能通过新版本打补丁。所以语法设计的原则是：能不加就不加，加上的每一个标志位都要有明确的收益。

听起来是常识，做起来很难。因为在会议讨论时，每个工具都要配套若干控制开关，每加一个开关就要多一组语法比特。这些开关在提案阶段看起来都很有用，但真到集成阶段，验证成本会成倍增加。我参与过几次审稿，最花时间的不是讨论新工具本身，而是讨论哪些冗余条件可以清理。

新一代标准普遍引入档次、级别、约束标志这类机制，本质上就是为了"留白"。通过一套受控的扩展机制，把不确定的未来需求挡在正式语法之外。这让我想起一句行话：真正成熟的标准，往往不是堆工具堆出来的，而是敢在工具过剩的时候砍掉一半。

3.3 参考软件与一致性测试是标准的质检线

没有参考软件的一纸标准，就像没有配套图纸的建筑设计图，很难落地。标准化组织在推进过程中会同步维护官方测试模型软件，每一次会议后更新一版，记录所有被接受工具的实现细节。这份软件既是后续提案的基线，也是新工具有没有按预期工作的试金石。

更关键的是解码一致性测试。标准里很多环节对解码器行为作了严格约束，有些甚至要求在无损配置下解码输出和参考解码器逐位一致。这个要求听起来苛刻，但正是所有厂家设备能互相播放同一路流的保证。否则，A 厂的播放器解码出来画面正常，B 厂的芯片解码出来颜色偏了一点，整个生态就乱了。

注意：跑一致性测试并不只是跑官方那几条测试序列。真正有价值的测试，是从真实世界中收集极端比特流，比如异常帧率、超大运动矢量、混合屏幕内容。很多解码器的问题都出在"标准测试都过了，一跑真实内容就崩"。

4. 在标准化组织里，比编码能力更值钱的是这三样本事

技术能力强的人，在标准化组织里一抓一大把。真正让一个人说的话有分量、提的案能落地的，往往是技术之外的软实力。我自己也是从技术思维转向标准化思维之后，才慢慢摸清这个门道。

4.1 提案文档是写给反对你的人看的

写技术报告和写标准提案是两回事。技术报告只要把结果讲清楚就行，标准提案从一开始就要预想到谁会反对这件事，然后把可能导致反对的问题提前回答掉。

一份成熟的提案文档，通常按这个结构组织：先定义问题的范围，说明当前标准在这个场景下有什么不足；再交代实验条件，告诉别人你的结果在什么前提下成立；随后给出主客观数据和复杂度分析，把编码端、解码端、内存、带宽的影响分别列出来；最后给出明确的文本修改建议，让审阅者知道如果同意，改动会落在哪个章节哪个表格。

我见过不少方案，技术上很出彩，但因为文档里没有复杂度分析，现场讨论时直接被问穿帮。也见过相反的情况，一个两三个点的工具收益其实很小，但因为文档写得滴水不漏，很快就得到了共识。在标准化组织里，表达能力就是生产力。

4.2 会前沟通往往比台上一小时更重要

正式的大会讨论时间非常有限，几十个提案排队，每个提案可能只有十几分钟汇报。如果提案方把所有希望寄托在台上的十几分钟，基本等于裸奔。真正有效的做法是在会前把文档发给相关团队的核心成员，约几个单独的小范围讨论，听一听他们的疑问和预期，提前消化掉最尖锐的问题。

早期我不太理解为什么前辈们那么看重茶歇和晚餐时间，总觉得那是社交，不如回酒店写代码。后来才意识到，那些看似随意的走廊对话，往往才是信息交换最充分的时候。标准这种技术共同体的决策逻辑，决定了很多态度不会放在正式会议上公开表达，而是通过私下沟通逐步收敛。会前把反对意见摸清楚，会上才能真正推动议题往前走。

需要注意，这里的沟通指的是技术层面的预沟通，不是请客吃饭拉关系。大家最终看重的还是你的数据是否经得起推敲、你承诺的验证是否靠谱。会前把功课做到位，本质上也是在帮对方节省决策成本。

4.3 新人最容易打开局面的，是小而有用的议题

如果你刚进入标准化工作，我强烈建议不要一上来就去挑战思想性问题。比如重构块划分结构、推翻熵编码框架这类大改，几乎不可能由新人提案推动，因为需要的基础验证和信任都还不够。最聪明的做法是找一个边界清晰、收益明确、改造范围限于某个模块的小议题。

比如调整某个候选列表的长度、改进某个语法元素的初始值、为某种特殊内容补充一个跳过模式。这类提案看起来不起眼，但风险小、容易快速形成共识，是最适合建立信誉的入口。我见过很多后来成为核心贡献者的人，起初都是从整理测试序列、维护交叉验证脚本开始的，慢慢积累起别人对你"实验做得严谨"的信任，再逐步参与更大议题。

5. 把坚持、主动、投入拆解成可执行的日常动作

标题里那三个词——坚持、主动、投入——听起来像口号，但落到标准化工作里，其实都有非常具体的打开方式。我在这个领域工作几年后的最大收获，就是发现它们并不是态度问题，而是方法论问题。

5.1 坚持的正确打开方式：以版本为单位，而不是以天为单位

标准演进是以年为单位运行的。你今天提出的工具，很可能因为当前测试模型的基线还不支持、复杂度分析不充分、或者恰好碰上另一个更优方案，在当个版本被搁置。但这不代表它没有价值。

我自己经历过一次很有意思的轮回。某个帧内预测工具在推进时，因为当时主流的梯度信息处理方式不同，收益始终被一个更新更强的方案盖住，最后只能搁置。两年后，新一代标准的框架变了，那个方案的优势不再明显，我们用新的框架重新实现了一遍，做了若干简化，竟然顺利进入了标准文本。这件事给我的启发是：坚持并不是每天盯着同一个表格看，而是每隔一个版本周期，把旧想法拿出来重新跑一遍。基线在变、工具在变、硬件约束也在变，原来不成立的条件可能已经悄悄变化了。

5.2 主动的正确打开方式：先去接管没人愿意干的基建活

标准化组织里最缺的，其实不是天马行空的创新提案，而是愿意干脏活累活的人。维护统一测试序列、跑长周期实验、写交叉验证脚本、整理会议结论和行动项，这些工作技术含量看起来不高，却能让一个人快速接触到完整的技术链路和各方利益相关者。

我自己就是从帮忙做交叉验证开始的。那轮验证偏偏碰上一些棘手的序列，代码要反复调、环境要反复换，折腾了快两周。但正因为这次帮忙，后续很多提案作者在投稿前都会主动把实验配置发给我，请我提前看看有没有问题。这种信任一旦建立起来，你再提出的任何技术意见，别人都会更认真地对待。

5.3 投入的正确打开方式：把时间用在对结论有影响的地方

最后说投入。标准化工作最怕的不是不投入，而是把时间撒在大量重复劳动上，却没有沉淀出任何对结论有影响的信息。要真正投入进去，我有一套自己坚持的实验管理习惯：每个提案单独建目录，环境配置、编译命令、运行日志、结果表格全部存档；每个实验记录当时的编码器commit号、测试序列版本、码率点设置；每次调整参数，先问自己这个改动会不会影响之前已经得出的结论。

这套习惯看起来很笨，但能帮你省下大量返工时间。很多时候，提案被质疑，不是因为算法不行，而是因为你无法说清楚"这组数据是在什么条件下跑出来的"。实验记录做得细，被人质疑时就能直接甩出日志和复现命令，这种底气是任何临场发挥都给不了的。

记得有一次，一个数据异常波动，我排查了很久才发现是 Anchor 编译时参数没有对齐。从那以后，我再也不信任任何没有完整日志的实验结果。把每一条命令、每一个参数都记下来，对结论负责，这才是标准化工作里最朴素的投入。

我经常跟团队里的人说，标准文档读三遍，不如把参考软件里那行改动自己敲一遍。在标准化组织里做事，所有看似枯燥的坚持、主动和投入，最终都会通过一个又一个提案编号留下来。这大概就是这项工作最迷人的地方。