rk3588 MIPI采集 + OpenCV处理 + 硬件编码推流 + WebRTC低延迟播放 + 客户端保存视频

本人是第一次做摄像头推流相关的工作,一开始只是想简单做一个小工具。但是经过我几天的研究,发现网上的教程要么极其复杂,要么漏洞百出,导致我连最简单的推流都迟迟没做出来。

经过几天的极限折腾,我终于打通了 MIPI摄像头 -> 硬件ISP -> OpenCV(AI处理) -> 硬件H.264编码 -> 局域网WebRTC超低延迟推流与客户端录制 -> 客户端保存视频 的完整链路。今天把整套方案和踩过的深坑全盘托出,希望能帮大家少走弯路。

整体架构思路

主要功能使用python实现:

  1. 画面采集:使用 GStreamer 直接对接底层驱动,利用 RK3588 的硬件 ISP 把 MIPI RAW 数据转成彩色的缩小画面。
  2. opencv处理:OpenCV 拿到图片后,可以进行你想要的图像处理。
  3. 硬件编码推流:将处理后的画面交给 mpph264enc(瑞芯微硬件编码器)压缩,推给本机的流媒体服务器。
  4. 终端分发:使用极其轻量的 MediaMTX 作为流媒体服务器,客户端通过 WebRTC 协议实现网页端秒开与超低延迟观看。

第一步:环境准备

  1. 确认你的摄像头节点(比如单摄时是 /dev/video11)。

确保安装了带 GStreamer 支持的 OpenCV 和相关插件(注意pypi上的opencv默认不支持gstreamer,建议直接下载系统环境的opencv,或者手动编译):

sudoapt-get update sudoapt-getinstall python3-opencv sudoapt-getinstall gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-rtsp 

第二步:部署轻量级流媒体服务器 (MediaMTX)

注意:此服务器不是我们通常理解的网站服务器,我使用的设备只有板子和我的电脑。
建议在板子上跑服务器,这样客户端不需做任何配置

在 RK3588 上下载 ARM64 版本并运行:

wget https://github.com/bluenviron/mediamtx/releases/download/v1.16.1/mediamtx_v1.16.1_linux_arm64.tar.gz tar -zxvf mediamtx_v1.16.1_linux_arm64.tar.gz ./mediamtx 

你应该能看到以下输出

cat@lubancat:~/Downloads$ ./mediamtx 2026/02/21 15:07:07 INF MediaMTX v1.16.1, linux, arm64 2026/02/21 15:07:07 INF configuration loaded from /home/cat/Downloads/mediamtx.yml 2026/02/21 15:07:07 INF [RTSP] listener opened on :8554 (TCP/RTSP), :8000 (UDP/RTP), :8001 (UDP/RTCP) 2026/02/21 15:07:07 INF [RTMP] listener opened on :1935 2026/02/21 15:07:07 INF [HLS] listener opened on :8888 2026/02/21 15:07:07 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP) 2026/02/21 15:07:07 INF [SRT] listener opened on :8890 (UDP) 

(保持此终端不关,另外打开新的终端)

第三步:核心 Python 脚本(rtsp推流与处理)

新建一个 Python 脚本 stream.py。这段代码包含了降分辨率防缓存延迟调用 MPP 硬件编码的核心参数。

