[Bug]: MiMo-V2.6 video timestamps ignore real frame times (every clip is labelled 00:00–00:30)

快速结论：该问题通常出现在用 vLLM 运行 MiMo-V2.6 并输入视频时：多模态数据解析器把每一帧都按 1 fps 处理，导致视频时间戳全部落在 00:00–00:30，而不是真实帧时间。优先排查 MiMo 数据解析器是否保留了视频加载器元数据（frames_indices / fps）。

适用环境：Ubuntu 24.04.3 LTS（aarch64），Python 3.12.3，PyTorch 2.13.0+cu130，CUDA 13.0，GPU 为 NVIDIA GB10，NVIDIA 驱动 580.178.04；报告中未确认 vLLM 版本号。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的 diff 是把 MiMo 数据解析器改为 video_needs_metadata=True，并通过 frames_indices / fps 计算帧时间戳；该改动仅报告为在旧构建上验证过，合并到 main 后的版本只做过 ruff format 和辅助函数单测，尚未在 main 上实际跑通。

注意事项：该 diff 是社区用户提供的参考补丁，不是 Issue 中已合并或已验证的官方修复；它依赖上游 #64477 解决 second_per_grid_ts 被转成 bf16 的问题，否则长视频中重建出的提示标签可能仍有约 1 秒偏差。

问题场景

用户在 vLLM 中加载 MiMo-V2.6 模型并传入视频输入进行推理。视频被采样成约 32 帧后交给 MiMoVLProcessor 处理，但生成的多模态提示中每个视频块的时间标签都使用固定 1 fps 间隔，因此所有片段都被标成 00:00–00:30，忽略了视频真实的帧时间和采样间隔。

报错原文

[Bug]: MiMo-V2.6 video timestamps ignore real frame times (every clip is labelled 00:00–00:30)

原因分析

可能原因：MiMo 的输入处理器 _INPUT_FPS 默认为 1.0，时间戳直接用 torch.arange(T) / _INPUT_FPS 生成，即假设每帧相隔 1 秒。视频加载器实际按均匀间隔采样，并在元数据中带有 frames_indices 和 fps，但数据解析器没有把这份元数据传下来，所以无法根据真实帧索引和帧率计算媒体时间。

环境排查

确认 vLLM 版本（Issue 未记录，社区补丁基于 main 的 d3fb7166e0 附近，并在 0.1.dev20051 上做过等效验证）。
确认 Python 3.12.3、PyTorch 2.13.0+cu130、CUDA 13.0 与 NVIDIA 驱动 580.178.04。
确认 GPU 平台为 NVIDIA GB10（aarch64），与 Issue 环境一致。
确认输入的 MiMo-V2.6 视频是否经过 vLLM 视频加载器采样并带有 frames_indices、fps 元数据。
确认多模态解析是否启用了 video_needs_metadata，以及前后的时间标签是否仍为固定 30 秒。

解决步骤

先用复现用的 150 秒视频在处理器层打印提示文本，检查每个前的时间标签，确认是否仍为 00:00–00:30 的固定模式。
在 MiMo 数据解析器构造处加入 video_needs_metadata=True，让加载器的视频元数据能传递到 MiMoVLProcessor。
在输入处理器读取视频时，识别 (video, metadata) 二元组，取出 metadata 中的 frames_indices 和 fps。
新增时间戳计算逻辑：以 indices[0] / fps 为起点，以 (indices[-1] - indices[0]) / fps / (num_frames - 1) 为步长，均匀生成每帧的媒体时间；当元数据缺失或不合法时，回退到原来的 1 fps 时间戳。
保持 profiling dummy 使用 1 fps 元数据，避免改变显存 profiling 结果。
在目标 vLLM 构建和 main 分支上实际跑通后再上线；Issue 中的补丁仅做过格式检查和辅助函数单测。

验证方法

用 25 fps 和 29.97 fps、时长 7–194 秒的多个视频重新推理，检查每个视频块的时间标签是否与该块第一帧的真实媒体时间一致；同时确认像素输入和 token 数量与修改前一致。还要检查长视频场景下时间标签的偏差是否仍在可接受范围内，因为 second_per_grid_ts 的 bf16 转换问题尚未解决。