IM系统实时音视频技术选型

IM系统实时音视频技术选型 ##背景     最近公司需要在自研IM项目中增加支持音视频通讯的功能，不但要实现微信那样的基础版两人通话的功能，还需要支持多人音视频通话乃至会议的功能。看到这里，大家可能会想，增加音视频功能不是很简单的事情么？？直接从云平台上接入通讯sdk不就完事了么？没有什么难度的呀。实际上一般的业务应用系统这样子去实现问题不大，但是公司一直以来有一个比较硬性的要求，所有的东西要求是自研，也就是说可以用开源的代码，但不能用sdk（至于为啥，这里就不多说了。。。）。包括当前自研的IM项目，全部都是基于自研的引擎和开源代码进行开发的，并没采用过其他的sdk。 ##技术选型     既然不能用sdk，那只能硬着头皮自己实现每个功能了。考虑到团队之前很少做过音视频相关项目，缺乏相关实战经验，这是一个从0到1的一个项目，对团队来说，它是一个非常大的挑战，从技术上来说，也是一个对技术要求高，技术体系偏底层的项目。所以直接pass自己去实现一个音视频系统了，我们选择了拥抱开源，选择了在开源项目的基础上进行二次开发。那么，如何选择合适我们团队的开源项目呢？考虑到项目是必须要支持多人音视频功能，因此我们在市场上进行了一系列的调研，最终得出了几个可选方案：     ▸ **webrtc**
    ▸ **h323plush**
    ▸ **live555**
    ▸ **OpenMeetings** ### 1 webrtc Google开源的基于浏览器的实时通信开源项目，号称是全世界最先进的实时音视频通讯技术，里面的网络传输模块，采集模块，音视频编码打包等做得非常的领先，项目包括android/ios/web等主流端的实现，其最大的特点是在浏览器端能直接进行音视频通讯。缺点:但是这个项目是不支持多人音视频会议的。 ### 2 h323plus

最成熟也算是比较老的一套音视频开源系统，包含了全部的H.323协议功能，包括音频视频会议等功能，它有大量视频会议实现的参考例子，如MCU服务器等。该项目应用在传统的局域网音视频会议中，典型的应用例如学校政府应用的局域网会议，它需要配套硬件起来一起使用。

### 3 live555

c++著名的流媒体服务器，不仅包括了传输协议（SIP、RTP）、音视频编码器（H.264、MPEG4）等，还包括流媒体服务器的例子，是流媒体项目的首选，里面的传输模块是非常值得视频会议开发作为参考的，但是它只支持服务器，客户端得自己去实现

### 4 OpenMeetings

OpenMeetings主要是基于flash客户端的开源项目，核心技术基于另外一个开源Red5，包括音视频会议系统、电子白板等，开发语言是java

项目名称 |  h323plus       |   webrtc   | live555     |   OpenMeetings
------- | --------------- |  --------- | --------    | --------------
使用场景 | 基于局域网高清联机会议| 互联网行业 | 只用作服务器  |  互联网行业

缺点    | 对手机端支持不够   |    暂无     |没有实现客户端  | 只支持flash客户端 

开源语言 |   c          | c++/node.js/go |  c++        | java

    从上面的对比看出，我们优先对比了webrtc 和 h322plus两个开源项目，虽然h323plus在目前的主流局域网高清晰视频会议中用得非常多也比较成熟，但鉴于我们应用的领域是互联网，需要提供五端（android/ios/h5/pc/mac)客户端功能，所以我们最终决定了使用webrtc项目进行音视频开发。
    前面提到，webrtc项目的优势是在于单对点（p2p）之间音视频通讯，不支持多人音视频通讯，但是项目要求是必须要实现多人音视频的功能，要求实现多人视频会议，必须需要研发服务端程序才可以支持（这点团队之前吃过很大的亏，花过大量的时间在研究webrtc如何支持多人音视频，但最终调研得知是不支持的）
    为了实现多人通话的功能，先了解三种可行的模式，分别是：Mesh模式，MCU模式，SFU模式，mesh模式主要是依赖客户端实现，后面两个模式都是依赖服务器实现，各自的优缺点都不同。 ### mesh模式     又称为网状模式，每个客户端之间都建立有连接，一方面自己的音视频数据平等地分发给其他的客户端，另一方面同时接受其他客户端的数据。缺点是在超过一定数量（5个）客户端参与以后，客户端就变得相当困难。

### mcu模式     MCU模式又称为融合服务器，服务器对每个客户端的媒体流进行混合和编码压缩后合并成一条融合流（区分音频视频）再转发给每个客户端。相对mesh模式来说，一个客户端只需要发送和接受一路数据流即可，大大减少了对客户端的压力，当然付出的代价是相应的服务端成本的提高。

sfu模式

SFU（Selective Forwarding Unit）称为选择性转发服务，服务器根据需要对客户端进行选择性的转发数据流，相比mcu模式客户端收到单一的流来说，客户端会收到多路来自服务器转发过来的流，业务层更加容易扩展。

#### 几个模式的对比

    一般常规的互联网应用，都是采取重服务端轻客户端的设计原则，主要是为了更好扩展了系统性能和功能，支持更为复杂的应用场景；因此一般都选择后面两种模式去实现多人音视频功能。

结论

    结合团队自身情况，最终选择基于webrtc技术体系来实现音视频功能。通过webrtc实现p2p音视频功能。为了支持多人音视频，团队需要独立研发webrtc服务器，产品项目要求有多屏动态展示和连mic操作，因此选择 mcu/sfu混合模式的服务器作为支撑多人音视频功能。支持mcu/sfu模式的开源项目比较多，内容也比较多，将在下篇文章中进行介绍。。

思考

    假设让你去实现一个实时音视频系统，你是通过什么方式进行技术调研以及技术选型的呢？是百度google还是通过其他更加快捷的方式呢？？欢迎留言交流

来源：https://www.cnblogs.com/ylpp/p/11542322.html