MTK Camera HAL 与 FeaturePipe 架构解析：从硬件抽象到功能管线的工程落地路径

关键词

MTK Camera HAL、FeaturePipe 架构、联发科影像系统、CAM-HAL3、Pipeline Model、流控制管理、Node 架构、Buffer 管理、Android Camera Framework

摘要

MTK 的 Camera 系统在 Android 平台下采用高度模块化的 HAL 与 FeaturePipe 架构组合，分别承担着底层硬件抽象与上层功能封装的职责。通过将 ISP、3A 算法、Sensor 驱动与图像处理节点解耦封装于功能链条中，联发科平台实现了灵活可控的影像能力调度机制。本文将基于真实项目实践，系统解析 MTK Camera HAL 与 FeaturePipe 架构的设计思路、核心模块与运行机制，结合 AE/AWB/AF 控制流、Buffer 管理策略、功能管线构建方法与多线程调度实现方式，帮助开发者理解 MTK 平台从 Frame Request 到图像输出的完整处理过程，并提供可直接参考的工程配置与调试经验。

目录

  1. MTK Camera HAL 架构演化概览：从 Legacy HAL 到 HAL3 模块化设计路径

    • Android Camera HAL 版本对比
    • MTK 在 HAL3 中的结构化抽象策略

  2. Camera HAL 模块组成与职责分工：Sensor、ISP、3A 与 Pipeline 的协作模型

    • MTK HAL 模块拆解（sensor_mgr、isp_mgr、aaa_mgr 等）
    • 每帧控制与同步策略

  3. PipelineModel 机制详解：如何构建 Request 到处理节点的流图关系

    • Pipeline Node 构造与连接方式
    • RequestQueue 与 FrameControl 调度核心

  4. MTK FeaturePipe 架构解析：功能节点注册与执行模型实战

    • FeaturePipe Node 分类（Capture、Preview、Video）
    • Graph Engine 与 Node Callback 管理策略

  5. Buffer 管理与内存同步机制：从 IImageBuffer 到同步队列实现

    • BufferPool 策略与生命周期控制
    • Buffer Handle 映射与元数据携带路径

  6. 控制流调度与线程模型：如何保证 Preview/Record/Capture 的流畅性与隔离性

    • Streaming FeaturePipe 与 Capture FeaturePipe 线程调度
    • Frame Sync 与时间戳一致性控制实践

  7. 3A 模块与 FeaturePipe 的融合路径：AE/AWB/AF 参数如何传递与驱动

    • Metadata 传入流程与控制策略
    • 调整反馈链路与控制闭环机制

  8. 工程实战案例：如何构建一个自定义 FeaturePipe Node 并接入主线处理流程

    • 自定义模块接入流程
    • Debug 工具链与调试方法分享

第1章 MTK Camera HAL 架构演化概览：从 Legacy HAL 到 HAL3 模块化设计路径

1.1 Android HAL 的演进背景

Android Camera HAL（Hardware Abstraction Layer）是连接系统 Camera Framework 与底层硬件的桥梁，其主要职责是屏蔽平台差异，统一控制接口，使上层应用以一致方式访问设备摄像头能力。Android 平台早期使用的是 HAL1 架构，采用回调式的数据流模型，适用于简单单帧拍照与低复杂度预览场景。

自 Android 5.0 起，Google 推出了 HAL3 架构，基于请求-响应模型（Request-Result Model），允许精细控制每帧的 Sensor 参数、3A 执行流程与 ISP 功能模块状态。这种机制特别适配复杂的多摄系统、高帧率拍摄与自定义图像处理路径等应用场景。

MTK 平台在 Android HAL3 基础上构建了自有的 Camera HAL 框架，并引入了高度模块化的组件分层结构，将复杂控制任务拆分至专职子模块中，实现了更强的可维护性与调优灵活性。

1.2 MTK HAL3 架构核心组成

