# VOD 深度剖析（二）：视频编解码器 —— 为什么一部 4K 电影只需 5 GB

> 视频压缩的工作原理、为什么 H.264 至今仍占主导、何时选择 H.265 或 AV1、逐标题编码、VMAF 质量指标，以及可上手实操的 ffmpeg 示例。

- 作者: zhuermu
- 发布: 2026-05-10
- 网页版: https://zhuermu.com/blog/vod-deep-dive-part-2-video-codecs-h264-h265-av1/

---
> *本文是 [VOD 流媒体深度剖析](/blog/vod-deep-dive-part-1-video-fundamentals/) 系列的第二篇。*

---

## 先算笔账：未压缩的视频到底有多大？

从[第一篇](/blog/vod-deep-dive-part-1-video-fundamentals/)中我们知道：

一段 1080p、30 fps、YUV 4:2:0、8 比特的**未压缩**视频流：

```
Per-second size = 1920 × 1080 × 1.5 (YUV 4:2:0) × 30 ÷ 1024² ≈ 89 MB/sec
```

于是：

- **1 分钟** ≈ 5.3 GB
- **90 分钟的电影** ≈ 480 GB
- **4K 电影**（像素量是其 4 倍）≈ 1.9 TB

而 Netflix 上一部真实的 4K 电影只有 5–15 GB。这意味着：

> **编码把视频压缩到了原始体积的 1% 以下。**

这不是魔法，而是几十年数学积累的成果。下面就来看看它是怎么做到的。

---

## 编码与解码：一枚硬币的两面

```
Raw video (89 MB/s)          Compressed video (2 MB/s)        Display
    ┃                             ┃                            ┃
    ▼                             ▼                            ▼
 ┌──────┐    encode           ┌──────┐    decode            ┌──────┐
 │ Raw  │  ──────────────►   │ File │  ────────────────►   │ Play │
 │ file │    (x264/x265)     │      │   (player/hardware)  │      │
 └──────┘                    └──────┘                      └──────┘
```

- **编码（Encoding）**：把大文件压缩成小文件 → **慢，极度消耗 CPU/GPU**
- **解码（Decoding）**：从压缩文件中重建图像 → **快，手机都有专用硬件**

**编码器（Encoder）** + **解码器（Decoder）** = **编解码器（Codec，coder-decoder）**。

为什么编码要慢那么多？因为编码需要尝试所有可能，才能找到最优的压缩方案；而解码只是照着指令执行。就好比把一件奇形怪状的物品塞进箱子，与打开箱子拿出来的区别。

---

## 视频压缩的两条主线

### 主线一：帧内压缩（Intra-frame）

**把每一帧单独压缩** —— 与 JPEG 类似：

- 人眼对低频信息（大块色彩）敏感，对高频细节（噪点、细小边缘）不敏感
- **DCT（离散余弦变换，Discrete Cosine Transform）** 把像素从空间域转换到频率域
- 不重要的高频系数在量化时被舍弃

由此产生 **I 帧（I-frame）** —— 每一帧都能独立解码。

### 主线二：帧间压缩（Inter-frame）

利用相邻帧几乎完全相同这一事实 —— 只存储差异。

```
Frame N (I-frame): Complete image
┌─────────────┐
│   🚗         │
│  ___________ │  ← Stored in full
└─────────────┘

Frame N+1 (P-frame): Only the difference
"Move the car in frame N 15 pixels to the right"
─────────► A few bytes to describe
```

其核心技术是 **运动估计（Motion Estimation）+ 运动补偿（Motion Compensation）**：

1. 把帧划分成小块（宏块，通常为 16×16 或 8×8）
2. 对每个块，在前一帧中搜索最佳匹配
3. 只记录**运动向量**（移动了多远）+ **残差**（残留的微小差异）

帧间压缩的效率远高于帧内压缩 —— 这正是视频比一串 JPEG 图像序列小上好几个数量级的原因。

---

## 其他编解码技术（知道有它们即可，不必死记）

| 技术 | 作用 | 效果 |
|-----------|-------------|--------|
| **变换（Transform）** | DCT / 整数变换：像素 → 频率系数 | 为量化准备数据 |
| **量化（Quantization）** | 把系数除以一个整数并取整 | 质量/压缩的主旋钮 |
| **熵编码（Entropy Coding）** | CABAC / CAVLC：常见符号用更少比特表示 | 无损的最终压榨 |
| **环内滤波（In-loop Filter）** | 消除块效应 | 图像更平滑 |
| **SAO / ALF**（H.265+） | 自适应样点偏移 | 减少边缘伪影 |
| **多参考帧（Multi-reference）** | P/B 帧可参考多个历史帧 | 预测更准 → 残差更小 |

