HEVC帧间预测中的运动矢量预测MVP：从候选列表到运动场存储的全链路解析

做HEVC帧间预测，很多人第一站是运动估计搜索，第二站是运动补偿插值，但很少有人老老实实把MVP的整条链路读完。我的真实体会是：MVP这个环节表面上是"预测运动矢量"，实际上同时牵扯了候选列表构建、码流语法传递、运动场存储三大块，任何一块没理解透，后面写解码器、做硬件加速或者调编码质量都会踩坑。这篇文章就围绕MV在MVP流程里的获取、传递、存储三条线展开，把我读代码时反复确认过的细节和绕过的弯都写清楚。

1. MVP在帧间预测里的位置：MV这条链到底有多长

1.1 为什么运动矢量必须先"预测"再编码

先回到一个根本问题：运动矢量MV为什么要做预测？直观答案是省码率。视频编码里相邻块的运动通常高度相关，一个物体往前飘，它周围的块大概率也在往同一个方向飘。如果每个块都老老实实把原始MV写进码流，那比特开销会相当大。MVP的思路很简单：用已重建的运动信息推导一个候选，编码端只需要编"候选和真实MV之间的差"（MVD）或者干脆只传"你选哪个候选"（merge），解码端再用同一套规则还原MV。

但这里有个容易被新手忽略的点：MVP不是"找一个最可能的运动矢量"，而是在编码器和解码器两端同时执行一套完全确定的、基于已重建信息的规则，两端各自生成候选列表。编码器要决定用哪个候选，然后把决定通过语法元素传给解码器。所以MVP的实现本质上是"两端必须对称执行同一套逻辑"，这比单纯找邻居平均复杂得多。

1.2 MV从产生到消费要经过几个阶段

我读代码时习惯把MV的生命周期拆成四个阶段：

第一，运动估计阶段。编码器对当前PU（预测单元）做搜索，得到一个最匹配的原始MV。这个阶段只有编码器做，解码器不知道也不用知道搜索过程。

第二，候选推导阶段。编码器和解码器同时基于空间和时间上已经重建的块，构建MVP候选列表。候选列表的内容可能因为merge和AMVP两种模式而不同，候选的数量、顺序、去重规则都是标准写死的。

第三，决策与传递阶段。编码器根据率失真代价决定按哪种模式走：merge模式只传索引，AMVP模式传参考帧索引、MVP索引和MVD。解码器从码流里读出这些语法元素，重建出MV。

第四，存储与复用阶段。重建后的MV要写回运动参数缓存，供后面的块作为空域候选，也供后面的帧作为时域候选。这里存储的粒度、范围和生命周期都有讲究。

明白了这四个阶段，再去对照参考代码结构就顺了。

1.3 编码器与解码器必须严格遵守的对称性

我在实际读代码时见过不少开发者卡在"为什么我把候选列表打出来和标准示例不一样"，最后发现是对称性出了问题：编码器在推导候选时用了包含当前块在内的运动信息，或者解码器在某个分支里提前break导致候选顺序错位。

HEVC的MVP体系里，候选列表推导必须只依赖已经编码/解码完成的信息，也就是当前PU的左边、右上、左上等已经重建的PU，以及时域共位图像里对应位置的运动信息。任何"未来的"信息都不能碰。这个原则听起来简单，但在实际代码里会因为PU划分、去重逻辑、可用性判断而变得隐蔽。所以读代码时建议时刻问自己一句：这一行访问的块，在解码当前PU的时候真的已经可用了吗？

2. 空域候选：邻居块MV是怎么被"取"出来的

2.1 先搞清楚五个邻居块的位置约定

空域候选是最直观的MVP来源，但HEVC对邻居块的位置定义非常细，不是简单一句"看左边的块"就完了。标准里约定了一组相对当前块的位置，命名也很有几何感：A0在左下角紧贴当前块，A1在左侧中下方紧贴当前块，B0在右上角紧贴当前块，B1在上方中右侧紧贴当前块，B2在左上角紧贴当前块。

