YUV/Dual RAW Pipeline 实现与切换机制：基于 MTK 平台的双景合成（PIP）系统架构解析与工程实战

关键词

MTK Camera、Dual RAW Pipeline、YUV Pipeline、PIP 双景合成、Preview 多通路、ISP 多路融合、异步流控制、双路 Sensor 同步、Frame Sync、FeaturePipe 多节点协同

摘要

多摄融合、前后景实时显示（PIP）、双路视频等复合影像应用，要求底层图像处理链路具备高带宽、低延迟与灵活的通道控制能力。在 MTK 平台上，Imagiq ISP 支持 Dual RAW 与 YUV Pipeline 的并行调度，可通过 FeaturePipe 配置不同的图像流路径，实现前摄+后摄、主摄+副摄等组合形式的实时合成。本文聚焦 MTK 平台下 YUV 与 Dual RAW Pipeline 的工程实现，解析其在 PIP（Picture-in-Picture）场景中的处理链条、帧同步机制、资源调度策略与典型项目调试方法，帮助开发者掌握复杂图像通路配置的核心机制与落地方案。

目录

  1. MTK Imagiq 多通道能力综述：RAW/YUV Pipeline 架构与支持范围

    • 单通 vs 双通架构比较
    • 多摄多模式配置支持策略

  2. PIP 场景图像路径构成与处理链路设计

    • 主路径与辅路径映射规则
    • 前后摄合成流程与分辨率匹配机制

  3. Dual RAW Pipeline 配置与启动流程解析

    • 两路 Sensor 同时输出 RAW 流配置
    • ISP 双通同步处理机制

  4. YUV Pipeline 数据流配置：从 Sensor 到 FeaturePipe 的映射

    • 基于 YUV Sensor 的快速路径构建
    • FeaturePipe 中双路径输入的 Buffer 控制

  5. Preview Stream 多通路管理与合成策略

    • 同步与异步输入源处理方法
    • Frame Sync 与帧号绑定逻辑

  6. FeaturePipe 中的双节点合成实现：双景融合与图层控制

    • OverlayNode/BlendNode 的使用方法
    • 双图层合成位置控制与效果调节

  7. 动态切换机制与帧流保护设计：从单摄到双景的无缝过渡

    • 流状态监控与链路重建逻辑
    • FeatureGraph 重建与缓存同步策略

  8. 实战案例：PIP 视频合成项目的图像路径设计与调试经验分享

    • 典型错误场景解析（帧延迟、错位、闪帧）
    • 参数配置推荐与平台调优策略

第1章 MTK Imagiq 多通道能力综述：RAW/YUV Pipeline 架构与支持范围

1.1 单通道与双通道架构的基础差异

在 MTK 平台的 ISP 架构中，图像处理链路以 Pipeline 为基础单元构建。通常分为：

  • 单通道 Pipeline（Single RAW/YUV）：适用于单摄系统或低功耗配置，仅支持一路 Sensor 输入、一套 ISP 模块处理；
  • 双通道 Pipeline（Dual RAW 或 YUV + RAW）：适用于多摄系统，支持同时接收两路图像输入，并并行执行 ISP 预处理或降采样。

联发科的 Imagiq ISP 从 Imagiq 6.0 开始支持并发双通结构，其中一条为主处理链路（P1/P2），另一条为辅处理链路（SubP1/SubP2），可独立控制 Sensor 输入、ISP 参数与 FeaturePipe 输出。此设计使得诸如 PIP（前后摄双景合成）、主摄 + 超广联动、双摄录制等成为可能。

1.2 支持配置组合与平台能力限制

不同芯片平台对双通道能力支持情况不同，以下为实际项目中主流平台能力归纳：

平台型号Dual RAW 支持YUV Pipeline 支持同时激活 Sensor 数量典型应用场景
Dimensity 720❌✅2YUV + RAW 合成
Dimensity 920✅✅3RAW + RAW + PIP 预览
Dimensity 1200✅✅3前后摄双通道实时处理
Dimensity 8300✅（改进型）✅（可并发）≥3三摄智能融合、AI PIP