实际使用中，你通过编码器参数来控制这些技术 —— 无需自己去实现。

---

## 五大编解码器

### H.264 / AVC（2003）：通用黄金标准

- **兼容性**：几乎**每一台**能播放视频的设备都支持它
- **压缩率**：作为我们对比的基准
- **专利**：需付费（MPEG LA 专利池），但仍是行业默认
- **最适合**：追求最大兼容性、算力受限的场景

H.264 已经问世 20 多年，至今仍是 YouTube、Facebook 和 Zoom 的兜底编解码器。

### H.265 / HEVC（2013）：压缩更好，授权噩梦

- **压缩率**：同等质量下相比 H.264 节省约 37% 码率
- **专利**：混乱而昂贵 —— 三个专利池（MPEG LA、HEVC Advance、Velos Media）外加大量未入池专利
- **硬件解码**：iPhone 7+（2016）、安卓 6+ 旗舰机、大多数 4K 电视
- **最适合**：Apple 生态、4K 流媒体、对带宽敏感的场景

正是这一团糟的授权局面，导致 HEVC 在 Web 上的普及格外缓慢。Chrome 和 Firefox 都曾抵制加入对它的支持。

### VP9（2013）：Google 的免费替代方案

- **出品方**：Google（收购了 On2 Technologies）
- **压缩率**：接近 H.265
- **专利**：**免版税**
- **主要用途**：YouTube、Google Meet
- **注意**：iOS **不**原生支持 VP9

### AV1（2018）：免版税的下一代

- **出品方**：AOMedia 联盟（Google、Netflix、Meta、Amazon、Cisco、Microsoft、Intel、Apple 等）
- **压缩率**：**相比 H.264 节省约 53%**，比 H.265 再好约 25%
- **专利**：**免版税**
- **硬件解码**：iPhone 15 Pro+（2023）、Pixel 6+、骁龙 8 Gen 2+、Intel Arc、NVIDIA RTX 40+
- **编码速度**：早期 SVT-AV1 实现已大幅提升；CPU 编码约比 H.265 慢 2–5 倍

Netflix、YouTube、TikTok 和 Meta 都在朝着以 AV1 为主力编解码器的方向迈进。

### H.266 / VVC（2020）：最新一代，尚未成为主流

- **压缩率**：相比 H.264 节省约 78%，比 AV1 再好约 25–30%
- **硬件**：从 2024 年起在旗舰机上出现；消费端覆盖率仍很低
- **状态**：观望

### 对比表

| | H.264 | H.265 | VP9 | AV1 | H.266 |
|---|---|---|---|---|---|
| 年份 | 2003 | 2013 | 2013 | 2018 | 2020 |
| 相比 H.264 的节省 | 基准 | **37%** | ~30% | **53%** | **78%** |
| 编码速度 | 最快 | 中 | 中 | 慢 | 最慢 |
| 解码负载 | 最轻 | 中 | 中 | 较高 | 重 |
| 兼容性 | 通用 | 很好 | 好（Web） | 增长中 | 低 |
| 版税 | 付费 | **高且混乱** | 免费 | **免费** | 付费 |

这些百分比数字来自特定的测试集和测试条件（基于 VMAF/PSNR 的 BD-rate）。实际结果会因内容类型（动画 vs. 实拍 vs. 屏幕录制）而有很大差异。切勿把它们当作绝对的营销宣传口径。

---

## 实践中如何选择编解码器

```
Where do your users watch?
│
├── ① Web browsers + all phones + legacy set-top boxes
│     → Must have H.264 (fallback)
│     → Add H.265 (iOS) + AV1 (Android flagships / modern Chrome) for bandwidth savings
│
├── ② Native app only (iOS + Android + optional TV)
│     → H.264 + H.265 as primary; AV1 gradual rollout by device capability
│
├── ③ Web-first, global bandwidth cost matters (YouTube/Netflix scale)
│     → AV1 primary + H.264 fallback
│
└── ④ 4K / HDR premium content
      → H.265 / AV1 + Dolby Vision
```

### 一份典型的短视频编码阶梯