联发科 HAL 架构围绕 HAL3 接口设计，构建出以下关键模块：

  • sensor_mgr：封装各类 Sensor 的控制接口，负责模式切换、帧同步管理；
  • isp_mgr：与底层 Imagiq ISP 寄存器通讯，控制图像处理 pipeline 启停、模块配置；
  • aaa_mgr（3A Manager）：调度 AE/AWB/AF 算法引擎，生成每帧曝光、增益、聚焦参数；
  • pipeline_model：构建 request 到处理节点的执行链，接入 FeaturePipe 功能模块；
  • stream_mgr：管理 Camera Framework 提交的 Stream 配置，映射到处理路径；
  • result_processor：接收 ISP 输出，构建 metadata，反馈至上层 framework。

HAL3 每次接收 capture_request 后，会根据场景类型（Preview、Video、Capture）在 pipeline_model 内部构建处理图，依次调用上述模块生成配置参数，完成帧级别的任务下发。完成后由 result_processor 接收结果并提交至上层。

MTK 的设计亮点在于采用 clear module boundary，允许在不改动整体框架的前提下引入特定功能模块，如 AI Scene Adaption、Custom Effect 等。

1.3 实战演进路径：从 Legacy 架构迁移至 HAL3 的项目流程

在早期某项目中，团队从 MTK HAL1 升级至 HAL3 架构时遇到多个关键挑战：

  • HAL3 要求每帧动态参数控制，与之前固定帧率配置流程不兼容；
  • Legacy pipeline 架构中多数 ISP 参数写死在静态配置中，需全部转移至 metadata 控制；
  • 预览与拍照路径分离逻辑被拆分为统一 request 管理，涉及多线程控制和同步管理。

最终，通过以下策略完成架构升级：

  1. 基于 HAL3 架构重新定义 CameraAdapter，逐步抽象出 sensor_mgr、aaa_mgr 等组件；
  2. 构建统一 metadata 映射模块，将 Legacy 参数配置表转为动态控制字段；
  3. 建立 test case 框架，覆盖 Preview/Capture/PDAF 等核心流程，保证功能对齐与稳定性；
  4. 使用 Google CTS/ITS 套件验证接口兼容性与图像表现一致性。

升级后系统支持复杂 FeaturePipe 插件、AI 插入路径及流式架构优化，大幅提高了工程维护效率与系统扩展性。

第2章 Camera HAL 模块组成与职责分工：Sensor、ISP、3A 与 Pipeline 的协作模型

2.1 MTK Camera HAL 层级结构

MTK Camera HAL 构建为多层封装结构，从底向上可分为以下主要组件：

  • Drv 层（Driver Adapter）：封装 V4L2 接口、I2C 控制器等底层通信接口；
  • Sensor HAL（sensor_mgr）：管理 Sensor 模式、帧率、同步信号、数据格式；
  • ISP HAL（isp_mgr）：配置并控制 ISP pipeline 运行状态；
  • 3A HAL（aaa_mgr）：封装 AE/AWB/AF 算法核心，管理参数采集与输出；
  • PipelineModel：构建整体帧处理链与 FeaturePipe 节点拓扑；
  • MetadataHandler：映射 Android metadata 到 ISP、Sensor、3A 参数控制项；
  • RequestController：调度帧序列、状态同步与 output result 构建流程。

每个模块遵循统一的 HAL3 架构规范，并支持通过 callback 或 interface 机制在 featurepipe 中注册自定义处理节点。

2.2 Sensor 管理机制与同步控制

Sensor 管理模块（sensor_mgr）负责与底层驱动通讯，完成以下关键任务：

  • Mode 切换（Preview, Capture, HDR, PDAF）；
  • Sensor 时序管理与 sync ID 对齐（用于多 Sensor 协调）；
  • 输入数据格式管理（RAW10, RAW14, YUV422）；
  • OTP 数据加载与调试配置支持。

实战项目中，常用 Sensor mode 如：

  • Preview 30fps, RAW10；
  • ZSD Capture, HDR RAW14；
  • DualCam Sync Mode, Master-Slave RAW。

sensor_mgr 通过 IHalSensor 接口提供 open/close/configure 功能，并配合 HAL 调用链在 request 启动时动态设定 mode，完成采样格式准备与数据总线配置。