工程中，在调度双通时需注意如下限制：

  • 双通 Sensor 需在同一时钟域运行，确保帧同步；
  • 辅通道处理能力受限，部分 ISP 模块（如 HDR、3A 统计）不可重复配置；
  • Buffer 分配需预留足够 DRAM 带宽，避免传输冲突。
1.3 多模式配置策略与通路规划

为支持不同拍摄场景，ISP 会根据 Camera UseCase 切换 Pipeline 模式，常见模式包括：

  • Preview Mode: 单通 RAW 或 YUV，低功耗快速预览；
  • PIP Mode: 主 + 前摄双通并发，需配置两套输入路径；
  • ZSD + Front: 主摄开启 Zero-Shutter-Delay，前摄同步显示；
  • Dual Video: 两个 Video Stream 并发输出，分别用于录像与 AI 处理。

调度时，HAL 层会根据 stream_configuration_mode 选择所需通路，并调用 FeatureGraphBuilder 构建 Pipeline 拓扑结构。例如，在 PIP 模式下，会配置：

graph.addNode<MainPreviewNode>();
graph.addNode<SubPreviewNode>();
graph.addNode<OverlayNode>();

主图与辅图在 ISP 预处理后分别进入 OverlayNode 进行合成，确保时序一致与视觉同步。

第2章 PIP 场景图像路径构成与处理链路设计

2.1 主路径与辅路径的角色划分

在 Picture-in-Picture（PIP）双景模式中，系统通常将一个 Sensor 输出的画面作为主视图（占据画面主体），另一个 Sensor 输出作为辅视图（嵌入窗口）显示。常见组合为：

  • 后摄为主视图（主摄 RAW Pipeline），前摄为 PIP 画中画（前摄 YUV Pipeline）；
  • 双后摄并列（主摄 + 超广角）模式下，画面右上角显示小视角补充；
  • AI 分析 + 主拍场景，辅视图显示人脸、手势、车辆等分析结果。

图像路径组成如下：

  • 主通道：Sensor1 → ISP Pipeline A → FeaturePipe 主节点 → 显示主图；
  • 辅通道：Sensor2 → ISP Pipeline B → FeaturePipe 辅节点 → OverlayNode 合成 → 显示画中画图层。

两通道需满足分辨率、帧率与帧号对齐基本要求。

2.2 分辨率匹配与裁剪策略

由于前后摄物理规格不同，主辅图像通常需要进行裁剪或缩放。以主摄为 4000x3000，前摄为 1920x1080 为例：

  • 主图通常输出为 1280x720（Display 预览用）；
  • 辅图由 YUV Sensor 输出，再通过 ISP 缩放为 240x180；
  • OverlayNode 将主图作为底层，辅图按设定位置叠加，并控制图层透明度与边框样式。

裁剪配置通过 Metadata 控制，每帧带有 Crop Region 与 Output Buffer 分辨率设定。调试中可通过 dumpOverlayLayout() 输出实际显示图层位置、分辨率与合成顺序。

2.3 合成链路与同步问题

在 PIP 模式中，常见问题为图层之间不同步，导致小窗画面延迟或撕裂。主要原因在于：

  • Sensor2 输出延迟（YUV 模式下帧处理速度快，但帧 Ready 不可预测）；
  • OverlayNode 合成时未等待辅图 Ready，直接合成空图；
  • Frame Sync 机制未绑定主/辅帧号，导致画面错位。

为解决上述问题，工程中采用如下机制：

  • 引入 DualFrameController，绑定主/辅帧号；
  • 每帧合成任务在两个 Buffer 均 Ready 状态下才触发 Overlay；
  • OverlayNode 内设置超时机制，未就绪则输出上帧缓存图，避免黑图。