| 档位 | 分辨率 | H.264 码率 | H.265 码率 | AV1 码率 |
|------|-----------|--------------|--------------|-------------|
| 低 | 360p | 500 kbps | 350 kbps | 250 kbps |
| 中 | 540p | 900 kbps | 650 kbps | 480 kbps |
| 主 | 720p | 1.5 Mbps | 1.0 Mbps | 750 kbps |
| 高 | 1080p | 3.5 Mbps | 2.2 Mbps | 1.6 Mbps |

---

## 上手实操：用 ffmpeg 压缩一段视频

### 基础 H.264

```bash
ffmpeg -i input.mov -c:v libx264 output.mp4
```

### CRF 质量控制

```bash
ffmpeg -i input.mov \
  -c:v libx264 -preset medium -crf 23 \
  -c:a aac -b:a 128k \
  output.mp4
```

| 参数 | 含义 |
|-----------|---------|
| `-preset medium` | 速度/压缩的权衡。可选：ultrafast → veryslow。**越慢 = 同等质量下文件越小** |
| `-crf 23` | 质量目标，0–51。**越低 = 质量越好、文件越大**。默认值为 23。 |
| `-c:a aac -b:a 128k` | 音频：AAC，128 kbps |

CRF 速查：18 = 视觉无损，23 = 高质量，28 = 可接受（能看出压缩痕迹）。

### 适配流媒体的 VOD 编码

```bash
ffmpeg -i input.mov \
  -c:v libx264 -preset slow -crf 22 \
  -profile:v high -level 4.0 \
  -g 60 -keyint_min 60 -sc_threshold 0 \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4
```

| 参数 | 原因 |
|-----------|-----|
| `-g 60 -keyint_min 60` | 每 60 帧一个 I 帧。在 30 fps 下 = 2 秒的 GOP，与切片对齐。 |
| `-sc_threshold 0` | 关闭场景切换自动插入 I 帧。确保所有码率档位在相同位置都有 I 帧。 |
| `-movflags +faststart` | 把 MP4 的"目录"（moov box）移到文件开头 —— 从而支持边下边播。详见[第四篇](/blog/vod-deep-dive-part-4-container-formats-mp4-fmp4-cmaf/)。 |
| `-profile:v high -level 4.0` | 兼容性：Level 4.0 最高支持到 1080p30。 |

### H.265 编码

```bash
ffmpeg -i input.mov \
  -c:v libx265 -preset medium -crf 26 \
  -tag:v hvc1 \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output_hevc.mp4
```

注意：要达到同等视觉质量，H.265 的 CRF 值需要比 H.264 高约 3–5（CRF 26 ≈ H.264 的 CRF 22）。`-tag:v hvc1` 标签是 Apple 设备识别该文件所必需的。

### 压缩结果（1 分钟 4K 源片，约 2 GB 原始体积）

| 命令 | 输出大小 | 占比 |
|---------|------------|-------|
| 未压缩 YUV | ~2 GB | 100% |
| H.264 CRF 23 | ~30 MB | 1.5% |
| H.264 CRF 18 | ~80 MB | 4% |
| H.265 CRF 26 | ~18 MB | 0.9% |
| AV1（SVT-AV1 preset 8） | ~12 MB | 0.6% |

压缩比达 100–500 倍，在手机屏幕上几乎看不出差别。

---

## 逐标题（Per-Title）与逐镜头（Per-Shot）编码

默认做法是对所有内容使用固定的码率阶梯。但问题在于：

- 一部**卡通片**（色块平坦、细节少）在 1080p@1000k 下就已经很好看
- 一场**演唱会**（灯光闪烁、运动剧烈）在 1080p@5000k 下仍能看出压缩痕迹

**逐标题编码（Per-Title Encoding，Netflix，2015）**：根据每部作品的视觉复杂度，为其单独计算最优的码率阶梯。

```
Traditional: Same ladder for every movie
  360p@500k / 720p@1500k / 1080p@4000k

Per-Title: Custom ladder per movie
  Cartoon:  360p@300k / 720p@800k / 1080p@1800k   (saves money)
  Concert:  360p@700k / 720p@2200k / 1080p@5500k  (needs more bits)
```

**逐镜头编码（Per-Shot Encoding，Netflix，2018）** 走得更远：按场景切换把电影拆分，再以 **VMAF** 为质量目标对每个镜头单独优化。据称在同等质量下可额外节省 17%。

对大多数平台而言，云厂商提供的"智能转码"模板（AWS MediaConvert QVBR、阿里云"窄带高清"）无需你自建体系，就能拿到其中的大部分收益。

