视频编解码标准体系全解析：H.264/H.265/AV1/AVS对比与实践指南

1. 一张地图看懂国内外视频编解码标准体系

1.1 为什么我们同时需要这么多视频编解码标准

这几年在音视频底层技术圈里，我越来越觉得音频视频编解码标准是一个“多极共存”的世界。很多人一提标准，第一反应就是H.264、H.265，似乎一套规范就能覆盖所有场景。但真正参与到国内外视频编解码标准体系的建设工作中之后，你会发现情况远比想象中复杂：既要理解老一代标准的存量生态，又要跟进新一代标准的压缩极限，还要评估不同授权模式带来的商业风险。实际做标准工作的人，手里至少会同时关注三套以上的体系。

先说最根本的问题：为什么不能一套标准打天下？因为视频应用场景的分化太严重了。拍短视频的人要的是编码速度快、兼容性好，上传后各个平台都能解；做流媒体点播的人要的是同样画质下码率尽量低，省带宽成本；广电系统要的是高规整、可管控的超高清链路；监控行业要的则是长时间稳定编码、低延迟回放。这些需求在压缩效率、复杂度、授权条款、硬件成熟度上的取舍完全不一样。奢望一套标准同时满足所有场景，结果一定是谁都服务不好。所以标准的“多线并存”不是市场混乱，而是产业分层的必然结果。

另一个现实因素在于视频数据量的膨胀速度。从1080p到4K再到8K，像素数量成倍翻，可传输带宽和存储成本的下降速度远跟不上视频分辨率的增长速度。标准每提升10%的压缩效率，对一个平台而言可能就意味着每年省下几亿元带宽费用。正因为利益巨大，各利益方都愿意花真金白银去推动一套对自己有利的标准。于是国际组织里有H.264到H.266的演进线，开源社区有AV1等开放性方案，国内也有自主知识产权的AVS系列。几套体系并存，本质上是不同技术路线和商业利益在同一个问题上的三种答案。

1.2 几个主要标准家族各自的位置

我习惯把目前主流的视频编解码标准分成三个家族来看，这样理解起来最清楚。

第一个是经典通用型标准家族，以H.264/AVC、H.265/HEVC、H.266/VVC为代表。这个家族的谱系很清晰，每代大约相隔八年到十年，核心目标很直接：用翻倍以上的计算复杂度，换来30%到50%左右的压缩效率提升。H.264到现在依然是录制、分发、播放兼容性的基本盘，几乎所有终端都能解；H.265在4K视频、高清监控、广播电视等领域已经大面积落地；H.266在H.265基础上再压一层，主要瞄准未来的8K分发、VR和极限低码率场景。这类标准最大的优势是终端生态成熟，从芯片到播放器全线打通，短板则是专利授权体系复杂，对中小厂商来说许可谈判压力不小。

第二个是开放开源型标准家族，AV1是这里面最典型的代表。它与传统标准的差异不只体现在技术路线，更体现在治理模式：由多家互联网公司组成的联盟共同推进，强调免许可费和开放性实现。AV1的解码端普及速度非常快，尤其是在Web浏览器、短视频、云转码这些对“成本敏感、部署灵活”要求高的场景里，已经成为事实性的优先选择。编码端的高复杂度是它的主要争议点，但硬编码器成熟之后，这个问题正在被逐步消化。

第三个是国内自主知识产权的标准家族，AVS系列是这条线的主干。AVS标准的推进路径和技术逻辑跟国际标准并行发展，覆盖了从标清到超高清的完整链路，在编码工具、参考软件、一致性测试方面都有自己的独立体系。它在广电超高清、卫星传输、部分专业视频监控和流媒体环节有明确落地场景。相比国际主流标准，AVS在授权模式上更简单清晰，面向国内产业链的综合成本控制也更友好。在超高清浪潮里，它承担的角色已经不只是技术标准，更是一套围绕版权、专利和产业协同的全链路底座。

这三个家族不是非此即彼的关系。实际工程中，同一个平台常常会同时编解码三种体系的码流，同一个芯片厂商也会同时布局多套标准的硬核模块。标准化组织的工作，很大程度上就是在这三个体系之间梳理边界、寻找共识、避免重复造轮子。

1.3 从压缩效率、实现复杂度、授权模式三个维度看差别

我整理了一份常用来跟新同事介绍情况的对比表，虽然细节会随版本更新变化，但大方向很稳定。