调试推荐开启 overlay_wait_log，查看帧同步日志，确保主辅图在 FrameNumber 一致的时序下完成图像合成。

第3章 Dual RAW Pipeline 配置与启动流程解析

3.1 双 Sensor RAW 并行配置的硬件基础

在 MTK 平台上启用 Dual RAW Pipeline，前提是硬件支持两个以上 MIPI 接口并具备对应 ISP 通道资源。以 Dimensity 920 平台为例，支持：

  • 同时接入两个 RAW 类型 Sensor；
  • 为每个 Sensor 分配独立的 P1 通道（如 P1A、P1B）；
  • 使用独立 ISP Path 进行 RAW 图像初步处理（包括 Binning、Black Level Correction、Lens Shading 等）；
  • 可将处理后的 RAW 数据分别送入 FeaturePipe 或交由 Fusion ISP 单元进行多帧联合分析。

该架构实现双路 RAW 流的并发处理，为诸如后摄主+超广并行拍摄、双景 HDR、双景 AI 分析提供数据支持。

3.2 Sensor 对应 Pipeline 的动态绑定流程

在双 RAW 模式下，系统需为每路 Sensor 动态分配与其匹配的 P1 Pipeline，配置流程如下：

  1. Sensor 注册阶段：通过 SensorList::search() 获取 SensorID 与工作模式（RAW/YUV）；
  2. Pipeline 分配：调用 P1NodeSelector::select() 分别为主副 Sensor 分配 P1A 与 P1B；
  3. Metadata 初始化：配置各自 Sensor 的解析度、输出格式、帧率等参数，并写入 Request Metadata；
  4. Node 启动：FeaturePipe 启动对应的 P1Node，分别接受 RAW 数据流并初始化 ISP 处理；
  5. 帧控制联动：通过 FrameSyncManager 管理双通帧同步，确保主副帧号对齐。

实际项目中，为减少初始化延迟，双 P1 Node 可在同一线程内预加载配置，同时延迟 1~2 帧后再进入正常运行状态。

3.3 多帧调度中的帧冲突与容错机制

由于双 Sensor 的帧采集存在天然抖动，MTK 在调度层加入如下容错机制：

  • 若某一帧 Sensor 数据未能按时进入 Pipeline，则保留上帧作为 fallback；
  • 对于关键帧（如拍照），强制等待两个 RAW Buffer 就绪后执行合成；
  • 提供 frameGapTolerance 配置项，控制主副帧最大容忍时间差，默认 33ms；

某三摄项目中，主摄与副摄 Sensor 输出同步抖动大，经调整副 Sensor Dummy Line、增加 1 行安全窗口后，帧同步成功率提升至 99.2%。

第4章 YUV Pipeline 数据流配置：从 Sensor 到 FeaturePipe 的映射

4.1 YUV Sensor 与 RAW Sensor 数据路径差异

MTK 架构中，对于 YUV Sensor 通常采用简化路径处理：

  • Sensor 直接输出 YUV 格式数据（NV21、YUY2 等）；
  • ISP Bypass 原始 Bayer 流处理，仅进行格式转换与降采样；
  • 数据直接送入 FeaturePipe，无需经过 P1Node 完整 RAW 路径。

相比 RAW Sensor，YUV Sensor 拥有更低的初始化开销、帧延迟更小，适合前摄或低功耗场景，如：

  • PIP 场景中的辅图（前摄）；
  • 双录中画中画部分；
  • 在线会议中前摄实时人像分析路径。

在配置时，通过 HAL 的 sensor_mode_config 标识该路径为 YUV 类型，系统将跳过 ISP 初始化步骤。

4.2 FeaturePipe 中的输入路径构建

FeaturePipe 为每路图像数据流构建独立的输入链路，典型路径包括：

  • RAW 主路径：P1Node → DenoiseNode → ResizeNode → DisplayNode；
  • YUV 辅路径：YUVInputNode → OverlayNode → DisplayNode；

