zoukankan      html  css  js  c++  java
  • 拓展

    众所周知,WebRTC非常适合点对点(即一对一)的音视频会话。然而,当我们的客户要求超越一对一,即一对多、多对一设置多对多的解决方案或者服务,那么问题就来了:“我们应该采用什么样的架构?” 。简单的呢有人会考虑copy多个p2p就完成了多人之间的会话,可并没有考虑到到来的问题:cpu、内存、尤其是流量问题;传统的解决方案是MCU服务器,利用服务器硬件的能力去mix音视频,然后传给各个参与者,这能到达预想的,这个亦能到达我们的需求;使用基于网状拓扑结构的结构可能是前两者的折中之选。

    尽管能实现WebRTC多人音视频的方案,该技术的最流行的用途不局限于多方视频会议场景。不要以为只是传统的音视频会议室,更多的情况包括:智能硬件、ipcamera、在线课堂,实时直播等。在每一种情况下,服务器的能力是能够从多个源的媒体流分发到多个客户端。所以...如果你是一个服务供应商如何才能在实现支持WebRTC的多方拓扑结构?

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

    § 集中VS对等网络(P2P)

    § 混合VS路由。

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

    Mesh解决方案

    Mesh方法是最简单的解决方案。因为它不需要假设任何服务器,而且直接使用成熟的WebRTC传输方案。该体系结构基于从每一个发送者创建多个一对一的数据流到每一个接收端。

     

    Mesh解决方案

    该方案优点:

    1,服务端压力最小,大多数情况下不需要用到流媒体服务。

    该方案缺点:

    2,客户端负载太大,不事宜扩展,特别是移动端,编解码压力会非常大.

    即使它看起来像一个低效的解决方案,在实践中是非常有效的,并且延迟最低,每个接收端都会根据实际情况产生不同的比特率。

    唯一的问题是,这种解决方案需要大量的上行带宽将媒体流同时发送至所有目的地,现有的设备实现所需的CPU功率会显著上升。

    Mixer解决方案

    Mixer的做法是多人视频会议的传统解决方案,并且使用多年取得了巨大成功。这一成功可以归功于它需要客户端更少消耗这一事实。该架构基于具有中心点保持与每个参与者一对一的流的特性。中心元件接收并混合每个传入的音频流和视频流,以合成一个单一的流出到每一个参加者。在视频会议行业对于这些集中元件的一个常见术语是多点控制单元(MCU)。在实践中,使用一个MCU的通常是指一个混合器容器。

     

    Mixer解决方案

    该方案优点:

    1.1,客户端负载最小,与一对一负载一样,所以理论上可以支持很多人同时视频。

    1.2,因为服务端有做编解码,所以可与现有产品无缝集成。

    1.3,可以最大程度利用硬件能力,如硬件MCU,芯片。

    该方案缺点:

    1.1,服务端负载很大,建设成本很高。

    1.2,延迟问题,因为服务端做了很多动作(解码,合屏,混音,编码),所以会带来延迟。

    混频器是供传统设备操作间很好的解决方案。它们还允许全位速率适配,因为混频器可以产生不同的输出流,所以每个接收器有不同的品质。混合器解决方案的另一个优点是它可以利用硬件设备编解码。

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

    Router解决方案

    Router(或中继)的办法使得H.264 SVC基础设施普及,这也正是广泛应用的。该架构基于具有中心点从每个发送器接收一个流并发送出一个流到每一个参与者。这个中心点只做数据包检测和转发,而不是昂贵的编码和实际的媒体的解码。常见术语是SFU。

     

    Router解决方案

    该方案优点:

    1.1,与Mixer相比服务端压力比较小,而且容易扩展。

    1.2,低延迟,特别是与SVC结合能大大提升客户端体验度(貌似h265和vp9才开始集成svc)。

    该方案缺点:

    1.1,考虑到不同客户端需要不同的接收能力,所以真正实现下来服务端的架构也并不简单。

    Router提供一个便宜的可扩展的多方传输,具有较好的延迟性、与传统的mixer解决方案相比没有质量劣化。

    这种方案非常适合大并发的事实会议和直播。目前较成熟的服务提供商就是声网

    来一张各个解决方案的流量图?

    我应该使用哪种架构?

    这个就需要根据自己的项目的需要了。其实,商业解决方案,包括上述所有方案,往往需要根据客户的实际应用场景选择对于的方法。不过,也有经验,你可以使用一些通用规则。

    1、如果您仅是提供P2P音视频传输的服务,Mesh架构可能是最适合你的。另外,如果基础设施的成本不是问题,并且参与者具有异构连接,这可以是一个很好的解决方案。

    2、假设你提供企业级服务,且有较好的宽带和高效的硬件(即一个企业内部服务),参加人数是有限的,那么你非常适合Mixer方案。

    3、一般来说,如果你提供大规模服务的,应优先考虑到Router的方法。Router传输接近把情报在网络的边界,构建最终用户应用程序时,以达到更好的可扩展性和灵活性的网络的范例
    ---------------------

    参考链接  https://blog.csdn.net/gupar/article/details/53101435

  • 相关阅读:
    【漏洞分析】5次shift漏洞破解win7密码
    skyler实战渗透笔记(五)—Tr0ll
    skyler实战渗透笔记(四)—Raven2
    skyler实战渗透笔记(三)—Raven
    python读写excel文件
    python_列表
    mysql安装教程
    centos7安装RabbitMQ教程
    centos7安装mongodb4.2.15教程
    tomcat9安装教程
  • 原文地址:https://www.cnblogs.com/baitongtong/p/10393802.html
Copyright © 2011-2022 走看看