视频描述与机器人动作对齐

一段巡逻视频生成了这样的描述：“机器人看到行人后减速停车。”你按描述检索到片段，又在同一段日志里找到速度下降，于是准备把它收进“遇人减速”的正样本。

这一步很容易做得过快。视频里的“之后”可能来自模型对画面的解释；日志中的时间可能是消息被记录的时间；检索到的描述还可能只覆盖长片段中的一个窗口。三个看起来相邻的事实，未必指向同一次动作。

可以先问一个更容易核查的问题：这条描述究竟对应源视频的哪些帧，这些帧又对应机器人哪一段采集时间？ 回答清楚后，才有条件讨论速度是否下降、谁触发了动作，以及证据能支持多强的事件标签。

下面以 Cosmos Curator v2.2.0 的固定源码为依据，沿一条候选事件走完这段追溯。示例数字都是为解释机制构造的，不来自实车、模型推理或已跑通的数据流水线。最后得到的是一条能够回查、也允许暂不下结论的视频事件记录。

一条描述，至少涉及三种时间坐标

Curator 的 Clip 保存源视频标识和 span。源码对 span 的定义很明确：它是片段在原始源视频上的秒数范围。Window 则用 start_frame、end_frame 表示片段内部的原生帧索引。窗口还有自己的模型描述。这里的“第十帧”，既不是原始长视频的第十帧，也不是机器人启动后的第十个采样点。¹

假设原始录像中的第 10 到 20 秒被切成一个 Clip，再拆成两个描述窗口。第一条 Caption 不能直接继承整个 10 到 20 秒范围。这样做会把第二个窗口中的动作也挂到第一条描述下面：行人在前半段出现，机器人在后半段因导航目标到达而停止，最后却被拼成了“因行人停车”。

即使已经定位到源视频第 14 秒，离机器人日志还有一步。视频的媒体时间说明画面在文件中的位置，未天然包含它与机器人采集时钟的对应关系。文件创建时间、编码开始时间、上传时间，都不能未经验证就当成摄像头第一帧的采集时间。

因此，一条候选事件要保留三段关系：描述对应哪个窗口；窗口对应源视频哪个位置；该位置如何映射到机器人日志使用的时钟。robot_id、session_id 和 sensor_id 可以防止把别的机器人、别次运行、别路相机拼进来，却不会替我们建立第三段关系。同一会话里，两台设备的时钟仍可能不同。

实际落库时，也不能只存一条 Caption 和两个含糊的时间戳。至少要能回查源视频身份、片段范围、窗口帧范围，以及这些值采用的单位和坐标系。源文件还应绑定稳定的版本或内容校验值；同名视频被重新编码后，旧的帧索引关系不能直接套用。

源码能把窗口映射回视频，但结果带着前提

在固定版本的 windowing_utils.py 中，frame_index_to_source_time_s 将帧索引线性映射到源视频时间。保留原变量名的关键计算如下：²

span_s = max(clip_span[1] - clip_span[0], 0.0)
denom = max(native_frame_count - 1, 1)
return clip_span[0] + (frame_index / denom) * span_s

设片段范围为 10 到 20 秒，原生帧数为 20，第一窗口的帧索引是 0 到 9。按这段实现，它的末帧映射到 10 + 9 / 19 × 10，约为 14.7368 秒；第二窗口从第 10 帧开始，对应约 15.2632 秒。官方测试也明确检查了这个计算。这里用低帧数只是为了方便看清分母，并不代表真实录像参数。³

两个窗口的映射结果之间出现间距，不能直接判定丢了半秒视频：这些值是首末帧对应的估计时刻，窗口帧索引采用包含末帧的约定。把它们当成连续时间区间的无缝边界，已经换了一种含义。业务层若要使用左闭右开区间，需要另行确定末帧持续时间和边界规则，不能机械给末端加一个固定帧周期。

更隐蔽的风险来自总帧数。estimate_native_frame_count 在窗口列表非空时，用最大 end_frame 加一恢复总帧数。源码同时写明：如果只剩窗口子集，估计可能偏小，映射也会变成近似。假设我们先删掉第二个窗口，只留下 0 到 9，再拿这个不完整列表恢复帧数，得到的 N 就从 20 变成 10。第 9 帧此时会被映射到 20 秒，比先前晚了约 5.2632 秒。