这张表解释了几件事。第一，编码效率的“代际提升”是有物理极限的，越往后越难挤。H.264到H.265花了近十年才换来明显升级，H.266和AVS3已经有大量工具是并行设计、互相借鉴。第二，实现复杂度不是线性增长，而是跳跃式增长。一个工具从提出到落地写进标准，往往意味着硬件设计里要多加一整条运算路径，对芯片面积和功耗的影响极大。第三，授权模式直接影响标准的推广速度。技术再好，如果授权条款让人算不清账，很多厂商会宁可选择效率略差但规则明朗的标准。

看明白这张地图，才算真正理解我们在音视频标准化组织里的工作为什么如此强调“坚持、主动、投入”——因为标准不是某一次技术突破写出来的，而是多年、多组织、多方案反复碰撞后凝固下来的社会契约。

2. 标准化组织里到底在做什么事

2.1 一份标准提案从提出到落地的完整过程

不少人以为标准化组织的工作就是专家们开会举手表决“我要这个工具”，或者偶尔评审一下文档。实际过程要严密得多，也枯燥得多。一次真正有价值的提案，通常要经过至少四个阶段。

第一阶段是问题发现与动机陈述。提案人需要在贡献文档里写清楚：现有标准在哪个环节有缺陷，是压缩效率不够，还是某种内容的编码效果差，或者是复杂度有不合理的突增。标准文档不是论文，不能只写“效果好”，必须有可复现的实验数据做证据。

第二阶段是技术方案设计与核心实验。提案人要基于参考软件实现自己的算法，然后在标准数据集上跑结果。这里头最花时间的是调参和搜索空间设计。举个例子，一个变换系数编码的新方案，涉及系数分组、上下文建模、扫描顺序三个维度，每个维度又有好几个候选值，组合起来几十种配置，全要跑完客观指标。如果没有可复用的脚本体系和高效的编排方式，光参数搜索就能耗掉几周。

第三阶段是交叉验证与协同评估。提案在会议上报告之后，通常会面临几个质疑：你的收益只在特定序列上有效？你的复杂度统计准不准？你的实现有没有边界溢出风险？这些质疑会变成实验任务，落到其他参与方手里去做独立复现。如果另外几家公司用各自独立实现的代码复现不出同等收益，提案的推进就会停摆。这一环节是最能体现“投入”意义的地方，独立复现是对提案人和整个组织的双重要求。

第四阶段是进入标准文本并维护参考软件。提案被接受后，还不能算结束。文本的措辞必须准确到让任何一家翻译成硅电路的人都能对齐；参考软件的代码要同步更新，并且保证输出与文本一致；配套的一致性测试码流要设计出来，确保后续所有实现者有一个“对答案”的锚点。很多新加入标准工作的人，最先接触的任务就是给参考软件修Bug，因为那个软件承载了太多历史决策，是标准文本的活体注释。

标准化组织内部的会议是“贡献驱动”的。你不带文档、不带实验结果，就没有资格进入核心讨论圈。哪怕你来自一个很小的团队，只要你连续几轮提供了高质量的数据和复现报告，大家就会认真对待你的意见。这套机制乍看很公平，实际上非常消耗参与者的持续产出能力。

2.2 测试评估环节最容易产生分歧

标准工作里最有争议的环节，永远是对“效率”的度量方法。客观指标上，标准组织一般用BD-Rate作为核心衡量手段。这个概念简单说就是：在同一画质水平下，新方案比参考方案省了多少码率。两个方案都必须跑若干组量化参数（QP），把不同码率下的失真点连成曲线，再比较曲线之间的面积差。我在实际项目里踩过不少坑，最常见的错误是只报一个QP点下的指标。单点提升1%看起来漂亮，但放到整条率失真曲线上可能完全不相干，最终在标准会议里会被其他专家直接否决。

更微妙的是主观质量评测。标准组织对新工具的评价，不光看PSNR和SSIM，还要组织主观观看实验：把参考序列和测试序列打乱编号，请一批受过训练也被随机挑选的观察者坐在标准条件下观看，用特定的评分表记录感受，再经过统计处理得出结论。原因很简单：某些客观指标提升很大的工具，在人眼感知里可能毫无区别甚至更差，尤其在纹理区域和边缘毛刺上。编码标准最终是给人看的，不是给机器跑分的。

多轮测试下来，我们对“好工具”的定义已经不只是数学上的提升，而是“在大部分内容类型上稳定提升、在极端内容上至少不劣化、复杂度增加可接受”的三重条件。这也是标准化组织内部严格到近乎苛刻的环境，逼着每个参与者用最扎实的实验证据来说话。

2.3 专利与授权策略对标准走向的影响

