简介：这份H.264学习资料包面向视频编码初学者、开发者与相关方向研究者，围绕“从标准规范到源码实现”提供较完整的学习路径，可用于理解宏块划分、熵编码、运动估计、变换量化等核心环节，也适合作为编解码器开发与课程实践的参考资料。压缩包约13.65MB，文件总数与主要类型明细暂无数据；从现有信息看，内容涉及H.264源代码、中文标准协议、英文官方文档以及配套讲解和编解码库资料，便于对照理论阅读实现。已有205人学习，说明其在视频编码入门与进阶场景中具备一定参考价值。读者可借助标准文档厘清语法、数据结构与解码流程，再通过源码观察编码器、解码器及辅助工具的组织方式，配合文档中的预测技术、率失真优化等主题建立框架认知；若需深入细节，还可回到官方文档查证，形成从规范到代码的闭环。

1. 预测才是主力：H.264 源代码里最反直觉的一课

把 1080p 压到 2 Mbps 靠的不是把画面糊掉，而是让解码器替编码器“猜”出绝大多数像素，这是翻 H.264 源代码时最先撞上的反直觉事实。配套的 H.264 文档只规定解码端怎么把比特流还原成图像，至于怎么找到那个猜得最准的方式，规范一个字都不写。于是同一份文档能支撑出完全不同的编码器，而所有解码器必须逐比特一致，因为参考帧一旦有半点偏差，误差会顺着预测链一路滚下去，越滚越大。搞清这条分界线，后面残差、变换、熵编码的每一处设计才有落脚点，也才能看懂源码里那些看上去“多此一举”的约束到底在防什么。

2. 宏块与片：码流为什么按 16×16 切开

2.1 NAL 单元、起始码与防竞争字节

打开码流第一步不是解码图像，而是切分。H.264 把整条比特流切成一个个 NAL 单元，每个单元前面挂 3 或 4 字节的起始码0x000001/0x00000001，后面跟一个 1 字节的头。这 8 个比特被切得很紧：1 位 forbidden_zero_bit 恒为 0，2 位 nal_ref_idc 表示这个单元要不要被当作参考，5 位 nal_unit_type 才是真正的类型。

这里有个容易被忽略的设计：起始码是固定比特模式，而图像数据里完全可能自然出现00 00 01。标准给出的解法是防竞争字节，编码器只要发现载荷里出现00 00 00、00 00 01、00 00 02、00 00 03这四种前缀，就在第三个字节前插入一个0x03；解码器则在00 00 03处把03丢掉。代价是极少数情况下多花 1 字节，换来的是不需要转义整个载荷、可以直接按模式扫描切分——这就是为什么很多解码器的第一个函数是扫起始码，而不是解析语法。

参数集和图像数据分开放，是另一个关键取舍。SPS/PPS 携带的是“怎么解释后面的比特”的元信息，把它们独立成 NAL，意味着一帧图像可以引用一个带外传输的参数集，也可以在码流里周期性重发以对抗丢包。代价是解码器必须维护一个小状态机：见到 SPS 就更新序列参数，见到 PPS 就更新图像参数，见到条带头就按pic_parameter_set_id去找对应的那一份。漏掉任何一次更新，后面的解析全错。

2.2 帧内预测的九种模式与重建像素依赖

宏块是 16×16 的亮度块加两个 8×8 的色度块，4:2:0 采样下一共 256 + 64 + 64 = 384 个样本。帧内编码的核心动作是：用左边和上边已经重建好的像素，去预测当前块。亮度 4×4 有 9 种模式（垂直、水平、DC，外加 6 个斜向），亮度 16×16 有 4 种（垂直、水平、DC、平面），色度 8×8 也是 4 种。

注意“已经重建”这四个字。编码器手里明明有原始像素，却必须拿解码器重建出来的、带量化误差的像素去做预测，原因是预测必须在两端完全一致。一旦编码器用原始像素预测、解码器用重建像素预测，两者的残差就对不上，误差立刻发散。这也是帧内预测必须严格按光栅顺序进行的原因：当前宏块上方和左方的邻居必须已经解完。

