客户看了些资料，问我们："要不要把视频都转成 AV1？听说能省一半带宽。"
我当时的反应是"得测"。因为"省带宽"和"能用"是两件事：AV1 的压缩率确实比 H.265 好，但编码慢得多，而且解码端支持度是碎片化的——如果用户的设备播不了，省下来的带宽毫无意义。
我花了两天做了一轮实测：三个编码器 × 多个速度档 × 六类素材，测 VMAF、耗时、体积。结论是：AV1 在同画质下比 H.265 省 20~30%（不是 50%），编码慢 3~20 倍。我们最后的方案不是"全转 AV1"，而是"给支持 AV1 的设备多提供一档"。
这篇写完整的实测数据和决策过程。
TL;DR：AV1 的三个编码器：
libsvtav1（推荐，速度快、质量好）、libaom-av1（参考实现，慢）、librav1e（中庸）。关键参数：-preset（SVT-AV1 是 0~13，越大越快）、-crf、-g（关键帧间隔）、-svtav1-params "tune=0:lp=8"。实测：SVT-AV1 preset 8 的体积是 H.265 的 78%，耗时是 3.4 倍；libaom 更省一点但慢得离谱。选型建议：点播大流量场景加一档 AV1（配合 ABR 让支持的设备用），归档和时效紧的任务继续用 H.265；老设备占比高的场景别用。
目录
- 一、先认识三个 AV1 编码器
- 二、确认你的 ffmpeg 支持
- 三、SVT-AV1 的参数怎么调
- 四、libaom 的参数
- 五、实测：速度、体积、画质
- 六、解码端：谁支持 AV1
- 七、和 VP9、H.265 怎么比
- 八、我们的决策：分层提供
- 九、批量编码的性能优化
- 十、坑清单
一、先认识三个 AV1 编码器
| 编码器 | ffmpeg 名称 | 出身 | 特点 |
|---|---|---|---|
| SVT-AV1 | libsvtav1 |
Intel + Netflix 联合开发 | 速度快、并行好；质量接近 libaom；生产首选 |
| libaom | libaom-av1 |
AOM 官方参考实现 | 质量最好（同码率下），极慢 |
| rav1e | librav1e |
Mozilla/Xiph | 速度中等，质量中等，生态一般 |
还有硬件编码器（Intel Arc 的 AV1 硬件编码、NVIDIA 40 系的 AV1 编码），但支持面还很窄。
结论：生产用 libsvtav1，除非你有充足的算力并且追求极致压缩率（那就用 libaom）。
二、确认你的 ffmpeg 支持
ffmpeg -hide_banner -encoders 2>/dev/null | grep -i av1
# V..... libaom-av1 libaom AV1 (codec av1)
# V..... libsvtav1 SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1)
# V..... librav1e librav1e encoder (codec av1)
如果只有解码器没有编码器，说明编译时没带这些库——要么换一个 ffmpeg 构建（官方静态构建一般都有），要么自己编译（前面那篇静态编译的文章讲过流程，SVT-AV1 需要 libsvtav1-dev 和 --enable-libsvtav1）。
检查版本（版本差异很大，老版本性能差不少）：
ffmpeg -hide_banner -h encoder=libsvtav1 2>/dev/null | head -20
三、SVT-AV1 的参数怎么调
基本命令：
ffmpeg -i input.mp4 \
-c:v libsvtav1 \
-preset 8 \
-crf 32 \
-g 240 \
-pix_fmt yuv420p10le \
-svtav1-params "tune=0:lp=8" \
-c:a libopus -b:a 96k \
output.mkv
参数说明：
| 参数 | 含义 | 建议 |
|---|---|---|
-preset |
速度档，0~13（0 最慢质量最好，13 最快） | 生产用 6~10 |
-crf |
质量目标（AV1 的 CRF 尺度和 H.264/265 不同，见下） | 1080p 常用 30~36 |
-qp |
固定量化参数（与 crf 二选一） | |
-g |
关键帧间隔（帧数） | 点播 240（约 10 秒 @24fps），ABR 要对齐 |
-pix_fmt |
建议 10bit（AV1 的 10bit 支持好，且压缩率更高） | yuv420p10le |
-svtav1-params tune= |
0=VQ（视觉质量，默认）、1=PSNR（客观指标） | 用 0 |
-svtav1-params lp= |
逻辑处理器数（并行度） | 设为机器的核数 |
-svtav1-params film-grain= |
胶片颗粒合成强度（0~50） | 保留颗粒感时用 4~8 |
AV1 的 CRF 尺度跟 H.264/H.265 不一样——H.265 的 CRF 28 大致对应 AV1 的 CRF 32 左右。不要直接照搬数值，一定要实测校准。这是我第一次用的时候最容易犯的错（我直接用了 28，结果画质明显偏低）。
preset 的选择（SVT-AV1）：
| preset | 相对速度 | 相对体积 | 适合 |
|---|---|---|---|
| 0~4 | 极慢 | 最小 | 离线、追求极致 |
| 5~7 | 慢 | 小 | 归档、不赶时间 |
| 8~10 | 中 | 中 | 生产常用 |
| 11~13 | 快 | 偏大 | 实时/准实时 |
四、libaom 的参数
ffmpeg -i input.mp4 \
-c:v libaom-av1 \
-crf 30 \
-cpu-used 4 \
-row-mt 1 \
-tiles 2x2 \
-g 240 \
-pix_fmt yuv420p10le \
-b:v 0 \
output.mkv
| 参数 | 含义 |
|---|---|
-cpu-used |
速度，0~8（越大越快质量越低） |
-row-mt 1 |
行级多线程，必须开，否则慢很多 |
-tiles 2x2 |
分块（利于并行解码） |
-b:v 0 |
配合 crf 使用（表示不限码率） |
-aom-params |
更多底层参数 |
-row-mt 1 这一条极其重要：不开的话 libaom 只用单线程，慢得让人怀疑人生。我第一次测的时候忘了开，得出的"libaom 比 SVT-AV1 慢 50 倍"的结论完全是错的。
五、实测：速度、体积、画质
测试条件：8 核机器（i7-10700），1080p 素材，30 秒片段，目标 VMAF ≈ 93。
编码耗时与体积（相对 libx265 preset slow = 100%）
| 编码器 | 参数 | 相对耗时 | 相对体积 | VMAF |
|---|---|---|---|---|
| libx265 | preset slow, crf 26 | 1.0× | 100% | 93.5 |
| libx264 | preset slow, crf 23 | 0.55× | 158% | 93.4 |
| libsvtav1 | preset 8, crf 32 | 3.4× | 78% | 93.6 |
| libsvtav1 | preset 10, crf 32 | 1.9× | 84% | 93.3 |
| libsvtav1 | preset 6, crf 32 | 8.1× | 72% | 93.7 |
| libaom-av1 | cpu-used 4, crf 30 | 18× | 70% | 93.8 |
| libaom-av1 | cpu-used 8, crf 30 | 5.2× | 81% | 93.2 |
关键数字：
- AV1（SVT-AV1 preset 8）比 H.265 省 22% 体积（不是"一半"）；
- 代价是 3.4 倍编码时间；
- 想再省（preset 6，省 28%）就要付出 8 倍时间。
分内容类型的差异
| 内容 | AV1 vs H.265 体积 | 说明 |
|---|---|---|
| 动画 | 68% | 收益最大 |
| 访谈 | 76% | |
| 赛事 | 80% | |
| 屏录（PPT） | 72% | |
| 夜景（高噪点） | 85% | 收益最小 |
| 胶片颗粒 | 62% | 开 film-grain 后收益巨大（颗粒被"合成"而不是编码） |
film-grain 参数是个隐藏武器：它允许编码器把颗粒"建模"而不是逐帧编码，对老片/胶片素材能省非常多。代价是解码端要支持颗粒合成（大部分现代解码器支持）。
我的判断
AV1 省 20~30% 是不是值得？ 取决于你的成本结构：
假设：存储/CDN 成本 = C，编码算力成本 = E
转 AV1：存储省 25%，编码耗时 ×3.4
如果 C >> E（点播大流量、长期存储）→ 值得
如果 C ≈ E 或者 C < E（时效紧、短期存储）→ 不值得
对我们（长期存储 + 播放量大）来说，点播内容值得；对时效性内容（客户当天下发）不值得。
六、解码端：谁支持 AV1
这一节决定了你能不能用。
| 平台 | AV1 硬件解码 | 说明 |
|---|---|---|
| Chrome / Edge | ✅（2019 后） | 支持好 |
| Firefox | ✅ | |
| Safari | ⚠️ 部分 | macOS 14+/iOS 17+ 在支持的硬件上 |
| Android | ⚠️ 2020 后的中高端 | 老设备只能软解（发热、耗电） |
| iPhone | ⚠️ A17 Pro / M3 系列才有硬解 | 老 iPhone 软解 |
| 智能电视 | ⚠️ 2021 后的中高端 | 便宜的盒子基本不行 |
| 老设备 | ❌ | 完全播不了 |
软解的代价：AV1 软解比 H.264 软解 CPU 占用高不少，手机上会明显发热掉电。
这就是"不能全转 AV1"的核心原因——你的用户里一定有一部分设备播不了（或者播得很痛苦）。
判断方法：看你的用户设备分布（如果有统计）。我们当时看了站点的 UA 数据，能确认支持 AV1 的大概占 62%——这个比例足够"加一档"，但远不够"替换掉 H.264"。
七、和 VP9、H.265 怎么比
| 编码 | 压缩率（相对 H.264） | 编码速度 | 解码支持 | 专利 |
|---|---|---|---|---|
| H.264 | 100% | 快 | 最好 | 有专利池 |
| H.265 | ~50% | 中 | 中等（硬件支持碎片化） | 专利复杂（HEVC Advance） |
| VP9 | ~55% | 中 | 浏览器好，硬件一般 | 免费 |
| AV1 | ~40% | 慢 | 新设备好，老设备差 | 免费（ royalty-free ） |
AV1 最大的优势其实不是压缩率，而是免专利费——这是它被 Netflix/YouTube/各大厂商推动的根本原因。对商业分发来说，避开 HEVC 的专利不确定性是有实际价值的。
什么时候用 VP9：Web 端、不想碰专利、目标浏览器为主、编码速度要求比 AV1 宽松一点。VP9 的编码速度比 AV1 快不少，是很多 YouTube 类场景的折中选择。
八、我们的决策：分层提供
最后我们没有"全转 AV1"，而是做了多码率里的额外一档：
H.264 档（必选） → 所有设备
H.265 档（可选） → 支持 HEVC 的设备
AV1 档（新增） → 支持 AV1 的设备（客户端探测能力后选择）
ABR 的 master playlist 里同时列出三档，播放器根据自己的解码能力选择：
#EXT-X-STREAM-INF:BANDWIDTH=1200000,CODECS="av01.0.05M.08,opus",RESOLUTION=1920x1080
1080p_av1.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4500000,CODECS="hvc1.2.4.L120.B0,mp4a.40.2",RESOLUTION=1920x1080
1080p_hevc.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6000000,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=1920x1080
1080p_avc.m3u8
收益：支持 AV1 的那 62% 用户，带宽省了约 22%；不支持的照旧。没有牺牲任何人的兼容性。
代价：多一档的编码和存储成本。但因为 AV1 档本身体积小（78%），总成本增加有限（约 +25% 存储，换 22% 带宽节省）。
实施建议：
- 先小范围灰度（比如 5% 的内容），确认客户端能力探测正确、切换无误；
- 监控播放失败率——如果 AV1 档的失败率明显高于其他档，说明能力探测有问题，立刻撤；
- 客户端能力探测用
MediaCapabilities.decodingInfo()（浏览器）或者平台 API（移动端），不要靠 UA 猜。
九、批量编码的性能优化
AV1 慢，所以批量处理时要榨干性能：
1. 并行度
-svtav1-params "lp=8" # 逻辑处理器数 = 核数
SVT-AV1 内部并行做得不错，单任务能吃满多核。所以批量处理时"一个文件一个进程"就够了，不要像 H.265 那样切片并行（切片对 AV1 的收益更大，但复杂度也更高）。
2. 大文件切片并行
对特别大的文件（几小时），切片并行依然有效（前面那篇文章的做法）。注意每段参数一致。
3. 10bit 输入输出
-pix_fmt yuv420p10le
AV1 的 10bit 编码效率更高（即使源是 8bit），而且解码器支持好。所以即使最终要 8bit，编码时也用 10bit。
4. 关键帧间隔
AV1 的关键帧比 H.265 更"贵"（体积大）。所以 GOP 可以设长一些（点播 10 秒甚至更长），能省体积。但 ABR 场景要对齐（前面 ABR 那篇讲过）。
5. 容器
AV1 常配 MKV 或 WebM（开源生态），MP4 也支持（需要较新的封装器）。HLS 分发用 fMP4（前面那篇讲过）。音频建议 libopus（配合 AV1 的开源组合）。
十、坑清单
- 直接照搬 H.265 的 CRF 值 → 画质不对。AV1 的 CRF 尺度不同，要重新校准。
- libaom 忘了
-row-mt 1→ 只用单线程，慢几十倍。 - 用 libaom 做生产批量 → 慢到不可能。用
libsvtav1。 - preset 数值理解反了 → SVT-AV1 是 0 慢 13 快，和 x264 的命名体系完全不同。
- 没设
lp→ 并行度不对，没吃满 CPU。 - 8bit 编码 → 压缩率不如 10bit。用
yuv420p10le。 - 全量转 AV1 → 老设备播不了。分层提供。
- 靠 UA 猜解码能力 → 不准。用
MediaCapabilities之类的能力探测 API。 - 不监控 AV1 档的播放失败率 → 出问题发现不了。
- 以为能省 50% → 实测 20~30%。做预算时别用宣传数字。
- 胶片/颗粒素材不用 film-grain → 白白浪费 AV1 的这个优势。
- GOP 设太短 → AV1 关键帧贵，体积增加。点播可以长一些。
- ffmpeg 版本太老 → 老版本的 SVT-AV1 封装有 bug（比如
-crf不生效）。用较新的版本。 - 中途换编码器版本 → 不同版本的输出可能不一致（质量/体积）。生产环境固定版本。
- 只测一个素材就下结论 → 不同内容收益差异很大（62%~85%）。测代表性的几类。
- 忽略音频 → AV1 常配 Opus，但某些平台不支持 Opus。确认播放端支持再换。
最后说说这次评估的方法论收获。
"要不要用新技术"这类问题，答案是"看场景"，但这个"看场景"不能是模糊的——它必须有数字支撑。
我这次做的事其实很简单：
- 定义清楚衡量指标（体积、耗时、画质 VMAF、兼容性覆盖率）；
- 跑一批有代表性的样本；
- 结合自己的成本结构和用户分布算账；
- 得出一个分层的、有条件的结论。
第 4 点很重要。如果一个技术评估的结论是"用"或者"不用"，那多半是偷懒了。真实的结论通常是"在什么条件下用什么、给谁用"。
还有一点：宣传材料里的数字要打折。AV1 的"省 50%"是在特定条件下（对比 H.264、特定素材、最慢的编码档）得到的。我们实测"对比 H.265、混合素材、生产可用的速度档"是 22%。两个数字都对，但后者才是你能指望的。
所以现在看到任何"提升 X 倍""节省 Y%"的宣传，我的第一反应都是：在什么的基准上、什么条件下测的？ 然后自己跑一遍——跑一遍的成本通常是半天，而基于错误数字做决策的代价要大得多。