# 测试现状与处理建议（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 变化、断流重连）