基于webrtc多人音视频的研究【转】

来自：http://blog.csdn.net/gupar/article/details/53101435

WebRTC技术和它的对等网络功能，非常适合一对一的通信。然而，当我与客户讨论使用超越一比一，即一对多或多对一的许多案例和服务，问题出现了：“好吧，但我会用什么架构吗？” 。一些服务提供商要重用他们在网络具有多播支持（我们有乐趣做一些实验与此），一些正在探索基于联播的解决方案，有的正在考虑类似的MCU /Mixer集中的解决方案，和一帮都是简单地愿意通过使用基于网状拓扑结构的一些变化放置在端点上的负担。

尽管超出今天在WebRTC中一到一个音频和视频呼叫，该技术的最流行的用途之一任何有限规格的是多方视频会议场景。不要以为只是传统的会议室。有不同的使用情况超出了会议室，包括电子学习，客户支持，或实时广播。在每一种情况下，芯能力是能够从多个源的媒体流分发到多个目的地。所以...如果你是一个服务供应商如何才能在实现支持WebRTC端点的多方拓扑结构？

有几种不同的架构根据您的要求，可能是合适的。这些架构基本上他们围绕二轴：

§ 集中VS对等网络（P2P）和

§ 混合VS路由。

我将在这里介绍最流行的解决方案。如果你需要去深入到协议的影响和实施细则的架构，你可以找到所有的相关信息，RTP拓扑IETF文档。

Mesh解决方案

网格的方法是最简单的解决方案。因为它不需要初始基础设施缺乏它已跻身新WebRTC技术役提供商受欢迎。该体系结构基于从每一个发送者创建多个一对一的数据流的每一个可能的目的地。

 

Mesh解决方案

即使它看起来像一个低效的解决方案，在实践中是非常有效的，并提供最低延迟，以外的现成独立的比特率适配为每个接收机。

“唯一”的问题是，这种解决方案需要大量的上行链路带宽的媒体同时发送至所有目的地，和现有的浏览器实现需要的CPU功率的显著量多次将视频编码并联。

Mixer解决方案

此混频器的做法是多会议传统的解决方案，并已使用多年取得了巨大成功。这一成功可以归功于它需要智能的端点最少的事实。该架构基于具有中心点保持单一到一个流与每个参与者。中心元件然后接收并混合每个传入音频和视频流，以产生一个单一的流出到每一个参加者。在视频会议行业对于这些集中元件的一个常见术语是多点控制单元（MCU）。在实践中，使用一个MCU的通常是指一个混合器溶液。

 

Mixer解决方案

混频器是供传统设备操作间很好的解决。它们还允许全位速率适配，因为混频器可以产生不同的输出流，以及每个接收器不同的品质。混合器解决方案的另一个优点是，它可以利用硬件解码设备中，提供了许多WebRTC中的设备将包括能力来解码芯片组单个视频频道。

的主要缺点是在MCU的基础设施成本。此外，由于混合需要解码和再编码，这引入额外的延迟和质量的损失。最后，转码和组合物可在理论上导致对应用程序的用户界面的弹性较小（尽管有此问题的解决方法）。

Router解决方案

路由器（或中继）的办法变得由H.264 SVC基础设施普及，这是正在使用的大部分的，如果没有任何遗留行李已经开始了新WebRTC中的平台的体系结构。该架构基于具有中心点从每个发送器接收一个流并发送出一个流的每一个参加者的每个。这个中心点只做数据包检测和转发，而不是昂贵的编码和实际的媒体的解码。

 

Router解决方案

路由器提供一个便宜的和可扩展的多方溶液，具有较好的延迟和与传统的混合器解决方案相比没有质量劣化。

在另一方面，在行业建设这些基础设施，以不同的接收器的经验较少，而且流的适应变得棘手。它需要在端点支持以产生流（即同时联播或VP8时间可伸缩性）的多个版本，可以在后面的路由器被选择性地转发，根据每个接收器的能力。

我应该使用哪种架构？

这个就需要根据自己的项目的需要了。其实，商业解决方案，包括为所有这些支持，以优化不同客户的使用案例。不过，也有经验，你可以使用一些通用规则。

如果您提供一个音频唯一的服务，或需要与传统设备的互操作性，那么，调音台的架构可能是最适合你的。此外，在一些情况下，所述基础设施的成本不是问题，并且参与者具有非常异构连接，这可以是一个很好的解决方案。

如果你正在建设一个服务被用户使用，真正的好连接和功能强大的设备（即一个企业内部服务），以及参加人数是有限的，那么你可能会得到一个网状结构的好成绩。

一般来说，如果你提供大规模服务的，应优先考虑到路由器的方法。在一天结束时，路由器溶液最接近把情报在网络的边界，构建最终用户应用程序时，以达到更好的可扩展性和灵活性的网络的范例。