WebRTC，是一个支持网页浏览器进行实时语音通话或视频聊天的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。WebRTC提供了实时音视频的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。虽然WebRTC的目标是实现跨平台的Web端实时音视频通讯，但因为核心层代码的Native、高品质和内聚性，开发者很容易进行除Web平台外的移殖和应用。很长一段时间内WebRTC是业界能免费得到的唯一高品质实时音视频通讯技术。
1 WebRTC版本m74详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
2 时间戳音视频采样后会给每个音频采样、视频帧打一个时间戳，打包成RTP后放在RTP头中，称为RTP时间戳，RTP时间戳的单位依赖于音视频流各自的采样率。
RTP Header格式如下：
2.1 视频时间戳
视频时间戳的单位为1/90000秒，但是90000并不是视频的采样率，而只是一个单位，帧率才是视频的采样率。
不同打包方式下的时间戳：
Single Nalu：如果一个视频帧包含1个NALU，可以单独打包成一个RTP包，那么RTP时间戳就对应这个帧的采集时间；
FU-A：如果一个视频帧的NALU过大(超过MTU)需要拆分成多个包，可以使用FU-A方式来拆分并打到不同的RTP包里，那么这几个包的RTP时间戳是一样的；
STAP-A：如果某帧较大不能单独打包，但是该帧内部单独的NALU比较小，可以使用STAP-A方式合并多个NALU打包发送，但是这些NALU的时间戳必须一致，打包后的RTP时间戳也必须一致。
2.2 音频时间戳 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
2.3 NTP时间戳RTP的标准并没有规定音频、视频流的第一个包必须同时采集、发送，也就是说开始的一小段时间内可能只有音频或者视频，再加上可能的网络丢包，音频或者视频流的开始若干包可能丢失，那么不能简单认为接收端收到的第一个音频包和视频包是对齐的，需要一个共同的时间基准来做时间对齐，这就是NTP时间戳的作用。
NTP时间戳是从1900年1月1日00:00:00以来经过的秒数，发送端以一定的频率发送SR(Sender Report)这个RTCP包，分为视频SR和音频SR，SR包内包含一个RTP时间戳和对应的NTP时间戳，接收端收到后就可以确定某个流的RTP时间戳和NTP时间戳的对应关系，这样音频、视频的时间戳就可以统一到同一个时间基准下。
如上图，发送端的音视频流并没有对齐，但是周期地发送SR包，接收端得到音视频SR包的RTP时间戳、NTP时间戳后通过线性回归得到NTP时间戳Tntp和RTP时间戳Trtp时间戳的对应关系：
Tntp_audio = f(Trtp_audio)
Tntp_video = f(Trtp_video)
其中Tntp = f(Trtp) = kTrtp + b 为线性函数，这样接收端每收到一个RTP包，都可以将RTP时间戳换算成NTP时间戳，从而在同一时间基准下进行音视频同步。
2 延迟视频延迟的单位为ms，对音频来说，由于采样跟时间戳一一对应，所有时间延迟都会被换算成了缓存大小(音频包的个数)，其值为：
音频延迟 = 时间延迟 << 8 / 20也就是说，对48000的采样率，960个采样对应一个20ms包，时间延迟 / 20ms等于延迟了几个包，左移8(乘以256)也就是所谓的Q8，是为了用定点数表示一定精度的浮点数。
3 同步3.1 一张图看懂音视频同步
首先接收端需要按照音、视频各自的帧率来解码、渲染，保证流畅地播放，在这个基础上，需要计算音视频两个流目前的相对延迟，分别给音、视频两个流施加一定的延迟，保证音视频的同步。
延迟播放，也就意味着在缓存中暂时存放数据，延迟换流畅。
对音频来说，施加的延迟直接影响到音频缓存的大小，音频缓存的大小就体现了音频的播放延迟。
对视频来说，施加的延迟影响到视频帧的渲染时间，通过比较渲染时间和当前时间来决定解码后的视频帧需要等待还是需要立刻渲染。
正确设置好音视频各自的播放延迟后，音视频达到同步的效果。
可以看到，音视频同步中主要需要做到三点：
正确计算音视频相对延迟；
正确计算音视频各自的网络目标时延；
正确设置音视频各自的播放延迟。
3.2 音视频相对延迟 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
如上图：
最近一对音视频包的相对延迟 = (Tvideo_recv - Taudio_recv) - (Tvideo_send - Taudio_send)
其中Tvideo_recv、Taudio_recv分别是接收端收到视频包、音频包记录的本地时间，可以直接获取，而Tvideo_send，Taudio_send作为视频包、音频包的发送时间无法直接获取，因为接收到的RTP包只有RTP时间戳，无法直接作为本地时间来与Tvideo_recv、Taudio_recv进行运算，这时候就需要SR包中携带的NTP时间戳和RTP的对应关系来进行换算。
通过SR包中的NTP时间戳和RTP时间戳做线性回归(通过采样归纳映射关系)得到两者的线性关系：
Tntp = f(Trtp) = kTrtp + b这样RTP时间戳就可以直接转化为NTP时间戳，也就是发送端本地时间。从最近一对音视频包相对延迟的计算公式可以看出，分别对发送端和接收端的时间做运算，两者都在同一时间基准，可以排除NTP时间同步问题的影响。
stream_synchronization.cc:34StreamSynchronization::ComputeRelativeDelay3.3 期望目标延迟 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题期望目标延迟就是保证音频流、视频流各自流畅播放的期望延迟。
从3.1的图可以看出，对视频来说，期望目标延迟 = 网络延迟 + 解码延迟 + 渲染延迟，对音频来说，期望目标延迟 = 前后两个音频包之间的到达间隔的期望值。在接收时间的基础上，加上各自的期望目标延迟进行播放，可以保证音频、视频流可以按照各自的步调进行流畅无卡顿的播放。
stream_synchronization.cc:34StreamSynchronization::ComputeRelativeDelay
当前音视频流相对延迟 = 最近一对音视频包的相对延迟 + 音视频目标延迟之差3.3.1 期望视频目标延迟 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
期望视频目标延迟 = 网络延迟 + 解码延迟 + 渲染延迟网络延迟其实就是视频JittterBuffer输出的延迟googJitterBufferMs，可以参考我的文章《WebRTC视频JitterBuffer详解》7.1节[抖动计算]，简单说就是通过卡尔曼滤波器计算视频帧的到达延迟差(抖动)，作为网络的延迟。
解码时间的统计方法：统计最近最多10000次解码的时间消耗，计算其95百分位数Tdecode，也就是说最近95%的帧的解码时间都小于Tdecode，以之作为解码时间。
视频渲染延迟默认是一个定值：10ms。
timing.cc:210VCMTiming::TargetVideoDelay3.3.2 期望音频目标延迟 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
音视频同步 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
视频渲染时间 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
期望接收时间 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
视频当前延迟 - googCurrentDelayMs 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
计算渲染时间 详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题
音频渲染时间
总结音频就是以缓存长度追赶目标延迟的方式达到延迟一定时间的效果，最终和视频的目标延迟对齐后，实现了音视频同步
WebRTC详细教程资料关注+后台私信；资料；两个字可以免费视频领取+文档+各大厂面试题 资料内容包括：C/C++，Linux，golang,Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，嵌入式 等。