📚 课程目录第1章 VP9编码概述

1. VP9 编码概述：从历史到实战

VP9 这个编码器，说实话，刚出来那会儿我并不太看好。2013 年 Google 把它推到台前时，H.264 已经统治了几乎所有的视频平台，H.265 也正在摩拳擦掌。我当时在做一个直播项目，团队里没人愿意碰 VP9——兼容性、编码速度，全是问号。

但后来我慢慢改观了。尤其是 2016 年以后，YouTube 全面转向 VP9，Chrome 浏览器原生支持，连 Android 系统都把它写进了硬件解码的标配里。嗯，这时候我才意识到，VP9 不是来「替代」谁的，它是在开辟自己的阵地。

1.1 VP9 的发展历史与行业地位

VP9 是 Google 在收购 On2 Technologies 之后推出的第二代开源视频编码标准。它的前身 VP8 其实没掀起太大波澜，但 VP9 不一样——它从一开始就瞄准了 4K 和互联网流媒体场景。

关键时间线：

2013 年：VP9 正式发布，与 WebM 容器绑定
2015 年：YouTube 开始大规模部署 VP9，节省约 35% 带宽
2016 年：Chrome、Firefox、Opera 全面支持，Android 6.0+ 硬件解码
2018 年：AV1 发布后，VP9 成为「过渡标准」，但实际使用量仍在增长
2020 年至今：WebRTC 场景中 VP9 成为 SVC 可伸缩编码的首选

行业地位这块，我个人的看法是：VP9 是「无专利授权费」阵营里最成功的编码器。H.265 虽然压缩率更高，但专利授权问题让很多中小团队望而却步。我在 2018 年帮一家创业公司选型时，就是因为 H.265 的授权费太复杂，最终全栈切到了 VP9——省心，而且效果不差。

1.2 VP9 与 H.264 / H.265 的技术对比

直接上对比表吧，这样更直观。我整理了一份基于实际项目测试的数据，码率控制在 2Mbps，测试序列是 1080p 24fps 的标准测试集。

对比维度	H.264 (AVC)	H.265 (HEVC)	VP9
编码效率	基准	比 H.264 节省 40-50%	比 H.264 节省 35-45%
解码复杂度	低（硬件普及）	中（硬件较新）	中（硬件较新）
编码速度	快	慢（约 H.264 的 3-5 倍）	中等（约 H.264 的 2-3 倍）
专利授权	有（MPEG LA）	有（复杂，多专利池）	无（开源，BSD 协议）
浏览器支持	全部	仅 Safari + Edge	Chrome / Firefox / Opera
SVC 支持	有限（SVC 扩展）	有限（SHVC）	原生（三层空间+时间）
4K/8K 适用性	勉强	优秀	良好

我的经验： 如果你做的是浏览器端视频播放，VP9 的兼容性其实比 H.265 好得多。H.265 在 Chrome 上只能靠软解，而 VP9 从 Chrome 29 开始就原生支持硬解了。我曾经踩过这个坑——给客户演示时，H.265 视频在 Chrome 上 CPU 直接飙到 90%，换成 VP9 瞬间降到 20%。

为什么会这样？核心在于 VP9 的编码架构设计。它采用了类似 H.265 的编码树单元（CTU），但做了大量简化。比如 VP9 的超级块大小固定为 64x64，而 H.265 的 CTU 可以从 64x64 到 16x16 自适应。VP9 牺牲了一点灵活性，换来了更低的解码复杂度。

1.3 VP9 的应用场景分析

VP9 不是万能的，但它在三个场景里特别能打。我按项目经验排了个优先级：

1.3.1 WebRTC 场景

这是 VP9 最让我惊喜的地方。WebRTC 默认用 VP8，但 VP9 的 SVC（可伸缩视频编码）能力实在太香了。你可以把视频流编码成三层：基础层（360p）、增强层 1（720p）、增强层 2（1080p）。网络差的时候，只传基础层；网络好了，自动叠加增强层。

实战配置（libvpx 编码器）：

ffmpeg -i input.yuv \
  -c:v libvpx-vp9 \
  -b:v 2000k \
  -s 1920x1080 \
  -ts_layers 3 \
  -temporal_layers 3 \
  -spatial_layers 3 \
  -s_layer 0:640x360 \
  -s_layer 1:1280x720 \
  -s_layer 2:1920x1080 \
  output.webm

我曾经在一个远程医疗项目里用这套方案。医生端网络不稳定，但 VP9 的 SVC 让视频通话始终没断过——虽然偶尔降到 360p，但画面还能看。换成 H.264 的话，网络波动直接卡死。

1.3.2 直播场景

直播对编码速度要求很高。VP9 的编码速度确实不如 H.264，但如果你用硬件编码器或者多路并行，问题不大。我建议直播场景用 cpu-used 参数调到 2-3，配合 row-mt 1 开启多行并行编码。

避坑指南： 我曾经把 cpu-used 调到 5 想提速，结果画面出现大量块效应。后来发现 VP9 的 cpu-used 参数范围是 0-5，0 最慢但质量最好，5 最快但质量最差。直播场景建议 2-3，点播场景建议 0-1。

1.3.3 点播场景

点播是 VP9 的主场。YouTube 每天处理数十亿次 VP9 播放，这已经证明了它的可靠性。点播场景下，你可以用更慢的编码预设换取更高的压缩率。我习惯用 -deadline good -cpu-used 0，配合两遍编码（-pass 1 和 -pass 2）。

# 第一遍：分析
ffmpeg -i input.mp4 \
  -c:v libvpx-vp9 \
  -b:v 2000k \
  -pass 1 \
  -deadline good \
  -cpu-used 0 \
  -f webm /dev/null

# 第二遍：实际编码
ffmpeg -i input.mp4 \
  -c:v libvpx-vp9 \
  -b:v 2000k \
  -pass 2 \
  -deadline good \
  -cpu-used 0 \
  output.webm

注意： VP9 的两遍编码不是简单的「第一遍分析，第二遍编码」。第一遍会生成日志文件（.log），第二遍读取日志做码率分配。如果你换了分辨率或帧率，日志必须重新生成。我见过有人直接复用日志，结果输出视频全是马赛克。

1.4 VP9 知识体系总览

下面这张图是我自己梳理的 VP9 学习路径。你可以把它当成整个课程的地图。

这张图把 VP9 的知识点分成了三大块：编码原理、调优实战、场景落地。后面的课程会沿着这个结构展开。你先把这张图存着，学到后面章节时回来对照，会发现整个体系是串起来的。

本章小结：

VP9 是 Google 主导的开源编码标准，无专利授权费
编码效率接近 H.265，但解码兼容性更好（尤其在浏览器端）
WebRTC 场景中 VP9 的 SVC 能力是独有优势
直播场景注意 cpu-used 参数，点播场景推荐两遍编码
知识体系分为编码原理、调优实战、场景落地三大模块