import cv2 import time classFPSCounter:"""FPS counter class"""def__init__(self, buffer_size=20): self.timestamps =[] self.buffer_size = buffer_size defupdate(self):"""Update FPS count""" current_time = time.time() self.timestamps.append(current_time)# Keep only recent timestampsiflen(self.timestamps)> self.buffer_size: self.timestamps.pop(0)defget_fps(self):"""Calculate current FPS"""iflen(self.timestamps)<2:return0.0 time_span = self.timestamps[-1]- self.timestamps[0]if time_span <=0:return0.0return(len(self.timestamps)-1)/ time_span # 1. 配置读取摄像头的 GStreamer Pipeline (根据你的MIPI摄像头节点调整,这里假设是 /dev/video11)# 强制设定分辨率和帧率,并转换为BGR格式给OpenCV处理 cap_pipeline =("v4l2src device=/dev/video11 io-mode=2 ! ""video/x-raw, width=640, height=480, framerate=30/1, format=NV12 ! "# 可以选择你想要的图像大小"videoconvert ! video/x-raw, format=BGR ! ""appsink"# 可选:max-buffers=1 drop=true -> 强制丢弃旧画面,永远只读最新帧!)# 2. 配置推流的 GStreamer Pipeline# appsrc接收OpenCV的BGR图像,转为NV12,交给mpph264enc硬编,然后推流给MediaMTX push_pipeline =("appsrc is-live=true ! ""video/x-raw, format=BGR, width=640, height=480, framerate=30/1 ! ""videoconvert ! video/x-raw, format=NV12 ! ""mpph264enc bps=4000000 rc-mode=vbr ! ""h264parse ! ""rtspclientsink location=rtsp://127.0.0.1:8554/live protocols=tcp"# 可选:sync=false -> 不用帧同步)# 初始化视频读取 cap = cv2.VideoCapture(cap_pipeline, cv2.CAP_GSTREAMER)ifnot cap.isOpened():print("错误:无法打开 MIPI 摄像头。请检查节点和 ISP 状态。") exit()# 初始化视频推流器 out = cv2.VideoWriter(push_pipeline, cv2.CAP_GSTREAMER,0,30,(640,480))ifnot out.isOpened():print("错误:无法初始化 GStreamer 推流器。") exit()print("成功启动采集和推流,按 'Ctrl+C' 停止。")try: fps_counter = FPSCounter()whileTrue: ret, frame = cap.read()ifnot ret:print("未能读取到画面")break# ==========================================# ★ 在这里加入你的 AI 推理代码 ★# ==========================================# 例如:# results = rknn_model.inference(frame)# frame = draw_bounding_boxes(frame, results) fps_counter.update() fps = fps_counter.get_fps()# 作为演示,我们在这里加上时间戳和fps cv2.putText(frame,f"Time: {time.ctime()}",(30,50), cv2.FONT_HERSHEY_SIMPLEX,1,(0,0,255),1) cv2.putText(frame,f"Fps: {fps}",(30,100), cv2.FONT_HERSHEY_SIMPLEX,1,(0,0,255),1)# ==========================================# 将画好框的处理后图像,写入推流管道(由mpp硬件编码) out.write(frame)except KeyboardInterrupt:print("停止推流...")finally: cap.release() out.release()

运行脚本:python3 stream.py

第四步:如何在客户端观看与保存?

此时,你的 RK3588 已经变成了一个的 IP 摄像头。假设你的板子局域网 IP 是 192.168.0.137

** 1. 低延迟观看(网页直开)**
直接在电脑/手机浏览器里输入:👉 http://192.168.0.137:8889/live (这里的端口号在之前MediaMTX的输出中能看到)
利用 WebRTC 协议,延迟基本在百毫秒以内。

在这里插入图片描述

** 2. 在客户端无损录像(不需板端CPU占用)**
想要在电脑上把刚才的监控视频存下来?只需要一行命令,直接将底层编好的 H.264 流封装成文件,完全不消耗客户端算力:
在电脑上安装ffmpeg(windows / linux / mac均可),运行:

ffmpeg -rtsp_transport tcp -i rtsp://192.168.0.137:8554/live -c copy -f mp4 record_video.mp4 # 注意这里的端口号选的是8554(rtsp)

cpu占用与延迟

以下是纯推流,基本没有图像处理的资源消耗。

cpu占用(htop)


延迟的话,体感上在1秒以内,没准确测过。
所以实际上还有很大的优化空间

避坑指南

分享几个过程中最容易卡住的问题:

  1. 使用gstreamer无法打开摄像头
    • 原因:RK3588 的 V4L2 驱动在处理 MIPI 摄像头和 ISP 内存时,默认的 mmap 内存映射方式有时候在 GStreamer 中会引发异常(特别是在申请 buffer 时)
    • 解法:给 v4l2src 加上 io-mode=4(使用 DMABUF)或 io-mode=2(USERPTR)往往能瞬间解决问题。
  2. MediaMTX报错 invalid rtmp version (71)
    • 原因:进错端口了!用 HTTP 浏览器去访问了 1935 (RTMP) 或 8554 (RTSP) 端口。
    • 解法:浏览器观看必须要访问 8889 端口。
  3. 推流成功了,但是画面全是“纯绿色”的
    • 原因:OpenCV 推入的画面分辨率和推流器配置的分辨率不匹配,导致内存错位;或者忘记启动 rkaiq ISP 服务导致画面全是空数据。
    • 解法:严格检查 cap_pipelinecv2.VideoWriterpush_pipeline 三个地方的分辨率参数是否完全一致。
  4. 延迟越来越大,跑久了像看回放
    • 原因:加入 AI 推理后处理速度跟不上采集速度,OpenCV 把旧画面全缓存在了内存里。
    • 解法:务必在读取管道末尾加上 appsink max-buffers=1 drop=true

