yolov5-inferrence/docs/debounce_positive_upload_plan.md

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

本文记录 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 最多上传一次正例：

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

上传 JSON 结构保持不变：

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。