RK3588 项目实战总结：从 GStreamer、DP 显示、OpenCV 到 YOLO 部署的一次完整梳理

RK3588 项目实战总结：从 GStreamer、DP 显示、OpenCV 到 YOLO 部署的一次完整梳理

这篇文章不是泛泛讲概念，而是站在一次真实项目调试的角度，把 RK3588 + Camera + DP + GStreamer + OpenCV + YOLO 这条链路串起来，做一份适合复习和回看的完整笔记。它适合下面几类人：

• 正在做 Rockchip 平台相机项目的人
• 想把摄像头图像显示到 DP 屏的人
• 想把 YOLO 跑到板端的人
• 经常在 GStreamer / Weston / OpenCV / NPU / GPU 之间切换、但总觉得知识点散的人

我会重点回答这些问题：

• GStreamer 的核心知识点到底是什么
• 图像显示到 DP 屏，到底需不需要完整图形界面
• Weston、OpenCV imshow、kmssink 之间是什么关系
• YOLO 在 RK3588 上应该优先用 CPU、GPU，还是 NPU
• Rockchip 和 Jetson 的思路差别在哪里
• 实际调试时最应该先看什么

如果你说的 "Jeston" 指的是 NVIDIA Jetson，本文里我按 Jetson 来理解。

---

一、先建立一张全局图：这套系统到底在做什么

一个板端视觉系统，通常可以拆成下面几层：

Sensor/Camera
    ->
ISP / 3A / RKAIQ
    ->
V4L2 视频节点
    ->
GStreamer / OpenCV / 自研程序
    ->
编码 / 推理 / 显示 / 网络传输
    ->
DP屏 / 主机 / 网络端 / 存储

如果再细一点，可以拆成三条主路径：

1. 预览路径
camera -> v4l2src -> 显示 sink -> DP 屏

2. 录制路径
camera -> 编码器 -> mux -> 文件

3. AI 路径
camera -> preprocess -> inference -> postprocess -> 叠框 -> 显示 / 输出结果

很多问题其实都是因为把这三条路径混在一起看，导致判断错误。实际调试时一定要先分清楚：

• 我现在是在查"采集"问题
• 还是在查"显示"问题
• 还是在查"推理"问题

---

二、GStreamer 的核心知识点：不是背插件，而是理解"流水线"

很多人一开始用 GStreamer，会把注意力放在某个插件名字上，比如 v4l2src、mpph265enc、kmssink。但真正要掌握的，是它的流水线思想。

1. 最核心的概念

GStreamer 本质就是一条数据流管道：

source -> filter/transform -> encoder/decoder -> sink

对应到摄像头场景就是：

v4l2src -> format/size/framerate 协商 -> 编码/转换/叠框 -> 显示或保存

2. 一条最典型的录制命令

gst-launch-1.0 -e \
  v4l2src device=/dev/video11 ! \
  video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \
  mpph265enc ! h265parse ! mp4mux faststart=true ! \
  filesink location=record.mp4

这条命令可以拆成：

• v4l2src
  从 V4L2 视频节点取图
• video/x-raw,...
  指定输入格式、分辨率、帧率
• mpph265enc
  用 Rockchip 硬件编码器做 H.265 编码
• h265parse
  规范码流
• mp4mux
  封装成 MP4
• filesink
  写入文件

3. 显示命令和录制命令的区别

录制是：

camera -> encode -> file

显示是：

camera -> display

例如：

gst-launch-1.0 -e \
  v4l2src device=/dev/video11 ! \
  video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \
  kmssink

所以不要把"录制正常"直接等同于"显示也一定正常"。它们只是共享前半段。

4. 真正需要记住的不是命令，而是这四件事

• 输入是什么：/dev/videoX、格式、尺寸、帧率
• 中间有没有重负载环节：videoconvert、软件缩放、CPU 后处理
• 输出是什么：文件、窗口、KMS、网络
• 是否走了硬件路径：硬件编码、硬件显示 plane、NPU

---

三、显示到 DP 屏，需不需要完整图形界面

答案是：不一定。

1. 不带桌面也能显示

如果 DP 已经连上，最轻量的方式是直接走 DRM/KMS，比如 kmssink。这条路不依赖完整桌面。

camera -> kmssink -> DP

这种方式适合：

• 预览
• 纯播放器
• 嵌入式产品化场景
• 资源敏感场景

2. 带桌面时的方式

如果系统里跑了 Weston，那就可以走窗口化显示：

• OpenCV imshow
• GTK
• waylandsink
• Qt/GTK 程序

这种方式适合：

• 开发调试
• 桌面应用
• 需要多窗口交互