这五个位置里，A1和B1分别代表正左和正上的常规邻居，A0和B0是拐角位置的邻居，B2是左上的对角邻居。我在代码里最常踩的坑就是混淆A0和A1：A1是左侧那一块的中间位置，A0是左下的那一小块，两者可能属于不同的PU，运动信息完全不同。如果你把A0当成主要左侧候选，构建出的列表就会有偏差。

2.2 merge和AMVP的空域候选顺序差异

HEVC里空域候选的检查顺序在不同模式下并不一样，这是读代码时最容易懵的地方。merge模式下的候选顺序是A1、B1、B0、A0、B2，最多取四个空域候选；而AMVP模式下，左侧候选优先取A0，A0不可用才取A1，上方候选优先取B0，B0不可用取B1，B1再不可用取B2，最多取两个空域候选。

我把这个差异列成一张表：

注意merge里不是说左侧先A1再A0，而是整体顺序A1、B1、B0、A0、B2。如果A1不可用，按照整体顺序去补B1等，并不会马上跳到A0。AMVP则完全不同，它把候选分成左侧和上方两个"槽位"，每个槽位按自己的优先级往下找。这种差异背后的原因是：merge模式列表需要尽量多而杂，好覆盖各种运动情况，所以按贴近程度均匀采样五个位置；AMVP模式只需要一两个备选，所以两个方向上各挑最合适的那个。

2.3 可用性判断、去重规则与PU归属陷阱

空域候选的可用性判断不只是"这个块存不存在"，还要看它是不是帧间预测的。HEVC里有两种PU类型：帧内PU没有运动信息，不能参与空域MVP；左右两个PU可能一个是帧间一个是帧内，这时候帧内的那个块直接视为不可用。另外，如果参考的PU超出了当前图像边界或未重建区域，也要视为不可用。

去重逻辑同样有标准约束。merge模式下，每次取一个新候选，都要和已有的候选比对，如果MV和参考帧索引都相同，就丢弃。AMVP模式下只取两个空域候选，但两个候选如果完全相同，也只能保留一个。去重是为了避免候选列表冗余，否则率失真优化时选哪个都没区别，白白浪费索引位数。

PU归属是代码阅读里最隐蔽的坑。同一个CU如果被划分为两个PU，左侧那个PU可能同时扮演A1和A0两个位置的提供者，导致候选列表里出现两个方向不同但内容相同的候选。标准里规定了取候选时访问的是"包含该位置的PU的运动信息"，但代码实现时往往通过坐标换算直接取"包含坐标点的运动参数"，两者在PU边界处容易产生认知差异。我自己调试时有一半的候选列表异常都出在这个位置归属问题上。

3. 时域候选与MV缩放：跨帧搬运动向信息的关键一步

3.1 共位图像和共位PU是怎么确定的

时域候选（也叫时间预测）是把参考帧里相应位置的运动信息借过来用。核心概念是"共位图像"（collocated picture）和"共位PU"。共位图像不是随便选的，它在每个条带（slice）头部里有明确指示：P帧里通常用第一个参考帧，B帧里可以选择前向或后向参考帧，具体由语法元素控制。

共位PU的确定方式更微妙。HEVC不是简单地把当前PU中心映射到共位图像对应坐标，而是采用"取右下角附近和中心附近两个位置之一"的策略。标准流程是：先检查当前PU右下角对应的共位图像位置，具体落在哪个4x4块上，如果这个块可用且是帧间预测，就取它；如果不可用，再取当前PU中心位置对应的4x4块。

这里的坐标系换算需要注意：由于共位图像和当前图像的分辨率可能不同？实际HEVC参考软件里，当前PU的坐标是直接除以参数得到对应位置的坐标，但在参考软件中运动场存储粒度不一样时会出现四舍五入差异。这个换算细节看起来不起眼，却直接决定了你能不能找到正确的共位PU。

