时码里的分号到底说明什么

因为当前两处“接近 29.97”的容差分别是 0.013 和 0.02。处在边缘的数值可能落入不同分支，因此接收方应核对实际文件和素材。

时码末段从冒号变成分号，通常是在提示“这串时码按丢帧记号显示”。它解决的是某些分数帧率下，帧计数与人类时钟长期偏离的问题。但接收交付文件时，分号只能当提示，不能单独证明帧位已经按丢帧规则换算。显示记号和计数算法必须分开核对。

分号告诉你“这串字想表达丢帧写法”，不自动告诉你“这串帧位已经按丢帧规则算过”。

为什么会有丢帧计数写法

像 29.97 这样的分数帧率，每秒实际推进的帧数和用整数 30 做时码编号时的节奏并不完全相同。如果一直按连续整数帧号显示而不做补偿，时码读数会逐渐落后于墙上时钟。

按公式推算，29.97 这种连续计数每天会累计到约一分半的量级。因此，丢帧计数的做法不是把视频帧真的扔掉，而是在时码编号里按规则跳过某些编号，让显示时钟与实际经过时间重新靠拢。

常见文本约定会把末段分隔符写成分号，例如 01:00:00;00。这个符号很有用，因为接收方一眼就能知道文件正在表达一种丢帧记号。但符号仍然只是字符串的一部分。

真正的丢帧计算需要在帧编号与时分秒帧之间转换时执行跳号规则。单纯把最后一个 : 换成 ;，只改变了外观，没有改变原来那一串数字代表的帧位置。

SlateX 当前交付路径里，这两种行为都存在。缺少结束位置、需要软件根据入点和时长计算出点时，会走实际的丢帧算术。已经存在的入点或出点字符串，则只把末段分隔符改成分号，不做任何帧位换算。

这就是本篇的硬边界：看到 ;，可以知道交付层把这条字符串标成了丢帧写法；但仅靠这个符号，不能判断这串数字此前是不是用丢帧规则得到的。

实时侧把相机标称率折算成基准率时用的容差是 0.013，导出侧按数值判定是否丢帧时用的容差是 0.02 —— 两处判定的对象不同，容差也不是同一个数。这意味着位于边缘的帧率值，在两处逻辑里可能得到不同分类。

这类差异不应该被包装成接收方无需关心的实现细节。只要它会改变时码采用什么显示或计算路径，就应该在验收时把文件里的实际 FPS、时码字符串和素材放到一起核对。

同样，不能把“数值接近某个常见帧率”直接等同于整条链路已经采用相同计数规则。判断入口不同，结论就可能不同。

接收方要验证的是一条真实素材如何对上时码，而不是只验证分隔符长什么样。

SlateX 的实时链当前输出全冒号时码，不产生分号表示。也就是说，App 屏幕上现场看到的实时字符串，与交付文件里可能出现的分号，是两套不同阶段的表示规则。

实时链在分数帧率下按分数值推进计数，再用整数帧率把帧数换成字符串；它本身没有丢帧跳号表示。因此，不能因为交付文件后来出现分号，就倒推现场实时显示已经按相同规则工作。

接收时应把这两层分开：现场记录的原始字符串来自哪里，交付时有没有重新计算，分隔符是否只是被替换，最终素材对点是否成立。缺一项，都不应把分号当成验收结论。

先看该行 FPS 是否与素材和现场记录一致，再选一条可定位的素材，对照实际入点和经过时长。若文件里的结束位置是软件计算出来的，还要单独确认它是否走了相应的计数规则。

如果入点或出点是既有字符串，就不要只看它是否带分号。接收方应验证帧位本身能不能对上素材。只换符号的字符串，在视觉上可以很像正确的丢帧时码，但它的数字仍可能来自另一种计数方式。

因此，分号适合当作“这里需要检查丢帧口径”的提示，不适合当作“这条已经验证完”的标签。

不能。分号可以只是显示层的记号。当前交付路径对已有时码字符串可能只替换末段分隔符，不重新计算帧位。

不是这里讨论的含义。丢帧计数调整的是时码编号规则，用来补偿分数帧率下连续编号与墙上时钟的长期偏差。

因为当前两处“接近 29.97”的容差分别是 0.013 和 0.02。处在边缘的数值可能落入不同分支，因此接收方应核对实际文件和素材。

当前实时链输出全冒号字符串，不产生分号表示。交付文件里的分号属于另一阶段的表示，不能反推实时链也采用了同样的丢帧计数。

上海智独教育科技有限公司 — SlateX。以上数字截至 2026-09-24。