/* 4x4 亮度帧内预测的简化写法：模式 0（垂直）与模式 2（DC） */ static void intra4x4_pred(int16_t pred[16], const uint8_t *top, const uint8_t *left, int mode, int have_top, int have_left) { int i, j; switch (mode) { case 0: /* Vertical：整列复制上方像素 */ for (j = 0; j < 4; j++) for (i = 0; i < 4; i++) pred[j * 4 + i] = top[i]; break; case 2: { /* DC：用可用邻居的均值填满整块 */ int sum = 0, cnt = 0; if (have_top) for (i = 0; i < 4; i++) { sum += top[i]; cnt++; } if (have_left) for (j = 0; j < 4; j++) { sum += left[j]; cnt++; } int dc = cnt ? (sum + cnt / 2) / cnt : 128; /* 都不可用退化为中灰 */ for (i = 0; i < 16; i++) pred[i] = dc; break; } /* 模式 1（水平）与 3~8（斜向）同理，区别只在取样位置和加权系数 */ } }

这段代码里have_top/have_left两个标志位是规范级别的存在，不是实现者的自由发挥。当宏块位于图像最上沿、最左沿，或者跨越条带边界时，邻居被判定为“不可用”，DC 模式必须按四种情况分别取均值（仅上方有、仅左方有、两侧都有、都没有取 128）。斜向模式在邻居缺失时还有一套固定的替代取样规则。源码里这类分支看着琐碎，漏一个就是边缘一像素宽的亮线或者偏色。

模式选择本身在编码器侧，规范不管。常见做法是先用 SATD（哈达玛变换后的绝对值和）粗筛、再对候选模式做完整的变换量化重建，取率失真代价最小的那个。9 种模式全试一遍在大分辨率下极慢，所以实用编码器普遍做了一层快速判决：先看边缘方向直方图，只试 2 到 3 个候选。

2.3 4×4 整数变换与量化：用移位代替浮点 DCT

预测完剩下的就是残差，残差要走变换、量化、熵编码。教科书上讲视频压缩都写 DCT，但 H.264 实际用的是 4×4 整数变换，矩阵里只有 ±1、±2 这几个数。原因很实际：浮点 DCT 在不同平台上舍入结果可能不同，编码器和解码器一旦算出的系数差 1，重建图像就会分叉。整数变换把运算全部约束在 16 位整数加减和移位上，任何平台结果都严格一致。

/* 4x4 前向整数变换：先对行做蝶形，再对列重复一次 */ static void fdct4x4(const int16_t src[16], int16_t dst[16]) { int16_t tmp[16]; int i; for (i = 0; i < 4; i++) { /* 第一步：水平方向 */ const int16_t *a = src + i * 4; int s0 = a[0] + a[3], s1 = a[1] + a[2]; int d0 = a[0] - a[3], d1 = a[1] - a[2]; tmp[i * 4 + 0] = s0 + s1; /* 直流分量 */ tmp[i * 4 + 1] = 2 * d0 + d1; /* 系数 2 是 Cf 矩阵的整数近似 */ tmp[i * 4 + 2] = s0 - s1; tmp[i * 4 + 3] = d0 - 2 * d1; } for (i = 0; i < 4; i++) { /* 第二步：垂直方向，同样的蝶形 */ int s0 = tmp[0 * 4 + i] + tmp[3 * 4 + i]; int s1 = tmp[1 * 4 + i] + tmp[2 * 4 + i]; int d0 = tmp[0 * 4 + i] - tmp[3 * 4 + i]; int d1 = tmp[1 * 4 + i] - tmp[2 * 4 + i]; dst[0 * 4 + i] = (s0 + s1 + 1) >> 1; /* 行变换放大了 2 倍，这里补偿 */ dst[1 * 4 + i] = (2 * d0 + d1 + 1) >> 1; dst[2 * 4 + i] = (s0 - s1 + 1) >> 1; dst[3 * 4 + i] = (d0 - 2 * d1 + 1) >> 1; } }

这里的>> 1在真实实现里通常被折进量化乘法，因为每行每列都会引入一个 2 倍增益，合并成一个缩放矩阵一次性补掉更省指令。变换本身不是正交归一化的，它把一部分缩放责任推给了量化环节。