每一路输入均有对应的 EnqueBufferPool 与独立调度线程。YUVInputNode 是 FeaturePipe 中专为 YUV Sensor 设计的轻量输入节点，其负责：

  • 接收来自 Sensor HAL 的 YUV buffer；
  • 判断 buffer readiness；
  • 注入时间戳与帧序号；
  • 发送至合成节点（如 Overlay 或 AI 节点）。

YUVInputNode 与主 RAW 路径通过 FrameSyncInfo 进行逻辑绑定，避免图像错位。

4.3 Buffer 管理与图像格式适配策略

YUV Path 通常伴随多种图像格式，为确保和主图像正确合成，需进行以下格式适配：

  • 若主图为 RGB 或 NV12，辅图需在 OverlayNode 前进行格式转码；
  • 图像大小不一致时需在 ResizeNode 内做分辨率匹配，通常将辅图缩放至主图的 1/4 或 1/6；
  • MTK 提供 image_transform::YUVToRGBA() 函数库用于处理格式转换，支持 GPU 加速。

工程调试建议使用 dump_overlay_input() 工具，每帧记录主图与辅图的格式、分辨率、图层位置等信息，便于问题复现与调试。

第5章 Preview Stream 多通路管理与合成策略

5.1 多通路 Preview 架构设计原理

在 PIP 双景预览场景下，Preview 流并非单一路径输出，而是由两路图像数据（主 + 辅）通过并行路径独立处理后在 ISP 或 FeaturePipe 层合成。因此系统需支持：

  • 两套 Preview 通路独立控制（包括帧率、分辨率、格式）；
  • 双路通路输出同步到合成节点，并发入流；
  • 合成后统一输出至 Display 或 Media Buffer。

在 MTK 平台上，Preview 通路管理主要依赖于两个核心机制：

  • StreamID 映射策略：主图与辅图注册不同 StreamID（如 0x01、0x02），便于调度与 Buffer 区分；
  • BufferQueueManager：根据 StreamID 管理对应的 Buffer 分配、流控状态与回调事件。

系统初始化阶段将创建两个 Preview Stream，主图接入 RAW Pipeline，辅图绑定 YUV Pipeline，在合成节点前均为独立路径，直到 OverlayNode 前统一处理。

5.2 Frame Sync 与帧号绑定逻辑实现

为避免 PIP 模式下主辅图像错帧，系统采用帧号绑定机制进行同步控制：

  • 每一帧主图与辅图均附带 FrameNumber 和 Timestamp；
  • OverlayNode 仅在两路输入均达到同一 FrameNumber 状态后才开始合成；
  • 若某一帧辅图延迟到达，系统会缓存主图并等待辅图就绪；
  • 最大等待时间超过阈值（如 20ms）后，辅图回退使用前一帧内容或输出空图，避免主图卡顿。

此逻辑由 DualFrameController 管理，其内部维护主辅帧队列，并根据时间戳与帧号进行动态匹配。每一帧合成前执行以下逻辑：

if (main_frame.frame_id == sub_frame.frame_id && 
    abs(main_ts - sub_ts) < sync_threshold) {
    overlay_exec(main_frame, sub_frame);
} else {
    hold_or_fallback();
}

调试中常见问题包括：

  • 主图帧正常，辅图帧断流导致黑窗；
  • FrameNumber 不匹配，导致合成帧频不同步；
  • 双路径输出帧率不一致（如主为 30fps，辅为 15fps），系统需配置 sub_frame_skip = 1 以维持时序对齐。

调试建议开启 FrameDump 模块，分别记录两个路径的帧号流与时间戳，并使用可视化工具对比其帧对齐状态。

第6章 FeaturePipe 中的双节点合成实现：双景融合与图层控制

6.1 OverlayNode 架构与图像输入管理

OverlayNode 是 FeaturePipe 架构中的合成节点，主要用于将两个不同来源的视频帧按指定位置、比例、透明度进行实时合成，形成 PIP 效果图层。

