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

VSCode 中精准禁用 Copilot 代码补全:按语言与场景灵活配置

1. 为什么需要精准控制 Copilot 代码补全 作为一个用了 VSCode 和 Copilot 好几年的开发者,我深刻体会到 AI 代码补全的双刃剑效应。刚开始用 Copilot 的时候,那种"它怎么知道我要写什么"的惊喜感真的很棒,但后来我发现,在某些场景下,这种自动补全反而会成为负担。 比如我在刷算法题的时候,刚写了个函数名,Copilot 就直接把整个实现都给我补全了。这还训练什么?完全达不到练习的目的。还有时候在写一些特定语言的代码,Copilot 的补全风格和团队规范不一致,每次都要手动调整,反而增加了工作量。 更让我头疼的是在不同项目间切换的时候。有些项目我希望充分利用 Copilot 提高效率,有些项目则需要完全自己动手写代码。如果每次都去全局开关 Copilot,那也太麻烦了。 其实 Copilot 的设计团队早就想到了这些场景,他们在 VSCode 中提供了非常精细的控制方式。不只是简单的开和关,你可以按编程语言禁用,

NASA火星代码测试内幕:用AIGC模拟外星环境攻击

NASA火星代码测试内幕:用AIGC模拟外星环境攻击

火星任务软件测试的迫切需求 NASA的火星探测任务(如“毅力号”和未来载人计划)依赖于复杂的软件系统,这些系统必须抵御未知的外星环境威胁,包括辐射干扰、沙尘暴、黑客攻击等。传统测试方法难以模拟这些极端场景,因此NASA创新性地引入AIGC(人工智能生成内容)技术,生成动态、高保真的攻击模拟环境。本文从软件测试专业视角,揭秘这一内幕,分析其技术框架、测试流程和行业启示,助力测试从业者提升风险应对能力。 一、背景:火星软件测试的独特挑战 火星任务软件(如导航、通信和生命支持系统)面临三重挑战: 1. 环境不确定性:火星表面辐射强度是地球的100倍,沙尘暴可导致传感器失效(数据来源:NASA JPL报告,2025)。 2. 安全威胁:外星黑客攻击可能通过深空网络渗透,例如2024年模拟测试中发现的零日漏洞。 3. 测试局限性:地面实验室无法完全复制火星条件,传统脚本测试覆盖率不足。 AIGC的引入解决了这些痛点: * 定义:AIGC利用生成式AI(如GPT-4和GANs)自动创建攻击场景,包括恶意代码注入、

找回 Edge 边栏中消失的 Copilot 图标

Edge 边栏的 Copilot 能根据网页内容增强回复,相当于内置了RAG,而且能不限次数使用GPT-5,非常方便。笔者有次打开 Edge 浏览器时发现边栏的Copilot图标消失了,探索了一些方法后终于找到解决方案,以下: 1. win+R 打开运行,输入 powershell 打开,复制以下正则表达式全文到powershell 命令窗口回车运行即可。命令窗口出现“✅ 已将 variations_country 设置为 US。已重新启动 Microsoft Edge”代表已经成功。 & { # 关闭所有 Edge 进程 Get-Process | Where-Object { $_.ProcessName -like "msedge*" } | Stop-Process -Force -ErrorAction SilentlyContinue Start-Sleep -Seconds 3 $localState

GLM-4.7-Flash实战教程:基于GLM-4.7-Flash构建本地Copilot工具

GLM-4.7-Flash实战教程:基于GLM-4.7-Flash构建本地Copilot工具 1. 为什么需要本地Copilot工具 在日常编程和工作中,我们经常需要代码建议、文档生成、问题解答等AI辅助功能。虽然云端AI服务很方便,但存在网络延迟、隐私安全、使用成本等问题。基于GLM-4.7-Flash构建本地Copilot工具,可以让你: * 完全离线运行:不依赖网络,响应速度极快 * 数据隐私安全:所有对话和代码都在本地处理 * 定制化能力强:可以根据自己的需求调整模型行为 * 成本可控:一次部署,长期使用,无按次付费 GLM-4.7-Flash作为最新的开源大模型,在代码理解和生成方面表现出色,特别适合作为本地编程助手。 2. 环境准备与快速部署 2.1 硬件要求 为了流畅运行GLM-4.7-Flash,建议准备以下硬件环境: * GPU:4张RTX 4090 D显卡(或同等算力) * 内存:至少128GB系统内存 * 存储:至少100GB可用空间(模型文件约59GB)