153 lines
4.4 KiB
Markdown
153 lines
4.4 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 范围提示，通常不影响功能验证。
|