2.3 ISP 控制模块的调用流程

Imagiq ISP 的控制接口封装在 isp_mgr 模块中，负责：

  • 加载 Tuning 参数（NR, CCM, EE, Gamma 等）；
  • 启动/停止 ISP Pipeline；
  • 监控 ISP 中断（Frame Done、Error）；
  • 配置双 pipeline 并发能力（Preview + Capture）；

isp_mgr 接收来自 metadata_handler 的参数映射，在 request 下发时生成寄存器配置表，并写入硬件 ISP 中。在某项目中曾遇到 ISP Pipeline 未同步关闭导致的帧资源冲突，通过补充 flushPipeline() 调用成功修复，说明 ISP 控制流程需与 request 生命周期严格一致。

2.4 3A 模块的执行链路

3A 管理模块（aaa_mgr）内部集成 MTK AE, AWB, AF 算法库，每帧接受 sensor 输入后计算控制参数，流程如下：

  1. 从 ISP/Metadata 中提取统计数据（brightness, color ratio, focus area）；
  2. 运行 AE/AWB/AF 算法，生成新一帧的配置（曝光时间、Sensor 增益、AWB gain）；
  3. 回写参数至 metadata，供下一帧 Sensor/ISP 使用；
  4. 输出调试日志与收敛信息。

算法运行节奏由 FrameControl 管理，根据 FrameNumber 顺序运行控制周期，保证同步性。开发者可通过 Debug 模式输出 AE Log，分析参数变化趋势判断是否进入收敛状态。

第3章 PipelineModel 机制详解：如何构建 Request 到处理节点的流图关系

3.1 PipelineModel 在 MTK HAL 中的角色

在 MTK Camera HAL 架构中，PipelineModel 是整个帧控制流程的核心。它负责将 Android Framework 层传递下来的 CaptureRequest 解析成可执行的图像处理流图（Processing Graph），并构建每一帧所需的功能节点（Feature Node）、数据路径与参数映射。

每个 PipelineModel 实例对应一个工作流配置（如 Preview、Record、ZSD Capture 等），由 IPipelineModel 接口统一调用并管理。它不仅包含节点关系与功能配置，还维护 Request 的生命周期状态，包括：

  • 构建节点图拓扑（Node Graph）；
  • 建立 Request 队列与流状态控制；
  • 管理 I/O Buffer 分配与 Metadata 路由；
  • 驱动每帧处理的执行计划。

PipelineModel 是 HAL 与 FeaturePipe 的桥梁，确保从逻辑请求（Request）到实际处理任务（FeaturePipe Execution）之间的映射准确、状态同步。

3.2 图结构构建流程：从配置到执行链条

PipelineModel 的图结构建立包括两个阶段：

  • Configure 阶段：在 Camera 初始化与 Stream 配置完成后，PipelineModel 根据 stream 信息构建功能链图结构，识别所需的 Node 类型（如 P1Node、P2Node、CaptureNode）；
  • Request Submit 阶段：每次收到 process_capture_request，PipelineModel 实例化该图的一次执行节点组合，配置其输入输出 Buffer 与参数，并推入执行队列。

每个 Node 节点具有以下基础接口：

  • onInit()：初始化资源与缓冲区；
  • onConfig()：设置节点运行参数；
  • onRequest()：接收并执行请求；
  • onFlush()：清理资源与取消运行中任务。

以 P1Node（Sensor + ISP 输入节点）为例，其输入为 metadata + Request ID，输出为 Raw/YUV 数据帧与统计信息。每个 Node 之间使用 Stream ID 建立数据通道，Frame Number 同步用于保证跨节点数据对齐。

3.3 RequestQueue 与帧控制机制

PipelineModel 内部维护 RequestQueue，用于按帧编号顺序管理请求的生命周期与状态转换。该结构支持如下控制操作：

  • 入队：系统从 HAL 接收 Request 时，将其以时间戳排序插入队列；
  • 状态跟踪：每帧维护状态标签（Queued, InFlight, Done）；
  • 错误回退：支持中途错误时取消后续节点处理并回收资源；
  • Metadata 路由：管理每帧的 input/output metadata 流转至 FeaturePipe。