3.2 为什么必须按POC距离做缩放

时域候选不能直接照搬共位PU的MV，因为时间的参考关系不一样。举个例子：当前帧是第10帧，共位MV指向第8帧，这个MV表示"从第8帧到第10帧的位移"；但当前帧要预测的是第6帧，那么从第10帧到第6帧的时间距离完全不同，运动向量必须按时间比例缩放。

具体来说，缩放涉及两个距离：td是共位图像和它参考帧之间的POC（图像顺序计数）差，tb是当前图像和当前目标参考帧之间的POC差。MV的缩放比例就是tb/td。所以跨帧搬运动信息时，本身帧间距越接近，缩放误差越小。

我见过有初学者问：直接设tb和td相等不就行了？不行，因为编码器选择当前块的参考帧时可能任意选，共位帧的参考方向和距离也可能不同，不缩放会把时序信息完全搞错，运动越快误差越离谱。

3.3 定点整数实现里的缩放系数

HEVC标准在缩放实现上用了定点化办法，避免浮点。核心是先计算一个缩放因子tx：tx = (16384 + (AbsTd >> 1)) / td，然后缩放后的MV等于Sign(tb * tx) * ((Abs(tb * tx) + 32) >> 6)，并对结果裁剪到16位范围。

这个公式原理上和直接乘tb/td等价，但好处是全整数、无除法溢出，而且用舍入而不是截断。拆开看：16384是2的14次方，AbsTd>>1是做半值舍入，这样算出来的tx相当于把缩放比例放大了2的14倍；后面((tb*tx)+32)>>6则是把结果重新对回到MV的整数像素精度。我自己手推过一组数据，用这个定点算法和直接用浮点乘算，在常见帧距下误差最多不超过1/4像素，这在HEVC的运动补偿精度下可以接受。

3.4 时域候选的边界条件：越界、不可用与缩放溢出

时域候选在三种情况下会失效：一是共位PU在帧内模式，没有运动信息；二是对应的坐标位置超出了参考图像的边界；三是共振位的位置落在参考图像之外，可能压根没有帧间数据。这些情况在参考代码里都通过有条理的返回逻辑处理，读代码时建议顺着"取位置->查可用->缩放"的顺序去理解，不要一上来就看最终候选结果。

还有一个容易漏掉的场景：td或者tb等于0，即共位图就是参考帧本身，或者当前帧引用的是同一帧。后者在长期参考帧配置里可能出现。此时缩放公式分母为零，代码里必须有保护判断，直接返回零MV或者不可用。实际编码配置中很少遇到，但写硬件解码器时必须考虑。

4. MV的传递：AMVP与merge在码流中的两条路径

4.1 merge模式：索引即一切，MV全靠推导

merge模式是MV传递里最"偷懒"但最高效的方式。它的核心思想是：当前块的运动信息完全继承候选列表中的某一个，码流里只传一个索引merge_idx。解码器按既定规则构建候选列表，根据索引取候选的MV、参考帧索引和预测方向，直接作为当前PU的运动信息。

读代码时要注意的是，merge模式下参考帧索引和预测方向也一并继承了。如果候选列表里某个候选来自左邻块，指向参考帧2，那么当前块也自动指向参考帧2，不需要额外传ref_idx。这意味着merge模式对"运动边界"特别敏感，物体边缘如果选了来自背景的候选，预测残差会很大，编码器一般不会这么选，但了解规则的人才会理解为什么编码器会花大量时间比较各个merge候选。

merge模式的候选列表通常有5个候选：4个空域候选加1个时域候选（也可以时域在前？实际是空域填充后再放时域），如果候选不够5个，用零运动矢量补齐。这5个候选中，索引对应的二进制长度不同：越靠前的候选在码流里所需的比特越少。所以"候选顺序"本身就是压缩工具，把最可能被选中的候选排在前面能显著省码率。

