308 lines
11 KiB
Markdown
308 lines
11 KiB
Markdown
# 测试现状与处理建议（RTSP + AI + 报警上传）
|
||
|
||
本文基于你提供的运行日志（`configs/test_cam1_strict_minio_alarm_rtsp_server.json`）整理：当前 **AI 推理 + 报警触发 + MinIO 截图/视频片段上传已通**，但 **内置 RTSP 复用输出无法播放** 的根因是 **端口冲突**。
|
||
|
||
---
|
||
|
||
## 1. 现状判定（从日志反推）
|
||
|
||
### 1.1 已成功的部分
|
||
|
||
- RKNN 推理已启用且模型加载成功：
|
||
- `[AiScheduler] loaded model ...` / `[ai_yolo] model loaded ...`
|
||
- 能出检测框：
|
||
- 多条 `[ai_yolo] det: ...`
|
||
- 报警触发：
|
||
- `[ALARM][info] ... rule=person_in_view ...`
|
||
- MinIO 上传已可用：
|
||
- 截图/视频片段已上传（你已确认“可以上传视频片段”）
|
||
|
||
### 1.2 当前失败点（导致 RTSP 播放不了）
|
||
|
||
日志里关键报错：
|
||
|
||
```
|
||
Bind socket failed: address already in use
|
||
mk_rtsp_server_start | Listen on :: 8554 failed: address already in use
|
||
[publish] zlm rtsp server start failed on port 8554
|
||
```
|
||
|
||
这表示：**板子上已经有进程占用了 8554**（可能是上一次启动的 media-server 没停干净、或另一个 RTSP 服务占用），导致本进程内置 RTSP server 无法监听 8554，自然无法播放 `rtsp://<board_ip>:8554/live/cam1`。
|
||
|
||
同时还有：
|
||
|
||
```
|
||
[HttpServer] bind failed on port 9000
|
||
```
|
||
|
||
说明 **9000 指标端口也被占用**（不是导致 RTSP 播放失败的主因，但说明你确实存在“重复启动未释放端口/已有服务占用”的问题）。
|
||
|
||
---
|
||
|
||
## 2. 立刻可用的处理方案（建议按顺序）
|
||
|
||
### 方案 A：释放端口（推荐）
|
||
|
||
1) 查 8554/9000 是谁占用：
|
||
|
||
```bash
|
||
ss -lntp | egrep ':(8554|9000)'
|
||
```
|
||
|
||
2) 若是旧的 `media-server`：停止旧进程（kill 对应 PID），再重启本次测试。
|
||
|
||
> 目标：让本次启动能出现这条日志：
|
||
>
|
||
> ` [publish] zlm rtsp server ready: rtsp://0.0.0.0:8554/live/cam1 `
|
||
|
||
### 方案 B：改端口避免冲突（适合并行跑多实例）
|
||
|
||
如果你需要同时跑多个实例，建议改配置：
|
||
|
||
- 内置 RTSP 输出端口从 `8554` 改为 `8555`（或其他空闲端口）
|
||
- 指标端口从 `9000` 改为 `9001`
|
||
|
||
配置示例（思路）：
|
||
|
||
```json
|
||
{
|
||
"global": { "metrics_port": 9001 },
|
||
"graphs": [
|
||
{
|
||
"nodes": [
|
||
{
|
||
"id": "pub_cam1",
|
||
"type": "publish",
|
||
"outputs": [
|
||
{ "proto": "rtsp_server", "port": 8555, "path": "/live/cam1" }
|
||
]
|
||
}
|
||
]
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
对应播放地址改为：
|
||
|
||
`rtsp://<board_ip>:8555/live/cam1`
|
||
|
||
---
|
||
|
||
## 3. 你提到“之前肯定能推理+播放”，为什么这次不行？
|
||
|
||
这次日志已经证明推理正常；播放不行是因为 **RTSP server 启动失败（端口占用）**。一旦 8554 可用，你会看到：
|
||
|
||
```
|
||
TCP server listening on [::]: 8554
|
||
[publish] zlm rtsp server ready: rtsp://0.0.0.0:8554/live/cam1
|
||
```
|
||
|
||
出现后再去播就能连上。
|
||
|
||
---
|
||
|
||
## 4. 当前配置里“我之前关过的东西”是什么？现在该怎么选
|
||
|
||
为了绕开之前遇到的 CMA/DMA 内存不足（`/dev/dma_heap/cma` 申请失败），目前配置偏向“稳定跑通”：
|
||
|
||
- `input_rtsp.use_mpp=false`：输入走 FFmpeg CPU 解码（更稳，但 CPU 更高）
|
||
- `preprocess.use_rga=false`：前后处理走 swscale（避免 DMA heap 申请）
|
||
- `post_cam1` 输出降到 `1280x720`：减少后处理/编码压力
|
||
|
||
如果你后续追求性能（多路 1080p），再逐步打开硬件链路：
|
||
|
||
1) 优先恢复 `input_rtsp.use_mpp=true`（硬解）
|
||
2) 再尝试 `preprocess.use_rga=true`（RGA），但需要：
|
||
- 增大 CMA（内核启动参数），或
|
||
- 降低中间分辨率/减少临时 buffer 需求，或
|
||
- 做 buffer 复用（代码层优化）
|
||
|
||
---
|
||
|
||
## 5. 建议的“稳定基线”验证步骤（每次改动都按这个验收）
|
||
|
||
1) 验证输入是否有帧：
|
||
|
||
```bash
|
||
curl http://127.0.0.1:9000/api/graphs/cam1_strict_minio_alarm
|
||
```
|
||
|
||
关注：`total_fps > 0`
|
||
|
||
2) 验证内置 RTSP 是否起监听：
|
||
|
||
```bash
|
||
ss -lntp | grep ':8554'
|
||
```
|
||
|
||
3) 播放：
|
||
|
||
`rtsp://<board_ip>:8554/live/cam1`
|
||
|
||
4) 验证报警与上传：
|
||
- 日志出现 `[ALARM][info] ...`
|
||
- MinIO `test` bucket 出现 `.jpg` 和 `.mp4`
|
||
|
||
---
|
||
|
||
## 6. 备注：日志里的两条“非致命提示”
|
||
|
||
- `[rtsp] decoding for stream 0 failed`：FFmpeg 在 RTSP 抖动/重连/首包阶段可能出现（但你后续已经推理、报警，说明最终还是拿到了帧）。
|
||
- `deprecated pixel format used`：swscale 对某些 YUV 范围提示，通常不影响功能验证。
|
||
|
||
---
|
||
|
||
## 7. 测试通过后的下一步计划（多路并发 + 分辨率自适应）
|
||
|
||
### 7.1 固化“基线验收标准”（先定义通过=什么）
|
||
|
||
- 每路 `total_fps` ≥ 目标帧率的 90%
|
||
- RTSP 输出可连续播放 N 分钟不断流
|
||
- 报警触发次数符合预期，MinIO 中 `.jpg/.mp4` 可用且数量/大小合理
|
||
- CPU/NPU/内存占用在可接受范围（尤其是内存不持续增长）
|
||
|
||
### 7.2 多路压测：按 2→4→8 逐步加路，不要一次拉满
|
||
|
||
- 每加一档路数就记录：每路 fps、掉帧、端到端延迟（拉流→输出）、报警/上传是否还能跟上
|
||
- 发现瓶颈后先定位/修复，再进入下一档
|
||
|
||
### 7.3 逐步切回硬件链路（性能优化主线，按顺序恢复）
|
||
|
||
当前为了稳定跑通（避免 CMA/DMA 申请失败）使用了 CPU 路径：`use_mpp=false`、`use_rga=false`。
|
||
|
||
建议按“阶段化 + 验收 + 失败回退”来做，每次只动一个开关：
|
||
|
||
#### 阶段 0：固定稳定基线（可随时回退点）
|
||
|
||
- `input_rtsp.use_mpp=false` + `input_rtsp.use_ffmpeg=true`（FFmpeg CPU 解码）
|
||
- `pre_cam1.use_rga=false`、`post_cam1.use_rga=false`（swscale）
|
||
|
||
验收：fps、报警、上传、RTSP 输出都稳定（建议至少跑 10~30 分钟）。
|
||
|
||
#### 阶段 1：先恢复输入硬解（只改一处）
|
||
|
||
目标：把输入从 CPU 解码切到 **ffmpeg demux + mpp decode**。
|
||
|
||
配置改动（示例）：
|
||
|
||
```json
|
||
{
|
||
"id": "in_cam1",
|
||
"type": "input_rtsp",
|
||
"use_mpp": true,
|
||
"use_ffmpeg": false
|
||
}
|
||
```
|
||
|
||
说明：`use_mpp=true` 会走 “FFmpeg 解复用 + MPP 解码”；为避免歧义建议把 `use_ffmpeg=false`（否则会同时存在两条可选路径）。
|
||
|
||
验收点：
|
||
|
||
- 启动日志出现：`(ffmpeg demux + mpp decode)`
|
||
- `/api/graphs/<graph>` 里 `total_fps` 稳定
|
||
- 对比基线：CPU 降、温度/功耗更稳（多路时收益更明显）
|
||
|
||
失败判定与回退：
|
||
|
||
- 若出现 “requested ffmpeg/mpp but not enabled at build time” 或持续拿不到帧：先回退到 `use_mpp=false`，确认编译选项/依赖再继续。
|
||
|
||
#### 阶段 2：再恢复 RGA（建议分两步）
|
||
|
||
目标：把缩放/色彩转换从 swscale 切到 RGA。
|
||
|
||
建议分两步开：
|
||
|
||
1) 先只开 `pre_cam1.use_rga=true`（AI 前处理）
|
||
2) 稳定后再开 `post_cam1.use_rga=true`（输出/编码前处理）
|
||
|
||
配置改动（示例）：
|
||
|
||
```json
|
||
{ "id": "pre_cam1", "type": "preprocess", "use_rga": true }
|
||
{ "id": "post_cam1", "type": "preprocess", "use_rga": true }
|
||
```
|
||
|
||
验收点：
|
||
|
||
- preprocess 启动日志从 `(swscale)` 变为 `(rga)`
|
||
- 无以下报错/告警（任意出现都算“资源不足/路径退化”，需要先处理再继续）：
|
||
- `[DmaAlloc] DMA_HEAP_IOCTL_ALLOC failed` / `failed to open dma_heap device`
|
||
- `[preprocess] DMA alloc failed`
|
||
- AI 输入尺寸/格式正确（例如 `pre_cam1` 要输出 `dst_format=rgb`），不能出现“RGA 失败直接 passthrough 导致下游格式/尺寸不匹配”。
|
||
|
||
若再次出现 CMA/DMA 不足：
|
||
|
||
- 系统层：增大 CMA（内核启动参数/设备树），保证 `/dev/dma_heap/cma` 有足够空间
|
||
- 代码层：做 DMA buffer 复用/池化（当前 RGA 路径会频繁 `DmaAlloc()`，多路更容易打爆）
|
||
|
||
回退策略：
|
||
|
||
- 先回退 `post_cam1.use_rga=false`，再回退 `pre_cam1.use_rga=false`
|
||
- 若仍不稳，再回退 `input_rtsp.use_mpp=false` 回到阶段 0
|
||
|
||
### 7.4 降低报警/上传对多路性能的影响（多路必须做）
|
||
|
||
多路压测时，原则是：**先把触发频率降下来**，再控制媒体时长，最后再看上传/队列的背压与丢弃策略。
|
||
|
||
#### 1) 规则侧：避免“每帧触发”
|
||
|
||
可直接在 `alarm.rules[]` 里调：
|
||
|
||
- `min_duration_ms`：设为非 0（例如 30fps 下 `300ms≈9 帧`，`500ms≈15 帧`）
|
||
- `cooldown_ms`：适当加大（例如 10s/30s），避免同一目标持续刷屏
|
||
- `roi`：缩小区域（减少无效触发与后续媒体/上传开销）
|
||
|
||
示例：
|
||
|
||
```json
|
||
{
|
||
"name": "person_in_view",
|
||
"class_ids": [0],
|
||
"roi": { "x": 0.2, "y": 0.2, "w": 0.6, "h": 0.6 },
|
||
"min_duration_ms": 500,
|
||
"cooldown_ms": 10000
|
||
}
|
||
```
|
||
|
||
#### 2) 媒体侧：先压测 snapshot，再开 clip
|
||
|
||
- 压测阶段建议先 `clip.enable=false`，只开 `snapshot`，先把“检测/触发/上传链路”跑稳。
|
||
- 需要 clip 时，尽量缩短：`clip.pre_sec/post_sec`。
|
||
|
||
备注：当前 clip 动作会等待 `post_sec`（内部会 `sleep(post_sec)` 以收集后置窗口帧），触发太频繁会导致动作堆积、事件队列更容易丢。
|
||
|
||
#### 3) 队列侧：区分“图流水线队列”与“报警事件队列”
|
||
|
||
- 顶层 `queue`：影响整条图的帧流转（你现在默认 `drop_oldest`）。多路时建议保持丢帧优先（而不是阻塞），避免某一路慢把全局拖死。
|
||
- `alarm.event_queue`（可选）：只影响报警动作执行（snapshot/clip/http 等），不会直接阻塞图处理（除非你把策略设成 `block`）。
|
||
|
||
建议给 `alarm` 增加 `event_queue` 来限制动作压力（示例）：
|
||
|
||
```json
|
||
{
|
||
"id": "alarm_cam1",
|
||
"type": "alarm",
|
||
"event_queue": { "size": 64, "strategy": "drop_oldest" }
|
||
}
|
||
```
|
||
|
||
说明：
|
||
|
||
- `strategy` 支持：`drop_oldest` / `drop_newest` / `block`
|
||
- 多路压测阶段不建议 `block`（可能把触发线程卡住，反而放大抖动）
|
||
|
||
#### 4) 上传/通知侧：超时与失败策略要心里有数
|
||
|
||
- MinIO 上传：当前是同步上传（snapshot/clip 都会直接调用 uploader），失败会打印 `upload failed: ...`，但未看到通用的“自动重试/退避”配置项。
|
||
- 若使用 presign：可配置 `presign_endpoint` + `presign_timeout_ms`（默认 3000ms）。
|
||
- HTTP 通知：内部有后台线程与队列，但同样没有重试语义；压测时建议先关 `http.enable`，等主链路稳了再开。
|
||
|
||
压测结论建议记录：每路触发频率（每分钟/每小时）、snapshot/clip 成功率、以及队列丢弃（若有）——否则很难判断“算力瓶颈”还是“报警/上传侧把系统拖慢”。
|
||
|
||
### 7.5 工程化：可重复部署 + 可观测 + 长稳
|
||
|
||
- 固化启动/停止流程（端口冲突处理、配置热更策略）
|
||
- 用 `/api/graphs` 做在线监控（fps、队列、alarm_total、publish_clients）并接入现有监控
|
||
- 做 24h 长稳（内存、线程数、句柄、CMA 变化、断流重连）
|