总述
WebRTC原生支持VP8和VP9，但也可以自行集成H264编解码器，比较常见的是OPENH264和X264（X264自身只有编码功能，如果要加入解码功能，可以再结合ffmpeg），总体来说，集成H264编解码器的流程和直接使用它们的库的流程类似，但是要先将相应功能依照WebRTC中对编解码器的封装形式重新封装，然后再通过注册外部编解码器的方法在主流程中使用它们。
下面先看一下WebRTC对编解码器的封装形式是怎么样的，定义在webrtc\modules\video_coding\codecs\interface\video_codec_interface.h中，如下
WebRTC技术的出现改变了传统即时通信的现状，它是一套开源的旨在建立浏览器端对端的通信标准的技术，支持浏览器平台，使用P2P架构。WebRTC所采用的技术都是当前VoIP先进的技术，如内部所采用的音频引擎是Google收购知名GIPS公司获得的核心技术：视频编解码则采用了VP8。
大家都说WebRTC好，是未来的趋势，但是不得不说这个开源项目对新手学习实在是太不友好，光是windows平台下的编译就能耗费整整一天的精力，还未必能成功，关于这个问题在我之前的文章中有所描述。编译成功之后打开一看，整个solution里面有215个项目，绝对让人当时就懵了，而且最重要的是，google方面似乎没给出什么有用的文档供人参考，网络上有关的资料也多是有关于web端开发的，和Native API开发有关的内容少之又少，于是我决定把自己这两天学习VideoEngine的成果分享出来，供大家参考，有什么问题也欢迎大家指出，一起学习一起进步。
首先需要说明的是，webrtc项目的all.sln下有一个vie_auto_test项目，里面包含了一些针对VideoEngine的测试程序，我这里的demo就是基于此修改得到的。
WebRTC 自誕生之日起, 就代表了實時通訊領域的最好的技術. 不過很長時間裡, 它所支援的視訊編碼器只有VP8, 後來隨著H265/VP9為代表的下一代視訊編碼器的誕生, WebRTC裡出現了VP9 Codec. 而當前應用最廣泛的H264 卻一直不受待見. 一直到Cisco 宣佈旗下的H264 Codec開源為OpenH264, 並且替所有OpenH264的使用者支付了H264的專利費， 以次為契機， 在IETF的WebRTC會議中， 把H264和VP8都列入了WebRTC所必需要支援的視訊編碼器。 接下來， Google終於在WebRTC中增加了對H264的支援， 在PC平臺(Windows和MAC), 編碼器是用OpenH264, 解碼器是用FFMPEG， 在iOS平臺上， 編碼器和解碼器既可以使用OpenH264和FFMPEG, 也可以用apple的VideoToolbox所支援的硬體編解碼器. 在Android平臺, 可以用 OpenH264, FFMPGE, 也可以用 MediaCodec. 這個對於廣大需要H264的公司來說是一大福音. 在下載的WebRTC程式碼中做稍許配置， 就可以使用H264了.
一、基本介绍
最近在做WebRTC相关的移动端视频会议，看了一下相关文档和一些Demo,总结一下构建webRtc应用流程。
相关文档连接：
1.一篇不错的中文文档，好像网上好多demo都是基于这个的http://segmentfault.com/a/1190000000439103
2.htmlRock里也有一些Sample，http://www.html5rocks.com/en/tutorials/webrtc/basics/
通过这2篇文档的学习，基本就差不多了解了相关内容
本次实验使用windows平台，其他平台如html5、android、ios、linux、mac等思路大同小异，上一篇文章已经提及，在此不再赘述。
TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果终端在NAT之后，那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一个中继， 对来往的数据进行转发。这个转发的协议就被定义为TURN。TURN和其他中继协议的不同之处在于，它允许客户端使用同一个中继地址（relay address）与多个不同的peer进行通信。
使用TURN协议的客户端必须能够通过中继地址和对等端进行通讯，并且能够得知每个peer的的IP地址和端口（确切地说，应该是peer的服务器反射地址）。而这些行为如何完成，是不在TURN协议范围之内的。其中一个可用的方式是客户端通过email来告知对等端信息，另一种方式是客户端使用一些指定的协议，如“introduction” 或 “rendezvous”，详见RFC5128
如果TURN使用于ICE协议中，relay地址会作为一个候选，由ICE在多个候选中进行评估，选取最合适的通讯地址。一般来说中继的优先级都是最低的。TURN协议被设计为ICE协议(Interactive Connectivity Establishment)的一部分，而且也强烈建议用户在他们的程序里使用ICE，但是也可以独立于ICE的运行。值得一提的是，TURN协议本身是STUN的一个拓展，因此绝大部分TURN报文都是STUN类型的，作为STUN的一个拓展，TURN增加了新的方法（method）和属性（attribute）。
随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.
WebRTC兴起提供的方案以及遇到的问题
WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.
RTMP系统推流播放延迟分析
一个经过优化的RTMP-CDN网络端到端的延迟大概在2-3秒, 延迟大一些要在5秒甚至10秒以上. 从推流到播放, 会引入延迟的环节有编码延迟, 网络丢包和网络抖动, 视频的分段传输, 多媒体节点的relay, 播放器的缓存等等. 实际上除了网络丢包和网络抖动不太可控之外, 其他的各各环节都有一定的优化方案, 比如使用x264的-preset ultrafast和zerolatency, 可以降低编码的延迟,
分段传输部分可以把GOP减少到1秒之内, 在播放器端可以适当减小buffer, 并设置一定的追帧策略, 防止过大的buffer引起的时延.
低成本的低延迟的实现
何为 WebRTC ？首先，字面上已经给出了关于这一技术的大量信息，RTC 即为实时通信技术。
WebRTC 填补了网页开发平台中的一个重要空白。在以往，只有诸如桌面聊天程序这样的 P2P 技术才能够实现实时通讯而网页不行。但是 WebRTC 的出现改变了这一状况。
WebRTC 本质上允许网页程序创建点对点通信，我们将会在随后的章节中进行介绍。我们将讨论如下主题，以便向开发者全面介绍 WebRTC 的内部构造：
每个用户的网页浏览器必须按照如下步骤以实现通过网页浏览器进行的点对点通信：
WebRTC音频引擎的实现代码主要分布在如下几个源码目录中：
webrtc/audio
webrtc/common_audio
webrtc/media/engine
webrtc/voice_engine
webrtc/module/audio_coding
webrtc/module/audio_conference_mixer
webrtc/module/audio_device
webrtc/module/audio_processing
WebRTC音频引擎的整体架构如图1所示。