每一帧合成包含以下流程：

  1. 接收主图 Buffer（来自 RAW Pipeline）；
  2. 接收辅图 Buffer（来自 YUV Pipeline）；
  3. 根据配置参数（图层位置、缩放比例、透明度）执行图像混合；
  4. 输出合成图至下一节点或直接用于显示/录像。

OverlayNode 的输入管理支持动态更新图层参数，即使在运行中，也可以通过 HAL3 Metadata 实时控制 PIP 窗口的大小、位置、边框样式。例如：

metadata.update(MTK_PIP_OVERLAY_POSITION_X, 800);
metadata.update(MTK_PIP_OVERLAY_POSITION_Y, 100);
metadata.update(MTK_PIP_OVERLAY_WIDTH, 240);
metadata.update(MTK_PIP_OVERLAY_HEIGHT, 180);

这些参数将传递至 OverlayNode 内部，通过 GPU Shader 或专用图像加速硬件执行图层叠加操作。

6.2 BlendNode 支持的图像融合与增强策略

对于需要进行更复杂融合处理的场景（如景深模糊、画面风格统一、亮度对齐），MTK 提供了 BlendNode，具备以下能力：

  • 两图亮度自动对齐；
  • 图像边缘平滑融合；
  • Alpha Map 支持，融合区域可设定 Mask；
  • GPU 与 CPU 混合执行策略，根据性能状态选择执行路径。

BlendNode 主要应用于以下场景：

  • 后摄双景：主图主摄像头，辅图为超广角或长焦，进行视角拼接；
  • 前后融合：前摄主图，后摄用于背景或景深信息增强；
  • 多通视频通话：主图为远端图像，辅图为本地预览，执行风格统一处理。

系统中可配置 Overlay 与 Blend 同时存在，在图像合成链中，OverlayNode 在前，BlendNode 作为后处理单元执行增强。

调试中可通过 blend_debug_overlay() 工具打开融合边界展示，验证图像融合准确性与边缘效果是否符合预期。

第7章 动态切换机制与帧流保护设计：从单摄到双景的无缝过渡

7.1 动态通路切换的应用背景与挑战

在实际产品中，PIP 双景功能通常需要支持以下动态切换场景：

  • 普通拍摄切换至双景录制；
  • 视频会议从单人视角切换为前后视图同显；
  • 根据用户姿态（如翻转）动态启用前摄画中画窗口。

这些场景要求 Camera Stack 在不中断帧流的前提下，实现通路切换、Buffer 重配置与图层合成策略的重建。技术挑战主要体现在：

  • FeaturePipe 图像路径结构重建需耗时，若切换不当会导致帧丢失或图像撕裂；
  • Sensor 状态切换需在 ISP 空闲帧间完成，防止正在传输数据中断；
  • HAL 与中间件需支持状态感知与状态机驱动，自动协调主辅摄启动与关闭。
7.2 切换流程的状态机设计与实现机制

MTK Camera HAL 中实现了完整的 DualCamStateMachine，用于管理 PIP 模式的状态迁移过程。主要状态包括：

  • SINGLE_CAM_MODE: 主摄独立运行；
  • WAIT_FOR_SUB_SENSOR_READY: 副摄上电并初始化；
  • DUAL_CAM_PREPARE: Pipeline 重构，图像链路双通接通；
  • DUAL_CAM_ACTIVE: 双图流合成稳定输出；
  • ROLLBACK_TO_SINGLE: 退出副摄，回到主摄运行状态。

每一次模式切换由 HAL 层控制触发，并向 ISP 与 FeaturePipe 下发 Metadata 标记。示意操作：

metadata.update(MTK_CONTROL_CAM_MODE, MODE_DUAL_PIP);
metadata.update(MTK_STREAM_RECONFIG_TRIGGER, true);

