摘要
从游戏录像里读信息时，很多帧处在动画中：面板淡入淡出、魔法书翻页、属性面板打开或关闭。在这些帧上读数字既慢又容易错。用户的方向是：不必读每一帧动画，优先抓住稳定、有用的画面。
本实验做了一个“区域稳定选帧器”：盯住要读的那块区域（例如英雄面板、生物属性面板、魔法书），只有当这块区域连续两次采样几乎没变化时，才把当前帧送去做深度读取（OCR 读文字和数值，较慢）；内容和上次已读的相比没有明显变化就不再重复读。
在冻结参数后的其它来源上，它覆盖了 13/15 次已标注的界面展示（漏掉 2 次底部控件提示，这类区域根本还没实现），所选帧都落在标注的“清楚可读”区间内，从清楚开始到被选中的等待 p95 为 334 毫秒；选中的 8 张面板图上重新核对的 80 个头部数值全部读对。选帧器只作为显式可选的实验组件，没有接入默认视频流、App 或下游模块。
要回答的问题
- 只用“当前及之前已到达”的帧（不偷看未来），能否在面板稳定后及时选出一帧去精读？
- 会不会漏掉真正可读的展示，或者在过渡帧上误触发、重复调用？
- 选出的帧送进现有读取器后，数值读得对不对？
数据与来源
- 从已知来源截取 13 个片段，共 116 秒，以每秒 10 帧采样 1,160 张。训练用 3 个来源组的 630 帧；参数冻结后再用另外 2 个来源组的 530 帧评估。后者是过去实验已经用过（已暴露）的校准/最新来源，不是新的盲测，也不能算 13 场独立战斗。
- 人工标注（助手标注）每次展示中“内容真正清楚可读”的时间区间，以及“不存在/过渡”的区间，分开记录。
- 时间戳来自 OpenCV 解码时间，未认证为原视频容器的真实播放时间（PTS）；保留源帧序号。原录像未改动，重新解码后逐帧序号和时间都与首次一致。
方法
背景教训：之前的一次实验用“附近一个稳定按钮”来判断要不要读，结果把 14 次清楚的提示框全部当成重复去掉了——判断依据必须是真正要读的那块区域。另一次实验用“以当前帧为中心的五帧”做决定，但那需要未来两帧，实时时并不可用。
选帧器的规则：
- 用已有的面板检测器找到目标面板，取它的固定兴趣窗口（只支持 2560×1440 这一种布局）。生物属性面板的右侧有会动的 3D 生物形象，把这部分避开。
- 同一区域的两次采样间隔 100–200 毫秒，若平均像素变化 ≤ 2，就提出当前帧。
- 与“已经读过的内容”相比，差异 ≥ 4 才会再次提出，避免重复调用。
- 区域在变化时就等待；面板关闭或视频断流时清空状态。读取失败不更新“已读内容”，下一次稳定时可以重试。绝不回填未来帧，也不倒填时间。
这两个阈值是在训练片段上选出来的，不是置信度或可读性保证。
选中的帧（无损原图）再交给现有的整图文件读取器，读出界面、日志和数值。
设置
- 在训练的 630 帧上调参，然后冻结，再跑另外 530 帧，不回头调。
- 回放里的调度时间用名义上的 100 毫秒网格；报告的延迟一律用实际解码帧的时间。截图、排队和显示延迟没有测。
结果
| 指标 | 训练片段 | 冻结后其它来源 |
|---|---|---|
| 总采样帧 | 630 | 530 |
| 送去深读的原图 | 31 | 13 |
| 已标可读展示被覆盖 | 14/14 | 13/13 |
| 尚未实现、因此漏掉的额外展示 | 未单列 | 2 次底部控件提示 |
| 选中帧落在标注清楚区间之外 | 0 | 0 |
| 清楚区间开始 → 选帧，p95 | 207 ms | 334 ms |
| 同上，最大等待 | 217 ms | 601 ms |
其它来源上应如实报告为 13/15 次已记录展示，不能只报 13/13 而掩盖两个缺口。窗口开始前就已经打开的面板不计算“开启”延迟。训练复审时还发现一次额外的法术提示（第 31–32 帧），选中了第 32 帧，但它没有回填进原来 14 次的调参分母。
选帧器保留了约半秒的生物面板展示、魔法书关闭再打开、以及魔法书页内从 11 个图标筛到 6 个图标的变化。训练片段的 31 个候选里仍有一些由背景变化或位移触发的额外调用，没有逐个证明每次都带来了新字段。
选中帧的读取结果
44 张选中的原图都经过了现有的整图读取工具。其中 8 张校准/最新来源的英雄页和生物页，重新精标了 80 个面板头部数值：80 正确、0 误读、0 漏读、0 拒判，包括数量、生命值区间、属性、负士气/负幸运、英雄等级和资源。名字、技能/法术身份、完整日志、提示全文和全部界面元素都没有评估，因此不能说整图识别达到 100%，更不能说项目整体 ≥ 95%。
速度
44 张图从热启动读文件到输出 JSON（界面、日志、数值）的 p95 为 1.109 秒，最大 1.221 秒；界面冷加载 4.414 秒、OCR 冷加载 8.634 秒。选帧等待单独统计；视频检测、排队、App 截图和显示没有组合计时，所以没有 App 整链路 ≤ 3 秒的结论，也不能把两个 p95 直接相加当成整链路 p95。
失败与负结果
- 底部控件提示还没有区域入口，2 次展示被漏掉。
- 魔法书面板容器不能保证外部弹出的提示框也被完整覆盖；整个容器也可能因为背景或悬浮变化重复触发。
- 评分脚本出过两次错：初版用了一个不存在的“已读”状态，第二版又漏了“检测到的行候选”状态。按原有数值评分协议修正并补了协议测试；原始预测没有改，两份临时统计保留，第三版证据为正式结果。这是评分脚本的错误，不是识别器拒读。
- 稳定帧没被选中多半是因为去重，不应直接算作误拒；但这也意味着“每次额外调用是否有用”尚未证明。
局限
- 只支持 2560×1440 布局；评估来源已暴露，不是独立盲测。
- 统计的是已标注的展示，不声称审完了全片每一条新日志、每一次数值变化和所有提示。
- 时间是解码时间而非真实 PTS；截图、排队、显示延迟未测。
- 软件测试：19 个筛选语义测试、3 个评分协议测试通过；全模块 7353 通过、2 个既有冷导入顺序失败、6 跳过——这些是软件正确性检查，不是识别准确率。
结论与下一步
“等目标区域稳定再精读”能在不偷看未来帧的情况下，以几百毫秒的等待选出可读帧，选中帧上的面板数值读得准。下一步：
- 优先补底部提示/状态栏和外部法术提示的真实区域入口，用区域内的文字/内容变化来判断，避免用一个按钮或整张背景代表目标信息。
- 用新日志行、页内细小数值变化和短提示做漏读试验，收紧重复调用；冻结失败后再立新候选，不回头调本次评估来源。
- 独立验收预览/状态栏、不同分辨率、未暴露来源，以及从选帧到可用结果的整体时延。单图模式继续只返回当前像素能读的部分和“未知”，不偷偷换成后面的帧。
项目目标（≥ 10 场独立真实对战、逐场景逐字段 95%、App p95 ≤ 3 秒）仍未达成。
Comments