视频编解码（二）：H.264 是怎么把 10GB 压成 100MB 的？

上一篇我们算了笔账：一分钟 1080P 原始视频高达 10.5 GB。但你从 B 站下载回来的 40 分钟高码率视频，拢共才 500 MB。中间这 98% 的数据去哪了？答案是：视频编码器干掉了"你肉眼压根看不见的东西"。

大家好，我是黒漂技术佬。

这一篇我们直奔主题------视频编码的核心原理。不讲数学公式推导，用你能听懂的人话把 帧内预测、帧间预测、宏块、GOP、码率控制 这些唬人概念全部拆干净。

一、编码的核心思路：找冗余，然后扔掉

视频数据里充满了三种冗余：

1.1 空间冗余（同一帧内部）

打开一张照片，你会发现相邻像素的颜色往往很接近：蓝天背景里，下一个像素大概率也是蓝的；白色墙壁上，一片区域都是接近的白。一个像素一个像素单独存，99% 是浪费。

1.2 时间冗余（相邻帧之间）

这是视频压缩的大头。一段视频里，前后两帧通常只有很小一部分在变化------新闻主播嘴在动，背景一直不变；足球场上，草皮连续几十帧一模一样，只有球和球员在位移。

如果不利用这个，把每一帧当成独立图片去存，你就是个冤大头。

1.3 视觉冗余（人眼感知不到的部分）

上一篇讲的色度抽样就是利用人眼对颜色不敏感。编码器还会继续深挖：人眼对高频细节（细碎纹理）的敏感度低于低频轮廓（物体边缘），对极亮和极暗区域的细节也迟钝。这些地方都可以用更少的数据糊弄过去。

二、帧内预测：一帧内部的"猜谜游戏"

编码器把画面切成一个个 宏块（Macroblock），H.264 的宏块是 16×16 像素。每个宏块独立编码时，不直接存原始像素值，而是：

看看周围的宏块（左边、上边、左上角）已经编码完的像素是什么。
基于这些邻居预测当前宏块大概长什么样。
只存残差（Residual）：预测值和真实值之间的差值。

因为相邻区域高度相似，残差大多是接近 0 的小数字，压缩算法处理起来极其高效。就好比你跟朋友描述一张图：你不会逐个像素报颜色，你会说"左边那个蓝方块往右挪两格"，这比存全部像素省太多数据。

三、帧间预测：I 帧、P 帧、B 帧，全家桶

这是视频编码最大的杀手锏。编码器把帧分成三种类型：

3.1 I 帧（Intra-coded，关键帧）

完全独立编码的完整画面，不依赖任何其他帧。像一个"存档点"，解码器读到这里就能立刻恢复一整张图。I 帧体积最大，但它是一切帧间预测的起点。

3.2 P 帧（Predicted，前向预测帧）

P 帧只记录相对于前面已编码帧（I 或 P）的变化。如果两帧之间只有一个小人在动，那 P 帧就只存这个小人移动了多少像素、背景部分直接复用前一帧的数据。

一个 P 帧的大小可能只有 I 帧的 1/5 到 1/10。

3.3 B 帧（Bi-predicted，双向预测帧）

比 P 帧更狠：B 帧同时参考前面和后面的帧。比如视频中一个人走过一面墙，B 帧可以从"人还没到的前帧"拿到墙的像素，从"人已经走过的后帧"拿到另一部分，拼出当前画面。B 帧压缩率最高，但编解码复杂度也最高------因为解码时要等前后的参考帧都就绪。

3.4 一张图讲清楚

复制代码

时间轴 →

  I₀ ←──── P₁ ←──── B₂ ←──── P₃
  │        │  ↘      ↙  │        │
  │        │    ××××    │        │
  │        │  双向参考   │        │
  └── 参考 ──┘           └── 参考 ──┘

I 帧：完整画面，体积最大，独立解码
P 帧：只参考前面的帧，记录变化部分
B 帧：同时参考前帧和后帧，体积最小

四、GOP：一组帧的"团队作业"

一组连续的 I、P、B 帧的排列结构叫 GOP（Group of Pictures，图像组）。

一个典型的 GOP 结构：I B B P B B P B B P ... I（下一个GOP开始）

GOP 有两个关键参数：