一旦进入 DUAL_CAM_PREPARE 状态，FeaturePipe 将析构当前 Graph 拓扑，重新构建包含主、辅通路与 OverlayNode 的新图像链路，并确保下帧图像之前准备完毕。

工程实践中，为避免画面黑帧或跳帧，需控制以下两个时序关键点：

  • 主通与辅通帧号同步点需延迟两帧完成绑定；
  • 新通道输出第一个有效 Buffer 前，主通需保持上帧缓存输出，避免空窗。
7.3 帧流保护策略与异常场景处理

在极端场景下，如副摄初始化失败、前摄被遮挡、Sensor 断连等问题发生时，系统需具备强健的帧流保护能力。常用策略包括：

  • Fallback 替换机制：辅通未就绪时，PIP 图层输出最近一次缓存帧，或使用预设图像填充；
  • Overlay Skip 控制：OverlayNode 可被动态设为 bypass 模式，仅输出主图；
  • Sensor Timeout 保护：Sensor 初始化超时超过 100ms，将主动回退至 SINGLE_CAM_MODE，并通知上层 UI 状态变化；
  • Motion 保活判断：辅摄若连续丢帧超过 N 次（如 5 次），自动进入空图模式，等待恢复。

调试建议启用如下 Debug Tag：

CAM::DualCamStateMachine::log_state_transition = 1;
FeaturePipe::OverlayNode::dump_frame_info = 1;

以获取切换时的状态流、帧时间戳、Buffer Ready 状态等完整记录。

第8章 实战案例：PIP 视频合成项目的图像路径设计与调试经验分享

8.1 项目背景与业务需求

某短视频平台客户提出产品需求：

  • 拍摄时支持后摄作为主图、前摄作为画中画合成；
  • 双摄像头图像需实时显示、支持 1080p + 480p；
  • 系统需支持一键开启/关闭画中画效果，无明显延迟或黑屏；
  • 需支持视频录制时双图合成流同时编码，帧率不低于 25fps；

项目基于 MTK Dimensity 8200 平台，前摄为 GC8054（YUV Sensor），后摄为 IMX766（RAW Sensor）。

8.2 图像路径构建与关键配置解析

系统使用 Dual Pipeline 模式，图像链路配置如下：

  • 后摄 → P1NodeA → Denoise → Resize → DisplayNode；
  • 前摄 → YUVInputNode → Resize → OverlayNode；
  • 合成后流入 VideoNode 与 DisplayNode 分发到编码器与预览；

核心配置参数：

  • main_preview_resolution: 1920x1080；
  • sub_preview_resolution: 480x360；
  • overlay_position: x=1600, y=800；
  • overlay_alpha: 240（近不透明）；
  • 帧同步模式为 SYNC_BY_TIMESTAMP，最大误差不超过 ±10ms。

使用 MTK Camera DebugTool 打印如下关键信息：

  • overlay_latency_avg: 8.3ms；
  • frame_drop_main: 0，frame_drop_sub: 2（辅通初始化时）；
  • merge_success_rate: 100%，合成无黑图。
8.3 调试与性能优化经验总结

项目上线前进行如下调优操作：

  • 将辅摄 Sensor 初始化提前两个帧周期，减少画中画延迟；
  • 开启前摄 Clock Always On，避免频繁休眠导致初始化超时；
  • OverlayNode 执行融合逻辑转由 GPU 完成，减轻 ISP 负载；
  • 视频编码采用双输入流模式，保证主辅帧统一时间戳；

最终项目达到以下性能指标：

  • PIP 模式下录制视频帧率稳定 30fps；
  • 主辅帧时差 <8ms，肉眼无延迟；
  • 切换画中画过程无黑屏、无跳帧；
  • CPU 占用平均下降 11%，系统整体功耗下降约 8%。

该项目实现了 Dual RAW + YUV 同时工作的高质量视频合成，为后续多摄融合功能提供了可复用基础架构。

本文转自 https://zhxin.blog.csdn.net/article/details/148676876，如有侵权，请联系删除。