4.2 AMVP模式：MVD、refIdx、mvpIdx的配合

AMVP模式走的是另一条路：它不继承参考帧索引，而是由编码器显式选择参考帧ref_idx；也不直接把MV写进码流，而是选择MVP候选，编码MVD（真实MV减去MVP的差值）。

AMVP语法里同时存在mvp_lX_flag和mvd_lX两个元素。mvp_lX_flag表示选了候选列表里的第几个MVP（因为AMVP列表最多2个，所以1 bit足够），mvd_lX表示当前预测方向下的运动矢量残差，解码器重建MV时要做MV = MVP + MVD。

理解AMVP的关键是"MVP候选列表只有2个候选，而且不补零"？其实AMVP如果候选不足也会补零向量，但最多补到2个。这也意味着AMVP的表达能力更强：可以精确编码任意MV，但代价是MVD的比特开销可能不小。

4.3 参考帧索引和MVD如何配合还原MV

实际解码还原MV的顺序是：读pred_flag确定方向，读ref_idx确定参考帧，读mvp_lX_flag确定MVP候选，读mvd确定残差，然后重建MV。这里要注意的是，MVD在码流里按绝对值加符号存储，是一种特殊的旁瓣编码，数值越大消耗比特越高。

我自己读这部分时有一个收获：与其把MVP和MVD拆开理解，不如把整个AMVP路径看成"用帧间相关性近似MV"的方案，MVP是近似基准，MVD是修正项。近似基准选得好，修正项就小，码率就低。这解释了为什么MVP候选质量对编码效率影响那么大。

4.4 传递过程中的MV范围裁剪与合法值约束

HEVC限定了MV分量必须落在[-32768, 32767]的16位有符号整数范围内。这个限制在MVD重建后还要再做一次检查，以防候选与残差相加后溢出。这部分在参考代码里体现为裁剪函数，解码端和编码端必须做成完全一致，否则会出现解码漂移。

别忘了还有边界扩展：运动补偿时MV可能超出参考图像边界，这里有专门的边界扩展机制，把超出部分填充为边界像素。这个机制不在MVP范围内，但如果从"MV在市场里跑一圈"的角度看，它是MV消费的最后一环。读代码时要是把MV边界处理和MVP裁剪混在一起，很容易把自己绕晕，建议分开读。

5. 运动场存储：MV从重建到进入下一次预测的落点

5.1 运动场到底是什么，存在哪

运动场（motion field）是整个视频图像区域的运动参数集合。HEVC解码端在重建每一帧后，并不是只把像素存下来供参考，还要把每个块的运动信息存下来，供后续帧的时域MVP使用。这部分内存区域在参考软件里是独立的运动参数缓存，和像素缓冲区分开维护。

运动场的存储粒度值得注意。HEVC的亮度块划分最细是4x4，但运动参数实际上以PU为单位产生，一个PU内所有4x4块共享一份运动信息。为了兼顾访问效率和内存开销，参考软件以4x4为最小存储单元，每个单元保存一组运动参数，包括参考帧索引和预测方向。这就是为什么时域候选取位置时要换算到4x4坐标。

5.2 为什么不能完整存储每个像素的MV

从直觉看，存4x4粒度好像已经足够密集了，但一帧1080p图像大约有13万个4x4块，每块存两三个运动参数，一帧下来也要好几兆字节，多参考帧配置下内存压力更大。所以HEVC参考软件里有时域运动参数压缩的考虑，例如把同一PU导出的4x4运动参数在存储时压缩，或在运动估计时复用前一帧压缩后的运动场。

存储压缩的本质是"以可接受的时域候选精度损失，换内存和带宽"。因为时域MVP对MV精度的要求并不像运动估计那么苛刻，统计上稍粗一点的运动场对最终压缩效率影响很小。这个设计思想在硬件解码器里尤为重要，全分辨率逐像素存运动参数的成本不可接受，大家基本都是存压缩运动场。

