摘要

本项目想从《英雄无敌:上古纪元》的游戏录像里自动读出“现在在哪个界面、屏幕上写了什么、这些字和哪个图标对应”。B020 是这一系列(B021–B024)的总设计:它规定系统由哪些部分组成、每一帧输出什么、哪些是当前观察、哪些是跨时间的推断,以及怎样验收。

设计之后,B020 又承担了“组合验证”:把各个专项实验(数字复读、单格补读、魔法书页、HUD、生物面板、状态图标)一个个接回同一条视频处理流水线,确认原视频 → 读数 → 审核网页这一整条链是通的,且不丢证据。

主要结论:

  • 设计上,“场景分类”和“这一帧能不能处理”一起判断、分开输出;同一场景内容不变时只留一张代表帧,内容变化就留新帧。
  • 接线上,所有阶段都在开发录像上实际跑通,并逐项确认旧结果没被改写。
  • 在事后补的参考上,若干小组读数很好(例如魔法书页 535/543 精确、0 错收),但这些参考来自已用于开发的同一批录像,不是独立测试准确率;整帧穷尽标注完成数始终为 0。

要回答的问题

  1. 场景识别、文字识别、图标关联和时间推断这些模块如何组合?哪些输出属于“当前帧”,哪些属于“历史推断”?
  2. 专项实验里得到的读取方法,接回真实视频流水线后能否完整运行,且不覆盖、不丢失原有证据?
  3. 接回以后,在能核对的地方读得怎么样,还缺什么?

数据与来源

  • 设计依据:用户对场景流程的纠正(例如技能页空白其实是翻页动画;属性加点到最终确认之后不能返回;任何时候都可能切出游戏)以及外部审阅建议(约束标签不能证明可靠的状态跟踪)。
  • 录像:全部是已经参与开发的用户自己的录像,包括 9 月 8 日一段长录像中 27:00–29:00 的两个一分钟片段、9 月 9 日两段录像(约 4 分钟和约 19 分钟),后期还有 9 月 5 日一段录像的 8 秒片段。两段预留给独立验收的 9 月 12 日录像全程没有打开。
  • 参考答案:多数由助手逐图查看原像素后转写,标记为“助手审核、待用户确认”,属于模型目视核对,不是人工审核(REVIEWED)。

方法

总体设计:一个入口,多个独立输出

游戏流程大致是:菜单 → 对局设置 → 等待匹配 → 加载 → 选英雄 → 选技能 → 选宝物 → 选魔法 → 选生物 → 属性加点 → 最终确认 → 排兵布阵 → 实际战斗 → 结果。设计把它整理成 12 个游戏内顶层场景,再加一个独立的“可见性”条件(是否切出游戏),因为切出游戏可以发生在任何阶段,不能当流程里的一个节点。

不采用“先判断画面质量,合格后再分类场景”的串行方案,因为判断“缺了什么内容”本身就需要知道候选场景。改为一个公共入口:OCR(光学字符识别,把图里的文字读出来)给出文字和位置,必要时再用整图或局部图像分类器补证据,最后分别输出:场景、子类、可见性、内容是否就绪、是否疑似过渡、处理策略(例如“等下一帧”)。证据不够时输出 UNKNOWN 加原因,不能把所有失败都叫“过渡”。上一帧的场景只放在带“年龄”的历史上下文里,不能冒充当前观察。

关键帧:只在内容变化时保留新图

候选配置是约 10 fps 粗分类、有意义区间最多约 5 fps 提取细节(这是提出的候选,不是已实测的最佳值)。例如 20 分钟匹配等待只保存起止和代表帧;同一场景里候选刷新、等级、提示变化则必须保留新帧,不能只按场景标签去重。

接线原则

每接一个新阶段都遵守同一组规则:

  • 新结果写入单独命名的新目录(称为一个“变体”),旧结果逐项保持不变;
  • 待处理、失败、场景门控跳过、未接入分别记录,失败不能变成“空的成功”;
  • 上游原图、OCR 或模型配置变化后,旧的下游结果必须失效、在网页上隐藏;
  • 推理时不读取任何参考答案,参考答案只在结果冻结后用于事后比较。

