在基于IP网络的多媒体通信系统(比如WebRTC)中，网络丢包对多媒体通信质量有非常严重的影响：例如造成视频的马赛克、图像模糊、帧率下降等问题，造成音频的声音失真、噪声干扰、音频中断等问题。这都会严重影响系统的通信质量，造成非常差的用户体验。
WebRTC主要采取两种手段对抗网络丢包：丢包重传(NACK)和前向纠错(FEC)。丢包重传在之前文章中有专门论述[1]，本文集中注意力于FEC。FEC是一种前向纠错技术，发送端将负载数据加上一定的冗余纠错码一起发送，接收端根据接收到的纠错码对数据进行差错检测，如果发现差错，则利用纠错码进行纠错。而ULPFEC(Uneven Level Protection FEC，直译为非均等保护前向纠错)则是WebRTC实现的FEC方案之一，本文深入学习ULPFEC的理论基础和实现细节。
对于实时音视频应用来讲，媒体数据从采集到渲染，在数据流水线上依次完成一系列处理。流水线由不同的功能模块组成，彼此分工协作：数据采集模块负责从摄像头/麦克风采集音视频数据，编解码模块负责对数据进行编解码，RTP模块负责数据打包和解包。数据流水线上的数据处理速度是影响应用实时性的最重要因素。与此同时，从服务质量保证角度讲，应用需要知道数据流水线的运行状态，如视频采集模块的实时帧率、当前网络的实时速率、接收端的数据丢包率，等等。各个功能模块可以基于这些运行状态信息作相应调整，从而在质量、速度等方面优化数据流水线的运行，实现更快、更好的用户体验。</br>
WebRTC采用模块机制，把数据流水线上功能相对独立的处理点定义为模块，每个模块专注于自己的任务，模块之间基于数据流进行通信。与此同时，专有线程收集和处理模块内部的运行状态信息，并把这些信息反馈到目标模块，实现模块运行状态监控和服务质量保证。本文在深入分析WebRTC源代码基础上，学习研究其模块处理机制的实现细节，从另一个角度理解WebRTC的技术原理。</br>
作为Google开源的技术，WebRTC并不是一个可以拿来就用并且性能很好的产品，需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。
WebRTC的优点：
1. 方便。对于用户来说，在WebRTC出现之前想要进行实时通信就需要安装插件和客户端，但是对于很多用户来说，插件的下载、软件的安装和更新这些操作是复杂而且容易出现问题的，现在WebRTC技术内置于浏览器中，用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说，在Google将WebRTC开源之前，浏览器之间实现通信的技术是掌握在大企业手中，这项技术的开发是一个很困难的任务，现在开发者使用简单的HTML标签和JavaScript API就能够实现Web音/视频通信的功能。
2. 免费。虽然WebRTC技术已经较为成熟，其集成了最佳的音/视频引擎，十分先进的codec，但是Google对于这些技术不收取任何费用。
3. 强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。
WebRTC的缺点：
getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。<br />
本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。<br />
getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />
另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />
通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />
前两天收到一个经过处理的webRTC源码，主要包含AEC，NS，AGC，VAD四项主要功能。要将其编译成一个ARM平台下库供Android APP使用。
怎么说呢，相当坑，源码好像是从GitHub上翻出来了，大牛精简抽离后，x86下可至今编译，但ARM下就需要下点功夫了。改起来相当累啊，耗时一个半工作日搞定，成果如下，请品鉴。
configure时为了好看，连接符可能不太标准。ANDROID_NDK的需自行设定。仅有脚本还不行，源码中还需做些微修改，这里就不再上传了，都是基本的编译问题，很简单。
在刚刚落幕的 WWDC17 上，苹果为我们带来了一个不小的惊喜 —— 其浏览器内核WebKit将正式支持 WebRTC，而未来基于 WebKit 内核的苹果浏览器，比如macOS High Sierra、iOS 11 中的 Safari 浏览器和Safari 技术预览版 32，都将使用到 WebRTC 技术。
适逢我也正在倒腾一些 WebRTC 的东西，万事开头难，搞事情最怕的就是开始的拦路虎，编译环境、demo 工程、Server 如何部署，这三个问题（尤其是最后一个）想必会浇灭很多朋友的热情之火。经过近两周的不懈奋斗，我总算把这几头拦路虎一一解决，今天我就在这里把这一套开箱即用的 WebRTC 开发环境分享给大家。
注意：这里我假设大家具备 Docker 的基本使用能力，如不具备，请自行搜索相关教程。
平台UBUNTU16.04
sudo apt-get install build-essential
1、安装ninja
mkdir -p ~/ninja && cd ~/ninja
git clone https://github.com/martine/ninja
cd ninja
python ./bootstrap.py