这不是说正常完整窗口路径必然算错，而是提醒下游：筛选后的窗口集合，不能无条件充当原始帧数的来源。 如果业务只保存命中检索的窗口，就要同时保留完整上下文中的帧数或已确定的映射结果，以及计算方式和版本。否则同一条描述在筛选前后可能得到不同时间。

这组帮助函数也没有逐帧读取采集时间。其假设是原生帧连续且在片段跨度上均匀分布。对于变帧率、丢帧或经过剪辑的媒体，应进一步核对解码帧的呈现时间 PTS 和源数据映射。PTS 仍然是媒体坐标，不是设备采集时钟；拿到了更细的媒体位置，也不能省掉跨时钟校准。

源码还提供 window.source_start_s、window.source_end_s 等 trace 属性，适合排查一个描述窗口来自哪里。这些是跟踪属性，不能据此声称所有最终输出文件都自带机器人时间戳，更不能把观测链路中的估算直接升级为精确的训练标签。²

统一成纳秒之前，先确认时间记录的是什么

ROS 的 sensor_msgs/Image 定义要求 Header 时间戳应为图像采集时间；MCAP 则分别定义消息的记录时间 log_time 和发布时间 publish_time，并规定发布时间不可用时填记录时间。这几种含义并不相同。消息载荷内部的传感器时间还需要按其 schema 单独解释。⁴⁵

这个差别会直接改变事件顺序。构造一个例子：相机画面实际采集于公共时钟的 100.000 秒，图像消息到 100.120 秒才被记录；一条制动命令的采样或发送时间是 100.050 秒。若拿记录时间与命令时间比较，看上去命令早于画面 70 毫秒；若采集时钟关系可靠，画面其实早于命令 50 毫秒。两次比较使用了不同的事件定义。

这里没有一个适用于所有系统的“永远选 Header”规则。Header 是否真的按采集时间填充、是否中途重置、不同设备是否同步，必须由采集链路证据确认。ROS 消息定义表达的是约定，不是对某个设备驱动的验收证明。发布时间等于记录时间，也可能只是缺失值回退，不能反过来推断发布没有延迟。

在关系尚未建立时，最有价值的动作往往是保留原始时间及其来源，而不是覆盖成一个看似统一的整数。业务记录可以同时保留媒体位置、采集时间、记录时间、时钟域和映射版本；明确哪一个用于事件比较，其余值用于排查传输和记录延迟。

对于确认可用线性关系描述的一段采集，业务层可以采用 t_common = a × t_sensor + b：偏移量 b 对齐起点，比例 a 描述这一段内的时钟速率差。它是可选的工程模型，不是 Curator 提供的跨设备校时功能。参数必须来自同步机制或可靠锚点，并记录适用区间和拟合残差；设备重启、时钟跳变后应重新分段。只用一个起点，无法观察后续漂移。

即便都转换成纳秒，精度也不会自动提高。假设映射的保守误差边界达到 80 毫秒，而两事件名义上只差 50 毫秒，就不宜断言谁先谁后。若这里的 80 毫秒只是平均残差而非经过验证的误差上界，连这种保守判断也要继续收紧。存储单位、显示小数位和实测时间精度是三回事。

在同一段时间里找到了日志，还不能直接写“因为”

时间关联解决的是“哪些证据值得一起看”。它不会自动补足事件的语义。对“机器人因行人出现而减速”这条候选，至少有三类需要分别核对的观察：画面是否真的出现相关行人；状态流是否显示速度下降；控制或规划记录是否支持两者之间的触发关系。

模型描述适合缩小检索范围。即便一次 Caption 调用完成且返回了文字，也不能据此证明其中的因果解释正确。速度指令降低只说明系统发出了目标变化，不能代替实测速度；实测速度下降也可能来自转弯、坡度、导航终点或其他约束。只有速度日志而没有触发原因时，可以记录两者在时间上相邻，不应把“因行人”写成已经证实的标签。

窗口级描述还有一个尺度限制。一句话覆盖数秒视频，不代表模型给出了行人进入画面的准确起始帧。应先回看相关帧或使用经过验证的定位结果，确定观察范围；之后再查询相邻日志。不能拿整个描述窗口的起点，充当其中每个动作的发生时刻。