量化才是真正决定画质和码率的地方。H.264 的量化步长按 QP 索引，QP 每增加 6，步长翻倍，所以 QP 每加 1 步长约 12.5%。这个指数关系让码率控制有了一个非常顺手的旋钮：想省 10% 码率，就往上调一档 QP，而不是去改什么复杂参数。16×16 帧内预测的亮度 DC 系数会先过一遍 4×4 哈达玛变换再量化，色度 DC 同理，因为低频直流分量彼此高度相关，单独聚成一块处理能再省一点。

3. 帧间预测与环路滤波：运动补偿为什么能省掉大部分比特

3.1 运动矢量预测与 1/4 像素插值

帧间编码的思路朴素到近乎粗暴：这一帧的某个 16×16 块，大概率能在参考帧里找到一块长得差不多的，把“差多少”记下来就行。真正麻烦的是怎么把“位置偏移”这件小事编码得足够便宜。

如果每个宏块都独立编码一个运动矢量，光矢量本身就能吃掉可观码率。H.264 的做法是预测加残差：取左（A）、上（B）、右上（C）三个相邻块运动矢量的分量中值作为预测值，只编码差值。C 不可用时用左上（D）顶替。

/* 运动矢量中值预测：分量各自取中值，不是矢量层面的中值 */ static int median3(int a, int b, int c) { int max = a > b ? a : b; int min = a < b ? a : b; if (c > max) return max; if (c < min) return min; return c; } static void mv_pred_median(const mv_t *A, const mv_t *B, const mv_t *C, const mv_t *D, mv_t *pmv) { const mv_t *c = C->available ? C : D; /* 右上不可用，用左上顶替 */ pmv->x = median3(A->x, B->x, c->x); /* x、y 分量分别取中值 */ pmv->y = median3(A->y, B->y, c->y); }

选分量中值而不是平均值，是为了抗 outlier：只要三个邻居里有两个运动一致，第三个哪怕是乱飘的噪声，中值也不会被带偏。这个预测子在物体做匀速平移时几乎不需要额外比特，是帧间编码最划算的一笔投资。

3.2 四分之一像素精度与 6 抽头滤波器

真实运动极少刚好落在整像素格点上。H.264 允许运动矢量精确到 1/4 亮度像素，代价是参考块必须插值出来。半像素位置用 6 抽头 FIR 滤波器(1, -5, 20, 20, -5, 1) / 32计算，1/4 像素位置则用相邻的半像素或整像素做双线性平均。

这个滤波器不是随便凑的，它在频域上接近一个理想低通的一半，用来补偿下采样带来的混叠。代价也很直接：每插值一个半像素点要 6 次乘加，一个 16×16 块在 1/4 精度下最多要算 4 倍的插值点。这就是解码器里最热的几个函数之一，几乎所有优化都在做同一件事——把插值结果缓存起来复用。

多参考帧把复杂度又推高一层。一帧的宏块可以从最多 16 个已解码帧里挑一个作参考，编码器要为每个候选算一遍率失真代价。这笔账在编码端极贵，在解码端只是一个索引，正好体现了整套设计的一贯倾向：把复杂度留给编码器。

B 帧的直接模式更极端。所谓时域直接模式，是让当前块的参考块直接沿用“同位置块”的运动矢量，按 POC（图像顺序计数）距离做线性缩放，编码器连矢量差值都不用发。空域直接模式则从相邻块推。两种模式都不需要显式传矢量，代价是编码器要判断哪种更划算。

3.3 去块滤波：为什么必须放在解码环路里

变换量化是按 4×4 块独立做的，块与块的量化误差互不相干，边界上就会出现台阶，也就是常说的块效应。H.264 的解法是在解码完一帧、显示之前做一次自适应去块滤波。

关键在于“在环路里”：滤波后的帧要被存进 DPB，作为后续帧的参考。如果滤波只做在显示侧、不进参考帧，那么编码器预测时用的是滤波前的帧，解码器显示的是滤波后的帧，两边微妙的差异会被下一帧的帧间预测放大，形成漂移。

