Doni/safesight-edge

Fork 0

sladro c3c0ff380e

CI / host-build (push) Waiting to run

Details

CI / rk3588-cross-build (push) Waiting to run

Details

修改bug

2026-01-05 15:39:41 +08:00

4.4 KiB

Raw Blame History

测试现状与处理建议（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：释放端口（推荐）

查 8554/9000 是谁占用：

ss -lntp | egrep ':(8554|9000)'

若是旧的 media-server：停止旧进程（kill 对应 PID），再重启本次测试。

目标：让本次启动能出现这条日志：

[publish] zlm rtsp server ready: rtsp://0.0.0.0:8554/live/cam1

方案 B：改端口避免冲突（适合并行跑多实例）

如果你需要同时跑多个实例，建议改配置：

内置 RTSP 输出端口从 8554 改为 8555（或其他空闲端口）
指标端口从 9000 改为 9001

配置示例（思路）：

{
  "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），再逐步打开硬件链路：

优先恢复 input_rtsp.use_mpp=true（硬解）
再尝试 preprocess.use_rga=true（RGA），但需要：
- 增大 CMA（内核启动参数），或
- 降低中间分辨率/减少临时 buffer 需求，或
- 做 buffer 复用（代码层优化）

5. 建议的“稳定基线”验证步骤（每次改动都按这个验收）

验证输入是否有帧：

curl http://127.0.0.1:9000/api/graphs/cam1_strict_minio_alarm

关注：total_fps > 0

验证内置 RTSP 是否起监听：

ss -lntp | grep ':8554'

播放：

rtsp://<board_ip>:8554/live/cam1

验证报警与上传：

日志出现 [ALARM][info] ...
MinIO test bucket 出现 .jpg 和 .mp4

6. 备注：日志里的两条“非致命提示”

[rtsp] decoding for stream 0 failed：FFmpeg 在 RTSP 抖动/重连/首包阶段可能出现（但你后续已经推理、报警，说明最终还是拿到了帧）。
deprecated pixel format used：swscale 对某些 YUV 范围提示，通常不影响功能验证。

4.4 KiB Raw Blame History Unescape Escape