---

## 硬件编码 vs. 软件编码

| 方式 | 实现 | 速度 | 质量 | 最适合 |
|----------|---------------|-------|---------|----------|
| **软件**（CPU） | libx264 / libx265 / SVT-AV1 | 慢 | **最好** | VOD 离线转码 |
| **硬件**（GPU/ASIC） | NVIDIA NVENC、Intel QSV、Apple VideoToolbox | **快 5–50 倍** | 略低 | 直播、实时场景 |

VOD 应当使用软件编码：你只需编码一次，而带宽节省会长久受益。直播则*必须*使用硬件编码 —— 你不可能花 10 秒去编码 1 秒的视频。

---

## VMAF、PSNR、SSIM：衡量视觉质量

| 指标 | 全称 | 方法 | 取值范围 | 与人眼感知的相关性 |
|--------|-----------|--------|-------|----------------------------------|
| **PSNR** | 峰值信噪比（Peak Signal-to-Noise Ratio） | 像素级差异 | 0–∞ dB（越高越好） | 弱 |
| **SSIM** | 结构相似性（Structural Similarity） | 亮度/对比度/结构 | 0–1（越高越好） | 中 |
| **VMAF** | 视频多方法评估融合（Video Multi-Method Assessment Fusion） | 多特征的机器学习融合 | 0–100（越高越好） | **强** |

**VMAF**（由 Netflix 开源）是业界公认的感知质量标准：

- VMAF ≥ 93：视觉无损
- VMAF ≈ 80：高质量
- VMAF ≈ 60：可接受
- VMAF ≤ 40：明显的压缩伪影

---

## 关键要点

1. 视频压缩通过**帧内压缩**（逐帧压缩每张图像）+ **帧间压缩**（只存储差异）将体积压到原始大小的 <1%。
2. 编码慢，解码快。编码器 + 解码器 = **编解码器（Codec）**。
3. **H.264** 是通用兜底方案。**H.265** 节省 37% 但授权混乱。**AV1** 免费且节省 53%。**VVC** 是未来，但还没准备好。
4. VOD 转码要点：**CRF 质量控制、GOP 对齐、faststart、关闭场景切换**。
5. **逐标题 / 逐镜头**编码是进阶优化；云端"智能转码"已能覆盖大部分收益。
6. **VMAF** 是业界标准的质量指标。

---

*上一篇：* [第一篇：视频基础](/blog/vod-deep-dive-part-1-video-fundamentals/)

*下一篇：* **[第三篇：音频基础](/blog/vod-deep-dive-part-3-audio-fundamentals/)**

---

## 常见问题

### H.264、H.265 和 AV1 该选哪个？

H.264 必须保留作为兜底——几乎所有设备都支持。H.265 同等画质下比 H.264 省约 37% 码率，iPhone 7 及以后、多数 4K 电视都有硬解，但专利授权混乱昂贵。AV1 比 H.264 省约 53% 且完全免版税，缺点是硬解普及较晚（iPhone 15 Pro 起）。常见做法：H.264 兜底，iOS 端加 H.265，新款安卓和现代浏览器上逐步铺 AV1。

### 视频压缩到底能把文件缩小多少倍？

未压缩的 1080p 30fps 视频每秒约 89 MB，一部 90 分钟电影约 480 GB，4K 更是接近 1.9 TB。现代编码器通过帧内压缩（类似 JPEG 的 DCT 变换）加帧间压缩（只记录运动向量和残差）把体积压到原始的 1% 以下——Netflix 上一部真实 4K 电影只有 5–15 GB，压缩比可达 100–500 倍。

### VMAF 分数多少算画质好？

VMAF 是 Netflix 开源的感知质量指标，用机器学习融合多种特征给视频打 0–100 分，与人眼主观感受的相关性远强于 PSNR、SSIM 等传统像素级指标。一般来说：93 分以上属于视觉无损，80 分左右是高质量，60 分左右勉强可接受，40 分以下就会出现明显的压缩伪影。


---

## 参考资料

- [H.264: Advanced video coding](https://www.itu.int/rec/T-REC-H.264) — ITU-T
- [H.265: High efficiency video coding](https://www.itu.int/rec/T-REC-H.265) — ITU-T
- [Alliance for Open Media (AV1)](https://aomedia.org/) — AOMedia
- [VMAF — perceptual video quality metric](https://github.com/Netflix/vmaf) — Netflix / GitHub