3. 一个关键理解

"DP 屏能亮" 和 "OpenCV 能弹窗" 不是一回事。

DP 亮说明的是：

• 显示硬件链路通了
• DRM/KMS/Weston 基本正常

imshow 能否弹窗，还取决于：

• OpenCV 是否带 GUI backend
• 当前进程是否在正确的图形会话里
• GTK/Wayland/X11 环境变量是否正确

这也是为什么很多时候：

• kmssink 可以显示
• 但 cv2.imshow() 会失败

---

四、Weston、OpenCV、GTK、Wayland 到底是什么关系

这一块很容易混。

1. Weston 是什么

Weston 是 Wayland compositor。你可以把它理解成：

• 显示会话管理者
• 负责窗口合成
• 管理 Wayland 客户端

2. OpenCV 自己不是桌面系统

OpenCV 只是库。cv2.imshow() 本质上需要借助 GUI backend，比如：

• GTK
• Qt
• Cocoa
• Windows API

在你的板子上，OpenCV 走的是 GTK。

3. 为什么 imshow 经常报错

常见两类报错：

第一类

The function is not implemented

这说明：

• OpenCV 编译时根本没带 GUI backend

第二类

Can't initialize GTK backend

这说明：

• GTK 已经编进去了
• 但当前命令运行环境没有连接到图形会话

也就是：

• 不是 OpenCV 不支持
• 是当前 shell 不是那个 GUI session 里的 shell

4. 这一点对实际调试非常重要

如果你是在：

• 串口
• ssh
• adb shell
• 普通 root shell

里跑 yolo-demo --show，哪怕 DP 屏亮着，也可能打不开窗口。

因为 cv2.imshow() 不是直接画到物理屏，它需要连到 Weston 的图形会话。

---

五、RKAIQ / 3A server 到底做什么，有没有副作用

很多人会问：rkaiq_3A_server 到底要不要留。

答案是：大多数相机场景建议保留。

1. 3A 的核心含义

• AE
  自动曝光
• AWB
  自动白平衡
• AF
  自动对焦

2. 它的主要作用

就是不断根据当前场景，去调节相机成像参数，让你画面看起来正常。

3. 它不负责什么

它不负责：

• DP 显示
• GStreamer 显示逻辑
• 网络传输
• YOLO 推理

4. 它会不会有副作用

它没有和系统无关的副作用，但会持续改变成像参数。

这意味着：

• 做普通预览时，这是好事
• 做固定曝光实验时，这可能不是你想要的
• 做检测算法验证时，画面亮度和颜色可能会动态变化

所以一句话总结：

RKAIQ 不是必须参与显示链，但通常应该参与成像链。

---

六、OpenCV 在这套板端 YOLO 方案里到底扮演什么角色

这次项目里，OpenCV 不是主要推理引擎，而是"视觉工具层"。

它负责：

• 打开摄像头
• resize
• letterbox
• BGR/RGB 转换
• 画框
• 打字
• NMS
• 可选窗口显示

它不负责：

• RKNN 推理
• GPU 推理
• NPU 推理

如果走 OpenCV DNN，OpenCV 还会负责模型加载和推理；但你这次碰到的问题恰恰说明：

OpenCV 4.5.5 DNN 对新的 YOLO ONNX 支持不稳定。

所以这次更合理的路线变成了：

OpenCV 做图像处理
onnxruntime 做模型推理

这也是一条很典型的工程拆分思路。

---

七、YOLO、ONNX、PT、RKNN：板端部署时怎么选

这是本文最关键的一块。

1. .pt 是什么

.pt 是 PyTorch 模型，一般依赖：

• torch
• ultralytics
• Python 环境

优点：

• 开发方便
• PC 上实验快

缺点：

• 板端依赖重
• 镜像大
• 不适合做轻量产品部署

2. .onnx 是什么

.onnx 是通用交换格式。

优点：

• 比 .pt 轻
• 便于跨框架部署
• 可以接 onnxruntime、OpenCV DNN、TensorRT 等后端

缺点：

• 不同后端兼容性差异很大
• 不是所有 ONNX 都能被 OpenCV DNN 吃下

3. .rknn 是什么

.rknn 是 Rockchip NPU 友好的模型格式。

优点：

• 最适合 RK3588
• 可以真正利用 NPU
• 功耗和性能更适合产品化

缺点：

• 需要模型转换
• 和平台绑定更强

4. 当前板端最合理的排序

如果你在 RK3588 上做产品：

• 开发验证：.onnx
• 最终部署：.rknn

如果你只是临时实验：

• .pt 也能玩
• 但不建议作为最终板端方案

