摘要
项目的战斗记录 App（Battle Notes）可以导入“按时间排列的一局截图”文件夹来回放和测试识别。用户希望每段录像都有 8–20 张覆盖战斗准备和战斗过程的截图，大量标注，并留一部分作测试。10 月的 22 段录像已经有 24 局截图包；本实验（内部编号 B144）把 8–9 月和 9 月底到 10 月 2 日的其余自录录像也做成截图包。用户在当天明确允许旧录像用于训练。
这是一个数据建设实验，不训练模型。最终得到 111 个截图包、1,785 张图，全部由标注助手逐帧像素精审（不是人工真值）。
要回答的问题
能否把旧录像按局整理成符合 App 格式的截图包，并为每局留下可用于后续识别和推断评测的精审记录？精审中能发现哪些系统性问题？
数据与来源
划分（按整段录像，不拆帧）：
- 冻结、不打开：10 月留出测试来源和 9 月 12 日留出来源。
- 排除：12 段 QQ 录屏（1920×1078/1080，不是读取器使用的原生 2560×1440 版式）和 1 段转封装/续录隔离录像。
- 旧录屏测试：从未被训练用过、或早先协议禁止用于训练的录像，共 12 段（检测器的验证/测试源 4 段、9 月审计预留的验收候选 3 段、一场选秀的两段续录、3 段早先未准入训练的录像）。
- 训练：其余 36 段 2560×1440 录像。
方法
- 扫描：每段录像按 5 帧/秒做场景与稳定性扫描，方法与 10 月截图包相同；视频用 GPU 硬件解码（H.264 解码逐位一致，缩放仍在 CPU）。
- 切局：按“战斗段（布阵/战场/战斗中面板，间隙 ≤20 秒）+ 之前的选秀”切出一局。
- 选帧：每局用生产的离线选帧（≤15 张），再加战斗 25/50/75/95% 处的战场、较晚的日志、法术与军队选择末段；不足 8 张的短局补布阵面板和战场。按原生时间戳导出 PNG。
- 精审：每局一个标注助手逐帧判断接收/拒收（动画、半透明过渡、遮挡到不可读则拒收）和真实场景，记录整局的我方侧、双方英雄、我方构筑（技能与等级、子技能、装备、法术、军队）、双方施法事件、生物面板字面、第一张开局战场的双方 HUD 数值。助手不运行任何识别模型；唯一允许参考的算法输出是我方构筑草稿，且必须逐项对照像素核对。
- 打包：只用接收的帧，每包 8–20 张、含准备与战斗，并用 App 的文件夹校验工具检查。
设置
48 段录像扫描（两段 I/O 错误重试成功），导出 86 局候选帧；13 个标注助手逐帧精审，部分早期未做完的局由后来的助手补齐。
测试池盲标：原协议允许测试局参考我方构筑草稿；当天晚上起新标的测试局改为不看草稿的盲标。在规则改变前已看过草稿的 2 局另行注明。之后评估确认页读取时，只把盲标局当独立参照。
结果
111 个截图包、1,785 张图，App 文件夹校验 111/111 通过。
| 池 | 录像 | 有截图包的录像 | 局 | 张 |
|---|---|---|---|---|
| 训练（含 10 月训练 15 局） | 49 | 49 | 75 | 1,215 |
| 10 月测试 | 9 | 9 | 10 | 126 |
| 旧录屏测试 | 12 | 12 | 26 | 444 |
精审发现：
- 扫描场景标签有系统性错误：开战瞬间（HUD 还没出现但已显示移动范围）被标成布阵；很多“战场”其实是攻击/法术预览（共约 40 张攻击预览、6 张法术预览）；部分“英雄面板”其实是日志。精审已按实际场景改判。
- 最终确认页只显示 10 个法术；第 11–14 个只能在战斗中的法术书里看到，且确认页上看不到等级。
- 战斗中法术书的等级常比确认页低 1（多局如此，也有局没有），与对方某些“降级”装备一致，照字面记录。
- 项目知识库里有几组子技能参考图标逐字节相同，只能靠所在主技能或战斗证据区分；已通知模拟器负责人。
- 我方构筑草稿在训练池 40 局中有 124 处修正，多数是漏读（某些子技能、空装备槽、士气 0）；真正的错值集中在“化身召唤”的档位和被鼠标遮挡或误读的生物数量。
- HUD 魔法值下降但日志里没有对应施法行的情况很多（日志滚出了视野），这些不计入施法事件。
失败与负结果
- 场景扫描的分类错误相当普遍，说明单靠扫描标签切局和选帧会混入预览、日志等画面。
- 不足 8 张接收帧的局不打包。
局限
所有标注是助手像素精审，不是人工真值，旧录像标注还没做独立二审；同局多帧是重复观察，局数不等于独立来源数。
结论与下一步
旧录像已整理成可直接导入 App 的 111 个截图包，并附带逐局精审记录。精审发现的问题（场景误标、确认页法术数、构筑草稿漏读）分别交给后续实验处理，例如确认页读取的改进交由 B149。
Comments