在讨论 IP 之前，我想提请您注意广播领域中使用的口型同步技术。这也是最棘手的问题之一，因为您不仅要保持非常准确的口型同步，而且还需要在电视网络的 24x7x365 全天候运行系统上做到这一点。

为了更深入地了解这一点，我建议阅读有关打包压缩音频/视频实际上是 MPEG2 -系统层的信息。请参阅：http: //downloads.bbc.co.uk/rd/pubs/reports/1996-02.pdf。第 8 节解释了时间同步方面。

本质上，每个编码器都会记录时间戳并将其标记在相应的音频视频上。稍后，当解码器播放它时，它会做两件事 - 第一，确保解码器自己的时钟被编码器的时钟“奴役”，第二，它确保每张图片都显示在屏幕上，并且音频帧在相应的时间准确地呈现给扬声器时间发生。这是音频与视频保持同步的唯一也是最好的方式。这些时间戳称为 PTS/DTS 值，其分辨率为 90 Khz 时钟。

现在这不是解决方案的结束。了解随着时间的推移时钟会出现偏差，但由于只引用了准确的时间，因此解码器播放完全按照相同的时间顺序。

现在主要的问题仍然是解码器的时钟需要保持在编码器时钟的控制/同步中。在 MPEG 中做的第一件事是在 27 MHz 处使用更高的精度（高 300 倍）。此外，这需要在中间的任何传输路径期间保持一致。（这称为时钟恢复过程）。

解释时间戳方案的详细论文在这里：MPEG-2 系统层的时间戳方案及其对接收器时钟恢复的影响 (1998)，作者：Christos Tryfonas、Anujan Varma、IEEE Transactions on Multimedia

这是另一篇被广泛引用的关于此作为一般理论的论文。 RP Singh、Sang-Hoon Lee、Chong-Kwoon Kim，“宽带分组网络中周期性流量的抖动和时钟恢复”，IEEE Trans。关于通讯，卷。42, No. 5, May 1994.或者这个A New Method for Clock Recovery in MPEG Decoders

现在来到 IP 网络

这里还有其他方面需要了解：

1. 带宽的不确定性要高得多（即使在相当好的网络上）。

2. 通常，系统同时为一个（单播）或更少（多播）用户提供服务，这与广播的更广泛假设不同。

3. 与 24x7 实时广播相比，整个系统只有有限的持续时间。

几乎所有的基本原则都是一样的。但是，很少做额外的事情。

1. 接收器需要保留一个明显更大的缓冲区。通常这是对 MPEG2 TS 案例中描述的缓冲区的补充。缓冲区越大，启动的延迟就越大，但内容用完的机会就越小。

2. 如果您按照上述操作，则时钟数据包到达的时间用于解码器的时钟同步。实际上，在基于 IP 的系统中，解码器时钟同步通常会被忽略 - 因为即使您只运行 10 分钟的剪辑，时钟也会出现差异，但效果也不是很明显。但是，如果有较长的 VoD 会话，可能会应用这样的时钟恢复 - 但 IP 网络的抖动仍然会太大。

在这种情况下，在这种情况下使用RTP 协议，应用基于每个数据包的附加时间戳，这表明如果没有抖动，它将具有的典型理论到达时间。除此之外 - 为了使接收方的本地时钟与发送方的本地时钟同步，使用了基于 NTP 时间戳的数据包。RTP 流由接收方根据发送方生成的 RTCP SR 数据包中包含的信息进行同步。有关详细信息，请阅读RTP rfc的第 6 节，完整说明 RTCP 数据包如何用于同步。