小贴士

我们直接传图像到pc端之所以会卡,只是因为图像没有经过压缩,网络传输速度不够。如果只是单纯想流畅的观看调试图像,可以直接用opencv自带的编码函数:

# 编码为 JPEG 格式 success, encoded_img = cv2.imencode(".jpg", img) 

然后再通过flask之类的框架进行网络传输,好处是简单直接方便,只是性能不高。

Read more

【面试分享】前端 React 50个基础高频面试题,助你轻松拿 offer!

【面试分享】前端 React 50个基础高频面试题,助你轻松拿 offer!

目录 前端基础高频面试题之-- React 篇 1、什么是React? 2、React有什么特点? 3、列出React的一些主要优点。 4、React有哪些限制? 5、什么是JSX? 6、为什么浏览器无法读取JSX? 7、React中的组件是什么? 8、怎样解释 React 中 render() 的目的。 9、什么是 Props? 10、React中的状态是什么?它是如何使用的? 11、 React 中的箭头函数是什么?使用箭头函数的好处? 12、什么是高阶组件(HOC)? 13、你能用HOC做什么? 14、什么是纯组件? 16、什么是React 路由? 17、为什么 useState 返回的是数组而不是对象? 18、如何实现

Spring Web MVC从入门到实战

Spring Web MVC从入门到实战

—JavaEE专栏— 1. Spring Web MVC核心概念 1.1 什么是Spring Web MVC Spring Web MVC是基于Servlet API构建的原始Web框架,从一开始就包含在Spring框架中,其正式名称来源于源模块名称(spring-webmvc),通常简称为Spring MVC。 官方定义:Spring Web MVC is the original web framework built on the Servlet API and has been included in the Spring Framework from the very beginning. Servlet是Java Web开发的规范,定义了动态页面开发的技术标准,而Tomcat、Weblogic等Servlet容器则是该规范的具体实现,

Passkey攻击技术:绕过FIDO2/WebAuthn实现的逻辑漏洞

前言 1. 技术背景:在现代网络攻防体系中,身份窃取是绝大多数攻击的起点。从APT攻击到大规模数据泄露,获取合法凭证始终是攻击者的核心目标之一。传统密码因其易被钓鱼、撞库和暴力破解的固有缺陷,已成为安全体系中最薄弱的一环。Passkey,作为基于FIDO2/WebAuthn标准的下一代身份验证技术,通过公钥密码学从根本上解决了密码被盗用的问题,被誉为“抗钓鱼的终极解决方案”。 它在攻防对抗中,将防御重心从“保护一个可被窃取的秘密(密码)”转移到了“验证一个不可被窃取的证明(私钥签名)”。 2. 学习价值:掌握Passkey的攻击技术,并非为了作恶,而是为了更深刻地理解“安全是一个整体,而非单个技术的堆砌”。学会本文内容,您将能够: * 识别并验证Web应用在Passkey实现中常见的逻辑漏洞。 * 在安全评估和渗透测试中,模拟针对Passkey的真实攻击场景,评估系统风险。 * 作为开发者或架构师,构建出真正具备韧性的Passkey认证系统,避免纸面上的安全。 3. 使用场景:本技术适用于以下实际场景: * 授权渗透测试:对实现了Passkey登

OpenClaw 中 web_search + web_fetch 最佳实践速查表

OpenClaw 中 web_search + web_fetch 最佳实践速查表

OpenClaw 中 web_search + web_fetch 最佳实践速查表 摘要:本文帮助读者明确 OpenClaw 网络搜索工具和不同搜索技能的的职责边界,理解“先搜索、再抓取、后总结”的最佳实践,并能更稳定地在 OpenClaw 中使用 tavily-search 与 web_fetch 完成网络信息搜索任务。主要内容包括:解决 OpenClaw 中 web_search、tavily-search、web_fetch、原生 provider 与扩展 skill 容易混淆的问题、网络搜索能力分层说明、OpenClaw 原生搜索 provider 与 Tavily/Firecrawl 扩展 skill 的区别、标准工作流、提示词模板、