STM32MP25 视频编解码实战系列
·
一套基于真实嵌入式项目的踩坑复盘。平台是 STM32MP25(双核 Cortex-A35)+
IMX335 摄像头 + Verisilicon(Hantro)VPU,目标形态:摄像头采集 → 硬件 H264
编码 → 共享内存广播 → WebRTC 双向对讲,同时跑一路人脸识别。
技术栈:Linux 6.6 + V4L2 mem2mem + GStreamer + libcamera + Amazon KVS WebRTC SDK。项目从 2026 年 5 月做到 8 月,这个系列按演进顺序复盘每一步:
问题是什么、怎么定位的、改完之后实测数据变化多少。
目录
| # | 文章 | 一句话 |
|---|---|---|
| 01 | 点亮硬件视频编解码:VPU 与那些"安静"的坑 | 编解码先跑通;NV12 带 padding、裸流 VLC 打不开这类不报错的坑 |
| 02 | 摄像头这条路坑更多 | /dev/videoN 号每次开机都变、media link 默认是关的、STREAMON -22 |
| 03 | 人脸识别管线优化:7.6 → 29 fps | 灰图之谜、整帧转色改 ROI 转色、IoU 追踪跳过 FaceNet |
| 04 | WebRTC 低延迟优化实录 | 出画面 11.5 秒 → 1.23 秒,首帧压到百毫秒级的每一步 |
| 05 | 一个摄像头,多个消费者 | 拆进程 + 共享内存广播,raw 环 CPU 三级优化 114% → 1.7% |
| 06 | 统一 libcamerasrc 与架构定型 | 为了 3A 删掉低延迟路径;CPU 归因方法;一次黑屏回归 |
| 07 | 补齐对讲的另一半 | 麦克风上行 G.711、强制 IDR 反向通道选型、音频 PTS 坑 |
| 08 | 从局域网到公网:wss/TLS 部署 | 非 https 页面禁 getUserMedia;lws 客户端不加载系统 CA |
背景速览(读任何一篇前先看这段)
硬件:STM32MP257(A35 ×2,无 GPU 依赖的场景全靠软扛)+ IMX335(2592×1944,
无硬件 ISP)+ Verisilicon VPU(硬编 H264/JPEG/VP8,硬解上限 1080p)。
软件分层:
应用层 webrtc_master(WebRTC 推流) face_rec(人脸识别)
↑ 订阅 ↑ 订阅
共享内存 ufifo 环:H264 / raw / det 三路广播,nng ipc 反向控制
采集层 media_pub:独占摄像头,libcamerasrc 采集 + VPU 硬编 + μ-law 音频
驱动 DCMIPP(ISP/camera) + verisilicon VPU(V4L2 mem2mem)
最终实测基线(2026-08 板测,后文各篇展开):
| 读数 | 数值 |
|---|---|
| 采集延迟(摄像头→编码→共享内存→WebRTC) | 24~30ms |
| 局域网呼叫→浏览器首帧 | ~120ms |
| 公网 5G 呼叫→首帧 | ~690ms |
| 人脸识别循环 | ~30fps(满帧) |
| 待机整机负载 | ≈30%(双核 A35 口径) |
读法建议
- 只想让板子出图:读 01、02,照着命令敲即可。
- 做低延迟视频:04 是核心,05 解释为什么最终拆成发布-订阅。
- 关心性能优化方法论:03(CPU)、04(延迟)、06(CPU 归因三步法)连读。
- 所有数字都来自板子上实测,文中给了复现方法;涉及具体
/dev/videoN号的地方,
先读 02 的设备号漂移。
更多推荐



所有评论(0)