摘要

项目积累了大量 2560×1440 的对局录像，占用很多磁盘空间。用户计划以后删除或压缩大部分原始录像，因此后续的数据流程需要能只依靠一个“帧库”工作：从每段录像里挑出有用的帧，以无损格式保存，并记录每一帧来自哪段录像的哪个时间点。

本实验计划先在三段录像上试做这样的帧库，并估算全量建库需要多少空间和时间。这是一个计划：选帧、编码、核对和估算工具以及 7 项测试已经写好，但试点和估算都没有运行。 这一批数据工作在 2026 年 10 月 9 日被用户要求暂停，之后标记为“等机器空闲时再做”。全量只做估算，等待用户决定；不全量建库，也不删除、清理、移动任何原始媒体。

要回答的问题

  1. 按画面变化选帧并无损保存，三段录像的帧库有多大、建库要多久？
  2. 能否保证帧库里的每一张图与原始解码帧逐像素相同，并能准确追溯来源时间？
  3. 已有实验引用过的帧，会不会在去重时被悄悄丢掉？
  4. 按这三段的比例推算，全量建库大概需要多少空间和时间？

数据与来源

只选三段录像：

  • 10 月 9 日 08:38 的一段录像；
  • 一段 01:11 的剪辑；
  • 一段已登记为开发集的 9 月 29 日 22:15 长录像（现有场景扫描约 42 分钟）。

冻结的测试来源只用文件大小做估算，不打开、不探测内容。

方法（计划）

  1. 选帧。 界面 / 文字类场景按稳定的每秒 5 帧缩略图、10×10 格中变化 >8 保留；战场画面每 2 秒固定取一帧，再加变化 >16 的帧。扫描中不稳定的界面画面和清晰度 <20 的画面记为过渡 / 模糊候选；原生图近乎全黑或极度模糊的另外拒绝并记录原因。
  2. 保护已有引用。 旧实验标签引用过的帧强制加入计划，不能被去重悄悄丢掉；质量不合格的也列出原因。另一个脚本只读已知实验帧清单和标签元数据，筛出属于这三段的引用，记录实际读取范围和找不到的元数据文件。旧文件名里的毫秒只算“候选时间匹配”，不能说旧图片与新帧像素相同。
  3. 无损编码与核对。 CPU 精确抽帧，四个工作线程编码为无损 WebP（源图 2560×1440）。每张图编码后解码回来，逐像素与原帧相等才保存；后续完整性检查再解码一遍。不使用图片哈希或哈希命名。
  4. 清单。 每段录像一份清单，记录：录像原名、项目内相对路径、源文件字节数和修改时间、整段的日期 / 划分 / 分组、每帧请求的毫秒和实际原生时间戳、场景、选入理由、编码、尺寸、占用、像素是否相等、失败原因和运行耗时。文件名保留毫秒。源文件大小和修改时间不是内容校验摘要。已存在的不同帧不覆盖；重复运行只补未完成的帧。
  5. 全量估算。 只对登记的媒体文件取文件大小，同一文件系统对象去重（排除别名和历史目录链接造成的重复），不计算内容哈希。给出按三段的字节比例和每 GiB 耗时推算的范围，不把小试点当作全局容量保证。

设置

计划使用项目的视觉理解 Python 环境，通过限制在 8 个 CPU 核上的包装器运行；不安装新依赖。

结果

已经完成的只有：工具代码和 7 项专项测试通过（包括 WebP 逐像素相等、变化去重、固定间隔、原生相邻帧与旧毫秒候选的区分）。没有生成选帧计划、帧库，也没有实际的空间与耗时估算。

失败与负结果

没有运行，因此没有实验结果意义上的失败。已知缺口：已知标签元数据的核对不能证明覆盖了所有动态或未知格式的引用。

局限

  • 三段录像的比例不一定能代表全部录像。
  • 文件大小和修改时间只能识别文件，不能证明内容未变。

结论与下一步

本实验交付的是帧库格式和工具。下一步是在机器空闲时运行三段试点，得到真实的帧数、空间和耗时，再按比例估算全量，由用户决定是否全量建库以及之后如何处理原始录像。