记得两年前刚开始做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就可以了:
/* Convert nanoseconds to 32-bits fraction (232 picosecond units) */
|