设置

各阶段使用的固定方案(都沿用专项实验已选好的配置,不重训、不调阈值):

阶段 做什么 使用的方法
稳定帧选择 从视频里挑内容稳定的代表帧 B033 已训练的稳定性模型,阈值 0.5,内容去重
整屏 OCR 读全图文字 PP-OCRv6 系列,后期用“小切块 + 保护”配方
视觉场景补充 OCR 认不出战场时用颜色/边缘参考补判 B022 的历史参考模型,阈值不变
数字复读 对自动选中的数字框再读一次 本地 PaddleOCR-VL-1.6(视觉语言模型)
单格补读 原字段未知的数值格,裁小格重读 PP-OCRv6_medium_rec 原尺寸,分数 ≥ 0.90
魔法书页字面 每个法术槽周围的数字/罗马数字 PP + VL 两个模型各读一次原尺寸
生物面板、状态提示、状态图标角标 局部读取属性、说明文字和图标上的小数字 VL 原尺寸,状态部分另加 4 倍放大并列保存

结果

第一次本地流水线(9 月 10 日)

录像 时长 5 fps 采样 稳定候选 OCR 完成
9 月 9 日第一段 262.1 秒 1,311 27 27
9 月 9 日第二段 1126.3 秒 5,631 248 248

第二段只用 OCR 判场景时,只有 45 帧被认成战场、72 帧 UNKNOWN。例如 553.4 秒那张图明明是普通战场,却没命中 OCR 规则。加入视觉场景补充后,战场 45 → 112 帧,UNKNOWN 72 → 5,其他场景数量不变。随之得到 1,163 个行动条框(行动条 = 屏幕上排着的单位行动顺序头像),其中 1,050 个有身份候选;这些来自同一段录像的重复头像,不是 1,163 个独立样本。

同日接入战场生物身体和数量牌(数量牌 = 单位脚下显示这支部队还剩多少个体的小牌子):第二段得到 1,234 个身体候选、1,176 个数量牌候选。助手从 10 帧裁出 40 张数量牌事后核对:32 张可读的牌 32/32 数字一致;但 6 张根本不是数量牌(5 个魔法书装饰边框、1 个绿色移动范围边缘),其中有算法把装饰边框读成了“1”。

10 fps 与数字复读(9 月 12 日)

9 月 8 日录像两个一分钟片段:1,200 次采样 → 53 张稳定原图,1,997 个自动数字框全部完成 VL 复读,38 处候选文字被改写。改写数不是修正数:例如 1635.8 秒左上角时钟 02:4 被复读成正确的 02:47,但同图一块背景纹理被从 10 读成 2,仍然是在非文字区域“幻读”。另一张图 OCR 判出生物信息面板,两个视觉参考对底层场景其实一致,却因完整标签不同而被拒,导致整帧 UNKNOWN——这被记为下一步要修的真实失败。

单格补读、书页和 HUD(9 月 12 日)

四个运行共 328 张图、949 个自动数值字段。其中只有原字段未知的 270 个发给单格补读,全部完成,137 个得到可解析候选。事后在能核对的 32 项上:

参考组 原字段精确 单格补读精确
旧开发参考 17 项 / 11 图 0/17 17/17
长录像新增 15 项 / 15 图 0/15 15/15

其余 105 个新候选本阶段没有核对。121 个“拒识”起初被当成魔法书中央数字漏读,同日槽位审计更正:这些都是中央位置,许多根本没有数字,不能当成 121 次漏读。

魔法书页先只恢复了 11 张,7 张被拒;逐图检查发现那 7 张都是清晰的单页,问题出在旧规则要求左右两页都有标题。改用单页布局后,加上同帧英雄 HUD(HUD = 屏幕两侧显示英雄属性、法力和时钟的固定区域),事后参考结果是:

组 可见字面 精确 拒识 错读 负位置误收
新 10 张双页 360 353 7 0 0 / 200
原 7 张单页 147 146 1 0 0 / 245
原 450.2 秒那张 36 36 0 0 0 / 20
同帧英雄字段 80 80 0 0 未评估
同帧角落时钟 40 40 0 0 未评估

