记得两年前刚开始做RTP/RTCP的时候碰到一个问题，是关于如何计算RTCP中的NTP时间戳，最近又有人问这个问题，于是就想把它贴出来，让大家参考，提提建议，交流促进进步。

记得当时有个客户说用openRTSP(open source ,you can get it from www.live555.com) 无法录制我们送出去的RTP流，于是我也去下了一个，试了发现果然不行，于是就把openRTSP的source code捞出来看看，最后发现它必须要收到RTCP包后才开始录制视频，于是我就加了RTCP，结果发现视频录制是没问题，但用VLC播放的时候老是抖 动，于是回后去找原因，一个排下来，最后focus到NTP时间戳上来了。

NTP的时间戳有MSW和LSW组成， MSW好算，以秒为单位，LSW就头痛了，查了RTP的文档，讲得很模糊，NTP(RFC1305)中只讲单位大约是200 picoseconds，但我试了用200 picoseconds为单位不行，还是闪。

没办法了，之后去研究Darwin Streaming Server,看看人家是怎么做了，抓了包，找了好几个RTCP的点，画了个数轴，因为抓包工具wireshark会显示NTP时间（如下图），于是我就 倒过去算，最后算出来单位大约是232 picoseconds, 把这个值代入到我的source code中，果然不闪了。

问题虽然解决了，但心里一直有个结，就是一直不知道232这个值是怎么来的，纠结啊。 只好回去再看RFC1305, 它只说单位大约是200 picoseconds， 而1 second = 1,000,000,000,000 picoseconds, 这个值貌似有点大啊，而2³²=4294967296，很明显用32bits无法精确到1 picoseconds， 于是我就想到不能精确到1 picoseconds， 那也应该尽力而为之吧，于是自然就有了把1,000,000,000,000 picoseconds劈成2³²份：

1，000，000，000，000/4294967296 = 232.83064365386962890625

That's it！！

现在想想其实有更快捷的方法，直接看VLC的source code就可以了：

/**
 * @return NTP 64-bits timestamp in host byte order.
 */
uint64_t NTPtime64 (void)
{
    struct timespec ts;
#if defined (CLOCK_REALTIME)
    clock_gettime (CLOCK_REALTIME, &ts);
#else
    {
        struct timeval tv;
        gettimeofday (&tv, NULL);
        ts.tv_sec = tv.tv_sec;
        ts.tv_nsec = tv.tv_usec * 1000;
    }
#endif

    /* Convert nanoseconds to 32-bits fraction (232 picosecond units) */
    uint64_t t = (uint64_t)(ts.tv_nsec) << 32;
    t /= 1000000000;

    /* There is 70 years (incl. 17 leap ones) offset to the Unix Epoch.
     * No leap seconds during that period since they were not invented yet.
     */
    assert (t < 0x100000000);
    t |= ((70LL * 365 + 17) * 24 * 60 * 60 + ts.tv_sec) << 32;
    return t;
}