很多人低估了专利因素在标准化组织工作中的分量。在标准组织里提交一个技术提案，通常伴随专利披露义务：你提案里如果包含公司持有的必要专利，就要同步做专利检索和声明。否则等到标准发布后，你的专利很可能因为“已经公平、合理、无歧视地许可给授权池”而被稀释掉议价能力。

这种专利披露与授权策略，又反过来影响技术选型。举例来说，如果一个压缩工具能带来5%的效率提升，但它的专利覆盖面太复杂，产权不清晰，标准组织里的各家成员就会斟酌：要不要为5%的收益给整体授权体系增加不确定性？有时候答案是否定的。这种讨论通常非常激烈。技术上讲大家都认同这是一个优秀工具，商业上却没法防住潜在的授权隐患。这个环节里，“主动”显得尤其重要，主动参与专利评估会，主动梳理授权池的最新清单，主动在早期提出排除某类关键权利要求的建议，都能帮自家公司争取到更多缓冲空间。

所以，不要把标准组织工作单纯理解成技术协作。它其实是“技术评价+商业博弈+专利布局”三位一体的复杂工程。

3. “坚持、主动、投入”三个词背后的实操心得

3.1 坚持：标准周期以年为单位，怎么才能扛住长期看不到成果的压力

我带过的团队成员，最快辞职的人往往不是干不了活，而是受不了标准工作的节奏。一个提案从萌芽到落地，往往跨越两到三个标准版本周期，而以年为单位的周期对习惯了“两周一迭代”的互联网人来说，简直难以忍受。我刚参与标准工作时，也经历过半年忙活、计算结果无法进入下一轮评估的窘境。后来慢慢总结出几条坚持的方法论。

第一，把长期目标切分成可交付的中间节点。不要上来就盯“必须进标准文本”这个大目标，而是先定一个阶段目标：比如下一轮会议贡献一份完整的某工具复杂度分析报告，或者独立完成一项交叉验证任务。每一个中间节点都是看得见、可汇报、能被其他参与方认可的成果，这样团队士气就不会因为大目标遥遥无期而崩溃。

第二，建立长期稳定的参考实验环境。标准对比实验最忌讳每次换参数、换脚本、换序列池。我们内部把参考序列、编码配置、评估脚本全部固定成基线，任何人都能一键复现历史结果。这样投入的时间会沉淀下来，变成团队资产的复利。坚持做标准工作的团队，实验环境是否稳定，往往比算法点子多不多更重要。

第三，顺着标准的版本演进持续维护自己的测试序列库。标准组织关注内容类型逐年变化，早年以自然景观和运动场景为主，这两年越来越多加入屏幕内容、HDR、高帧率游戏画面等新类型。如果团队平时不关注这些新增序列，临到要提案了再去准备，时间投入根本来不及。

3.2 主动：从旁听者到提案者，关键不是头衔而是贡献量

标准化组织里的地位，不来自你的公司名气，也不来自参会年限，而来自你实际贡献文档的数量与质量。我见过很多新手第一年去开会，整场都在旁听，不敢发言，结果第二年觉得“反正去了也插不上话”就不去了。实际上，主动进入核心圈层是有路径的。

路径之一是主动认领“脏活累活”。标准组织有一批长期被忽视但极其重要的任务：修参考软件Bug、补充测试序列、维护代码风格统一性。这些事情不会上新闻，但每个组织成员都看在眼里。你把连续三轮的Bug修复报告高质量交出来，下轮会议上你说“这个工具在某类内容上有边界问题”的时候，哪怕只是口头意见，其他人也会认真对待。

路径之二是主动承担跨组织的交叉验证。某个提案需要三个独立实验室复现，你可以举手接一份。这种任务能让你在最短时间内接触最前沿的工具实现，同时对整个评估流程的理解会深很多。很多核心专家就是从这些验证任务里熬出来的，因为他们在各个实验室的复现工作中积累出很强的“代码直觉”和“实验嗅觉”。

路径之三是主动把自己的研发周期对齐到标准组织的会议节奏。如果公司的产品研发节奏是季度版本，做标准工作的团队就必须另开一条“会议驱动”的并行线：每轮会议前几周集中冲刺，会议后几天立刻复盘，定出下一轮的实验计划。这需要从项目规划层主动设计，否则根本排进不了日程表。

3.3 投入：算力、人力和时间账都要算明白

