基于 RK3588 平台的 4K 视频流拉取、硬编码与 NPU 局部切图（Tiling）推理系统设计与实现

在智能边缘计算网关中，处理 4K（3840×2160）级别超高清分辨率视频流是一项系统性挑战。由于 4K 分辨率单帧原始 NV12 数据量达到 12.44 MB，使用常规 CPU 缩放和串行处理无法满足实时性（>=25 FPS）要求。

本文将详细探讨基于 Rockchip RK3588 平台的智能边缘网关——AlertGateway 的工程设计。我们将着重分析多线程流水线架构、基于 ROI 的多 Tile 切图推理（Tiling）、NV12 缩略图提取、MPP 硬件编码以及严苛的内存与性能压测细节。

1. 系统架构与线程调度模型
   系统的核心设计思想是解耦与流水线化。为防止因阻塞操作（如网络拉流抖动、NPU 推理延迟）导致系统吞吐率下降，AlertGateway 采用生产者-消费者模型，构建了 5 个核心线程与有界阻塞队列：

[拉流线程] (PullStreamThread)
    │
    ▼ (Frame Queue: NV12/YUYV 帧数据)
[推理线程] (InferThread) ────► [MQTT线程] (MqttThread) (JSON 结构 + Base64 缩略图)
    │
    ▼ (Encode Queue: 渲染后带框的 NV12 帧)
[编码线程] (EncodeThread)
    │
    ▼ (Stream Queue: H.264 NALUs)
[推流线程] (StreamThread) ────► [SRS RTMP 服务端]

1.1 关键并发控制机制
使用有界阻塞队列控制缓存规模：推理队列采用非阻塞投递，队列满时丢弃当前待入队帧；编码队列使用有限容量和短时阻塞，避免编码延迟无限累积。
主动丢帧策略：推理帧采用 non-blocking 投递，在队列拥塞时主动丢帧，使推理线程优先处理最新可用画面，最大程度保证算法的实时性。
FFmpeg 异步中断机制：拉流线程配置了 FFmpeg 读包回调的中断标志位，在收到 SIGINT/SIGTERM 信号时，先将中断标志位置 1，打断阻塞的 av_read_frame 网络 I/O，然后调用 std:🧵:join 优雅注销线程，防止死锁。
2. 核心模块技术设计
2.1 ROI 与 Tiling 局部推理设计
对于 4K 高清大图，远端目标（如键盘、水杯、车辆）的实际像素面积占比微乎其微。若将 4K 直接缩放到 640×640 送入 RKNN NPU，这些小目标会因特征丢失而无法检出。 为此，AlertGateway 引入了局部 Tile 推理机制（ROI Tiling）：

感兴趣区域配置：定义归一化浮点区域（例如 x=0.0, y=0.0, w=0.5, h=1.0 表示左半屏幕）。
瓦片划分（Grid Generation）：根据设定的切图列数与行数（当前测试配置为 2×1），在 ROI 内部计算重叠（Overlap Ratio）的子瓦片位置坐标。
轻量级内存切片：当前版本采用轻量 CPU 路径完成 ROI 裁剪和 Tile 数据组织，后续可进一步引入 RGA 优化。
NPU 算力封顶机制：
规则约束：单帧 NPU 调用次数上限为 2 次。
在当前 2×1 ROI Tiling 测试配置下，全局 NPU 推理被旁路，仅对划分出的 2 个 Tile 执行独立推理，单帧 NPU 调用次数固定为 2 次，且每个 Tile 最终缩放为模型所需的 640×640 输入尺寸。
坐标还原映射：

x_global = x_tile + x_tile_offset
y_global = y_tile + y_tile_offset

全局 NMS 合并：Tiling 后会产生瓦片交界处的重叠检测框。系统在坐标映射还原后，调用类感知（Class-aware）的全局非极大值抑制（NMS），以 IoU 阈值 0.45 对重叠的 Box 进行去重合并。
2.2 动态缩略图生成与 MQTT 载荷扩展
系统采用 CPU 路径直接缩放 NV12 视频帧生成缩略图，避免整图传输造成的带宽灾难：