合计 18 张书页 543 个可见字面中 535 个精确、8 个拒识,465 个“本来没有字”的位置没有误收。原先报告的“473 个拒识”其实 465 处本来就无字,只有 8 处是真的漏读,全部是左下角罗马数字 I。这 10 张图来自同一段录像、书页内容重复,不能当 10 个独立来源。

“当前值/上限”传给下游(9 月 12–13 日)

内部已经能读出 88/100 这类值,但原来的公共输出格式不认识这对数,下游拿到的是 unknown。新增独立的 v2 输出后,328 帧 420 个数值对位置中 281 个已读并导出、139 个仍未知。其中 9 月 8 日两个片段的 112 个位置全是未知。

逐位置排查这 112 个:102 个单格补读其实早已读对(只是没进入公共输出),10 个是同一个底栏 62/102。原图和多数读法都是 62/102,但其中一个 OCR 切块读成 62/10。检查切块原像素后确认:切块右边界正好切掉了末位 2。新规则只在“切块边缘离文字行边界不超过 2 像素且有其他读法跨过该边缘”时,才剔除这次截断读法、对完整小格重读一次:

比较 10 个已知截断位置
原冲突门控 10 拒识
边缘证据 + 完整格重读一致 10 候选,均为 62/102,与原图一致

328 帧 949 格中,另外 939 格不触发规则、输出不变。这 10 处是同一录像同一字面的重复,所以规则没有全局采用。

生物面板和状态(9 月 19 日)

阶段 实际产出
生物面板局部 VL 5 张面板 25 个裁图全部读出候选(同一录像,有相邻重复)
状态提示文字 2 张提示、4 个裁图 × 两种尺寸,例如读出“寒霜刺骨 / 受到的魔法伤害提升50%。”
状态图标角标 346 帧中 13 帧有图标,共 56 个角标,原尺寸与 4 倍读法全部一致
∞ 字形检查 既有 56 角标均“未见 ∞ 证据”;新跑 8 秒片段 9 个角标中 3 个给出 ∞ 候选

“两种尺寸一致”和“未见 ∞ 证据”都不等于读对。这些阶段都另外从原视频空目录重新跑了一遍完整流水线并验证续跑不改写上游文件,但用的是已曝光的同一批录像,属于回归而不是新来源。

失败与负结果

  • 第一次本地运行因扫描缓存返回值解包错误失败,失败状态和缓存保留,修复后另建新目录。
  • 数字复读会在背景纹理上“幻读”,格式检查挡不住。
  • 数量牌搜索会把魔法书装饰边框、移动范围边缘当成数量牌,并给出确定数字。
  • 生物信息面板因两个视觉参考标签细节不同而整帧 UNKNOWN。
  • 魔法书页旧布局要求双页标题,导致 7 张清晰单页被拒。
  • 9 月 8 日片段的 112 个数值对位置在公共输出里全部未知;其中 10 个是切块截字造成的真实冲突。
  • 状态字形接线完成后,标注网站服务的正常重启受当时工具策略限制,新变体没有在实时网站上激活,不能声称已上线。

局限

  • 所有录像都参与过开发;参考多为助手事后目视核对、待用户确认,不是人工审核真值,也不是独立测试。
  • 近邻帧、同一段录像的重复内容很多,计数(框数、候选数、改写数)都不是独立样本数,更不是准确率。
  • 整帧穷尽标注完成数为 0;HUD、书页等只是“部分维度”的参考。
  • 软件测试(例如 Perception 全套 2,000 多项通过)证明的是接线、来源检查和不改写旧数据,不证明识别正确。

结论与下一步

B020 的设计——场景与可处理性分开输出、只在内容变化时保留关键帧、模型候选与参考答案分层——在 9 月中旬的一系列接线中被逐步落实。专项读取器都能在真实视频上运行并保留完整证据,部分小组的事后核对结果也很好,但这些都是开发数据上的结果。

下一步的方向在各报告中一致:不再围绕同一录像里的重复值调参,而是扩大不同录像的短悬停说明、非文字和遮挡负例、其他 UI 缩放等数据;在完成来源隔离审计后,用预留的独立录像做真正的验收。