cloudHandler提供了nuve对EC的调用：获取房间中的所有用户，删除房间，删除指定用户；以及EC对nuve的调用：删除token，EC的添加、状态更新，删除以及保活。
调用方法通过RPCMQ实现，他们共同维护了两个队列，队列A用来传递调用消息，Nuve发布调用消息后，并且会维护一个调用方法和回调函数的字典；EC从队列A中获取调用消息后执行调用方法，并将结果消息push进队列B；Nuve从队列B中获取调用结果消息，并从字典中得到回调函数并执行callback，删除对应字典值。
2.3服务、房间、用户管理
1.只有superService才有权限进行service的相关操作，即配置文件中的superService = config.nuve.superserviceID
2.在room模块中currentService即当前请求的service，会维护一个rooms列表，且创建房间的时候可携带房间的媒体信息：room.mediaConfiguration
libnice介绍：
libnice库是基于ICE协议实现的一套通信连接库。
主要功能是实现p2p连接及媒体数据流发送接收。其类似于webrtc源码中自带的libjingo。我们可在我们的项目中使用libnice库来实现端到端的ICE连接和数据流发送接收。以及candidates(候选地址)和SDP（媒体描述文件）的相互交换。
libnice库是基于glibc语言的，跨平台，在linux和手机端都可使用，但需依赖于glib库。
libnice介绍：
libnice库是基于ICE协议实现的一套通信连接库。
主要功能是实现p2p连接及媒体数据流发送接收。其类似于webrtc源码中自带的libjingo。我们可在我们的项目中使用libnice库来实现端到端的ICE连接和数据流发送接收。以及candidates(候选地址)和SDP（媒体描述文件）的相互交换。
libnice库是基于glibc语言的，跨平台，在linux和手机端都可使用，但需依赖于glib库。
抽取的代码没有webrtc自带的音视频处理框架(voice engine/video engine/media engine)，这是由于SFC只在RTP层进行转发并不解码，只需要check一下媒体流属性(如I帧头)即可。
抽取代码的亮点在于将webrtc强大的抵抗网络时延和丢包的网络适应性算法和协议都提炼出来了，可以供广大研究视频传输的网络适应方向的开发者们单独学习、实验并快速集成到自己非webrtc-based的产品中来。
libav是从ffmpeg中分离出来的开发者发布的开源工程，代码量更小、第三方依赖库更少、编译简单。目前FFmpeg的使用更广泛。
libnice基于ICE协议实现的网络层库，Licode使用libnice库来实现端到端的ICE连接和数据流发送接收，以及candidates(候选地址)和SDP（媒体描述文件）的相互交换。（但是配置文件中默认使用nicer，此配置文件仅是example的配置）
libsrtp库主要是是用来加密rtp/rtcp的。
webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：
（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；
（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；
（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。
这里编辑文章摘要...
Basic example of using OpenCV 2.4 to access an RTSP H.264 video stream from an IP video camera and performing real-time motion detection and object tracking.
Install Homebrew if not already installed
Install OpenCV using...
$ brew tap homebrew/science $ brew install opencv --with-ffmpeg
实时流媒体应用的最大特点是实时性，而延迟是实时性的最大敌人。从媒体收发端来讲，媒体数据的处理速度是造成延迟的重要原因；而从传输角度来讲，网络拥塞则是造成延迟的最主要原因。网络拥塞可能造成数据包丢失，也可能造成数据传输时间变长，延迟增大。
拥塞控制是实时流媒体应用质量保证(QoS)的重要手段之一，它在缓解网络拥堵、减小网络延迟、平滑数据传输等质量保证方面发挥重要作用。WebRTC通控制发送端数据发送码率来达到控制网络拥塞的目的，其采用谷歌提出的拥塞控制算法(Google Congestion Control，简称GCC[1])来控制发送端码率。
本文是关于WebRTC拥塞控制算法GCC的上半部分，主要集中于对算法的理论分析，力图对WebRTC的QoS有一个全面直观的认识。在下半部分，将深入WebRTC源代码内部，仔细分析GCC的实现细节。
本文在文章[1]的基础上，从源代码实现角度对WebRTC的GCC算法进行分析。主要内容包括： RTCP RR的数据源、报文构造和接收，接收端基于数据包到达延迟的码率估计，发送端码率的计算以及生效于目标模块。
拥塞控制是实时流媒体应用的重要服务质量保证。通过本文和文章[1][2]，从数学基础、算法步骤到实现细节，对WebRTC的拥塞控制GCC算法有一个全面深入的理解，为进一步学习WebRTC奠定良好基础。
本节内容基本上是文章[1]第1节的复习，目的是再次复习GCC算法的主要框架，梳理其算法流程中的数据流和控制流，以此作为后续章节的行文提纲。GCC算法的数据流和控制流如图1所示。
对发送端来讲，GCC算法主要负责两件事：1)接收来自接收端的数据包信息反馈，包括来自RTCP RR报文的丢包率和来自RTCP REMB报文的接收端估计码率，综合本地的码率配置信息，计算得到目标码率A。2)把目标码率A生效于目标模块，包括PacedSender模块，RTPSender模块和ViEEncoder模块等。