一个 Request 的完整生命周期为：

  1. 接收并入队；
  2. 绑定对应 PipelineNode 实例；
  3. 分配 Buffer 与参数；
  4. 驱动 FeaturePipe 执行；
  5. 收集输出并回传结果。

通过这一机制，MTK 平台可在复杂场景（如 Burst Capture + MultiCam）下保持帧处理的顺序与独立性，防止因资源冲突造成图像错帧、卡顿等问题。

第4章 MTK FeaturePipe 架构解析：功能节点注册与执行模型实战

4.1 FeaturePipe 的设计目标与结构组成

FeaturePipe 是 MTK 平台为图像功能处理所构建的一套图形化功能执行引擎。其目标是将各类图像处理功能（如美颜、夜景合成、AI 模型调用、视频增强等）封装为可复用的节点（Node），通过图结构串联为一条功能处理管线。

FeaturePipe 架构基于以下核心组件：

  • Node：功能节点，每个 Node 封装一个图像处理子模块；
  • IOPipe：节点间输入输出连接管道；
  • StreamManager：控制整个流的激活、调度与终止；
  • Graph Engine：驱动所有节点并发执行，并协调资源调度；
  • Context：记录整条流水线的执行环境与配置参数。

整个 FeaturePipe 支持独立线程模型，每个 Node 默认在独立线程中运行，配合线程间缓冲机制，满足高并发、低延迟处理需求。

4.2 FeaturePipe Node 分类与使用场景

根据图像处理功能与处理位置的不同，FeaturePipe 中的 Node 分为以下几类：

  • Source Node（如 P1Node）：与 Sensor 打通，负责图像数据的输入；
  • Core Node（如 NRNode、FaceDetectNode、EffectNode）：执行图像核心处理；
  • Sink Node（如 EncodeNode、CallbackNode）：最终数据输出、结果封装与回传；
  • Control Node（如 MetaCollectorNode）：仅处理 metadata，不产生图像结果。

每个节点需实现标准接口：

  • init()：初始化内部变量与资源；
  • config()：设定功能模式与资源配比；
  • process()：执行一次数据处理任务；
  • flush()：取消处理与回收状态。

实际项目中，开发者可在 FeaturePipe 中插入自定义处理节点，例如美颜滤镜、人脸打光、图像语义分析等，并通过 registerNode() 将其添加至流图中。

4.3 节点连接与执行流程管理

FeaturePipe 支持通过描述式配置文件或代码接口手动搭建节点关系，节点间的数据通过 ImgBuf 与 MetaBuf 对象传递。图建立完成后，由 Graph Engine 启动节点线程并调度帧任务。

每一帧图像处理大致执行路径如下：

  1. P1Node 采集 Sensor + ISP 输出数据；
  2. 传递至核心 Node（如 NRNode、CCMNode）完成预处理；
  3. 调用 AI 推理类节点（如 SceneDetectNode）输出场景信息；
  4. 进入后处理节点，如 SharpNode、ToneNode；
  5. 最终输出至 CallbackNode 回传至 HAL3 ResultProcessor。

FeaturePipe 支持异步流控制，在输入数据尚未到达时，节点将进入等待状态，避免空跑；数据就绪后立即执行，形成稳定、可预测的帧处理延迟。

4.4 多线程调度策略与性能优化

为了适配多核异构 SoC 平台，FeaturePipe 采用线程池机制进行调度优化，每类功能节点可配置线程优先级、绑定核心策略等。开发者可通过以下方式优化性能：

  • 使用 NodePriority 调整关键节点的调度优先级；
  • 启用 BatchFrameMode 提高重复处理场景的吞吐率；
  • 使用 SharedBufferPool 降低 Buffer 分配开销。

某项目中，启用异步调度后将夜景模式下每帧处理时间从 42ms 降至 27ms，实现连续拍照下不卡顿的用户体验目标。

第5章 Buffer 管理与内存同步机制：从 IImageBuffer 到同步队列实现

5.1 IImageBuffer 架构与内存生命周期控制