滤波强度由一个 0 到 4 的边界强度 bS 决定：

只有 bS 大于 0 还不够，还要过阈值：|p0 − q0| 小于 alpha 且 |p1 − p0| 小于 beta 才真正动像素，阈值由边界两侧的平均 QP 查表得到。这套设计的意图很清楚——真边缘（本身就是画面里的锐利边界）不要抹，量化台阶才抹。判断错了就是满屏油画感或者糊成一团，血泪经验大多栽在这一步的阈值表偏移上。

4. 熵编码：CAVLC 的码表和 CABAC 的状态机

4.1 CAVLC：用 nC 选表，靠上下文省比特

残差块经过变换量化，稀疏得厉害：大量系数是 0，非零系数集中在低频。CAVLC 就是冲着这个分布设计的。它按顺序编码五类语法元素：非零系数个数与拖尾 ±1 个数（合称 coeff_token）、每个拖尾系数的符号、每个非零系数的幅值、最后一个非零系数之前有多少个零、以及每个非零系数前面连续几个零。

第一项的编码表不是固定的，而是根据邻居推出来的 nC 动态选表。

/* CAVLC 码表选择：nC 越小说明邻块越稀疏，用越短的码表 */ static int calc_nc(const block_t *A, const block_t *B) { int nA = A->available ? A->total_coeff : 0; int nB = B->available ? B->total_coeff : 0; if (A->available && B->available) return (nA + nB + 1) >> 1; /* 两块都可用，取平均后向上取整 */ if (A->available) return nA; /* 只有左边可用 */ if (B->available) return nB; /* 只有上边可用 */ return 0; /* 都不可用，退到最低档码表 */ }

nC 落在 [0,2)、[2,4)、[4,8) 三个区间各有一张表，nC 等于 −1 时（4:2:0 的色度 DC 块）走一张专用表，nC 大于等于 8 时干脆改用 6 位定长码。这种“按上下文挑表”的思路本质上是在做在线自适应：邻块稀疏，当前块大概率也稀疏，用短表能省下可观比特。

拖尾系数的符号各占 1 比特，幅值用前缀加后缀的变长码，剩下的 total_zeros 和 run_before 又各有自己的表。整套下来平均能比定长编码省 10% 到 15%，代价是码表大、分支多，解码器里那几张常量表能占掉几十 KB 的只读数据。

4.2 CABAC 的二进制化与上下文建模

CABAC 把压缩再往前推一截，思路完全不同：先把所有语法元素拆成一串二进制符号（bin），再把这串 bin 送进一个自适应算术编码器。二进制化有四种基本式样——一元码、截断一元码、k 阶指数哥伦布码、定长码，按元素类型挑。

上下文建模是精髓。每个 bin 有一个上下文索引 ctxIdx，对应一个状态(pStateIdx, valMPS)：pStateIdx 是 0 到 63 的概率状态，valMPS 是当前最可能出现的符号。状态转移由两张固定表驱动，编码一个 MPS 就沿 transIdxMPS 走一格，编码一个 LPS 就沿 transIdxLPS 跳，概率因此能跟着实际分布慢慢收敛。

上下文的初始值不是固定的，而是由条带 QP 和初始化 ID 算出来：

/* 上下文初始化：m、n 来自标准里的表，随 QP 线性插值 */ int pre_ctx_state = clip3(1, 126, ((m * slice_qp) >> 4) + n); if (pre_ctx_state <= 63) { ctx->p_state_idx = 63 - pre_ctx_state; /* 概率低于一半 */ ctx->val_mps = 0; } else { ctx->p_state_idx = pre_ctx_state - 64; /* 概率高于一半 */ ctx->val_mps = 1; }

让初始概率跟 QP 挂钩是有道理的：QP 高意味着量化狠、残差稀疏，非零系数的先验概率天然不同，用同一个初始状态会让开头几百个符号编码效率明显偏低。

4.3 区间更新：什么时候需要重归一化

算术编码的骨架只有三个变量：区间下界 low、区间长度 range、待输出比特计数。查表得到当前上下文下 LPS 的子区间长度，然后分两条路走。

