# DVC｜视频基础、预测与残差
> 用户问题：先教我基础知识
>
> 来源：本聊天 `01a13ae4-6cb2-7f23-b09c-942490bf8387`，公开回复记录第 145 行，2026-10-14 23:54:29 +08:00。
>
> 可核实定位：讲解辅助交互演示；原自查问题。
我们先学最基础的一层：**视频为什么能压缩，以及“预测”和“残差”是什么。**
一张数字图像，可以理解为一张像素表。以常见的 8 位灰度图为例，每个像素用一个 0～255 的数字表示亮度：0 是黑，255 是白。彩色图像还需要表示颜色。
视频则是一系列按时间播放的图像，每张图像叫一帧。30 fps 表示每秒播放 30 帧。每一帧都包含大量像素，直接保存所有像素会需要很多数据。
视频压缩能省空间，是因为画面中存在大量**重复或可以预测的信息**，也叫“冗余”：
- **空间冗余：** 同一帧里的相邻像素往往很相似，例如一大片天空。
- **时间冗余：** 相邻帧往往很相似，例如背景没变，只有一个人向右移动。
先看时间冗余。假设上一帧里有一个亮块，当前帧里它向右移动了一点。我们可以根据上一帧，生成一张对当前帧的猜测，这张猜测叫**预测帧**。
接着计算：
\[
\text{残差}=\text{当前帧}-\text{预测帧}
\]
“残差”就是预测错了多少。接收端只要拥有相同的预测帧，就可以恢复当前帧：
\[
\text{当前帧}=\text{预测帧}+\text{残差}
\]
下面用一行像素演示。你可以切换预测方式，观察残差如何变化。
[交互演示：预测方式与残差](DVC_讲解资源/interactive/video-prediction-basics.html)
[演示在打印中的全部三种状态](#prediction-static)
**预测越准确，残差通常越容易压缩。** “沿用上一帧”已经能利用重复信息；根据运动调整上一帧，往往能得到更准确的预测。不过，运动参数也需要传输，因此还要考虑它消耗多少比特。演示中的非零数量用于帮助理解，不能直接当成真实码率。
这里就引出了两个容易混淆的概念：
- **运动估计：** 找出画面中的内容移动了多少，例如“向右移动一格”。
- **运动补偿：** 根据这个移动量调整参考帧，生成预测帧。
到这里，预测和残差相加可以精确恢复原图。常见的有损压缩还会加入**量化**：把一些数值近似表示。例如，把 101 和 103 都近似为 100，表示会更简单，但细微差别丢失了。这就是重建图像与原图出现误差的一个主要原因。
H.264 的基本流程可以先这样记：
**生成预测 → 计算残差 → 变换 → 量化 → 熵编码**
其中，变换把残差换成更适合压缩的表示；熵编码把这些符号编码成比特。接收端再通过相应的解码过程重建图像。[H.264 标准中的基本编码说明](https://www.itu.int/rec/dologin_pub.asp?id=T-REC-H.264-202108-S%21%21PDF-E&lang=f&type=items)
实际编码时，预测使用的是**已经重建的参考帧**。因为接收端也只有重建结果，两端必须从相同的信息出发，才能生成相同的预测。
先检查一个小例子：某个像素的预测值是 100，真实值是 108，那么残差是多少？如果压缩后解码出的残差变成了 6，最终重建值又是多少？
**讲解辅助演示的打印内容（全部交互状态）**
上一帧：`[20, 20, 100, 100, 20, 20, 20, 20]`；当前帧：`[20, 20, 20, 100, 100, 20, 20, 20]`。
| 预测方式 | 预测像素 | 残差（当前减预测） | 非零数量 | 运动说明 |
|---|---|---|---:|---|
| 沿用上一帧 | 20, 20, 100, 100, 20, 20, 20, 20 | 0, 0, -80, 0, 80, 0, 0, 0 | 2/8 | 0 格 |
| 上一帧向右移 1 格 | 20, 20, 20, 100, 100, 20, 20, 20 | 0, 0, 0, 0, 0, 0, 0, 0 | 0/8 | 向右 1 格 |
| 不预测 | 0, 0, 0, 0, 0, 0, 0, 0 | 20, 20, 20, 100, 100, 20, 20, 20 | 8/8 | 无 |
这是已讲过的自构造示例，不是论文图表。非零数量不能替代实际码率。