Phase 1：视频预标注管线里的两套帧率

Phase-1 概览里点过一个决定——管线里有两个互相独立的 fps 旋钮，老被混在一起。概览说别混。这里说为啥。

两个旋钮各是啥

推理帧率：MediaPipe / YOLO 多久跑一次。默认是视频原生 fps。--inference-fps N 编译成一个传给 MediaPipe 迭代器和 YOLO vid_stride 的步长。

review 帧采样：Project B / C 里标注员最终会打开多少张 JPEG。跟推理完全独立。旋钮：--review-fps、或者按 project 分的 --review-hand-fps / --review-pose-fps、或者默认的四信号策略。

它们共享单位（帧每秒）和数据底层（同一个视频）。共享的就这些。

GPU 时间。一段 2 分钟、60 fps 原生的视频，每路 7200 帧推理。砍到 30 fps 推理 → 3600 帧。一批几百段视频，省下的算力是真实的。

代价是逐帧的运动信号。动作分段依赖密集采样的手部运动学——角速度、位置差分、接触判定。推理砍到 1 fps，分段器读的就是每 60 帧一帧、空洞由线性插值补的稀疏信号。实测分段 F1 从原生 fps 的 ~72% 掉到接近噪声。

所以：降推理 fps 省 GPU，但下游运动相关的精度跟着掉。不是免费午餐。

人的时间。闭环里的瓶颈是标注员，不是模型。Project B 从每 episode 100 帧砍到 30 帧，整条最慢的环节直接快 3 倍。

代价是覆盖率。漏太多帧，稀有事件（一闪而过的抓取、滑落的物体）就进不了 review 集，模型也就没机会在它们上被纠正。四信号默认策略靠采段边界和低置信帧来对冲；纯均匀降采样不对冲。

都是视频上的「fps」旋钮。有人问「这条管线是几 fps 的？」答案本身就有歧义。然后人就抓一个旋钮，假设另一个跟着走。

常见的翻车模式：有人设 --inference-fps 5，以为这能给整条管线封顶。分段器饿死、review 帧从稀疏的预测 JSON 里采、下游一片狼藉。修复方法只有一个：「除非只是抽查一段，别动推理 fps」。

推理 fps 写进 metadata。每份预测 JSON 都该带着它是按几 fps 生成的。下游就能做一条 sanity check：「这个 episode 的预测是 1 fps 的、但分段器期望原生」——在分段器静默地输出垃圾之前先报警。
每 episode 的 review 帧数分布。如果四信号采样开始产出 200 帧的 episode，要么是置信阈值不对、要么是 bbox 跳变检测漂了。

把两个旋钮混在一起这事儿，只有犯过一次才看得见。两旋钮的框架是「别犯第二次」的廉价保险。