---

八、在 RK3588 上，YOLO 应该用 CPU、GPU 还是 NPU

当前这版方案

现在这版 yolo-demo 是：

• onnxruntime + CPUExecutionProvider
• 所以是 CPU 推理

为什么没有直接用 GPU

不是因为 GPU 不能做计算，而是因为在 RK3588 上，做模型推理时：

最佳优先级通常不是 GPU，而是 NPU。

原因是什么

CPU

优点：

• 最容易先跑通
• 依赖最少

缺点：

• 速度可能不够
• 功耗不划算

GPU

优点：

• 可以做部分图形和通用计算
• 适合渲染、合成、OpenGL

缺点：

• RK 平台上做深度学习推理生态不如 Jetson/CUDA 顺
• 不是板端视觉产品的主力路线

NPU

优点：

• 专门做 AI 推理
• 更适合板端实时检测
• 性能/功耗比最好

缺点：

• 需要转 rknn
• 开发门槛略高

一句话结论

在 RK3588 上，YOLO 真正想高效实用，最终应优先走 NPU/RKNN，不是 GPU。

---

九、和 Jetson 对比，思路差别在哪里

如果把 RK3588 和 Jetson 做工程视角上的对比，可以这样理解。

Jetson 的典型思路

• GPU/CUDA 是主力
• TensorRT 生态成熟
• PyTorch/ONNX/TensorRT 路线很自然
• "GPU 做 AI" 是主流思维

RK3588 的典型思路

• NPU/RKNN 是主力
• GPU 更多偏图形、渲染、辅助计算
• CPU 路线可以先验证
• 最终部署更强调 RKNN + NPU

工程上怎么选

如果你是：

• 想快速复用大量 CUDA 生态
• 已有 TensorRT 工具链
• 偏算法研究环境

Jetson 更顺。

如果你是：

• 做板端产品
• 想成本、功耗、集成度更平衡
• 接受用 RKNN 做部署

RK3588 很合适。

所以不是谁绝对强，而是路线不同。

---

十、怎么看 CPU 和 GPU 占用，调试时先盯什么

1. 当前最该盯 CPU

因为当前 yolo-demo 是 CPU 推理。

看 CPU：

top

看进程线程：

PID=$(pgrep -f yolo-demo.py)
top -H -p $PID
ps -T -p $PID -o pid,tid,%cpu,psr,comm

2. 看 GPU

RK3588 常看：

cat /sys/class/devfreq/fb000000.gpu/load
cat /sys/class/devfreq/fb000000.gpu/cur_freq

实时看：

watch -n 1 '
echo -n "load: "; cat /sys/class/devfreq/fb000000.gpu/load 2>/dev/null
echo -n "cur_freq: "; cat /sys/class/devfreq/fb000000.gpu/cur_freq 2>/dev/null
'

3. 当前这版可能看到什么

大概率是：

• CPU 很忙
• GPU 不高
• NPU 基本没动

这正说明：

• 现在还没进入 RKNN 路线
• 推理主力还是 CPU

---

十一、这次调试里最应该记住的几个经验

经验 1

"DP 能亮"和"OpenCV 能弹窗"不是一回事。

经验 2

录制正常，不代表显示一定正常。

经验 3

显示问题先分清是 KMS 问题、Weston 问题，还是 OpenCV/GTK 会话问题。

经验 4

新 YOLO ONNX 模型不一定能被老 OpenCV DNN 正常加载。

经验 5

RK3588 做 AI 推理，长期正确方向是 NPU/RKNN。

经验 6

Weston 有时会息屏，测试阶段要关 idle-time。

经验 7

如果程序要弹窗口，它必须运行在正确的图形会话里。

---

十二、我给自己的最终复习结论

如果以后我再做一块 RK3588 视觉板子，我会按下面这个顺序思考：

第一步：先打通相机链

• V4L2 节点是不是对的
• 分辨率/帧率是不是对的
• RKAIQ/3A 是否正常

第二步：再打通显示链

• DP 是否 connected
• 是走 kmssink 还是 Weston
• 是否需要窗口显示

第三步：再打通 AI 链

• 先 CPU/ONNX 验证功能
• 再转 RKNN/NPU 做性能优化

第四步：最后才谈产品化

• 自动启动
• 全屏显示
• 网络传输
• 低功耗
• 稳定性

---

十三、一句话总收尾

这次项目真正让我记住的一句话是：

在 RK3588 上做视觉系统，不要把"采集、显示、推理"混成一个问题来查；显示看 DP/Weston，推理看 CPU/NPU，最终部署优先走 RKNN，而不是把所有问题都归结到 GPU。