在 MTK Camera HAL 架构中，图像数据在节点间的传输依赖于统一的 IImageBuffer 接口。该接口封装了物理地址映射、虚拟地址访问、缓存同步以及格式转换等功能，是 ISP、FeaturePipe 与上层 HAL3 控制模块之间实现零拷贝图像传输的基础。

IImageBuffer 的核心特点包括：

  • 多种格式支持：支持 YUV、Bayer RAW、JPEG、RGB 等主流图像格式；
  • 物理地址管理：封装 ION/MMAP 操作，实现硬件加速兼容性；
  • Cache 操作接口：提供 clean/invalidate 缓存指令，保障数据一致性；
  • 自描述属性：包含宽高、stride、plane 数量、格式等元信息；

在典型工作流中，PipelineModel 会根据每帧 Request 构建 IImageBuffer 对象并映射至各个节点使用。FeaturePipe Node 只负责处理接口传入的 Buffer，不直接管理内存释放，所有 Buffer 生命周期由 BufferHandler 与 StreamBufferProvider 控制，确保系统资源不泄漏。

5.2 Buffer Pool 策略与帧重用机制

为了降低高帧率场景下的频繁内存申请释放带来的性能开销，MTK 在 HAL 架构中集成了 BufferPool 机制。该机制主要包括：

  • 预分配池（Pre-Alloc Pool）：在 Camera 打开阶段按需求预分配固定数量 Buffer；
  • 重用管理（Recycle Queue）：处理完成后的 Buffer 回收至池中待复用；
  • 动态扩展策略：根据帧负载动态调整池容量，确保不丢帧；

以 Preview Stream 为例，系统通常配置 5~8 个循环 Buffer，在 Graph Engine 启动时通过 allocatePool(size) 接口构建，并在 Frame Done 后通过 returnBuffer() 将 Buffer 放回。

某项目中，因高帧率录像（60fps）与 AI 节点并发处理带来大量内存压力，工程团队通过扩展 BufferPool 上限至 12，并启用 LRU 回收策略，显著提升系统稳定性并避免内存碎片化。

5.3 BufferHandle 与元数据携带通路

除图像数据本身外，HAL 系统还需同步传递与图像相关的元信息（如时间戳、曝光参数、人脸识别区域等）。为此，MTK Camera HAL 引入 BufferHandle 与 MetadataBundle 的联合机制：

  • BufferHandle：记录实际 Buffer 映射的句柄，用于内核级资源绑定；
  • MetadataBundle：挂载于 Buffer 上的扩展字段结构，用于传输 ISP 配置、拍照参数等；

在 FeaturePipe 执行过程中，部分节点可直接读取 MetadataBundle 中的 Scene Type、AI 标签、帧编号等字段，实现动态调节处理策略。

开发过程中常用 debugDumpBufferInfo() 接口查看当前帧 Buffer 映射状态与元数据结构，快速定位数据丢失、格式异常等问题。

第6章 控制流调度与线程模型：如何保证 Preview/Record/Capture 的流畅性与隔离性

6.1 HAL 与 FeaturePipe 的线程调度架构

MTK Camera 架构在高负载场景下采用分层线程模型，将控制流、图像处理与内存管理等任务隔离到不同的线程域中，避免阻塞与资源竞争。主要线程分类如下：

  • Request Thread：负责从 Android Framework 接收 CaptureRequest，进行初步解析与分发；
  • 3A Thread：独立线程运行 AE、AWB、AF 算法循环，保持算法与帧速异步运行；
  • Pipeline Thread：处理每帧图像数据的流图构建与执行；
  • Node Thread（FeaturePipe）：每个 Node 单独线程运行，支持并发处理与同步等待；
  • Result Thread：收集处理完成的结果帧并向上层回传 Metadata 与 Output Buffer；

通过线程间异步队列通信，每帧数据可以在不同处理阶段进行并行调度，极大提升了系统吞吐能力。

6.2 Preview、Record、Capture 的独立处理通道配置

