一、项目背景最近在做一个基于RK3588OrangePi 5 Ultra的多路视频采集与录制项目。系统需要同时接入三路 USB UVC 相机video3第一路核心相机video5第二路核心相机video1第三路辅助相机项目要求两路核心相机必须稳定 30FPS同时录制 MP4 文件后续还需要进行实时推流和 AI 推理CPU 占用尽量低整体数据流如下USB Camera │ ▼ MJPEG 30FPS │ ▼ Hardware DecodeMPP │ ▼ RGA 色彩转换 │ ▼ MPP H264/H265 Encoder │ ▼ MP4 Recorder最终目标不是 ffprobe 显示 30fps而是真实采集、真实编码都稳定达到 30FPS。二、硬件环境开发板OrangePi 5 Ultra RK3588 Ubuntu 22.04 Kernel 5.10相机USB UVC Camera 960×720 MJPEG 30FPS编码Rockchip MPP mppjpegdec mpph264enc mpph265enc色彩转换librga三、首先确认相机本身是否支持30FPS第一步一定不要急着写程序。先确认相机到底支持什么格式。查看v4l2-ctl-d/dev/video5 --list-formats-ext得到MJPG 960x720 30fps 1280x720 30fps YUYV 960x720 10fps这里得到两个重要结论MJPEG 可以 30FPSYUYV 最大只有 10FPS因此后续所有录制方案都必须基于 MJPEG。四、第一步排查——到底是不是采集问题很多人第一反应就是GStreamer 怎么只有 28FPS实际上第一步应该先验证V4L2 驱动采集能力。测试v4l2-ctl\-d/dev/video5\--stream-mmap\--stream-count600\--stream-to/dev/null结果30.07 fps 30.08 fps 30.06 fps说明相机本身没问题。USB 没问题。V4L2 驱动也没问题。真正的问题发生在后面的处理链路。五、第二步排查——GStreamer 是否已经开始掉帧继续验证gst-launch-1.0-v\v4l2srcdevice/dev/video5 io-mode2\!image/jpeg,width960,height720,framerate30/1\!queue\!fpsdisplaysink\video-sinkfakesink\syncfalse\text-overlayfalse观察current30.08 ↓ 28.20 ↓ 26.30 ↓ 30.07平均28.xx FPS这里说明采集虽然平均还能接近30FPS但是整个 GStreamer Pipeline 已经开始发生抖动。虽然没有真正丢帧但 Pipeline 已经出现 Scheduling 抖动。六、第三步——验证最简单的录制先不要编码。直接保存 MJPEG。Pipelinev4l2src ↓ jpegparse ↓ avimux ↓ AVI命令gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!avimux\!filesinklocationtest.avi优点不解码不编码CPU 非常低基本可以保持 30FPS缺点文件巨大三分钟接近1GB显然不能用于实际项目。七、第四步——尝试硬件 H264/H265 编码开始尝试MJPEG ↓ mppjpegdec ↓ videoconvert ↓ NV12 ↓ mpph264enc测试命令gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!mppjpegdec\!videoconvert\!video/x-raw,formatNV12\!mpph264enc\!h264parse\!mp4mux\!filesinklocationtest.mp4最终得到画面正常MP4正常但是三路录制开始掉帧CPU 使用率明显升高。八、定位真正瓶颈——videoconvert为了确认到底是谁慢分别测试① 只有mppjpegdec和②mppjpegdec ↓ videoconvert统计结果不使用 videoconvertreal ≈64suser ≈8s使用 videoconvertreal ≈70suser ≈207sCPU 时间暴涨。说明真正瓶颈不是MPP Encoder而是videoconvert软件颜色转换。九、为什么会出现 NV16很多人会疑惑为什么 mppjpegdec 出来的不是 NV12查看 capsvideo/x-raw formatNV16原因MJPEG 本质来自YUV422Rockchip 的 mppjpegdec 会直接输出NV16。而编码器需要NV12。因此以前其实一直都是NV16 → videoconvert → NV12CPU 就耗在这里。十、尝试直接送编码器于是尝试NV16 → mpph265enc结果FPS 非常漂亮。但是颜色错误尺寸错误例如输入 960×720输出 1280×720颜色也偏绿。说明不能直接使用。十一、最终解决方案——RGA 硬件转换于是改成MJPEG ↓ mppjpegdec ↓ NV16 ↓ RGA ↓ NV12 ↓ mpph265enc转换代码imcvtcolor(src,dst,RK_FORMAT_YCbCr_422_SP,RK_FORMAT_YCbCr_420_SP);整个转换完全走RGA HardwareCPU 基本不参与。十二、60秒严格30FPS测试测试程序./rga_appsrc_h265_test\60\960\720\50\2\videos\1200000\/dev/video1\/dev/video3\/dev/video5统计结果video31800 Frames30.08FPS→ PASSvideo51800 Frames30.08FPS→ PASSvideo11705 Frames28.6FPS项目要求只有 video3 和 video5 这两路核心相机必须严格 30FPS第三路辅助相机允许略低帧率因此最终方案满足需求。十三、常用测试命令汇总1查看相机支持格式v4l2-ctl-d/dev/video5 --list-formats-ext2查看当前参数v4l2-ctl-d/dev/video5--all3测试底层采集 FPSv4l2-ctl\-d/dev/video5\--set-parm30\--stream-mmap\--stream-count600\--stream-to/dev/null4测试 GStreamer Pipeline FPSgst-launch-1.0-v\v4l2srcdevice/dev/video5 io-mode2\!image/jpeg,width960,height720,framerate30/1\!queue max-size-buffers60\!fpsdisplaysink\video-sinkfakesink\syncfalse\text-overlayfalse5MJPEG 原始 AVI 录制gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!avimux\!filesinklocationtest.avi6MPP H264 编码录制gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!mppjpegdec\!videoconvert\!video/x-raw,formatNV12\!mpph264enc\!h264parse\!mp4mux\!filesinklocationtest.mp47RGA MPP H265 测试程序./rga_appsrc_h265_test\60\960\720\50\2\videos\1200000\/dev/video1\/dev/video3\/dev/video58检查录制结果ffprobe\-hide_banner\-select_streamsv:0\-show_entries\streamcodec_name,width,height,avg_frame_rate,r_frame_rate,nb_frames,duration,bit_rate\video3_rga_nv12_h265_strict.mp4期望输出width960 height720 avg_frame_rate30/1 nb_frames1800十四、最终架构最终采用如下录制架构USB Camera │ ▼ MJPEG (30FPS) │ ▼ mppjpegdec │ ▼ NV16 │ ▼ RGANV16 → NV12 │ ▼ mpph264enc / mpph265enc │ ▼ MP4 Recorder │ ▼ Frame Monitor统计帧率、掉帧、同步状态其中Frame Monitor持续统计以下指标实际采集帧数Capture Frames编码输出帧数Encoded Frames平均 FPSAverage FPS最大帧间隔Max Frame Interval超过 40 ms / 50 ms 的帧数核心两路相机是否达到expected_frames seconds × 30这些统计信息能够快速判断问题究竟发生在采集、颜色转换还是编码阶段对于后续定位性能瓶颈非常有帮助。十五、总结经过多轮测试与逐步排查最终得到以下结论USB UVC 相机本身可以稳定输出 30FPSV4L2 驱动不是瓶颈。MPPRockchip 硬件编解码性能充足三路实时编码并非主要限制因素。软件videoconvert是三路实时录制最大的性能瓶颈CPU 开销明显。mppjpegdec原生输出为 NV16直接送入编码器虽然帧率高但会导致颜色和分辨率异常。使用 RGA 完成 NV16→NV12 的硬件色彩转换后可以兼顾正确画面和低 CPU 占用。在当前方案下两路核心相机video3、video5已经连续 60 秒实现严格 1800 帧30FPS满足项目需求。下一步计划验证 RGA 输出的视频颜色和分辨率在长时间运行下保持正确。完成 5 分钟、10 分钟压力测试观察是否存在累计掉帧。在实际业务曝光、补光条件下再次验证帧率稳定性。将这套MPP RGA的录制链路完整迁移到正式项目实现三路采集、实时录制、推流与 AI 推理协同运行。希望这篇实践记录能为使用RK3588、OrangePi 5 Ultra、GStreamer、MPP、RGA实现多路 USB UVC 相机稳定录制的开发者提供一些参考。欢迎交流更多关于多路采集、硬件编解码和嵌入式视觉系统优化的经验。
一、项目背景最近在做一个基于RK3588OrangePi 5 Ultra的多路视频采集与录制项目。系统需要同时接入三路 USB UVC 相机video3第一路核心相机video5第二路核心相机video1第三路辅助相机项目要求两路核心相机必须稳定 30FPS同时录制 MP4 文件后续还需要进行实时推流和 AI 推理CPU 占用尽量低整体数据流如下USB Camera │ ▼ MJPEG 30FPS │ ▼ Hardware DecodeMPP │ ▼ RGA 色彩转换 │ ▼ MPP H264/H265 Encoder │ ▼ MP4 Recorder最终目标不是 ffprobe 显示 30fps而是真实采集、真实编码都稳定达到 30FPS。二、硬件环境开发板OrangePi 5 Ultra RK3588 Ubuntu 22.04 Kernel 5.10相机USB UVC Camera 960×720 MJPEG 30FPS编码Rockchip MPP mppjpegdec mpph264enc mpph265enc色彩转换librga三、首先确认相机本身是否支持30FPS第一步一定不要急着写程序。先确认相机到底支持什么格式。查看v4l2-ctl-d/dev/video5 --list-formats-ext得到MJPG 960x720 30fps 1280x720 30fps YUYV 960x720 10fps这里得到两个重要结论MJPEG 可以 30FPSYUYV 最大只有 10FPS因此后续所有录制方案都必须基于 MJPEG。四、第一步排查——到底是不是采集问题很多人第一反应就是GStreamer 怎么只有 28FPS实际上第一步应该先验证V4L2 驱动采集能力。测试v4l2-ctl\-d/dev/video5\--stream-mmap\--stream-count600\--stream-to/dev/null结果30.07 fps 30.08 fps 30.06 fps说明相机本身没问题。USB 没问题。V4L2 驱动也没问题。真正的问题发生在后面的处理链路。五、第二步排查——GStreamer 是否已经开始掉帧继续验证gst-launch-1.0-v\v4l2srcdevice/dev/video5 io-mode2\!image/jpeg,width960,height720,framerate30/1\!queue\!fpsdisplaysink\video-sinkfakesink\syncfalse\text-overlayfalse观察current30.08 ↓ 28.20 ↓ 26.30 ↓ 30.07平均28.xx FPS这里说明采集虽然平均还能接近30FPS但是整个 GStreamer Pipeline 已经开始发生抖动。虽然没有真正丢帧但 Pipeline 已经出现 Scheduling 抖动。六、第三步——验证最简单的录制先不要编码。直接保存 MJPEG。Pipelinev4l2src ↓ jpegparse ↓ avimux ↓ AVI命令gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!avimux\!filesinklocationtest.avi优点不解码不编码CPU 非常低基本可以保持 30FPS缺点文件巨大三分钟接近1GB显然不能用于实际项目。七、第四步——尝试硬件 H264/H265 编码开始尝试MJPEG ↓ mppjpegdec ↓ videoconvert ↓ NV12 ↓ mpph264enc测试命令gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!mppjpegdec\!videoconvert\!video/x-raw,formatNV12\!mpph264enc\!h264parse\!mp4mux\!filesinklocationtest.mp4最终得到画面正常MP4正常但是三路录制开始掉帧CPU 使用率明显升高。八、定位真正瓶颈——videoconvert为了确认到底是谁慢分别测试① 只有mppjpegdec和②mppjpegdec ↓ videoconvert统计结果不使用 videoconvertreal ≈64suser ≈8s使用 videoconvertreal ≈70suser ≈207sCPU 时间暴涨。说明真正瓶颈不是MPP Encoder而是videoconvert软件颜色转换。九、为什么会出现 NV16很多人会疑惑为什么 mppjpegdec 出来的不是 NV12查看 capsvideo/x-raw formatNV16原因MJPEG 本质来自YUV422Rockchip 的 mppjpegdec 会直接输出NV16。而编码器需要NV12。因此以前其实一直都是NV16 → videoconvert → NV12CPU 就耗在这里。十、尝试直接送编码器于是尝试NV16 → mpph265enc结果FPS 非常漂亮。但是颜色错误尺寸错误例如输入 960×720输出 1280×720颜色也偏绿。说明不能直接使用。十一、最终解决方案——RGA 硬件转换于是改成MJPEG ↓ mppjpegdec ↓ NV16 ↓ RGA ↓ NV12 ↓ mpph265enc转换代码imcvtcolor(src,dst,RK_FORMAT_YCbCr_422_SP,RK_FORMAT_YCbCr_420_SP);整个转换完全走RGA HardwareCPU 基本不参与。十二、60秒严格30FPS测试测试程序./rga_appsrc_h265_test\60\960\720\50\2\videos\1200000\/dev/video1\/dev/video3\/dev/video5统计结果video31800 Frames30.08FPS→ PASSvideo51800 Frames30.08FPS→ PASSvideo11705 Frames28.6FPS项目要求只有 video3 和 video5 这两路核心相机必须严格 30FPS第三路辅助相机允许略低帧率因此最终方案满足需求。十三、常用测试命令汇总1查看相机支持格式v4l2-ctl-d/dev/video5 --list-formats-ext2查看当前参数v4l2-ctl-d/dev/video5--all3测试底层采集 FPSv4l2-ctl\-d/dev/video5\--set-parm30\--stream-mmap\--stream-count600\--stream-to/dev/null4测试 GStreamer Pipeline FPSgst-launch-1.0-v\v4l2srcdevice/dev/video5 io-mode2\!image/jpeg,width960,height720,framerate30/1\!queue max-size-buffers60\!fpsdisplaysink\video-sinkfakesink\syncfalse\text-overlayfalse5MJPEG 原始 AVI 录制gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!avimux\!filesinklocationtest.avi6MPP H264 编码录制gst-launch-1.0-e\v4l2srcdevice/dev/video5\!image/jpeg,width960,height720,framerate30/1\!jpegparse\!mppjpegdec\!videoconvert\!video/x-raw,formatNV12\!mpph264enc\!h264parse\!mp4mux\!filesinklocationtest.mp47RGA MPP H265 测试程序./rga_appsrc_h265_test\60\960\720\50\2\videos\1200000\/dev/video1\/dev/video3\/dev/video58检查录制结果ffprobe\-hide_banner\-select_streamsv:0\-show_entries\streamcodec_name,width,height,avg_frame_rate,r_frame_rate,nb_frames,duration,bit_rate\video3_rga_nv12_h265_strict.mp4期望输出width960 height720 avg_frame_rate30/1 nb_frames1800十四、最终架构最终采用如下录制架构USB Camera │ ▼ MJPEG (30FPS) │ ▼ mppjpegdec │ ▼ NV16 │ ▼ RGANV16 → NV12 │ ▼ mpph264enc / mpph265enc │ ▼ MP4 Recorder │ ▼ Frame Monitor统计帧率、掉帧、同步状态其中Frame Monitor持续统计以下指标实际采集帧数Capture Frames编码输出帧数Encoded Frames平均 FPSAverage FPS最大帧间隔Max Frame Interval超过 40 ms / 50 ms 的帧数核心两路相机是否达到expected_frames seconds × 30这些统计信息能够快速判断问题究竟发生在采集、颜色转换还是编码阶段对于后续定位性能瓶颈非常有帮助。十五、总结经过多轮测试与逐步排查最终得到以下结论USB UVC 相机本身可以稳定输出 30FPSV4L2 驱动不是瓶颈。MPPRockchip 硬件编解码性能充足三路实时编码并非主要限制因素。软件videoconvert是三路实时录制最大的性能瓶颈CPU 开销明显。mppjpegdec原生输出为 NV16直接送入编码器虽然帧率高但会导致颜色和分辨率异常。使用 RGA 完成 NV16→NV12 的硬件色彩转换后可以兼顾正确画面和低 CPU 占用。在当前方案下两路核心相机video3、video5已经连续 60 秒实现严格 1800 帧30FPS满足项目需求。下一步计划验证 RGA 输出的视频颜色和分辨率在长时间运行下保持正确。完成 5 分钟、10 分钟压力测试观察是否存在累计掉帧。在实际业务曝光、补光条件下再次验证帧率稳定性。将这套MPP RGA的录制链路完整迁移到正式项目实现三路采集、实时录制、推流与 AI 推理协同运行。希望这篇实践记录能为使用RK3588、OrangePi 5 Ultra、GStreamer、MPP、RGA实现多路 USB UVC 相机稳定录制的开发者提供一些参考。欢迎交流更多关于多路采集、硬件编解码和嵌入式视觉系统优化的经验。
