前两天收到一个经过处理的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
技术上来说，从IP摄像头实现在线广播并不需要WebRTC。IP摄像头本身就是服务器，可以自行连接路由器并传输视频内容。既然这样，我们为什么还需要WebRTC？
有两个原因：
1.随着观看以太网广播的观众增加，他们会逐步感受到带宽的不足，然后是摄像头资源，如果观众持续增加的话；
2.如上面提到的，一个IP摄像头就是一个服务器。但是它使用什么协议传输视频到浏览器或者移动设备？一个使用HTTP的摄像头很有可能基于HTTP传输视频帧或者JPEG图像。但是，HTTP流并不完全适用于实时视频传输。对于请求式视频，它确实工作良好，但是仅限于互动性和延迟要求不高的场合。确实，如果你在线观看一部电影，延迟5-10秒确实不太重要。好吧，除非你在和其他人同时观看：“oh，不，杰克谋杀了她！”爱丽丝给鲍勃发送信息10s之后，鲍勃才看到了这一幕悲剧。
另外一个选项是RTSP/RTP加上H.264。但是这种情况下浏览器需要安装一个视频播放插件，例如VLC或者QuickTime。这类插件将会接受并播放视频，就像播放器一样。但我们需要真实的基于浏览器的流，不需要任何附加的工具。
好，现在让我们“sniff”我们的IP摄像头，学习一下它到底向浏览器发送了什么。我们采用D-Link DCS 7010L来做测试：
关于我们WebRTC APP的故事起始于2018年2月份，形象地来说，一个叫 Redacted 的人在开会时想要我们实现一个具有 redacted 特性的 redacted APP。你可以将它理解为实时视频交流。
起初，我们对WebRTC没有任何实际经验。尽管2011年就发布了WebRTC,但是它的想法包含了许多已经建立的领域，例如VoIP交流，网站开发， 视频流等等。
但是WebRTC是一种新技术，它在浏览器中的实现经常变化，你所了解的WebRTC信息经常有可能是过时或者错误的。
因此我的建议是在你开发App之前充分了解WebRTC：
1.你应该了解关于你必须用来开发WebRTC App的服务器的一切.
2.学习建立点对点连接的发信过程。
3.明确媒体是如何处理传输的。
4.有必要时咨询专家。
系统: ubuntu14.04 工程: webrtc-linux 网络:本机localhost
webrtc工程编译过后会在out/linux目录下生成一些测试用可执行程序
其中有 peerconnection_server 和 peerconnection_client可以用于测试连接
我的视频对话框图像是红色的,不正常 有待解决问题.