在 HAL 初始化阶段，系统会根据 StreamConfiguration 中的使用场景配置对应的处理路径。常见三种通道如下：

  • Preview Stream：低延迟路径，关闭部分 ISP 模块（如 HDR），优先保证帧率；
  • Video Stream：稳定输出路径，启用实时 NR 与 ISP Boost 功能，优化视频编码前图像质量；
  • Capture Stream：完整图像质量路径，激活全部 ISP 功能（HDR Merge、CCM、AI LUT 等），输出高质量静态图像。

系统通过 StreamID 与 StreamConfigMap 建立 Preview/Video/Capture 各自的通道与缓冲区配置，并在 PipelineModel 构建中为其分配不同 FeaturePipe 实例，实现资源隔离与调度独立性。

在某 5G 旗舰项目中，Preview（60fps）与 Capture（全像素 RAW HDR）路径共存，工程团队通过将两个路径绑定至不同 ISP Pipeline 并发执行，结合核心优先级配置成功实现零帧丢失与延迟控制在 40ms 以内。

6.3 帧间同步与时序控制机制

为了保证多线程环境下的帧一致性，MTK 架构引入帧控制器（FrameControl），其核心职责包括：

  • 帧编号同步：确保 Sensor 输出帧编号、3A 反馈与 ISP 数据一致；
  • 时间戳管理：控制各模块对同一帧的时间对齐，避免 Preview 与 Metadata 输出错位；
  • 丢帧处理：在 Buffer 不足或算法阻塞情况下主动丢弃帧并反馈 warning；
  • 请求调度策略：针对高优先级请求（如触发快门）可打断普通请求链并提升处理优先级。

通过 frame_number, timestamp, request_id 三位一体的关联机制，系统可精确追踪每一帧的流转过程，保障各模块输出结果的时序一致性。

第7章 3A 模块与 FeaturePipe 的融合路径：AE/AWB/AF 参数如何传递与驱动

7.1 3A 模块与 Frame Request 的联动机制

在 MTK Camera HAL 中，3A（Auto Exposure、Auto White Balance、Auto Focus）模块与每一帧的 Request 实例高度绑定。每一次 process_capture_request() 调用，不仅提交了图像采集需求，还包含了用于控制 Sensor 曝光时间、增益、白平衡增益、对焦行为等关键参数。

其核心机制如下：

  • Request 接收时绑定 Metadata 控制字段：如 ANDROID_CONTROL_AE_MODE, ANDROID_CONTROL_AF_TRIGGER, ANDROID_CONTROL_AWB_LOCK 等；
  • PipelineModel 解析这些字段并传递至 aaa_mgr；
  • aaa_mgr 在每帧调度中调用 AE/AWB/AF Core 算法模块生成控制值；
  • 控制值通过 MetadataHandler 回写，交由 Sensor HAL 与 ISP HAL 实施硬件控制。

该流程形成一个动态反馈闭环，在每帧图像捕获前，算法基于前帧统计数据调整控制参数，在当前帧内完成更新，确保图像质量稳定性。

7.2 AE/AWB/AF 与 FeaturePipe 的数据路径集成

FeaturePipe 中多个节点（尤其是 YUV 后处理节点）对当前帧的曝光与白平衡状态有直接依赖，例如：

  • 夜景增强节点需判断当前帧是否低曝光状态，以决定是否开启多帧融合；
  • 肤色 LUT 节点需基于当前 AWB Gain 修正色温；
  • AF 模型判断是否处于聚焦区间，决定是否应用虚化或锐化策略。

为了完成此类操作，FeaturePipe 引入 MetadataCache 机制，将 3A 算法模块返回的 AE、AWB、AF 状态缓存到 Frame Metadata 中，并在每个处理节点中通过标准接口 getFrameMetadata() 提取字段，如：

float exposure = meta->getEntry(MTK_CONTROL_AE_EXPOSURE_TIME);
float gain = meta->getEntry(MTK_CONTROL_AE_GAIN);
MRect af_window = meta->getEntry(MTK_CONTROL_AF_REGION);

这一机制保证了图像后处理链条具备 3A 感知能力，实现真实场景下的效果智能适配。

