从扩展RTP数据包报头解码unix时间戳以计算延迟

Question

我正在开发一个项目，我正在努力计算使用RTP在两个Android设备之间收到的数据包的延迟。

所以我继续扩展RTP标题，其中包含unix时间戳，其中包含12到19个字节。

我现在收到了数据包，试图从中提取unix时间。但是，我在解码过程中做错了，如截图所示。在左边，是我从数据包解码的时间，在右边是到达时间。请忽略我手边的照片。 （抱歉大分辨率，不知道如何在SO上调整图像大小。

我已将字节转换为十六进制，以便尝试调试将字节数组转换为long时获得的巨大数字。我没有注意到许多线索，除了一致的＆＃34; 41＆＃34;在我的十六进制值和＆＃34; 14＆＃34;在我的长期价值观中。

我目前没有关于如何解决这个问题的想法。 如何从数据包中提取毫秒的正确Unix时间？

我使用其他人的代码来生成我放入数据包的字节，他使用此代码将SSRC放入标头（也是64位）。

private void setLong(byte[] buffer, long n, int begin, int end) {
    for (end--; end >= begin; end--) {
        buffer[end] = (byte) (n % 256);
        n >>= 8;
    }
}

我的代码使用上述方法：

public void setUnixTime() {
    for (int i=0;i<mBufferCount;i++) {
        setLong(mBuffers[i], System.currentTimeMillis(),13,20);
    }
}

我也对以这种方式计算滞后超过RTP的想法感兴趣（在数据包上设置unix时间并将时间与到达时间进行比较）。

Answer 1

我相信，既然你说你的时间戳应该是字节12-19，你的开始和结束也应分别是12和20。正如它当前读取的那样，你的for循环只执行7次，最后一个字节留空。将设置字节19,18,17,16,15,14和13，但永远不会设置字节12。

此外，您可以考虑使用按位和＆amp;而不是模数来截断你的大数字（n＆amp; 255），因为它稍微快一些。

Answer 2

以上所有事情都是正确的。我得到错误值的原因是因为Libstreaming库的打包器覆盖了我的扩展标头。我不得不手动调整库代码中的标题大小以扩展它。