标准工作的投入，本质是三本账。第一本账是算力账。一次标准对比实验可能包含十几个序列、六到八个QP点、两到三个模型配置，叠加起来就是上百次编码运行。新一代编码器对算力的消耗经常高到离谱，尤其涉及VVC或者AVS3级工具集时，单次运行时间可能是老标准的几十倍。如果不提前算好任务队列，实验结果可能在下轮会议截止前跑不完，前面投的人力全部白费。

第二本账是人力账。标准工作适合的背景组合是“算法工程师+软件工程师+专利工程师”的三角结构。算法工程师负责方案和实验，软件工程师负责参考软件维护和优化跑的效率，专利工程师负责同步检索与声明。很多公司只投算法工程师，结果提案效果不错，但在专利披露环节暴露出严重合规问题，最后反而丢分。标准组织内部的消息流传很快，一次专利失误会让整个团队的声誉受损很久。

第三本账是时间账。标准工作的周期不以季度为节奏，而是以会议周期为节拍。通常距离下轮标准会议还有两个月，就该确定实验计划；还有一个月，实验必须进入收尾阶段；还有一周，所有文档数据必须内审完毕，提交上去做预装订。等到会议开始前几天才紧急启动实验，几乎不可能拿到高质量结果。长期做下来，我们内部已经形成惯例：每轮会议结束后，当天晚上就讨论下一轮的投入估算和时间窗，一周内发出实验任务书。把节奏前置到极致，是标准工作“投入”效率的关键。

4. 标准落地实现时的高频问题与排查经验

4.1 参考软件和真实编码器之间的行为差异

标准组织发布的参考软件，首要目的是验证算法的正确性，而不是给你一个能商用的高速实现。它的代码结构追求“与标准文档逐条对应”，可读性高、扩展性好，但运行速度通常比商用编码器慢几十倍甚至上百倍。我做实现的时候，最常踩的第一个坑是：拿参考软件的结果当性能基准去和商用编码器对比，完全得不出有效结论。

参考软件起到的作用是“语义锚点”。遇到协议解析问题、码流兼容性问题，我会先用参考软件生成一条码流，再送入待测实现去解，从中排查边界行为差异。如果待测实现出来的像素和参考软件对不上，就该逐模块排查：是不是环路滤波的边界强度算错了？是不是运动矢量预测的候选项顺序不对？是不是变换系数的反量化取整方式有偏差？这类问题单纯看代码，往往在直觉盲区里，但一和参考软件对比，就很容易定位。

排查工具上，我建议把标准里的“一致性测试码流”作为内置回归用例长期维护。别只在标准发布前测一遍，而是要放在日常开发里，每次代码改动都跑一次。这些测试码流覆盖了无数边界场景：超大分辨率、极端量化参数、不规则分块、特殊色度格式等。老实说，我接手某个标准项目实现时，前两个月基本都在跟一致性测试码流较劲，过了这道关，后面才能安心做自研优化。

4.2 多标准同时实现的架构设计思路

前文提到很多平台要同时支持H.264、H.265、AV1、AVS等多个标准，真正落地时架构设计就非常重要。最忌讳的做法是一套标准一套独立代码栈，结果维护成本翻倍，功能间还没法复用。

我的实践经验是抽象出四个公共层次。第一层是世界与数据结构层，把图像缓冲、帧引用管理、参数集解析这些共性能力抽取出来，底层共用一套内存管理。第二层是块级流水层，不同标准都是“分块-预测-变换-量化-熵编码”的流水线，差异只在工具细节。把公用流水线搭好，再把各标准特有的块分类、预测模式、变换集合以插件方式接入。第三层是熵编码适配层，算术编码和上下文建模是各标准风格差异最大的地方，这一层不太适合强行统一。第四层是质量评估与码流分析层，用于输出调试信息、率失真统计和主观质量预览。

这样设计之后，新增一个标准大多是写一个新的“工具配置表”加若干特有实现，而不是从零搭建整个编码器。多标准兼容的调试要养成良好习惯：在关键模块的输入输出处留好数据导出开关，方便随时拿着各标准参考软件的数据做逐级对比。我处理过最麻烦的Bug就出在变换系数扫描顺序上，同样的块在不同标准里的扫描方向定义不同，代码复用时长了一个垂直翻转角度，排查了很久才发现。

4.3 质量评估与性能对比的标准动作

给音视频编码做性能对比时，绝对不能拿默认参数直接开跑。以下这套是我在标准化测试中摸索出来的标准动作。

先用统一的目标码率或统一的质量锚点，而不是固定参数的盲目乱跑。很多团队为了省事，固定CRF（码率控制因子）或固定量化参数，但不同标准的编码工具差异大，固定一个参数并不等价于相同视觉质量。专业做法是设置多个质量锚点，把码率点覆盖从低到高的大致区间，保证曲线能反映整体性能，而不是被某个区间带偏。