/* CABAC 单 bin 编码的核心循环（简化示意） */ static void cabac_encode_bin(ctx_t *ctx, int bin, cabac_t *c) { unsigned lps = range_tab_lps[ctx->p_state_idx][(c->range >> 6) & 3]; c->range -= lps; /* 先假定走 MPS，把 LPS 区间让出来 */ if (bin != ctx->val_mps) { /* 实际是 LPS */ c->low += c->range; /* 下界要跳过整个 MPS 区间 */ c->range = lps; if (ctx->p_state_idx == 0) /* 概率已经压到最低，翻转 MPS */ ctx->val_mps ^= 1; ctx->p_state_idx = trans_idx_lps[ctx->p_state_idx]; } else { ctx->p_state_idx = trans_idx_mps[ctx->p_state_idx]; } while (c->range < 256) { /* 重归一化：range 必须撑满 9 bit */ c->range <<= 1; c->low <<= 1; if (++c->bits_left == 8) { /* 攒够一字节就吐出去 */ c->buf[c->buf_pos++] = (uint8_t)(c->low >> 24); c->low &= 0xFFFFFF; c->bits_left = 0; } } }

range_tab_lps是 64×4 的常量表：行是概率状态，列是当前区间长度的高两位量化值。用区间长度做表索引而不是实时算乘法，是 CABAC 能做到实时解码的关键——整个算术编码环节没有一次除法，只有查表、加减和移位。

重归一化的触发条件是 range 小于 256。这是因为 range 用 9 位表示，一旦跌破 256，区间长度的高位信息就不足以支撑下一次查表，必须左移补位。真实实现里还要处理进位传播和 leading zero 计数，比上面这段复杂得多，但骨架就是这个循环。

CABAC 平均比 CAVLC 再省 10% 到 20% 码率，代价是编解码都必须严格串行——每个 bin 依赖前一个 bin 的区间状态，天然没法并行。这就是为什么高吞吐场景里仍有人愿意选 CAVLC：省下来的那点码率，可能还不够补上并行度损失。

5. 排查常见问题：花屏、绿边、时间戳错乱从哪来

5.1 花屏与绿边

现象一：第一帧就大面积花屏，色块呈规则方格。原因通常是参数集丢失。很多播放链路会把 SPS/PPS 当成“元数据”过滤掉，或者把它们缓存在与图像数据不同的位置，结果解码器拿到条带数据却不知道该按什么分辨率、什么熵编码模式解析。 解决办法是把类型 7 和 8 的 NAL 与图像数据绑在同一个访问单元里处理，解码器侧维护一份“当前生效参数集”，遇到新的 SPS/PPS 就整体替换，绝不做增量合并。

现象二：拖动进度条之后，画面持续花屏好几秒才恢复。原因是从非 IDR 帧开始解码。P/B 帧依赖前面的参考帧，中途切入等于把参考链从中间剪断，解码器只能用不完整的参考帧硬解。 解决办法是 seek 时回退到最近的 IDR 或 SPS 位置，把中间那一段全部丢弃，从 IDR 起解，再靠 POC 把显示顺序排回来。

现象三：画面右边缘或底部有一条绿色或紫色窄边。原因是没处理裁剪参数。编码器的宏块必须是 16 的整数倍，1080p 这种高度不是 16 倍数的分辨率，实际编码高度是 1088，多出来的 8 行是填充数据，靠 SPS 里的 frame_cropping 字段告诉解码器裁掉。 解决办法是解码完按裁剪参数裁，或者干脆在输出时按显示宽高做一次行拷贝，别指望渲染层自动处理。

5.2 参考帧管理与 POC

现象四：B 帧前后颠倒，人物动作看起来在倒放。原因是按解码顺序输出了。H.264 的码流顺序是解码顺序，不是显示顺序，B 帧的解码时间戳晚于显示时间戳。 解决办法是用 POC 排序。POC 的算法要区分 IDR 帧（直接归零）和非 IDR 帧（按 frame_num 与 pic_order_cnt_lsb 推），推错一步整段顺序全乱。

