延迟测量：端到端延迟测量方法、时间戳对齐、NTP同步

聊完延迟的构成，咱们得面对一个更实际的问题：怎么量？

你优化了半天，总得有个尺子吧。我见过不少团队，上来就调编码参数、换传输协议，折腾一圈发现延迟根本没变——因为连测量方法都是错的。这一章，咱们就把尺子做出来。

端到端延迟测量：最直观的“黑盒”方法

端到端延迟，说白了就是从摄像头采集到观众屏幕显示的总耗时。我习惯把它叫做“黑盒测量”——你不需要关心中间链路，只看输入和输出。

方法一：时钟法（最常用）

在推流端放一个数字时钟（用手机秒表就行），在播放端录屏。然后对比两边的画面，算时间差。

操作步骤：
1. 推流端打开秒表，记录起始时间 T1
2. 播放端开始录屏，持续 10-15 秒
3. 逐帧分析录屏，找到推流端秒表显示 T1 的那一帧
4. 该帧的播放时间戳记为 T2
5. 端到端延迟 = T2 - T1

方法二：打点法（更精确）

在视频画面中嵌入一个 LED 灯或二维码，灯亮瞬间记录时间。播放端检测到灯亮，再记录时间。这个方法能精确到帧级别。

时间戳对齐：为什么你的延迟数据是“假的”？

端到端测量只是第一步。真正让工程师头疼的，是时间戳对齐。

你想想看，推流端说“我在 10:00:00.000 发了这帧”，播放端说“我在 10:00:00.300 收到了”。这两个时间戳能直接减吗？

不能。因为两台设备的系统时间可能差了 5 秒。

RTP 时间戳 vs. NTP 时间戳

在流媒体协议里，时间戳分两种：

• RTP 时间戳：基于采样时钟，只表示相对顺序。比如 44100Hz 的音频，每帧增加 441 个 tick。它不表示绝对时间。
• NTP 时间戳：基于网络时间协议，表示绝对时间。SR（Sender Report）包里会携带 RTP 时间戳和 NTP 时间戳的映射关系。

我刚开始做直播时，犯过一个低级错误：直接用 RTP 时间戳算延迟。结果发现延迟是负的——因为推流端和播放端的采样时钟不同步。

对齐步骤

1. 从 RTCP SR 包中提取 NTP 时间戳和对应的 RTP 时间戳
2. 计算 RTP 时间戳到 NTP 时间戳的转换系数
3. 将播放端的 RTP 时间戳转换为 NTP 时间
4. 与推流端的 NTP 时间做差，得到真实延迟

// 伪代码示例
struct SenderReport {
    uint64_t ntp_timestamp;  // NTP 时间戳
    uint32_t rtp_timestamp;  // 对应的 RTP 时间戳
};

double calculate_delay(SenderReport sr, uint32_t current_rtp, uint32_t clock_rate) {
    double ntp_of_current = sr.ntp_timestamp + 
        (double)(current_rtp - sr.rtp_timestamp) / clock_rate;
    return ntp_of_current - sr.ntp_timestamp;
}

NTP 同步：让所有设备用同一个“时钟”

时间戳对齐的前提，是所有设备的系统时间一致。NTP 就是干这个的。

NTP 的工作原理

NTP 采用客户端-服务器模式。客户端向服务器发送请求，记录发送时间 t1；服务器收到后记录接收时间 t2，然后回复，记录发送时间 t3；客户端收到回复，记录接收时间 t4。

网络延迟 = (t4 - t1) - (t3 - t2)
时间偏移 = ((t2 - t1) + (t3 - t4)) / 2

嗯，这里要注意：NTP 假设网络延迟是对称的。但在实际网络中，上行和下行延迟往往不一样。所以 NTP 的精度通常在 1-10ms 级别，对于大部分直播场景够用了。

生产环境中的 NTP 部署

本章知识体系

下面这张图，把延迟测量的核心逻辑串起来了。你可以把它当作一个检查清单：

延迟测量这件事，说难不难，说简单也不简单。关键是方法要对、时钟要准、数据要全。我见过太多人拿着错误的延迟数据去优化，结果越优化越糟糕。所以，先把尺子校准了，再谈优化。