RTCP中的NTP的時間計算方法

記得兩年前剛開始做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, 這個值貌似有點大啊，而232=4294967296，很明顯用32bits無法精確到1 picoseconds， 於是我就想到不能精確到1 picoseconds， 那也應該儘力而為之吧，於是自然就有了把1,000,000,000,000 picoseconds劈成232份：

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;
}