实时音视频通信（RTC）音视频实时的几种算法

1、背景
RTC（Real-time Communications），实时通信，是一个正在兴起的风口行业，特别是近两年电商、教育等行业直播的普及以及各种设备之间的音视频通话场景。从技术角度来说，RTC并不是一个新兴技术，从智能手机流行以来，RTC就已经出现在一对一的音视频通话场景中，最初的技术方案也比较直观，当设备通过服务端建立通话连接后，两个设备以点对点的方式直接通信，具体实现方式就是把编码压缩过的音视频数据包通过UDP协议封包后发送给接收方，接收方收到UDP数据包后，就可以进行拆包，解码并播放，这种方式的特点就是简单粗暴，不需要关心网络情况，后果是有可能出现丢包，特别是网络情况发生变化时，会出现听不到声音，画面卡顿等情况，所以整体用户体验会比较差。随着技术的发展进步，考虑到网络情况随时可能发生变化，在原有技术方案的基础上，出现了一些比较有名的网络拥塞控制算法，它可以根据网络变化情况控制数据包发送速率，从而平缓网络抖动造成的一些丢包，卡顿等现象。

在RTC领域，最有名的就是Google的WebRTC，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输，支持网页浏览器进行实时语音对话或视频对话。WebRTC是一个开源项目，从功能流程上来说，它包含采集、编码、前后处理、传输、解码、缓冲、渲染等很多环节。比如，前后处理环节 有美颜、滤镜、回声消除、噪声抑制等，采集有麦克风阵列等，传输有拥塞控制，NetEQ等，编解码有 VP8、VP9、H.264、H.265 等等。这里主要是基于学习的角度，简单介绍WebRTC中比较重要的几个算法：拥塞控制算法，NetEQ以及音频3A（噪声抑制，回声消除以及自动增益）。

2、拥塞控制算法
WebRTC包含三种拥塞控制算法，GCC（Google Congest Control）、BBR和PCC。这里主要想介绍一下GCC。

GCC核心思想就是通过预测可用带宽来控制发送的速率，并结合发送端和接收端两端各自估测的带宽来综合计算，其中发送端的带宽估测主要依赖于丢包率(其实也有延迟)，接收端的带宽估测依赖于延迟(的变化)。打个比方，GCC的角色就像是一个繁忙的十字路口的交警，当前方道路车辆太多时，他会阻止后方车辆继续行驶ÿ