RTP的同步包含两个含义，一个是RTP流自己的同步，一个是多个RTP流的同步。举例来说，一个音乐的正常播放需要流自己的同步，而音视频的同步播放需要多个RTP流的同步（注意，音视频一般是分开RTP流传的）。
RTP的同步靠这几个东西来完成：
1. RTP帧头的以下三个域 sequence number， timestamp，SSRC
2. RTCP SR报文的以下三个域：RTP timestamp， NTP timestamp，SSRC of sender
同步机制
RTP
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 01
1. 某RTP流的第一个包中的sequence number是一个随机产生的16bit正整数。发送端按发送先后顺序进行加1。这个数字是为了保证接收端可以按照发送先后顺序重排RTP包。
2. 某RTP流的第一个包中的timestamp是一个随机产生的32bit正整数。后续包计算第一个Byte数据被采样的时刻的Offset，再加上这个随机值得到这个值。算Offset的单位是采样次数，每两帧之间timestamp的增量是 = 采样次数 / 帧率。
其中采样次数（也可称为时钟频率）可从SDP中获取，如:
m=video 2834 RTP/AVP 96
a=rtpmap:96 H264/90000
其时钟频率为90000（通常视频的时钟频率），若视频帧率为25fps，则相邻帧间RTPtimestamp增量值 = 90000/25 = 3600。
注意：某些帧可以分成多个RTP包，所以多个帧的timestamp相等
3. SSRC也是一个随机值，但是在整个RTP Session中必须是全局唯一的。它代表一个正在参与Session的流。
总之，sequence number，timestamp保证了一个RTP流自身的同步，SSRC和RTCP结合起来用在不同RTP流的同步上。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length |header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word |sender
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+info
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender‘s packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender‘s octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block
| fraction lost | cumulative number of packets lost | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
再说RTCP SR头，SR是指发送者报告。我们看看它的包结构：
1. NTPtimestamp： 64bit，标示该SR发送时的绝对时间，这个时间来自RTCP发送者的系统时钟。
2. 该NTP timestamp对应的RTPtimestamp，也就是该SR发送时的，这个SSRC对应的RTP时间。这样，我们就知道了RTP对应的绝对时间。
3. SSRC发送者的id，也是跟某发送源建立一个映射关系。
因此对于接受者来说，若它同时接收多个流，就可以检查当前处理的多路RTP流的RTP时间戳对应的NTP时间是否一致，若不一致，说明这几个流没有同步，然后调整处理时延进行调整。
计算NTP时间
那怎么计算NTP时间呢？根据系统时间算出来的，函数是gettimeofday。
在RTCP中NTP时间存放在8个字节中，分为：MSW和LSW，分别占用4个字节。
MSW： 单位是秒，不过是从1900年1月1日算起，所以使用gettimeofday后需要加上：1900-1970的时间差：
msw = (70LL * 365 +17) * 24 * 60 * 60 + tv.tv_sec;
LSW:单位是232皮秒，其中1s =10^12ps，所以以32bit表示的话，每个bit就是10^12/2^32=232.83皮秒。
VLC有一个这样的函数，我加了些注释：
/**
* @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;
/*获取系统时间，tv_sec是秒，tv_nsec是纳秒，纳秒是微秒的1000倍*/
gettimeofday (&tv, NULL);
ts.tv_sec = tv.tv_sec;
ts.tv_nsec = tv.tv_usec * 1000;
}
#endif
/* t=ts.tv_nsec*2^32/1000000000，也就是说，ts.tv_nsec*1000/(1,000,000,000,000/2^32)*/
/* 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;
}
原文地址：http://blog.csdn.net/ffmpeg4976/article/details/45787293