现象五：长时间播放后内存持续上涨，最终崩溃。原因是 DPB 没做淘汰。参考帧最多保留 16 帧，但具体保留哪几帧由滑动窗口和 MMCO 命令共同决定，遇到 adaptive_ref_pic_marking_mode_flag 为 1 的码流必须老老实实执行内存管理命令。 解决办法是实现完整的 DPB 状态机，按 POC 淘汰最老的参考帧，并且在 IDR 到来时清空全部参考帧。

5.3 内存与性能

现象六：开启多线程解码后偶发崩溃，单线程正常。原因是去块滤波跨宏块边界读写。滤波一个宏块要用到上下左右邻居的像素，如果按帧级并行，线程 A 正在滤边界时线程 B 可能已经改了邻居。 解决办法是改成波前并行：按宏块对角线推进，保证同一时刻各线程处理的是互不重叠的邻域；或者退一步用条带级并行，让每个线程独立解一个 slice。

现象七：CPU 占用不高但帧率上不去。常见原因是每帧都重新分配重建缓冲区。1080p 一帧 YUV420 约 3 MB，60 帧就是 180 MB 的分配释放，全落在堆上。 解决办法是预分配一个固定大小的缓冲池，按 DPB 容量一次性建好，之后只在池内轮转。

6. 设计取舍：复杂度为什么被推给了编码器

把整条链路串起来看，会发现一个贯穿始终的取舍：规范只定义码流语法和解码过程，不定义编码器怎么搜索。这意味着一份码流可以有无穷多种产生方式，但只有一种解码结果。这条线划下去，压力全到了编码器那边——帧内 9 种模式要不要全试、运动搜索窗开多大、参考帧用几个、CABAC 还是 CAVLC、率失真代价的 lambda 怎么设，全是编码器的自由。

这种不对称是刻意设计的。解码器要跑在手机、机顶盒、浏览器插件上，成本必须可控；编码器可以跑在机房、可以离线跑、可以堆算力。所以你会看到运动估计这种“试错”性质的重活被彻底推给编码端，而解码端只保留查表、移位和加法。这也解释了为什么解码器优化到最后，热点往往集中在插值滤波和去块滤波这两个纯计算函数上——它们是解码端仅剩的、无法用查表消掉的成本。

另一层取舍在错误恢复。把一帧切成多个 slice，丢一个包只影响一个 slice，代价是 slice 头部的重复开销和跨 slice 边界不能做帧内预测。抗丢包能力是花钱买来的，具体花多少由编码器根据网络状况决定。所以同一段视频，直播场景和本地播放场景切出来的 slice 数能差好几倍。

还有 profile 和 level 的取舍。Baseline 砍掉 B 帧和 CABAC 换取低延迟与低复杂度，Main 补上 B 帧，High 加上 8×8 变换和量化矩阵。level 则约束分辨率、码率、DPB 大小的组合上限，本质是给硬件实现者一个可验证的复杂度天花板。选型时先定 level 再定 profile，比反过来更省事。

验证这一整套理解是否到位，有个笨但可靠的办法：拿一段已知内容的原始 YUV 编码再解码，逐帧比对的不是 PSNR，而是重建像素的哈希。PSNR 只能告诉你“差不多”，哈希能告诉你“一模一样”。一旦哈希对不上，问题一定出在预测、变换、滤波这类必须两端严格一致的环节，而不是码率控制这种允许有偏差的部分。

我最早做解码器联调时，花了两天才定位到一处去块滤波阈值表的偏移错误，症状只是暗部出现极淡的方形纹理，肉眼几乎看不出来，但参考帧一旦带上这种偏差，几十帧后整片画面就开始发灰。从那以后我每次改动预测或滤波相关代码，都强制走一遍“编码—解码—逐像素比对哈希”的流程，哪怕只改了一行。

H.264 的源代码和配套文档，真正有价值的地方不在于告诉你某个函数的参数顺序，而在于把上述每一个取舍落成了可读的实现：规范里一句“上下文由相邻块推导”，对应到代码里就是一张表、一个分支、一个边界条件。对着文档读源码，再对着源码回头读文档，那些原本像玄学的阈值和约束，会一个个变成能推出来的必然。希望帮到你。

本文还有配套的精品资源，点击获取