一段 1080p、60 帧的未压缩原始视频，每秒钟会吐出约 370 MB 的数据，一张 50GB 的蓝光光盘只够装两分钟。2003 年 5 月获批、并在 2026 年 6 月更新至第 16 版的 H.264/AVC 标准，是过去二十年扛住这股数据洪流的底座。开发者 Sid Bala 曾做过一个著名的反差实验，苹果官网首页的一张单帧 PNG 截图重达 1015KB，而录制同一页面 5 秒钟、60fps（共 300 帧）的 H.264 视频，体积只有 175KB。
300 倍的画面帧数，体积却只有单张图的五分之一，账面上看 H.264 的效率似乎是 PNG 的 1500 倍。但如果你把这个数字当成工程基准去选型，就会掉进坑里。把这场视觉魔术扒开，里面藏着三个不对等的测试条件；而更值得今天开发者改写认知的事实是，新一代开源编码器 SVT-AV1 已经在同等 CPU 算力下比老牌 x264 多省出 30% 码率，视频压缩的账本早就换了算法。
拆穿 1500 倍神话：三个不对等的测试猫腻
魔术好看，是因为魔术师只让你看他想让你看的地方。2016 年这篇科普文登上 Hacker News 时，底下的音视频工程师立刻拿出了放大镜，指出了这场对比里三个严重偏科的变量：
- 有损对无损的降维打击，PNG 是无损格式，每个像素的 RGB 值都得原封不动还原；H.264 是有损编码，上来就先把人眼不敏感的色彩砍掉一半（4:2:0 色度抽样，仅保留四分之一色度分辨率），再把 MacBook Pro 扬声器网孔这种高频细节直接抹平，单帧体积当场就能缩到原图的 7% 甚至 2%。拿扔掉九成行李的赛车跟满载货车比油耗，本身就不讲武德。
- 静态网页的极端帧间重复，这段 300 帧的视频录的是苹果官网主页，整个画面只有 3 个完整编码的 I 帧（关键帧），其余两百多帧画面几乎只是把 16×16 的像素宏块做平移。P 帧和 B 帧只需要记录位移向量，再用无损熵编码把满屏相同的位移数字合并同类项。如果换成树叶晃动或漫天雪花的画面，体积立刻会暴涨。
- 被虚标的 PNG 分母，当时有较真的读者把原文里的 PNG 截图下载下来，发现实际文件大小是 637,273 字节（约 622 KiB，当时文章写的是 916 KiB，后来页面又变成了 1015 KB）；再用
pngout工具做一次纯无损重压缩，体积直接降到了 597,850 字节。
把有损压缩、极端静止画面、未优化的无损原图叠在一起，才凑出了 1500 倍的噱头。Sid Bala 自己也承认，这个悬殊的对比是为了帮初学者建立直觉而设计的钩子。
真正的工业壁垒：不是扔掉细节，而是控制误差
很多读过入门科普的人会留下两个技术错觉，一是以为频域变换扔掉了高频细节，二是以为预测帧（P 帧 / B 帧）里只存了像素块的运动方向。如果 H.264 真这么粗糙，画面早就糊成马赛克了。
在 H.264 的混合编码流水线里，频域变换本身并不丢弃信息。真正下刀砍体积的环节叫量化。在 8-bit 亮度下，H.264 设定的量化参数（QP）范围是 0 到 51；QP 每增加 6，量化步长就会翻一倍，更多细微的高频系数会被除成零。而且 H.264 放弃了早期标准常用的离散余弦变换（DCT），改用 4×4 整数变换（High Profile 下可选 8×8）。原因很现实，不同芯片厂商的 CPU 和 GPU 做浮点运算时会有微小的舍入差异，P 帧一帧接一帧累加下来，解码器画面就会跟编码器发生撕裂漂移；全改成整数运算，才彻底锁死了跨平台解码的一致性。
预测帧干的活也比画个箭头复杂得多。H.264 支持把 16×16 的宏块一直切小到 4×4 亮度样本，并以四分之一像素的精度去搜索运动轨迹。找到最接近的参考块之后，编码器必须把真实画面与预测块相减，算出一张残差图，把残差做变换和量化后一起塞进码流，最后还得过一道环路去块滤波器（In-loop Deblocking Filter）抹掉方块接缝。
这也是为什么你在视频网站往回拖动进度条时，哪怕那几秒视频早就缓存在内存里，画面也会顿一下才播。因为你戳中的往往是一个 P 帧或 B 帧，解码器没法直接画出来，必须退回到最近的一个 I 帧，把沿途几十帧的运动向量和残差全部重算一遍。H.264 的统治力，靠的不是哪一招鲜，而是把多参考帧、可变块划分、四分之一像素预测、整数变换、环路滤波和 CABAC 熵编码这几十个工程零件严丝合缝地焊在了一起。
算力借口已经失效：为什么 H.264 还没退场
距离那篇科普文发表已经过去近十年。今天在音视频工程圈里，最顽固的一个刻板印象是 AV1、HEVC（H.265）这些新标准虽然省带宽，但编码慢如蜗牛，普通服务器根本跑不动，所以大家只能继续用 H.264。
困住新标准的从来不是算法上限，而是早期参考编码器的工程债。
这句话放在十年前是事实，放在今天就是拿着旧皇历看新船。行业里经常把编码标准（Codec）和编码器实现（Encoder）混为一谈。早年让开发者算力报警的，是 AV1 早期的参考编码器 libaom，而不是 AV1 标准本身。看看大厂跑出来的实测账本，代差已经非常清楚：
| 评测机构与时间 | 对比编码器与预设 | 核心性能与码率结论 | 工程判断 |
|---|---|---|---|
| Facebook (2018.04) | AV1 vs x264 High / VP9 | 400 个视频两遍编码（PSNR），AV1 比 x264 省 47% 码率，比 VP9 省 30% | 验证了新标准的压缩天花板 |
| Netflix (2018.12) | EVE-VP9 vs x265 | PSNR 下比 x265 差 1%，但高质量 HVMAF 指标下反超 12% | 传统信噪比指标已低估新编码器画质 |
| Meta (2023.02) | SVT-AV1 M12 vs x264 veryfast | CPU 算力消耗相当，SVT-AV1 依然多省约 30% 码率 | 慢如蜗牛的算力借口被工程优化攻破 |
| Meta (2023.02) | SVT-AV1 M8 vs libvpx-vp9 preset 0 | 压缩率相近，但 SVT-AV1 编码速度快了近 10 倍 | 现代软件编码器已具备大规模投产条件 |
既然 SVT-AV1 在 M12 预设下已经能用跟 x264 veryfast 差不多的 CPU 算力白捡 30% 的带宽节省，为什么满大街的监控探头、无人机和流媒体兜底流还在死守 H.264？
答案不在软件机房里，而在全球几十亿台终端的硅片上。先入关中者王之，H.264 早在二十年前就通过 Profile（定义编码工具集）和 Level（定义解码硬件上限）把规矩定死了。比如常见的 High Profile Level 4.0 规定最大视频码率 25 Mbit/s，支持 1920×1080@30fps；Level 4.2 支持到 1080p@60fps，规定解码器每秒最多处理 522,240 个宏块。这套死板的边界，让全世界最廉价的电视盒子、车载屏幕和安防芯片都能用几毛钱的硬解电路流畅跑通 H.264，不费电也不发热。
- 建议.如果你在负责流媒体分发、点播转码或短视频后台，别再拿算力太贵当挡箭牌死守 x264，直接去测 SVT-AV1 的快预设并改用 VMAF/HVMAF 指标验收，那 30% 的 CDN 带宽账单是立刻能省下来的真金白银；但如果你的产品要面对长尾老旧硬件、低功耗物联网摄像头或极端兼容场景，H.264 依然是唯一不会让客户端黑屏的底线。
技术标准能不能赢，上半场比的是数学家的压缩公式，下半场比的是无数窄门里的硅片惯性。接下来两年的真正分水岭，就看 SVT-AV1 这类软件编码器能不能在实时直播和中低端 CPU 上进一步压低延迟，在硬件硬解全面换代之前，先从服务器端把 x264 的基本盘切走一半。