GOP 长度：两个 I 帧之间的帧数。长度越大，I 帧比例越低，整体压缩率越高，但拖进度条时的 seek 延迟也越大（因为要往前找最近的 I 帧开始解码）。通常 1~3 秒一个 I 帧。
参考帧数量：P/B 帧可以向前/后参考多少帧。参考越多，预测越准，压缩率越高，但解码器需要的缓存也越大。

4.1 为什么你拖进度条会卡一下？

你拖到一个 B 帧上，解码器不能直接解------它必须先找到前面最近的 I 帧，解码那条链路（I → P → P → ...），把前面的帧全部算完，才能解出你拖到的这一帧。GOP 越长，这个"算完"的过程越久，卡顿越明显。所以直播场景通常用短 GOP（比如 1 秒一个 I 帧），追求低延迟；点播可以适当拉长 GOP 来省带宽。

五、H.264 vs H.265：青出于蓝

H.264（也叫 AVC，Advanced Video Coding）是过去 20 年互联网视频的绝对霸主，你手机拍的视频、B 站的 1080P、Zoom 的视频会议，大概率都在用 H.264。它优秀，但老了------标准于 2003 年发布，彼时 iPhone 还没出生。

H.265（也叫 HEVC，High Efficiency Video Coding）是继任者，2013 年发布，核心改进：

能力	H.264 (AVC)	H.265 (HEVC)
宏块尺寸	固定 16×16	64×64 到 8×8 自适应（CTU）
帧内预测方向	9 种	35 种
压缩率	基准	同画质省 50% 码率
4K/8K 支持	吃力	原生
编码时间	快	慢 3~10 倍
专利授权	统一低价	三方收费，贵

简单粗暴的结论：H.265 能在 H.264 一半的码率下达到同等画质。 一部 H.264 编码的 1080P 蓝光电影（约 15 GB），用 H.265 同等画质只需 7~8 GB。

那为什么 H.265 还没一统天下？专利费烂账。MPEG LA、HEVC Advance、Velos Media 三家分别收钱，浏览器厂商（尤其是 Mozilla、Google）不乐意交，于是 Google 自己搞了 VP9 ，后来又联合一堆巨头推 AV1（完全免费开源）。编码格式的江湖，技术强不是唯一规则，钱和阵营才是。

六、码率控制：带宽有限，怎么分配数据？

编码的最后一步：给定一个目标码率（比如 2 Mbps），怎么把有限的"数据预算"分给每一帧？

6.1 CBR（恒定码率）

不管画面是静态背景还是爆炸特效，码率恒定。优点是网络带宽占用稳定，适合直播推流；缺点是画面复杂时清晰度会崩。

6.2 VBR（可变码率）

静态场景少给点数据，高速运动/复杂画面多给点数据。适合点播、本地存档，同等平均码率下画质明显优于 CBR。

6.3 CRF（恒定画质因子）

FFmpeg 用户的宠儿。你设定一个画质目标（0~51，越小越好，推荐 18~28），编码器自动分配码率来达到这个画质，文件最终大小完全由编码器决定。CRF 18 接近视觉无损，CRF 23 是大多数人的甜点。

复制代码

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium output.mp4

这条命令如果看不懂，别急------FFmpeg 实战篇会细讲。

七、一个编码实战的"隐形坑"：preset

H.264/H.265 编码器都有一个 preset 参数，控制编码速度和压缩率的权衡。x264 的 preset 从快到慢分别是：

复制代码

ultrafast → superfast → veryfast → faster → fast → medium → slow → slower → veryslow → placebo

medium 是默认。ultrafast 比 medium 快 5~10 倍，但压缩率会差 20~30%；veryslow 压缩率最好，但编码时间是 medium 的 5~10 倍。placebo 如其名：比 veryslow 又慢不少，压缩率提升微乎其微------纯安慰剂。

实际使用时，直播选 veryfast，本地转码选 medium，做存档压片可以上 slow。

本篇核心回顾

概念	一句话理解
空间冗余	一帧内相邻像素相似，帧内预测省数据
时间冗余	前后帧大部分相同，帧间预测省数据
I 帧	完整画面，独立解码，关键帧/存档点
P 帧	只记录跟前面帧的差异
B 帧	同时参考前后帧，压缩率最高
GOP	I/P/B 帧的编组，长度影响压缩率和 seek 延迟
H.265 vs H.264	同画质省一半码率，但编码慢、专利贵
CBR / VBR / CRF	码率恒定 / 码率浮动 / 恒定画质
preset	快速编码还是极致压缩，自己选

我是黒漂技术佬，下篇见。