本文讲述一下音视频通话的缓冲区管理，按照我们正常的流程，对于采集的音视频到远端进行播放，要经过如下过程：
按照上述业务逻辑，我们可以实现从设备端采集的数据，通过网络发送到另外一端进行显示与播放，那么这样的过程如果某一模块发生了异常与抖动，则会造成音视频延迟和马赛克现象，比如说网络传输发送了延迟和丢包，远端视频的渲染卡顿和延时，对于音频和视频单独播放，如果保证每个环节理想状态，音画同步，若一处发生延时或者抖动，则音画不同步，同样的，这样单线程的处理，也没有充分利用到cpu的多核性能，那么，如何设计一套能够适应网络波动，编解码器抖动，平滑渲染同时能够降低延迟的缓冲区呢？webrtc设计了一套可以在QOS基础上的缓冲区控制原理：我用绘图描述后在用代码显示：
除去webrtc的QOS拥塞控制，我们来看如上的图：
对于发送端：采集的数据放入编码队列，然后编码线程取出队列中的数据进行编码，这里可以防止编码器抖动的异常，编码并打包后塞入发送队列，而不是直接发送到网络上，而是由PacerSender按照时间分片进行平滑发送，这样可以降低网络的压力，根据QOS的调控，平衡网络；
对于接受端：接收到的数据并不是直接解码渲染，而是首先经过rtp解包以及fec丢包补偿之后，对于顺序到达的数据包塞入decodedQueue，丢包数据塞入丢包缓冲区（rtcp结合调控），解码线程从解码队列中取数据进行解码，解码后塞入RenderQueue队列中，而不是直接渲染，因为由于decoder的解码后直接渲染可能导致视频迅速播放或者卡顿，同时RenderQueue还要进行音画同步，平滑渲染功能（根据帧率，也就是频率调控）；
以上描述了webrtc jitterbuffer中buffer的构造，buffer主要对丢包、乱序、延时到达等异常情况做处理，还会和NACK、FEC、FIR等QOS相互配合，jitter主要根据当前帧的大小和延时评估出jitter delay，再结合decode delay、render delay以及音视频同步延时，得到render time，来控制平稳的渲染视频帧。，这篇博客不做描述，下面提供部分webrtc buffer代码流程：
发送端buffer流程代码：
intH264EncoderImpl::Encode() 编码开始
->intH264EncoderImpl::GetEncodedPartitions
->int32_tVCMEncodedFrameCallback::Encoded 编码返回
->int32_tViEEncoder::SendData
->boolPayloadRouter::RoutePayload
->int32_tModuleRtpRtcpImpl::SendOutgoingData
->int32_tRTPSender::SendOutgoingData
->int32_tRTPSenderVideo::SendVideo
->boolRTPSenderVideo::Send//视频数据进行打包（rtp,fec，padding）
->int32_tRTPSenderVideo::SendVideoPacket
->int32_tRTPSender::SendToNetwork
->void PacedSender::InserPacket() //packets->Push()//塞入数据到缓冲区
->boolPacedSender::SendPacket //平滑发送
接收端buffer流程代码：
接收：
voidUdpTransportImpl::IncomingRTPCallback
->voidUdpTransportImpl::IncomingRTPFunction
->voidVideoChannelTransport::IncomingRTPPacket
->intViENetworkImpl::ReceivedRTPPacket
->int32_tViEChannel::ReceivedRTPPacket
->intViEReceiver::ReceivedRTPPacket
->intViEReceiver::InsertRTPPacket
->boolViEReceiver::ReceivePacket
->boolRtpReceiverImpl::IncomingRtpPacket//接受到rtp数据包
->int32_tRTPReceiverVideo::ParseRtpPacket//进行解包以及fec丢包恢复，统计丢包缓冲以及延时
->int32_tViEReceiver::OnReceivedPayloadData
->int32_tIncomingPacket
->int32_tVideoReceiver::IncomingPacket
->int32_tVCMReceiver::InsertPacket//塞入数据到缓冲区
->VCMFrameBufferEnum VCMJitterBuffer::InsertPacket
解码渲染：
boolViEChannel::ChannelDecodeThread
FunctionboolViEChannel::ChannelDecodeProcess()
int32_tDecode(uint16_tmaxWaitTimeMs)
int32_tVideoReceiver::Decode(uint16_tmaxWaitTimeMs)//解码
VCMEncodedFrame* VCMReceiver::FrameForDecoding//按照优先顺序，从相应队列取数据
VCMEncodedFrame* VCMJitterBuffer::ExtractAndSetDecode
VCMJitterBuffer::UpdateJitterEstimate//卡尔滤波计算延时，并基于延时估算码率，rtcp返回给发送端调控码率
VCMInterFrameDelay::CalculateDelay //计算两帧传输的延时，结合解码时间，渲染时间以及频率计算出渲染时间
注解：解码线程会一直从buffer中寻找期望的数据，这里说的期望的分为必须完整的和可以不完整的。如果期望的是完整的，那就要从decodableframes队列取出状态为complete的frame，如果期望的数据可以是不完整的，就要从decodableframes和incompleteframes队列取出数据。取数据之前，总是先去找到数据的时间戳，然后计算完jitterdelay和渲染时间，再经过一段时间的延时（这个延时为渲染时间减去当前时间、decode delay和render delay）之后再去取得数据，传递到解码，渲染。
以上是webrtc jitterbuffer大致流程，我们需要掌握其buffer的思想，后面在讲解jitterbuffer如何结合QOS对视频通话质量进行调控。
