一套基于真实嵌入式项目的踩坑复盘。平台是 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 的设备号漂移
Logo

智能硬件社区聚焦AI智能硬件技术生态,汇聚嵌入式AI、物联网硬件开发者,打造交流分享平台,同步全国赛事资讯、开展 OPC 核心人才招募,助力技术落地与开发者成长。

更多推荐