再按BD-Rate方式计算平均差异。BD-Rate可能依赖具体数据点拟合，所以至少要保证码率点覆盖足够宽，并且去除异常点。我的做法是把每个测试序列的原始码率-失真点画在同一张图上，肉眼先看曲线交叉部分，若交叉太多说明方案在不同质量区间表现不一致，这种数据不能简单加权平均。

计算工具方面可以手工实现。用ffmpeg测不同编码器输出后，再用音视频质量评估工具集算出PSNR/SSIM/VMAF等指标，最后在表格里汇总。我贴一段常用命令行写法，方便读者直接复用：

# 用同一输入序列，测试不同标准的大致档位 ffmpeg -i input.y4m -c:v libx264 -crf 23 -preset medium -pix_fmt yuv420p out_264.mp4 ffmpeg -i input.y4m -c:v libx265 -crf 26 -preset medium -pix_fmt yuv420p out_265.mp4 ffmpeg -i input.y4m -c:v libaom-av1 -crf 32 -cpu-used 4 -row-mt 1 out_av1.mp4 ffmpeg -i input.y4m -c:v libsvtav1 -preset 6 -crf 32 out_svt.mp4

这里CRF的具体值需要事先定好，目标是要让输出码率落在相近区间，不是直接拿着命令不加思考地运行。只有码率区间接近，BD-Rate的对比才有意义。主观评测环节也不能省。至少让两三位同事在同样的显示器、同样的观看距离下盲评，虽然说不上严格标准流程，但能筛掉很多用客观指标看不出问题的主观劣化。

5. 给想加入标准化工作的同行几条实战建议

第一，先把自己定位成“标准的验证者”，再想着做“标准的创造者”。刚参与标准工作，不要急着提交石破天惊的提案，而是先找一轮自己熟悉的提案，主动认领交叉验证任务。把验证报告写扎实，你会对组织的工作流程、文档规范、评估口径建立真实体感。

第二，算法能力只是入门，工程系统能力才是分水岭。标准提案里引用的每个数字背后，都是大量脚本、任务队列、数据管线在支撑。能把实验自动编排、参数搜索、结果可视化做得又快又稳的人，永远比只会画算法框图的人走得更远。我见过提案效果很漂亮，但因为复现工程太混乱导致数据可信度受质疑的真实案例。

第三，坚持做专利记录，从第一天就养成习惯。很多人觉得“我还没提交正式提案，不需要管专利”，等到提案被采纳后才匆忙回头检索，发现某个关键工具已经公开披露过，丧失了专利保护时间窗口。类似教训反复出现。我自己的做法是每个算法模块建立一张专利映射表，记录它与标准草案条款的对应关系，每两个月复查一次，确保没有遗漏。

第四，接受“工作在几年里可能看不到直接商业回报”的现实。标准工作的回报是复合型的：它会沉淀出团队对图像信号处理底层逻辑的系统理解，会锻炼工程实现与实验设计能力，会让团队在全行业技术演进里保持第一手敏感度。这些能力最终会在产品规划上变现，但你不能指望它按季报节奏回血。能长期坚持下来的团队，通常都有一套独立的“价值衡量标准”，不把项目收益作为唯一KPI。

第五，多参加交叉领域的联合测试。视频编解码标准从来不是孤立发展的，它和显示技术、传输协议、芯片架构、云服务部署紧密绑定。你在标准工作会议上认识的传输协议专家，可能下一次就帮你解决封装层兼容性问题；你参与过的HDR主观测试，可能直接指导了后续产品的画质调优方向。标准化组织的隐性价值，正是这种跨组织、跨领域的协作网络。

最后再分享一点个人体会

前几年带团队做标准项目，我最深的感触是：标准化工作不是一条单点突破的捷径，而是一场需要持续投入的组织长跑。它考验的不是你某一次提案的惊艳程度，而是你能否在三年、五年甚至更长的周期里，持续用高质量贡献证明自己的技术判断力。所谓“唯有坚持、主动、投入”，落到实操层面就是：坚持把实验数据做得可复现、可追溯，主动承担那些没人愿意做的验证与维护任务，投入足够的人力、算力和时间把每一轮会议当成一次产品发布来对待。做到这三点，哪怕一开始只是边角参与者，也会慢慢变成标准版图里一个别人愿意认真听你发言的角色。这套逻辑放在视频编解码标准体系里适用，放在任何一项长期技术协作事务里，我觉得同样成立。