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

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

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

为什么会有丢帧计数写法

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

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

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

显示记号和帧位换算是两件事

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

SlateX 交付件里，这两种写法各占一类格子。已经记着的入点或出点字符串分两路：录制链现采的读数会按丢帧规则重渲成一枚合法的 DF 地址——只换分号会造出 ;00、;01 这种 SMPTE 里不存在的号；场记照机器屏或板子手抄的读数逐字不动，只把末段分隔符改成分号。来源位缺失时不猜，数字一律不动，缺章由收工差异表 TC_SOURCE_UNDECLARED 点名。Duration 是起止两枚读数之间的帧精确跨度（不含尾帧），声明过 DF 的行里那一格写成分号形。

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

接近 29.97 不等于声明了丢帧

一个接近 29.97 的帧率值，不能仅凭数值就认定整条链路采用同一种计数规则。处在边界上的值尤其如此：屏幕上的显示与交付文件里的写法可能落到不同分类。你能核对的是文件里那一格最后写了什么，以及这一行的实际 FPS、时码字符串和素材能否互相对上。

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

App 实时显示与交付文件不是同一套表示

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

不能因为交付文件后来出现分号，就倒推现场屏幕当时也按相同规则显示。

接收时应把这两层分开：现场屏幕上读到的是哪一种字符串，交付文件里写的是哪一种，分隔符是否只是被替换，最终素材对点是否成立。缺一项，都不应把分号当成验收结论。

怎么实际核对一条带分号的时码

先看该行 FPS 是否与素材和现场记录一致，再选一条可定位的素材，对照实际入点和经过时长。出点是抄进来的读数，那一格要核的是“有没有被抄过”；Duration 才是算出来的跨度，核它要回到起止两枚读数和它们被读时所用的计数规则。

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

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

FAQ

时码末段是分号，就能确认它按丢帧规则算过吗？

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

丢帧是不是把实际视频帧删掉了？

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

为什么同一个帧率值可能得到不同结果？

因为屏幕上的显示与交付文件里的写法分属两个阶段。处在边缘的数值可能落到不同结果，所以接收方应核对实际文件与素材。

App 屏幕上的实时时码也会用分号吗？

App 屏幕上显示的实时时码是全冒号字符串。交付文件里的分号属于另一阶段的表示，不能反推现场屏幕也采用了同样的丢帧计数。

上海智独教育科技有限公司 — SlateX