7.3 3A 收敛与拍照时序的协同逻辑

拍照模式下，MTK HAL 会在 AE/AWB 收敛后再触发图像采集，流程如下：

  1. 系统进入 3A convergence state；
  2. 连续帧执行 AE/AWB 算法并检查是否达到设定阈值；
  3. 收敛成功后发出 Shutter 请求，锁定当前曝光与白平衡参数；
  4. 同步传递至 Sensor + ISP，完成图像采集与处理；
  5. Metadata 中返回最终使用参数，确保 EXIF 信息准确；

该收敛过程由 HAL 控制器执行，在某些项目中可配置收敛超时策略，以避免过度等待影响用户体验。例如，在夜景场景下允许 AWB 收敛延迟不超过 5 帧，超时后自动触发拍照动作。

该机制需与 FeaturePipe 完整对接，确保触发拍照帧与图像处理模块配置同步，防止参数漂移造成曝光偏移或白平衡偏色问题。

第8章 工程实战案例：如何构建一个自定义 FeaturePipe Node 并接入主线处理流程

8.1 需求背景与开发动因

在某海外电信定制项目中，客户希望在 Preview 模式下增加一种自定义滤镜功能，用于模拟怀旧胶片风格，并要求可动态切换滤镜强度。由于该功能需要实时处理 YUV 图像，且不能影响主线延迟，项目团队决定通过 FeaturePipe 插件方式实现。

该功能不依赖 ISP 内建模块，也不改变主线控制流程，因此选择在 P2Node 后插入自定义处理节点，并结合 AI 模型实现滤镜参数动态切换。

8.2 自定义节点开发流程

MTK FeaturePipe 框架为节点开发提供了标准模板，基本流程如下：

  1. 继承 CamNode 类，定义节点类型与接口；
  2. 实现 onInit()、onConfig()、onProcessFrame() 方法；
  3. 注册输入输出 Buffer 类型与 Format 要求；
  4. 在 GraphBuilder 中添加该节点，并定义其上下游连接关系；
  5. 在 Node 中处理图像数据，写入处理结果至 Output Buffer；

示例伪代码：

class VintageEffectNode : public CamNode {
public:
    MBOOL onInit() override {
        initLUT(); // 加载 LUT 表
        return MTRUE;
    }

    MBOOL onProcessFrame(FramePtr frame) override {
        auto in = frame->getBuffer(INPUT_PORT);
        auto out = frame->getBuffer(OUTPUT_PORT);
        applyVintageEffect(in, out);
        return MTRUE;
    }
};

该节点会在 FeaturePipe 中注册为中间处理单元，输入为 ISP 输出的 YUV420 图像，输出为已处理的增强图像。

8.3 节点接入与 Graph 构建实践

完成节点定义后，需在 FeatureGraphBuilder 中加入节点连接：

graph.addNode<P2Node>("p2");
graph.addNode<VintageEffectNode>("vintage");

graph.connect("p2", "vintage");
graph.connect("vintage", "callback");

系统在初始化时即建立图结构，并在每帧处理过程中调度节点执行。为控制性能，该节点启用独立线程，支持 QueueSize = 3，避免处理延迟阻塞主线。

测试中使用不同图片进行效果验证，并加入 Metadata 支持，允许 App 层通过 ANDROID_CONTROL_EFFECT_MODE 字段控制滤镜强度，最终实现在 Preview 预览中无延迟切换滤镜效果。

8.4 调试工具与性能分析方法

在开发与调试过程中，使用以下工具进行验证与调优：

  • FeaturePipeLogTool：观察节点运行时帧率、延迟、丢帧情况；
  • BufferDumpTool：抓取中间节点输入/输出 Buffer，用于验证图像处理效果；
  • CameraDumpTool：开启 Metadata Dump，对比节点处理前后的参数变化；
  • PerfMonitor：绑定节点线程到特定 CPU 核心，优化并发负载；

最终，该功能成功集成至正式版本中，并通过海外客户对图像表现与响应速度的双重验证，展示了 FeaturePipe 框架在自定义图像处理能力上的强大扩展性。

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