缩放机制：采用 CPU nearest-neighbor 路径将输入帧缩放为 320×180 NV12 缩略图。
内存占用计算：对于 NV12 格式（$Y:U:V = 4:2:0$），其单像素所占字节数为 1.5 字节（Y 占 1 字节，UV 交叉占 0.5 字节）。因此，一个 320 × 180 分辨率的缩略图在内存中的精确字节数为： $$\text{Size} = 320 \times 180 \times 1.5 = 86,400 \text{ Bytes}$$
MQTT 数据封包：将 86,400 字节的 NV12 二进制数据进行 Base64 编码，产生 $86,400 \times \frac{4}{3} = 115,200$ 字节的文本，嵌入 JSON 报文进行发布。
停留时间判定：基于 IoU 跟踪器维护一个检测框状态机，记录特定目标进入 ROI 的首帧时间戳。若其累积停留时间超过 track_dwell_sec，则会触发 roi_events 事件上报，包含 dwell_sec、label 和 region 信息。为保证告警时效，带有 roi_events 的帧将绕过常规 MQTT 聚合去重过滤机制，直接发送。
3. 异常配置与健壮性设计（Resolution Mismatch Guard）
在拉流应用中，网络端摄像头分辨率可能会被人工更改或配置错误。如果不进行校验，解码后的帧内存大于配置内存，将导致后续的 MPP 硬件编码和 RGA/CPU 拷贝操作发生段错误（Segmentation fault）或物理内存踩踏。

AlertGateway 在解码后执行严格的前置校验。

以下为逻辑示意伪代码，实际实现位于 PullStreamThread：

if (decoded_frame.width != config.source_width ||
    decoded_frame.height != config.source_height) {
    LOG_WARNING("Decoded resolution mismatch; dropping frame.");
    return;
}

该机制在测试中完美拦截了由于“配置 1080p，拉流实际 4K”造成的格式不匹配，且未引起任何内存踩踏或服务中止。

4. 系统验证与性能指标分析
   测试基于搭载 RK3588S SoC 且运行 Ubuntu 22.04 LTS 的开发板进行，主频调优为 performance。采用 WSL 实时向 SRS 转发器推送 4K@15 FPS 的合成 H.264 视频流作为输入。

4.1 内存稳定性（RSS Profiling）
全图像处理功能（Tiling 2×1 + ROI + Thumbnail）满载启用，运行时间 60 秒以上的 VmRSS 物理内存指标如下表所示：

运行时间 (s)	物理内存 VmRSS (KB)	物理内存 VmRSS (MB)	说明
5	246,736	246.7	初始化完毕，拉流开始
10	237,232	237.2	内存池回收与动态分配
20	237,768	237.7	状态稳定，检测队列活跃
30	274,092	274.0	双 Tile 推理帧率波峰，缓冲区填充
45	262,072	262.0	回收闲置硬编解码缓冲区
60	262,208	262.2	最终稳定值

结论：系统内存处于 225MB 至 274MB 之间动态波动（符合多路缓冲区动态分配特性），在长时间运行下未观察到单调累积和泄漏趋势。

4.2 管道时延与运行指标
NPU 单次推理（640x640）：26.0 ms - 29.3 ms。
单帧全计算时间：根据 InferThread 输出日志采样，单帧推理全计算耗时约为 36.0 ms - 46.0 ms（含图像预处理、拷贝与 NPU 推理）。
推流输出端帧率（FPS）：25.1 - 36.3 FPS。
输出格式：视频流编码为 H.264 Main Profile，分辨率为 3840×2160，配置文件中 stream 的 bitrate_kbps 设置为 3000。
人工播放反馈：在 rambosplayer 端拉取 rtmp://192.168.0.168/live/testsrc2_result 进行播放，4K 超清画面及检测框显示正常。但在高负载下观察到一定的显示时延和轻微卡顿，这反映了当前系统在极端并发吞吐时的时限开销，属于后续架构优化范畴。
5. 当前工程局限与演进方向
在当前架构的基础上，为了更进一步榨干 RK3588 硬件潜力，后续版本将着重在以下方面演进：

RGA 硬件预处理：目前版本的裁剪和 nearest-neighbor 压缩算法处于 CPU 路径，当跑满双 Tile + 缩略图时会加重 CPU 的常态负荷，后续计划重构为 RGA 零拷贝算子。
V4L2 链路格式扩展与 MJPEG 支持：目前的 V4L2 摄像头采集驱动仍硬编码为 YUYV 格式，导致部分摄像头（如 C310）受限于 USB 带宽在 1280×720 分辨率下只能跑 10 FPS。后续评估基于 FFmpeg/libjpeg-turbo 或平台硬件 JPEG 解码的 MJPEG 转 NV12 方案。
编码及传输优化：针对高负载下的轻微延迟卡顿现象，未来需要在 MPP 编码参数中引入更细致的 gop_len、bitrate_mode 调节机制，并配合推流队列的拥塞控制逻辑。
本文内容及测试数据均已在 AlertGateway 验证平台归档。
github:https://github.com/johnjiamzhong-project/AlertGateway