开头搞嵌入式AI视频处理的朋友这两年应该都有个体会板载推理早就不是“跑个demo拍个照”的玩具级别了真正难的是把整个视频链路串起来——摄像头拉流进来、硬解、推理、画框、再编码推出去每一步都有坑。尤其是在RK3588这种带NPU又带强劲视频编解码单元VPU/MPP的芯片上大部分教程只讲“怎么用YOLO识别一张图”很少告诉你一条完整视频流怎么在板子上闭环跑起来。这篇东西我拖了小半年才决定写原因是这套流程踩坑太多真要从零讲清楚得排不少篇幅。想做到的效果是摄像头或者RTSP源里的视频拉进RK3588之后经过MPP硬解码喂给RKNN转换后的YOLO模型做检测再把带检测结果的画面用MPP硬编码成H.264/H.265最后推回ZLMediaKit提供RTSP、HTTP-FLV之类的流给下游消费。整条链路全部在板端完成不依赖x86服务器转码。适合正在折腾RK3588视觉项目、想在板子上一站式搞定“拉流-推理-推流”的朋友也适合想搞懂MPP和ZLMediaKit怎么配合的开发者。先说一下我这边的硬件环境RK3588开发板8G内存版本USB摄像头一路海康RTSP摄像机一路系统是Ubuntu 22.04内核用的Rockchip官方SDK里的版本。软件栈包括ZLMediaKit源码编译、Rockchip MPP官方仓库编译、RKNN-Toolkit2和RKNN Runtime 1.6.0、YOLOv8s模型COCO数据集训练。下面每一节我都会把关键源码结构和配置参数展开说尽量做到你照着能复现。1. 整体方案设计先想清楚“谁拉谁推”1.1 视频链路架构在做任何代码之前先把整个数据流向画清楚。RK3588板子上我们其实扮演了两个角色一是ZLMediaKit的客户端拉流、推流二是视频处理的计算节点。我最后敲定的链路是这样的摄像头/视频源通过RTSP协议接入板端这一步用ZLMediaKit的API来拉流得到原始的H.264/H.265裸流注意是编码后的流不是图像帧。拿到编码裸流之后不自己写软解而是交给RK3588的VPU也就是MPP硬解码模块。MPP解出来的帧是NV12格式的YUV数据存在DRM分配的内存里。这部分NV12帧就是YOLO推理的输入。RK3588的NPU虽然可以直接吃NV12做量化模型的输入但我为了适配不同来源的流统一转成RGB做一次预处理再送进RKNN模型。推理输出的是检测框坐标、类别和置信度。我拿到这些数据直接在NV12帧上画框省掉一次颜色空间转换的开销。画完框之后的NV12帧再走MPP硬编码输出H.264/H.265码流。最后编码出的码流推流到ZLMediaKit服务端板子上跑一个或者远程服务器也行下游用户通过VLC、WebRTC、HTTP-FLV任意方式拉流观看。一个很关键的设计决策是推理和编码之间尽量不要拷贝内存。MPP解码出来的帧本身在物理内存里NPU推理需要的输入也喜欢物理连续内存如果能做到“解码内存直接给NPU用”延迟能少好几毫秒。但实际开发中NPU接口和MPP接口的缓冲区格式不完全一致所以在第一步不要强求零拷贝先用memcpy跑通全流程再逐步优化。1.2 为什么选择ZLMediaKit我在之前的系列文章里提过选流媒体框架要看三个维度协议覆盖、并发能力、二次开发成本。ZLMediaKit在这三点上都比较省心。先说协议。ZLMediaKit本身是一个服务端它支持RTSP、RTMP、HLS、HTTP-FLV、WebRTC等主流协议更重要的是它提供了非常完善的C API和RESTful API方便做二次开发。我们在这个项目里不仅用它的服务端能力还用它的客户端能力拉取远程RTSP流。这点很关键——ZLMediaKit不只是做“服务器”那么简单它的Player接口可以主动去拉外部RTSP流然后把这个流当成一个代理源来转发或处理。再说部署。ZLMediaKit是C写的依赖很少在RK3588这种arm64架构上编译相当顺利。相比起WebRTC框架那堆依赖这简直是一股清流。包体小内存占用也低跑在板子上毫无压力。1.3 为什么用MPP而不是FFmpeg软解这是很多人容易绕弯的地方。FFmpeg确实也有RK3588的硬件解码支持底层其实也调了MPP或者v4l2。但直接使用MPP的优势在于更底层、更可控、更容易做零拷贝优化。MPP是Rockchip官方的媒体处理平台直接和VPU驱动打交道内存管理、buffer复用都是它的核心能力。而FFmpeg封了一层能配置的细节变少出了问题也不好排查。我实测下来RK3588的MPP解1080p 30fps的H.264CPU占用几乎可以忽略不计。如果走FFmpeg软解A76核心直接跑满一个。NPU本身也要占CPU做一些调度CPU资源在这个项目里是紧张的所以必须硬解。1.4 部署形态考虑还有一个容易忽略的点ZLMediaKit跑在板子上还是跑在别的服务器上我的做法是板子上跑一个ZLMediaKit主要做拉流和最终推流的接收端同时中间处理逻辑作为一个独立进程挂在ZLMediaKit旁边通过RTSP拉流处理完再推流回去。这里其实有两个进程在各自做事情避免把ZLMediaKit的线程模型和推理代码耦合在一起。好处很明显处理程序崩了不影响ZLMediaKit服务排查问题方便很多。你不需要把YOLO代码写进ZLMediaKit内部。实际上ZLMediaKit可以通过Hook机制做二次开发把解码后的帧数据交给外部处理但那样耦合度高不利于我们这种经常要调模型的场景。独立进程模式是最稳的。2. 环境搭建RK3588上的依赖准备与编译2.1 确认系统与固件版本RK3588的开发板很多正点原子、友善之臂、瑞芯微官方板我都用过底子都差不多的Linux系统。首先建议拿瑞芯微官方SDK里的Ubuntu固件不要用第三方精简版因为MPP、RKNN这些都需要对应的内核驱动模块。命令检查一下uname -a cat /etc/os-release sudo dmesg | grep -i rknpu如果能看到rknpu相关日志说明NPU驱动已经就位。MPP驱动一般已经编进内核可以用ls /dev/mpp_service确认如果没有这个节点内核对VPU的驱动就有问题赶紧换固件。我用的内核版本是5.10对应的rknpu驱动版本是0.9.x。如果你用的是新一些的6.1内核驱动API有些变化后续编译RKNN Runtime的时候需要注意版本匹配。2.2 编译ZLMediaKitZLMediaKit有两种拿法一种是用git拉最新源码一种是release包。建议拉源码自己编译因为arm平台的编译选项要做些调整。git clone https://github.com/ZLMediaKit/ZLMediaKit.git cd ZLMediaKit git submodule update --initZLMediaKit依赖openssl、libsrtp等你可以用apt直接装也可以用它的build_depends脚本一键搞定。在RK3588上我建议全部走apt省时间sudo apt install build-essential cmake libssl-dev libsrtp2-dev libavcodec-dev libavformat-dev libavutil-dev然后编译mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease -DENABLE_WEBRTCON make -j8注意RK3588是八核CPU但A76和A55大小核架构make -j8没问题但如果你想稳一点就-j6。编译时间大概十分钟左右完成后在build目录下会有MediaServer可执行文件。启动ZLMediaKit默认配置就可以./MediaServer -d -c ../config.ini默认端口是1935RTMP、554RTSP、80HTTP-FLV。建议改一下HTTP端口避免和其他程序冲突在config.ini里搜http.port改掉就行。2.3 编译安装Rockchip MPPMPP的源码在GitHub上有官方仓库直接编静态库或者动态库都行。git clone https://github.com/rockchip-linux/mpp.git cd mpp mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease -DBUILD_TESTON make -j6 sudo make install编译之后会在/usr/local/lib下生成librockchip_mpp.so。这里建议把测试程序也编译出来比如mpi_dec_test、mpi_enc_test它们可以单独对一段裸流做解码或编码测试定位问题非常好用。一个常见坑MPP安装到/usr/local之后系统默认库路径可能不包含/usr/local/lib需要把路径加入ldconfig配置echo /usr/local/lib | sudo tee /etc/ld.so.conf.d/mpp.conf sudo ldconfig不然编译你自己的程序时链接找不到so。2.4 安装RKNN Runtime与RKNN-Toolkit2YOLO模型在PC上训练好之后不能直接跑在RK3588的NPU上需要通过RKNN-Toolkit2转换成.rknn格式然后在板端用RKNN Runtime来推理。板端安装比较简单pip3 install rknn-toolkit2-1.6.0-cp310-cp310-linux_aarch64.whl或者你直接把rknn-toolkit2仓库里的rknn_server和librknnrt.so拷到板子上。这里要注意版本一致性PC端RKNN-Toolkit2版本必须和板端RKNN Runtime版本一致否则模型加载会报版本错误。我用的组合是RKNN-Toolkit2 1.6.0 RKNN Runtime 1.6.0在Python 3.10和Ubuntu 22.04下跑得很稳。如果你用新板子的固件可能内置了更高版本的Runtime记得统一。3. 拉流与MPP解码从RTSP裸流到NV12帧3.1 用ZLMediaKit拉取RTSP流这里先讲一下怎么从ZLMediaKit拉流。ZLMediaKit提供了一套C API可以用于创建player拉流播放然后把得到的帧数据回调出来。在C代码里我会这么用#include Player/PlayerBase.h #include Player/PlayerProxy.h using namespace toolkit; using namespace mediakit; PlayerProxy::Ptr player(new PlayerProxy(nullptr, rtsp://192.168.1.100:554/stream1)); player-setOnPlayResult([](const SockException err) { if (err) { printf(拉流失败: %s\n, err.what()); } else { printf(拉流成功\n); } }); player-play();不过在实际项目中我用得更多的是ZLMediaKit的Hook机制直接在自己的进程里调用MediaPlayer类来拉流拿到底层frame回调。在回调中能拿到Frame::Ptr它包含了编码数据以及时间戳信息。一个重要的点ZLMediaKit的frame回调返回的是编码后的数据H264/H265裸流。我需要把它积累成一个完整的GOP或者至少一帧的起始码然后送入MPP解码器。MPP的输入是码流不是NAL单元所以得自己处理起始码。3.2 MPP解码器的创建与配置MPP的解码流程不复杂但接口细节多。核心是MppCtx和MppPacket、MppFrame这三个数据结构。#include rk_mpi.h MppCtx ctx nullptr; MppApi *mpi nullptr; mpp_create(ctx, mpi); // 设置为h264解码 MppCtxType type MPP_CTX_DEC; MppCodingType coding MPP_VIDEO_CodingAVC; mpp_init(ctx, type, coding);初始化之后就是送码流。这个循环逻辑是这样的先从ZLMediaKit回调里积累NALU数据凑够一帧判断关键帧或者帧结束符或者用时间戳变化判断。把这一帧数据封装成MppPacket然后mpi-decode_put_packet(ctx, packet)送入解码器。之后调用mpi-decode_get_frame(ctx, frame)取出解码后的图像帧。MppPacket packet nullptr; mpp_packet_init(packet, data, data_size); mpp_packet_set_pts(packet, pts); mpp_packet_set_eos(packet, 0); mpi-decode_put_packet(ctx, packet); MppFrame frame nullptr; MPP_RET ret mpi-decode_get_frame(ctx, frame); if (ret MPP_OK frame) { // 拿到解码后的YUV帧 MppBuffer buffer mpp_frame_get_buffer(frame); void *yuv_data mpp_buffer_get_ptr(buffer); int width mpp_frame_get_width(frame); int height mpp_frame_get_height(frame); int hor_stride mpp_frame_get_hor_stride(frame); int ver_stride mpp_frame_get_ver_stride(frame); }有一点必须注意hor_stride和width不一样。MPP为了保证内存对齐解码出来的YUV帧宽高往往会对齐到16或者64的倍数。我一开始没注意这个直接用width去读取YUV数据画面颜色完全错乱。之后统一用hor_stride和ver_stride作为内存布局尺寸。解码输出的格式默认是MPP_FMT_YUV420SP也就是NV12——Y平面连续UV交错平面跟在后面。这个格式正好是后续NPU推理和MPP编码都容易处理的格式。3.3 内存管理与Buffer复用MPP解码性能高低很大程度上取决于buffer是否复用。解码器内部默认会做buffer池但如果你每帧都分配新buffer系统负载会很高。建议在创建解码器时设置分组模式MppBufferGroup group nullptr; mpp_buffer_group_get_internal(group, MPP_BUFFER_TYPE_DRM); mpp_dec_set_ctx(ctx, group, MPP_DEC_SET_GROUP);这样解码器会自己管理一组DRM buffer循环使用。你从mpp_frame_get_buffer拿到的buffer在下一帧解码开始前可能会被复用所以如果你需要跨帧保存数据一定要自己拷贝一份或者用引用计数方式延长buffer生命周期。3.4 拉流中断重连RTSP拉流在真实场景中经常断。网络抖动、摄像头重启都会导致流断开。ZLMediaKit的PlayerBase提供了网络断开的回调在setOnShutdown里触发。我一般这样处理如果断流延迟1到3秒重连重连次数不限。同时把解码器reset一下因为解码器内部状态可能停留在旧流的尾帧不reset直接喂新流会有解码报错。player-setOnShutdown([](const SockException err) { printf(流中断: %s\n, err.what()); // 延迟重连 std::thread([](){ sleep(2); player-play(); }).detach(); });这个重连逻辑写好后7×24小时跑测试基本没出过问题。4. YOLO推理接入模型转换与NPU部署细节4.1 YOLO模型选择RK3588的NPU算力是6 TOPSINT8精度。这意味着你不能像在4090上那样跑YOLOv8x甚至YOLOv9系列。我最终用的是YOLOv8s输入尺寸640×640COCO数据集训练。如果你想要更高检测精度可以用YOLOv8m但帧率会掉一半。如果你对检测速度有极致要求YOLOv8n是个选择但在小目标上漏检比较多看场景取舍。说一下YOLO版本问题。很多人问“YOLO第几代了”这里多说一句Ultralytics的YOLOv8是目前社区最常用的YOLOv9、YOLOv10、YOLO11也有他们在各自方向上的改进。但对于部署到RK3588来说YOLOv8的生态最完善转RKNN的脚本也多建议别追新稳定第一。4.2 RKNN模型转换转换过程在PC端完成。首先在PC上装好RKNN-Toolkit2然后写一个Python脚本转换from rknn.api import RKNN rknn RKNN() # 加载ONNX模型 rknn.config(mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588) rknn.load_onnx(modelyolov8s.onnx) # 转换量化方式用i8 rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(yolov8s.rknn)这里的dataset.txt是一个文本文件每行是一张图片的路径用于启动量化校准。我一般准备50到100张和实际应用场景接近的图片如果图片内容差异很大比如平时检测车、偶尔检测人混在一起放就行。注意图片尺寸要和模型输入一致否则量化会报错。一个容易忽略的点YOLOv8的ONNX导出时最后输出是三个尺度的特征图。有些转换教程会建议你把输出层做一下后处理整合让输出直接就是检测框。我推荐在ONNX里只保留原始输出后处理放在板端做这样更灵活也能利用NPU的并行计算特性。4.3 板端RKNN Runtime推理流程初始化NPU#include rknn_api.h rknn_context ctx; rknn_init(ctx, model_data, model_size, 0, nullptr); rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num));每一帧推理时输入是一个640×640×3的RGB图像。但我们在解码环节拿到的帧是NV12所以需要先做一个颜色空间转换和缩放处理。我建议的图像预处理步骤把NV12的Y分量取出然后用RGARockchip的2D图形加速单元做缩放和格式转换直接把NV12转成RGB同时缩放到640×640。如果不想引入RGA也可以用CPU做转换。但实测在RK3588上A76核心跑NV12到RGB的转换1080p一帧大约要3到5毫秒加上再缩放到640×640整体要7毫秒以上对实时性影响比较大。用RGA的话总共1到2毫秒搞定。RGA的使用又是另一个话题了这里直接说结论用librga.so调用c_RkRgaTransform完成缩放和颜色转换。RGA支持NV12输入到RGB888输出并且支持同时缩放。推理调用rga_input.width hor_stride; rga_input.height ver_stride; rga_input.format RK_FORMAT_YCbCr_420_SP; rga_output.width 640; rga_output.height 640; rga_output.format RK_FORMAT_RGB_888; // 初始化rga_info并执行 rknn_input.input_buf rgb_buf; rknn_input.size 640 * 640 * 3; rknn_input.fmt RKNN_TENSOR_NHWC; rknn_input.type RKNN_TENSOR_UINT8; rknn_input.index 0; rknn_inputs_set(ctx, 1, rknn_input); rknn_run(ctx, nullptr); rknn_outputs_get(ctx, 1, rknn_output, nullptr);这里注意rknn_input.fmt一定要和模型输入匹配。转换成ONNX时默认是NCHW需要在RKNN转换脚本里设置inputs_layoutnhwc否则推理结果会乱。4.4 后处理解析YOLOv8的后处理和YOLOv5不太一样没有objectness分支。模型输出三个特征图80x80、40x40、20x20每个特征图对应四个维度reg边界框回归、cls类别概率。我写的后处理流程分这几步解包每个特征图把网格单元的回归参数转换成实际的x1,y1,x2,y2坐标。遍历所有候选框先按置信度阈值过滤我一般设0.45。对剩余框做NMS非极大值抑制NMS的IoU阈值设0.45到0.5之间。输出最终目标的坐标和类别。这部分在板端用C实现耗时取决于目标数量一般5到10毫秒左右。如果你追求极致性能可以把NMS放到NPU上用自定义算子实现但工程复杂度太高收益有限。在RK3588上用CPU后处理完全够用除非你要同时跑多路流。5. MPP编码与推流把检测结果变成标准视频流5.1 在NV12帧上画检测框推理拿到目标框之后我要在NV12帧上画框。NV12格式下画框有一个比较特殊的地方图像数据分成Y平面和UV平面两部分Y平面的像素位置对应图像的亮度UV平面是两倍下采样的色度信息。画框最简单的方式是只修改Y平面和对应区域的UV值。由于NV12的UV分辨率是Y分辨率的一半一个坐标为(x, y)的像素点对应的UV坐标是(x/2, y/2)。我通常使用以下方式画一个红色的框对于框的上边缘和下边缘把Y值设为76相对较暗U设为84V设为255红色色度。对于框的左边缘和右边缘同样处理。一个细节是边框的宽度。在1080p图像上画2到3个像素宽度的边框比较合适。太窄了看不清楚太宽了会遮挡目标。我一般用2像素。文字标注就比较麻烦了NV12上画文字需要自己实现字模绘制。我的做法是在PC端生成一套点阵字模数据嵌入到程序里然后在绘制时按位图填充。这样不依赖字体库效率也高。5.2 MPP编码器参数选择编码部分的MPP代码和解码类似但配置参数要多一些MppCtx enc_ctx; MppApi *enc_mpi; mpp_create(enc_ctx, enc_mpi); mpp_init(enc_ctx, MPP_CTX_ENC, MPP_VIDEO_CodingAVC); MppEncCfg cfg; mpp_enc_cfg_init(cfg); mpp_enc_cfg_set_s32(cfg, prep:width, width); mpp_enc_cfg_set_s32(cfg, prep:height, height); mpp_enc_cfg_set_s32(cfg, prep:hor_stride, hor_stride); mpp_enc_cfg_set_s32(cfg, prep:ver_stride, ver_stride); mpp_enc_cfg_set_s32(cfg, prep:format, MPP_FMT_YUV420SP); mpp_enc_cfg_set_s32(cfg, rc:mode, MPP_ENC_RC_MODE_CBR); mpp_enc_cfg_set_s32(cfg, rc:bps, 4 * 1024 * 1024); // 4Mbps mpp_enc_cfg_set_s32(cfg, rc:bps_max, 4.5 * 1024 * 1024); mpp_enc_cfg_set_s32(cfg, rc:bps_min, 3.5 * 1024 * 1024); mpp_enc_cfg_set_s32(cfg, codec:type, MPP_VIDEO_CodingAVC); mpp_enc_cfg_set_s32(cfg, codec:gop, 30); // I帧间隔 mpp_enc_cfg_init_enc_ctx(cfg);码率的设置要根据分辨率来。1080p我一般用4Mbps流畅度和画质平衡。如果你推流到互联网带宽有限可以压到2Mbps但画面压缩痕迹会明显一些。720p用2Mbps足够。GOP设为30帧也就是每1秒一个I帧便于拉流端快速起播。编码帧率控制在多少这取决于NPU推理耗时。YOLOv8s在RK3588 NPU上单帧推理大约20到30毫秒加上解码和编码整个流程大概能在15到25帧之间波动。因此编码器设置rc:fps最大25就合适不要设置过高。编码环节需要特别注意的另一点是每次调用mpp_enc_put_frame之前要确保送入的MppFrame格式和时间戳正确。时间戳建议用毫秒级的系统时间这样拉流端的音视频同步不会出问题。音频我们暂时没有接入纯视频流。5.3 编码输出处理与推流MPP编码器输出的是MppPacket其中包含完整的H.264/H.265码流。这些packet可能是一帧分成多个NAL单元也可能是多个帧合并到一个packet里不能想当然地认为一个packet就等于一个视频帧。我以前在这里吃过亏。ZLMediaKit在推流时要求帧参数use_ps等和时间戳都要设置正确如果直接把MPP输出的packet逐个推给ZLMediaKit会造成花屏、卡顿。正确处理是把MPP输出的packet解析成帧边界通过探测00 00 00 01起始码和NAL类型重新组装成完整帧再推给ZLM。推流到ZLMediaKit我用的是RtspPusher或者直接用MediaSource::sendMediaFrame。这里推荐用ZLMediaKit自带的RtmpDispatcher或者直接调用MediaSource的接口因为已经解决了sps/pps的组装问题。一个比较完整的推流伪代码MediaSource::Ptr source MediaSource::find(RTSP_SCHEMA, live, test); if (source) { auto rtpSender source-getSdpTrack(0); // 构造Frame auto frame std::make_sharedH264Frame(); frame-assign(buffer, size); frame-dts pts; frame-pts pts; frame-setIndex(0); source-sendMediaFrame(frame); }这种方式在生产环境里可用但ZLMediaKit更推荐的方式是直接通过MediaSource::getTrack拿到Track对象然后调用Track::inputFrame把帧送进去。我再强调一遍sps/pps一定要在关键帧前面带好否则拉流端要等很久才能出画面。5.4 推流协议选择ZLMediaKit支持多种协议接收推流我们推流端可以直接推RTSP。实测RTSP推流延迟比RTMP低而且支持TCP/UDP两种传输模式。在局域网内我优先用RTSP TCP模式推流稳定性好。走公网的话建议考虑其他协议UDP在弱网环境下丢包比较严重。要注意ZLMediaKit的流ID命名规则。在代理拉流或直接推流时stream_id的命名要统一下游拉流时才能用rtsp://ip:554/live/stream_id这样的URL播放。6. 全流程联调与性能数据6.1 单路1080p全链路时延测试我把完整的链路跑起来之后做了几个关键指标的测试。测试方法是用毫秒级时间戳记录每一帧的到达时间、解码时间、推理时间、编码时间。数据如下RTSP拉流到MPP解码完成大约30到50毫秒取决于网络缓冲。MPP解码1080p帧耗时大约2到5毫秒。NV12转RGB 缩放耗时RGA大约1到2毫秒。YOLOv8s推理耗时NPU20到30毫秒。CPU后处理NMS耗时5到8毫秒。MPP编码耗时3到6毫秒。从原始流到推流完成的端到端延迟大约100到150毫秒。这个延迟水平对于实时监控、轻度交互是够用的。如果你做自动驾驶或者遥控操纵还需要进一步压缩到50毫秒左右那就要做零拷贝和流水线并行优化了。6.2 多路并行潜力RK3588的NPU和VPU都是支持多路并发访问的。我后来的测试做了两路1080p流同时进入一路做行人检测一路做车型识别NPU通过时间片轮转分别推理整体帧率分别能到15和18帧左右。如果你用YOLOv8n这种轻量模型三路同时跑也能基本满足每秒10帧以上的检测需求。VPU的编解码通道数我没有刻意压测官方宣称8路1080p解码没有太大压力。6.3 CPU负载与功耗整链路运行时我用top看了CPU负载A76核心中有一个跑到了30%左右主要在RGA调用和编码预处理其他核心占用都比较低。NPU占用可以通过cat /sys/kernel/debug/rknpu/load查看单路推理时负载大约50%到70%。整板功耗在接入摄像头、网络和HDMI输出之后大概5W到8W做边缘盒子完全没问题。7. 常见问题与排查实战7.1 解码黑屏/绿屏现象ZLMediaKit拉流正常但解码出来的帧在推流端显示黑屏或者绿屏。排查思路先单独对源流用mpi_dec_test测试确认裸流本身没问题。如果裸流解码正常问题可能出在帧组装上——ZLMediaKit回调出来的数据可能包含多个起始码组装时不能漏掉SPS/PPS。另外检查解码器配置的编码类型是否和源流一致。有一次我拿到的是H.265的流却初始化成H.264解码器画面当然出不来。加一个MPP_VIDEO_CodingHEVC的判断即可解决。7.2 推理结果完全错误现象推理能跑通但检测框位置完全不对或者置信度极低。原因基本是输入图像排列不对。我的教训是先把落地的RGB输入存成一帧图片在PC上用工具查看确认转换和缩放有没有问题。很多时候问题出在RGA转换时stride设置错误尺寸不对导致图像内容错位NPU推理出来自然乱七八糟。另外mean_values和std_values设置必须和训练时保持一致。YOLOv8官方训练使用的是归一化到0~1但我们在RKNN里设置的是mean0、std255也就是不做减均值只做缩放这和YOLOv8原始cfg一致输入除以255。如果你设置了其他mean值推理结果会偏移得很离谱。7.3 推流延迟越来越大现象运行一段时间后下游播放器看到的延迟从100毫秒逐渐涨到几秒。这是典型的缓冲管理问题。我开始时每次解码后都把NV12帧拷贝到新的内存里再推理和编码内存增长不说数据堆积导致延迟翻倍。解决方法是给处理流程加一个队列控制最大堆积帧数。如果处理不过来就主动丢弃旧帧而不是让用户端无限等待。我实现了一个容量为5的环形队列满了就丢最老的一帧保证消费端永远拿到的数据足够新鲜。7.4 长时间运行内存持续增长现象内存占用随时间线性上升最终被系统OOM杀掉。排查思路用valgrind或者gdb检查代码里的内存分配和释放。常见泄漏点在MPP的packet和frame没有释放。MppPacket创建之后每次循环都要mpp_packet_deinit解码获取的frame如果不再使用要mpp_frame_deinit。还有RGA转换时申请的buffer必须在使用完后free或者munmap。其实MPP接口本身带有buffer管理功能如果你创建的临时buffer不进buffer池靠手动管理很容易漏。建议给所有MPP相关的分配/释放封装成RAII类析构函数里统一清理这样能省掉大量排查时间。7.5 软硬编解码像素格式不匹配现象编码推流之后画面颜色偏绿、偏紫。原因基本都是颜色空间配置不对。NV12在MPP解码器和编码器之间传递要求格式标志统一为MPP_FMT_YUV420SP。如果你在编码前做了颜色空间转换比如转成了RGB然后直接丢给编码器编码器会按YUV来编码颜色完全错乱。还需要确保编码器的hor_stride和解码器输出的hor_stride匹配。如果解码输出的hor_stride是19201080对齐到64编码器配置的也是1920但实际数据有效宽度是1920像素那没问题。如果解码输出是1920、编码器配置成1080数据就会错位。这个地方用调试打印把两边的stride值打出来对比一下是最快的排查手段。8. 优化方向与个人经验总结8.1 pipeline并行化串行处理“拉流→解码→推理→编码→推流”的延迟很大。我完成的第二个版本把整个流程拆成了四个线程拉流线程、解码线程、推理线程、编码推流线程。解码和推理之间通过双缓冲传递帧数据这样解码器在等待NPU推理时可以继续解码下一帧。帧率从刚开始的12帧左右提升到了20帧以上延迟也下降了不少。线程间同步用条件变量和互斥锁就够了不要上无锁队列——你无法预估GPU/NPU在极端情况下的调度延迟阻塞操作反而能让系统更有节奏地跑。8.2 零拷贝方向如果想要把延迟压榨到极致下一步就是做零拷贝。RK3588的NPU支持从DRM buffer直接读取输入也就是说MPP解码出来的buffer理论上可以直接作为NPU推理的输入不需要经过RGA或者CPU拷贝。官方文档里提到通过rknn_create_mem创建和MPP共享的buffer来实现。但我目前还没把这条路完全走通原因是NPU对输入内存的对齐要求比较高而MPP默认分配的内存可能不满足。如果你想做建议从驱动层面构造专门的buffer池让MPP和NPU共用同一个内存分配器。我后续如果有了稳定的实现会再写一篇专门分享。8.3 模型更新迭代工程化之后换模型是家常便饭。我的做法是模型文件放在一个固定目录启动时加载同时提供信号量通知程序热加载新模型。这样在设备运行中我只需要把新的.rknn模型文件传到板子上触发一个SIGUSR1信号程序就会重新初始化NPU并切换模型。每次模型更新后记得在板子上跑一遍自测图片集确认精度没有明显下降。NPU算子版本升级也可能导致模型行为变化做好回归测试再交付给客户。8.4 实际部署的坑和忠告这一套东西跑下来最明显的感触是硬件平台的能力上限很高但软件链路的细节决定最终效果。RK3588的NPU和VPU都很强悍但如果代码里某个buffer没释放、某个stride设置错了、某个协议参数不匹配整个系统就给你上演“间歇性故障”。调试这种事没有捷径日志指标监控分模块测试是最稳妥的做法。给新手一个建议不要一上来就搞全链路。先单独跑通ZLMediaKit的拉流和推流用VLC验证视频正常再单独跑通MPP对一段H264裸流的解码把YUV帧落盘成图片检查再单独跑通YOLO对单张图片的检测最后再串联起来。每一步都能确认结果最后联调时问题范围会小很多。还有一个实际教训不要把ZLMediaKit和你的业务代码编译在同一个进程里除非你真的非常熟悉它的线程模型。ZLMediaKit内部是多线程事件驱动架构如果你在它的回调里做耗时操作比如NPU推理会拖垮整个服务模块。我踩过这个坑之后就把业务逻辑独立成了进程ZLMediaKit只负责流协议我自己的程序通过RTSP从它拉流、处理、再推流回去边界清晰出问题也好定位。最后说一句关于这个项目后续的扩展。我现在正考虑把音频也接进来用ALSA采集板载声卡或者USB声卡的数据AAC编码后和视频合成一个标准TS流或者flv流推给ZLMediaKit。这样下游消费端可以完整地观看带声音的监控画面。另外就是多路视频的智能调度这个打算等RK3588s这类成本更敏感的芯片上做验证因为RK3588的成本对很多场景来说还是偏高。写到这里整个“RK3588上用ZLMediaKit实现拉流、MPP解码、YOLO推理、MPP编码和推流”的流程就完整铺开了。代码结构上面已经给了骨架细节逻辑每个环境会有差异但排查思路和优化方向是通用的。希望这些经验能帮你少走几步弯路有具体问题的话欢迎在评论区讨论。