# 推理程序去抖与漏报优化记录

本文记录 `time_period_P_r30_linaro` 分支上的去抖和正例上报优化，方便复查代码改动。

## 现场问题

1808 设备上同时运行 6 到 7 个推理程序时，资源紧张会造成推理结果波动。旧逻辑要求同一类别数量连续稳定 3 次才上传，短暂漏检或低置信过滤可能让结果稳定成 `number=0`，随后又上传 `number=1`。

管理程序只处理 `number > 0` 的识别消息，并根据持续时间判断是否触发后续视频合并和上报；目标消失不需要推理程序主动通知。因此推理程序侧不应主动上传 `number=0`。

## 新逻辑

- 当前推理帧只要在 workspace 内检测到可上传目标，就进入正例候选。
- `prop >= conf_threshold` 记为 `strong_present`。
- `0.30 <= prop < conf_threshold` 记为 `weak_present`，第一版也参与正例上传，用于降低漏报。
- `prop < 0.30` 记为 `filtered_low_conf`，不参与上传。
- workspace 外目标记为 `filtered_workspace`，始终不参与上传。
- 当前帧无可上传目标时，只记录 `no_target`，不上传 `number=0`。

## 上传节流

同一最终上传编码 `class_idx` 每 `500ms` 最多上传一次正例：

```text
首次检测到某 class_idx：立即上传
持续检测到同一 class_idx：每 500ms 最多上传一次
未检测到：不上报，只记日志
```

上传 JSON 结构保持不变：

```text
serial
type
at
params[].class_idx
params[].name
params[].number
```

多个模型 label 如果映射到同一个 `class_idx`，继续合并数量后上传。`codes[i] == 0` 的类别仍不上传。

## 日志字段

本次增加/规范以下日志事件，写入可执行文件目录下 `.log/YYYY-MM-DD-yolov5.log`：

- `frame_seen`：本次推理帧序号和原始检测数量。
- `strong_present`：超过阈值且在 workspace 内。
- `weak_present`：高于 0.30、低于阈值且在 workspace 内。
- `filtered_low_conf`：低于 0.30。
- `filtered_workspace`：不在 workspace 内。
- `upload_positive`：本帧触发正例上传。
- `upload_skip_throttle`：本帧有目标，但 500ms 节流跳过。
- `upload_skip_code0`：类别编码为 0，按旧规则不上传。
- `upload_skip_busy`：已有上传线程正在执行，跳过本次上传。
- `no_target`：本帧没有可上传目标。
- `upload_positive_payload`：实际组装进 JSON 的正例载荷。

日志清理策略：

- 程序启动后第一次写日志会清理旧日志。
- 程序长期运行跨天后，第一次打开新日期日志时也会清理旧日志。
- 只清理 `.log` 目录下命名匹配 `YYYY-MM-DD-yolov5.log` 的文件。
- 默认保留最近约 7 天日志。

## 额外风险修复

`main.cpp` 中 h264 分段轮转原来在内部重新声明了 `FILE *fpSave`，会遮蔽外层文件句柄。现在改为更新外层 `fpSave`，并在退出主循环后关闭当前句柄。

## 验收场景

- `1,0,1`：上传正例；中间 `0` 只记 `no_target`，不上传 `number=0`。
- `1,弱命中,1`：弱命中参与正例链路，持续上传或被节流跳过，不归零。
- `0,0,0`：只记录 `no_target`，不上传。
- workspace 外目标：只记录 `filtered_workspace`，不上传。
- 多 label 同 `class_idx`：合并成同一个业务编码上传。

## 编译验证

按 `docs/cross_compile_wsl_linaro.md` 的 WSL + Linaro 路线编译，并检查：

- 产物为 aarch64 ELF。
- 不依赖 `GLIBC_2.33`、`GLIBC_2.34`、`GLIBCXX_3.4.29`。
- 仍链接 `librknn_api.so`。