同一个帧率为什么要有计数率和显示基数

同一个帧率选项在这里同时带着两个数，但它们承担的工作不同。一个是推进墙上时钟到帧数时使用的计数率，可以带小数；另一个是时码字符串与帧数互相换算时使用的整数显示基数。

看见 29.97 却按 30 格去写时码，不是把两个帧率混在一起，而是计数率与显示基数在做两件不同的事。

为什么一档帧率要保留两套数

以 29.97 这类档位为例，计数率负责回答“墙上时钟过了这么久，应推进多少帧”，显示基数负责回答“这些帧应怎样切成时、分、秒、帧的字符串”。前者允许小数，是走时的尺度；后者必须是整数，是时码帧位的分组基数。把两者混成一个数，就会把走时速度和字符串编号规则误当成同一件事。

23.976 也是同样的结构：推进时使用带小数的计数率，字符串换算时使用整数显示基数。24、25、30 这类整数档则没有这层差异，因为计数率与显示基数相同。这里讨论的重点不是哪个数更“真”，而是两套数各自服务于不同计算。

两个数不一致会怎样累积成时间差

这些非整数档的计数率比显示基数慢大约千分之一，因此时码编号的节奏与墙上时钟的推进速度并不相同。29.97 配 30、23.976 配 24 时，字符串仍按整数显示基数分组，但实际推进使用较慢的计数率。结果不是偶尔少一个编号，而是同样的差持续累积。

在这种口径下，时码相对墙上时钟会越走越慢，量级是每小时秒级。按这个速率折算，每小时约慢 3.6 秒；把同一速率乘到 24 小时是 86.4 秒，也就是一分半这一档。这个差不能用“看起来接近”来抹掉，因为它正来自两套数的职责分离。

非整数档的关键不是小数长得像整数，而是计数率决定推进速度、显示基数决定编号结构，两者的差会随时间累积。

机位记录里的帧率怎样折回基准率

当某台机位上记录的帧率是一个高于基准的升格值时，折算逻辑会按除数逐个尝试，把结果与可用的基准率比较。落进极小容差的首个候选就作为基准率；如果没有候选命中，则回退到 24。这里使用小容差，是为了让接近的升格数值可以落回对应基准，又不把相邻的正常档混在一起。

例如 24 与 23.976 相差 0.024，所以容差必须比这段距离更小，才能让 24 保持为 24，而不是被吸到 23.976。升格素材按基准率计数是行业里常见的处理方式，但这不等于它是接收方必须采用的单一路径。接收方仍应根据实际交件与自己的媒体记录核对帧率标签。

为什么这种实时计数仍然是 NDF

在非整数档的实时链里，帧号连续递增，不通过跳过某些帧号来追回墙上时钟，因此这里属于非丢帧计数，也就是 NDF。NDF 说的是实时链怎样编号，不是在宣告端到端的交付链具有同一种显示规则。把“不跳号”理解成“时码会追上墙上时钟”正好相反：前面的累积差仍然存在。

导出侧另有自己的丢帧显示裁定，而且这种分号写法目前只出现在 ALE 与 CSV 的时码列上（日报 PDF 的表体没有时码列），所以实时链与导出侧的口径并不一致。这里不能据此说应用具有贯穿现场到交付的丢帧时码能力，也不能把时码写成与墙上时钟同步。关于交件中分号的含义，应另看《时码里的分号到底说明什么》，而不是从实时 NDF 直接反推导出结果。

交付时为什么还要看标签与分隔符

帧率标签告诉接收方这一行交件声称采用什么速率，时码分隔符则反映导出侧采用了什么显示写法。这两个信息都不能替代对源记录的核验，尤其在实时链与导出侧裁定并不统一的情况下。需要追一列值从哪里来时，可以结合《ALE 每一列的值从哪里来》逐列核对，而不是只看时码长得是否熟悉。

因此，接收方应自行核对交件里的帧率标签与时码分隔符，并把它们与现场记录、媒体侧信息放在一起判断。计数率负责推进、显示基数负责字符串换算、导出侧再决定显示形式，这三层不要互相代替。只要把层次分开，29.97 与 30 同时出现就不再是自相矛盾的两个答案。

FAQ

29.97 为什么还会看到 30 这个数？

29.97 是计数率，30 是显示基数，它们分别用于推进帧数和拆分时码字符串。两者同时出现是计算分工，不表示把一个档位临时改成了另一个档位。

23.976 也使用同样的双数结构吗？

是，23.976 用带小数的计数率推进，时码字符串换算使用整数显示基数。计数率比显示基数慢大约千分之一，因此时码相对墙上时钟会逐渐变慢。

实时链的 NDF 是否表示导出也按 NDF 写？

不能这样推出。实时链是不跳帧号的 NDF 计数，而导出侧另有丢帧显示裁定，端到端口径并不一致。

接收方最后应核对什么？

接收方应自行核对交件中的帧率标签和时码分隔符，并与现场记录及媒体信息对照。仅凭某个数字或某种分隔符，不能把整条链路当作已经验证。

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