关联前还应检查候选时间段内的日志覆盖。若摄像头窗口完整，但速度消息在关键位置中断，最近的一条旧速度不能被无限延用。对连续状态，是否插值、允许多大的采样间隔，要按该信号和采集条件决定；对离散命令和状态切换，则应保留实际事件及其有效语义，不能把两个状态编号做数值平均。

相同的限制也作用在负样本上。没有检索到“行人”不等于现场没有行人；没有找到减速记录，也可能只是时钟映射缺失或日志断档。正负标签都需要证据覆盖，证据不足时允许样本保留为待核查候选。这个状态没有浪费数据：后续补齐同步或状态流后，仍可重算判断，而不用猜测当时为什么被判为负例。

让一条事件记录能够被重新计算

可以从前面的候选出发，建立一条业务层事件记录。它不必一次容纳所有机器人数据，但必须同时能回答“这段画面在哪里”“时间怎样来的”“结论依据是什么”。下面是字段建议，不是 Curator 官方输出 schema，也不是已经填好的真实样本。

不建议用一个模糊的“置信度 0.9”代替这些关系。时间映射可靠、模型描述可信、状态覆盖完整，是不同问题；将它们压成一个分数，后续就难以判断究竟该重跑模型、补日志，还是重新校时。

为了减少首轮工作量，可以只选同一次采集中的一段短录像、一条速度状态流和一条相关控制流。把源帧、时间映射、日志定位和观察结论逐项填实，再决定是否扩展到更多传感器。暂时不需要设计完整训练数据平台，先让另一个人能沿记录复核一次判断。

这条记录也应允许局部重算。替换 Caption 模型时，可以保留原始视频和时间依据，重建语义候选；更新校时参数时，应重新查询日志并复核动作结论，不必自动把原视频描述当成错误。如果源视频被重新转码、剪辑或替换，则需重新检查帧与媒体时间的对应，不能只更新文件路径。

验收时，主动找出不能成立的样本

最容易发现关联问题的办法，是针对一条候选保留反例。除了看上去合理的样本，还应检查三个方向：移除后半段窗口后能否仍恢复原来的媒体位置；设备重启前后的数据是否被错误地套用同一映射；日志关键段缺失时，事件是否仍被强行判为正例。

这些检查可以先用明确标注的构造数据完成。本篇已对固定源码中的线性映射公式做了局部算术核验：完整 N=20 时第9帧为14.7368秒，只剩首窗口并重估为N=10时为20秒。它证明的是这个输入变化对计算的影响，没有执行视频解码、模型描述、设备同步或真实日志关联，也不能据此宣布整个系统已验收。

真实采集的验收还要回到原始画面和日志：所用锚点能否回查；误差是否小于要区分的事件间隔；速度与命令的定义是否明确；缺失或矛盾证据能否阻止自动下结论。若两段时间范围在不确定性下重叠，就保留顺序未定；若原因证据不足，就记录观察到的现象。不要为了让每条样本都有完整故事而填补空白。

一条可以追溯的事件样本，价值不只在于它写下了“机器人减速”。更重要的是，下一次换模型、改校时或补日志时，我们还能知道该重算哪一段关系，以及哪些判断从来没有被证实。Cosmos Curator 提供视频侧的片段和描述处理能力；把它们接到机器人数据里，关键在于把媒体位置、采集时钟和事件依据逐一接实。

Footnotes

1. NVIDIA Cosmos Curator v2.2.0，固定提交 de89c5e4，Clip 与 Window 定义：data_model.py。 ↩

2. 同一固定提交中的窗口总帧数估计、线性时间映射及 trace 属性：windowing_utils.py。 ↩ ↩²

3. 同一固定提交的官方测试：test_windowing_utils.py。本篇另做无模型依赖的局部算术核验，不将官方测试文件的存在当作本地完整测试通过。 ↩

4. ROS 2 官方消息定义：sensor_msgs/Image。本文于2026年9月22日归档，Header采集时间约定不等于某个设备驱动已满足约定。 ↩

5. MCAP 官方格式规范的 Message 字段定义，记录时间与发布时间分别定义，后者缺失时回退前者。本文于2026年9月22日核对并归档官方仓库原文。 ↩