NDI timecode 和 timestamp 能直接相减当延迟吗

NDI的timecode与timestamp虽都以100纳秒为单位，也不能无条件相减。timecode可能是发送应用自定义的时间标记，timestamp有明确的SDK提交时间语义；只有确认纪元、时钟来源和同域可比性，差值才有解释基础。单位相同并不代表是同一把时钟。

先固定输入与适用条件

输入应保留两个原始整数值、字段是否为合成标记、发送与接收时钟信息。这里不做跨机对时，也不读取现场日志；三组例子分别表示同域UTC、自定义节目位置与未知时钟。发送SDK的提交时间到接收应用记录点之间还包含处理与排队，不能简单命名为纯网络传播时间。

本篇按NDI官方滚动SDK文档解释视频v2或音频v3帧描述。文档核对日期为2026-10-24；这不是本地已安装NDI运行库的版本声明，设备与第三方软件需另录版本。

按字段与边界执行

1. 先给每个字段填写时间域与纪元。自定义节目时码可以从零开始，UTC时间通常以Unix纪元计数，二者均使用100纳秒也不能相减。

2. 将100纳秒整数转换为秒时保留原值，避免大整数先转浮点后丢精度。日志展示可以缩短小数，但计算应使用整数或有理数。

3. 只对确认同域、同纪元且时钟条件已知的两个采样点计算间隔；未知域直接输出不可比较，不用一个貌似合理的毫秒数填补证据空白。

4. 现场若需要延迟指标，明确起点、终点、时钟校准误差与调用位置。应区分应用观察间隔、编码延迟、网络延迟及最终出画延迟。

用具体样例核对结果

合成UTC案例让接收记录比SDK提交晚250000个单位，算得25毫秒；自定义timecode=12000000表示节目内1.2秒，与UTC timestamp不在同一域，脚本拒绝计算。第三组只知道整数不知道时钟，输出原因而不是零。25毫秒是本例定义的两个采样点差，不是一次真实NDI测量。

通过条件是原始整数未损失、每次计算都带时间域说明、不可比较案例被明确拒绝。即使两台机器都使用UTC，也不能因此假定已高精度锁定；校时误差会进入结果。若差值为负，先检查时钟域、跳变和记录点，不要自动取绝对值把异常变成正延迟。以timecode是否递增判断内容位置时，也需确认应用有没有自定义重置规则。

下载与复现

analyze.py、input.json、result.json。

附件将时钟域作为显式字段，analyze输出可比性、差值或拒绝理由。现场交接除了整数，还要附采样位置和时间源配置；没有这些上下文，仅发两列时间戳无法形成可靠的延迟结论。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看Ping 延迟很低但控制很慢，怎样拆开连接与应用应答耗时。相关流程收在多媒体播放专题；需要项目对接时，带上本文输入及结果向SoftPlayer核对实际能力。

• timecode与timestamp定义和100ns单位。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。