我正在尝试使用rtp时间戳重建音频对话（使用g711音频进行a-b调用）。我曾经使用两个rtp时间戳和采样率的差异来填充静音。对话失去了同步，然后我看到rtp时间戳不是线性的。我无法使用rtp时间戳获得准确的时钟时间并导致同步问题。我如何计算确切的时间。
答案 0 :(得分：0)
我对GStreamer提供的Stream有同样的问题，它不提供单调时间戳。 例如：邮票之间的差异应该恰好是1920，但它介于~120和~3500之间，但平均值为1920.
这里的问题是没有办法找到丢失的样本，因为你永远不知道高差异是来自编码器延迟还是缺少样本。
如果您只有要解码的音频，我会尝试将＆＃34;有效＆＃34;每个样本的PTS值（在我的情况下基准时间+ 1920，基准时间+ 3840等等。）
当视频和音频合并时，问题就出现了。在这里，这个技巧不能很好地工作，当样本丢失并且没有办法找出这种情况时：（
答案 1 :(得分：0)
当你想发送rtp时，你应该注意两件事： 由于字节数量的增加，时间戳会增加。 例如，对于PT = 10，您可能具有以下模式： 1160字节，时间戳增量：1154并等待26 ms 让我们看看这个计算是如何发生的：
时间戳增量：clockrate /＃= 1154
答案 2 :(得分：0)
关于RFC3550（https://www.ietf.org/rfc/rfc3550.txt）
采样时刻必须从递增的时钟导出 单调
它不是一个选择，也不是一个选择。顺便提一下，请阅读RTP数据包的时间戳字段的完整描述，我在那里也找到了：
例如，对于固定速率音频 时间戳时钟可能会增加一个 抽样期。如果音频应用程序读取块覆盖 来自输入设备的160个采样周期，时间戳将是 每个这样的块增加160，无论是否 block在数据包中传输或者以静默方式丢弃。
如果要检查线性度，请使用RTCP SR RTP和NTP时间戳字段。在SR报告中，RTP时间戳属于NTP时间戳。 所以两个连续RTP时间戳的差异（让我们称之为dRTPt_1，dRTP_2，...）和两个连续NTP时间戳的差异（让我们称之为dNTP_1，dNTP_2，...）然后将dRTP_t *与时钟速率相乘并检查天气你得到dNTP_t *。
但首先请阅读RFC。