5.3 压缩运动场如何服务时域候选

有了运动场，时域候选的读取就变得直接：取共位PU运动参数时，本质上就是从运动场缓存里按坐标索引取值。由于运动场上存的是4x4块粒度的运动信息，当前PU 8x8还是16x16都不影响读取方式，唯一要注意的是"位置换算后落在哪个4x4索引"。

我在调试时发现一个很有意思的现象：用不同参考软件版本实现同样的标准流程，时域候选在个别块上会不一样。原因往往不是标准变了，而是运动场更新时机不同——有的实现是整帧全部重建完才统一更新运动场，有的实现是边重建边更新。HEVC标准规定时域共位用的是"上一帧已重建的运动场"，所以运动场物理上必须滞后一帧，这是保证解码一致性的关键约束。

5.4 MV存储的生命周期管理：POC和参考帧的联动

运动场的更新和参考帧队列紧密绑定。HEVC解码器维护一个参考帧列表，每解码一帧就把新的运动场放进缓存，并清理长时间不用的参考帧对应的运动参数。这里如果POC管理做错，会造成灾难性的错误：时域候选引用了一个已经释放的运动场。

我读代码时建议把"运动场的写时机"和"参考帧的释放时机"一起看。P slice里每帧只有一个运动场要更新，B slice可能涉及双向参考，更新逻辑要同时维护两个参考方向。如果你在做多线程解码，还要小心运动场缓存的多线程访问顺序，因为时域候选读取和运动场更新可能在不同线程同时发生。

6. 读代码时我真正理解MVP的几条方法论

6.1 标准文本、参考代码、码流数据三方对照

读MVP相关代码最有效的方式不是从头到尾读，而是选一个具体PU，把它的完整解码过程逐行走一遍。具体做法是：跑一个简单序列编码，打印某个PU的merge_idx、AMVP标志、MVD、重建MV，再拿标准文本对同一PU推导一遍候选列表，最后对比参考代码里那个PU的候选列表。

这个三方对照法帮我发现了很多"我以为懂了其实没懂"的知识盲区。特别是候选列表构建，自己推一遍和看代码走一遍完全是两回事。标准里候选推导的编号是8.5.3.2.x，代码里对应的是某几个函数，把编号记下来对照着看，效率远高于盲目搜索。

6.2 我在调试MV时常用的打印手段

我调试MVP时最常用的手段是：在候选列表构建的出口处打印候选数量、每个候选的MV和参考索引；在重建MV后打印最终MV；在运动场更新后抽几个块打印存储内容。三个打印点一对应，基本能定位80%的问题。

有个技巧值得分享：把相邻块图像打成一个矩阵视图，用数字标注每个块选用的候选来源方向，一眼就能看出候选分布是否合理。比如一块纹理平滑的区域，如果候选来源方向显得杂乱，往往说明去重或者可用性判断出了问题。这个可视化的调试方法比我之前单纯看日志高效太多。

6.3 "传递"不是简单的赋值：我在MV问题上的理解进阶

最后想说一个观念上的进阶过程。我第一次接触MVP时，以为"传递"就是编码器把MV放进码流，解码器读出来，中间没什么花活。后来做编码优化才明白，MVP体系里"传递"的核心不是MV本身，而是"重建规则的一致性"。编码器无论选哪个候选，解码器都能用同一套规则还原；编码器无论怎么量化MVD，解码器都能精确恢复。这个一致性问题在普通软件编码器里不怎么突出，但一旦做并行解码或者硬件加速，就会频繁遇到。

读代码这轮下来，我最大的收获是学会了一套"以MV为线索"的阅读方式：先看MV从哪产生，再看它经过哪些变换进入码流，再看它从码流里怎么还原回运动场，最后看它怎么影响下一个块的预测。这条线索贯穿了HEVC帧间预测最核心的部分，理解了它，再回头读运动估计、运动补偿、参考帧管理，都会觉得顺畅很多。