Doni/OrangePi3588Media

Fork 0

sladro 644fb590fa

CI / host-build (push) Waiting to run

Details

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

Details

修改bug

2026-01-05 16:02:45 +08:00

11 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 范围提示，通常不影响功能验证。

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。

配置改动（示例）：

{
  "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。

建议分两步开：

先只开 pre_cam1.use_rga=true（AI 前处理）
稳定后再开 post_cam1.use_rga=true（输出/编码前处理）

配置改动（示例）：

{ "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：缩小区域（减少无效触发与后续媒体/上传开销）

示例：

{
  "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 来限制动作压力（示例）：

{
  "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 变化、断流重连）

11 KiB Raw Blame History Unescape Escape