ECM CCP

Cross-Component Prediction (CCP) Merge Mode Candidate Selection

即：跨分量预测（色度基于亮度残差建模）的合并模式候选列表构建机制。

一、背景：什么是 CCP？

✅ 跨分量预测（Cross-Component Prediction, CCP）

CCP 是一种Chroma from Luma的预测技术，用于提高色度（Cb/Cr）编码效率。其核心思想是：

利用已重建的亮度分量（Y）的残差信息来预测当前块的色度分量（Cb/Cr）值。

这与传统的线性模型不同，CCP 在 VTM 中通常表示为：
predchroma(x,y)=base_pred(x,y)+β⋅rec_residual_luma(x′,y′) \text{pred}_{chroma}(x,y) = \text{base\_pred}(x,y) + \beta \cdot \text{rec\_residual\_luma}(x',y')predchroma​(x,y)=base_pred(x,y)+β⋅rec_residual_luma(x′,y′)
其中：

• base_pred可以是平面、DC 或角度帧内预测；
• β\betaβ是缩放系数（由训练或 RDO 决定）；
• rec_res_luma是邻近区域亮度残差样本；
• (x′,y′)(x', y')(x′,y′)是映射位置（可能偏移）；

该方法能有效捕捉亮度残差与色度之间的相关性，尤其适用于纹理丰富区域。

二、为什么需要 “CCP Merge” 模式？

为了降低信号开销和复杂度，VVC 引入了Merge 模式—— 不传输运动矢量或模式参数，而是复用历史/空间候选。

类似地，在色度预测中也定义了：

CCP Merge Mode：不重新估计 β 系数和参考位置，而是从一个预构建的CCP Merge Candidate List中选择已有参数组合。

这样可以避免每次进行 RDO 判决时重复计算所有可能的 β 和模板配置，从而节省编码时间并减少语法比特。

三、ECM-19.0 中的 CCP Merge Candidate 如何生成？

虽然 ECM-19.0 并非最终标准化文档，但根据 JVET 提案系列（如 JVET-Z0058, JVET-AC0067, JVET-AD0047 等）以及 VTM-18~VTM-20 的发展路径，我们可以总结出ECM-19.0 中典型的 CCP Merge 候选选择流程如下：

🔷 步骤 1：确定是否启用 CCP Merge

仅当以下条件满足时，才考虑添加 CCP Merge 候选：

• 当前编码单元（CU）位于Chroma 分量上
• CU 尺寸 ≥ 4×4
• 当前 slice 类型支持帧内预测（I-slice 或 I-part in P/B）
• 启用了 CCP 工具（通过 SPS/PPS 标志位控制）

🔷 步骤 2：构建初始候选列表（Initial Candidate List）

候选来源共五类，依次尝试插入，去重后保留最多5 个候选。

候选类型 1：空间相邻块（Spatial Neighbors）

检查左侧（A1）、上方（B1）两个位置的相邻 PU 是否使用过有效的 CCP 参数。

+----------------+ | B1 | +--------+-------+ | | | | B0 | Current +--------+-------+ | A1 | +--------+

• 若 A1 或 B1 使用了 CCP 模式且有有效 β 和模板参数，则提取其：
  • 缩放因子 β
  • 残差采样模式（如 3×3 centered around top-left luma）
  • 映射偏移（offset_x, offset_y）
• 添加为候选项

注：若两者都存在，优先顺序为 B1 → A1

候选类型 2：非直接空间邻居（Non-direct Spatial）

某些提案扩展至 B2（上方右）、A2（左下），前提是它们属于同一 CTU 行且已解码。

候选类型 3：时间同位块（Temporal Co-located Block）

查找 co-located picture 中对应位置的 PU 是否使用过 CCP 模式。

• 如果是，提取其 β 和模板设置
• 应用时间运动补偿后的映射调整（如 scale with temporal MV）

候选类型 4：零参数默认候选（Zero-offset Default Candidate）

即使没有历史可用，也可强制加入一个“保守”的默认候选：

• β = 0 （即退化为普通帧内预测）
• offset = (0,0)
• template size = 1×1

作用：保证列表非空，便于熵编码统一处理

候选类型 5：历史缓存（History-based Buffer）

维护一个先进先出（FIFO）的历史缓冲区，存储最近成功使用的CCP 参数组。

• 最多保存 N 个条目（例如 3~5 个）
• 每次成功编码一个使用 CCP 的 CU 后，将其参数归一化后压入缓存
• 避免重复参数（去重）

🔷 步骤 3：去重与排序（Deduplication & Reordering）

对上述收集到的所有候选执行：

1.去重规则：

比较每对候选的以下字段是否完全相同：

• β 值（量化后整数形式）
• 模板形状 ID（如 3×3 centered vs 2×2 top-left）
• 偏移量 (dx, dy)

若相同，则跳过后续插入。

2.重排序依据：

按优先级重新排列候选顺序，常用策略包括：

目的：将最可能匹配当前块特性的候选放在前面，有利于快速收敛。

🔷 步骤 4：截断至最大长度

最终保留最多maxNumCcpMergeCandidates（典型值为 5）个候选。

可通过 SPS 层信令配置此数量。

🔷 步骤 5：语法传输与解码端重建

在码流中：

• 不显式传输候选列表内容
• 解码器按相同规则自主重建候选列表
• 编码器只需发送一个索引ccp_merge_idx
• 解码器查表获取对应的 β 和模板参数

实现了解码一致性，无需额外传输参数

四、示例：CCP Merge 候选列表构建过程（简化版）

假设当前色度 CU 条件如下：

→ 构建流程：

1. 加入 A1:(β=2, ...)✔️
2. 尝试加入 B1 → 与 A1 完全相同 → 跳过 ❌
3. 加入时间候选:(β=3, ...)✔️
4. 加入历史缓存:
   • 第一项(β=1)→ 新增 ✔️
   • 第二项(β=4)→ 新增 ✔️
5. 加入默认候选(β=0)→ ✔️
6. 去重完成，共 5 个候选 → 截断（已达上限）

最终候选列表（顺序）：

编码器通过 RDO 测试每个候选，选择成本最低者，并传输ccp_merge_idx。

五、性能影响与优化方向（来自 JVET 报告）

六、相关提案参考（真实 JVET 文档）

总结