精华内容
下载资源
问答
  • Mesh/MCU/SFU架构

    2020-05-09 11:30:12
    问题:为什么要搞这么多架构? webrtc虽然是一项主要使用p2p的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很带宽和性能的问题,所以就有了下图的三种...

    问题:为什么要搞这么多架构?

    webrtc虽然是一项主要使用p2p的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很带宽和性能的问题,所以就有了下图的三种架构。

    点击看大图

    一、Mesh架构

    即:每个端都与其它端互连。以上图最左侧为例,5个浏览器,二二建立p2p连接,每个浏览器与其它4个建立连接,总共需要10个连接。如果每条连接占用1m带宽,则每个端上行需要4m,下行带宽也要4m,总共带宽消耗20m。而且除了带宽问题,每个浏览器上还要有音视频“编码/解码”,cpu使用率也是问题,一般这种架构只能支持4-6人左右,不过优点也很明显,没有中心节点,实现很简单。

     

    二、MCU (MultiPoint Control Unit)

    这是一种传统的中心化架构(上图中间部分),每个浏览器仅与中心的MCU服务器连接,MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑,每个浏览器只要1个连接,整个应用仅消耗5个连接,带宽占用(包括上行、下行)共10m,浏览器端的压力要小很多,可以支持更多的人同时音视频通讯,比较适合多人视频会议。但是MCU服务器的压力较大,需要较高的配置。

     

    三、SFU(Selective Forwarding Unit)

    上图右侧部分,咋一看,跟MCU好象没什么区别,但是思路不同,仍然有中心节点服务器,但是中心节点只负责转发,不做太重的处理,所以服务器的压力会低很多,配置也不象MUC要求那么高。但是每个端需要建立一个连接用于上传自己的视频,同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5,消耗的带宽也是最大的,如果每个连接1M带宽,总共需要25M带宽,它的典型场景是1对N的视频互动。

     

    目前,随着5G技术的推广,可以预见带宽越来越不是问题,所以SFU在未来,可能会更有优势。

     

    建议:如果规模不大(5人以下) Mesh框架就够用了,毕竟实现简单;如果50人以下,且带宽有限,选择MCU比较适合;如果规模更大,且带宽良好,SFU相对更适合。

    展开全文
  • WebRTC -- Mesh、MCU、SFU架构

    千次阅读 2019-10-28 16:19:21
    一、Mesh架构 在只有2个客户端参与情况下,我们可以使用上图的这种拓扑结构。但假如同时有3个客户端参与(如多人视频会议),如果还是按照上面的方式,拓扑结构就会变成: 从上图中,我们可以看到,在3人参与的实时...

    WebRTC是基于P2P的实时通信技术,(如果P2P打洞失败,则会使用TURN服务器进行数据转发),在有2台客户端参与的情况下,网络拓扑结构如图:
    在这里插入图片描述

    一、Mesh架构

    在只有2个客户端参与情况下,我们可以使用上图的这种拓扑结构。但假如同时有3个客户端参与(如多人视频会议),如果还是按照上面的方式,拓扑结构就会变成:
    在这里插入图片描述
    从上图中我们可以看到,在3人参与的实时通信中,每个客户端要维持4个连接(2个上行,2个下行);同理,如果有N个客户端参与,每个客户端就要维持N-1上行,N-1个下行,这样会极大的占用客户端的上行带宽和下行带宽;

    这种每个端之前完全使用P2P方式架构称之为Mesh架构。

    二、SFU (Selective Forwarding Unit)架构

    在这里插入图片描述
    SFU架构最核心的特点是把自己 “伪装” 成了一个 WebRTC 的客户端,WebRTC 的其他客户端其实并不知道自己通过 P2P 连接过去的是一台真实的客户端还是一台服务器,我们通常把这种连接称之为 P2S,即:Peer to Server。除了 “伪装” 成一个 WebRTC 的客户端外,SFU 服务器还有一个最重要的能力就是具备one-to-many的能力,即可以将一个客户端的数据转发到其他多个客户端。

    这种网络拓扑结构中,无论多少人同时进行视频通话,每个 WebRTC 的客户端只需要连接一个 SFU 服务器,上行一路数据即可,可以极大的减少多人视频通话场景下 Mesh模型给客户端带来的上行带宽压力。

    SFU服务器跟TURN服务器最大的不同是,TURN服务器仅仅是为 WebRTC 客户端提供的一种辅助的数据转发通道,在P2P不通的时候进行透明的数据转发。而 SFU 是 “懂业务” 的, 它跟 WebRTC 客户端是平等的关系,甚至 “接管了” WebRTC 客户端的数据转发的申请和控制。

    三、MCU (MultiPoint Control Unit)架构

    从上述 SFU 的定义可以看到,SFU 这种网络拓扑模型,通过由 SFU Server 来实现 one-to-many ,减轻了多人视频通话场景下每个客户端的上行带宽压力,但是下行依然是多路流,随着通话人数的增大,下行带宽的压力依然会成比例的增大,那能否让下行也只剩一路流呢?—— 可以,通过在服务器端合流后再下发即可解决,如下图所示:
    在这里插入图片描述

    目前,随着5G技术的推广,可以预见带宽越来越不是问题,所以SFU在未来,可能会更有优势。常见的开源 SFU 服务器有:LicodeJanusJitsimediasoupMedooze 等等。

    文章参考:
    WebRTC 开发实践:为什么你需要 SFU 服务器
    webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU

    展开全文
  • ion-sfu架构与模块

    2021-06-19 14:15:51
    上面给一个简单架构图,很多细节表示不出来,需要看代码。 1、简介 得益于GO,ion-sfu整体代码精简,拥有极高的开发效率。 结合现有SDK使用,可以避免很多坑:ion-sdk-js等。 ion-sfu基于pion/webrtc,所以代码风格...

    在这里插入图片描述
    上面给一个简单架构图,很多细节表示不出来,需要看代码。

    1、简介

    得益于GO,ion-sfu整体代码精简,拥有极高的开发效率。

    结合现有SDK使用,可以避免很多坑:ion-sdk-js等。

    ion-sfu基于pion/webrtc,所以代码风格偏标准webrtc,比如:PeerConnection

    因为是使用了标准API,熟悉了之后很容易看懂其他工程,比如:ion-sdk-go/js/flutter。

    这样从前到后,整体门槛都降低了。

    2、工程组织

    这里给出主要模块列表

    ├── Makefile //用来编译二进制和grpc文件
    ├── bin //编译好的二进制目录
    ├── cmd
    │ └── signal //包含三个主文件 grpc、jsonrpc、allrpc
    ├── config.toml //配置文件
    ├── examples //网页示例目录
    ├── pkg
    ├── buffer //buffer包,用于缓存包
    ├── logger //日志
    ├── middlewares //中间件,主要是支持自定义datachannel
    ├── relay //中继
    ├── sfu //sfu主模块,包含router、session、peer等
    ├── stats //状态统计
    └── twcc //transport-cc
    ion-sfu使用方式有两种:

    作为服务使用,比如编译带grpc或jsonrpc信令的ion-sfu,然后再做一个自己的信令服务(推荐ion分布式套装),远程调用即可。
    作为包使用,import导入,然后做二次开发;此时抛弃了cmd下边的信令层,只需导入pkg/sfu下边的包即可,然后自行定制信令层,可以在sfu、session、peer层面,通过继承接口定制自己的业务;比较复杂。
    import (
    sfu “github.com/pion/ion-sfu/pkg/sfu”
    )

    3、信令层

    信令代码和主程序在一起,在cmd/signal/下边

    支持jsonrpc,主要处理逻辑在:
    func (p *JSONSignal) Handle(ctx context.Context, conn *jsonrpc2.Conn, req *jsonrpc2.Request) {
    支持grpc,主要处理逻辑在:
    func (s *SFUServer) Signal(stream pb.SFU_SignalServer) error {
    而allrpc,是jsonrpc和grpc的合体封装,运行时会进入上面两个函数
    信令很简单:

    join:加入一个session。
    description:发起offer或回复answer,用于协商和重协商。
    trickle:发送trickle candidate。
    另外,出于简单考虑,一些信令和事件,直接走datachannel了,比如:大小流切换、声音检测、自定义信令等

    4、媒体层

    媒体层的主要模块

    ├── audioobserver.go //声音检测
    ├── datachannel.go //dc中间件的封装
    ├── downtrack.go //下行track
    ├── helpers.go //工具函数集
    ├── mediaengine.go //SDP相关codec、rtp参数设置
    ├── peer.go //peer封装,一个peer包含一个publisher和一个subscriber,双pc设计
    ├── publisher.go //publisher,封装上行pc
    ├── receiver.go //subscriber,封装下行pc
    ├── router.go //router,包含pc、session、一组receivers
    ├── sequencer.go //记录包的信息:序列号sn、偏移、时间戳ts等
    ├── session.go //会话,包含多个peer、dc
    ├── sfu.go //分发单元,包含多个session、dc
    ├── simulcast.go //大小流配置
    ├── subscriber.go //subscriber,封装下行pc、DownTrack、dc
    └── turn.go //内置turn server
    相比以前版本,增加了一些interface,主要是为了作为包使用时,封装自己的类。

    相关资源连接
    亢少军站点:http://www.kangshaojun.com
    亢少军 github: https://github.com/kangshaojun/
    文章转载自:https://zhuanlan.zhihu.com/p/376554019

    展开全文
  • TSINGSEE青犀视频研发团队于2020年上线的EasyRTC-SFU视频会议系统,就是采取了多媒体路由(multimedia routing)的设计,从而消除了对集中式MCU服务器的需求,与传统技术相比,这种新设计对带宽更加友好,这就是...

    我们对视频会议搭建的固定印象是什么?固定的会议室+固定的视频会议设备+指定的终端进入来实现远程音视频传输。那如果设备故障怎么办?人员无法到齐如何参会?使用硬件搭建视频会议系统除了高昂的成本外,还使得会议流程异常繁琐,维护成本高,开发难度大,需要对接各种设备的SDK来实现,进而导致硬件视频会议的渗透率低,只适合大型公司使用。

    352.png

    而随着5G时代的到来、通信技术大幅提升,依靠软件服务的云视频会议显示出优势,数据的传输、处理、存储全部由云服务器处理,用户完全无需再购置昂贵的硬件和安装繁琐的软件,只需打开浏览器,登陆相应界面,就能进行高效的远程会议。

    比起传统的硬件型视频会议,云视频会议在方便性、快捷性、易用性上具有更显著的优势。与此同时,中小型企业也成为云视频会议市场增长的主要驱动力,有着巨大的增量市场前景。

    EasyRTC会议直播观看.png

    据统计数据显示,我国视频会议行业主要由政府机关,医疗、教育、金融等领域的公共事业机构及企业带动需求,整个市场规模逐年增长,近年来增长率保持在20%以上,2018年我国视频会议市场规模约155.6亿元,预计至2022年,我国视频会议市场规模将达到445.7亿元。并且根据统计数据预测,到2025年国内云视频会议市场规模将超过硬件支撑的传统视频会议市场规模。

    353.png

    TSINGSEE青犀视频研发团队于2020年上线的EasyRTC-SFU视频会议系统,就是采取了多媒体路由(multimedia routing)的设计,从而消除了对集中式MCU服务器的需求,与传统技术相比,这种新设计对带宽更加友好,这就是EasyRTC-SFU既可以在高带宽也可以在低带宽情况下工作的原因。该方案适合企业规模大,且带宽资源良好的应用场景。

    方案功能特点

    • 简单易用,最便捷的方式可以通过网页、APP进入会议室参会,不需要插件;
    • 支持多种终端,电脑、手机、大屏TV,拥有App、H5,支持接入小程序,可覆盖全平台;
    • WebRTC低延时架构,即使网络环境再差,也能保证会议顺畅沟通;
    • 支持屏幕共享、本地投屏,能够同步呈现各类文档、视频、图片,实现信息同步和资料的实时共享;
    • 提供私有化部署,支持二次开发,可与企业实现系统对接;

    354.png

    展开全文
  • Webrtc音视频会议之Mesh/MCU/SFU常用架构列出这三种架构的优缺点,通过这种对比让我们在音视频会议架构设计的时候能...并且让我们对这三种架构有一个更准确的认识同时为后续为什么我选择SFU架构的Janus项目来研究做准备
  • Licode-SFU架构

    千次阅读 2019-12-20 17:41:11
    这个流程在Licode代码中是通过Pipeline-Handler这样的架构实现的,由于webrtc仅提供底层算法并未提供SFU架构,所以我认为这种架构是Licode最重要的关键技术,可供未来想成为软件架构师的开发者参考学习。日后我也再...
  • 了解TSINGSEE青犀视频产品的小伙伴都知道,目前在视频会议系统相关产品上,我们已有两款,一款是基于MCU架构的EasyRTC-MCU版,一个是基于SFU架构的EasyRTC-SFU版,那企业在选择的时候应该如何选择适合自己业务场景的...
  • webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU https://www.cnblogs.com/yjmyzz/p/11182761.html
  • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构 WebRTC 本身提供的是 1 对 1 的通信模型,在 STUN/TURN 的辅助下,如果能实现 NAT 穿越,那么两个浏览器是可以直接进行媒体数据交换的;如果不能实现 NAT 穿越,...
  • sfu

    2013-07-31 14:25:00
    为什么80%的码农都做不了架构师?>>> ...
  • 问题:为什么要搞这么多架构? WebRTC 虽然是一项主要使用 P2P 的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很带宽和性能的问题,所以就有了下图的三种...
  • 问题:为什么要搞这么多架构? webrtc虽然是一项主要使用p2p的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很带宽和性能的问题,所以就有了下图的三种...
  • 了解我们产品的小伙伴都知道,目前在视频会议系统相关产品上,我们已有两款,一款是基于MCU架构的EasyRTC-MCU版,一个是基于SFU架构的EasyRTC-SFU版,用户可以根据自身需求进行选择。 在EasyRTC-SFU软件开发过程...
  • 了解我们产品的小伙伴都知道,目前在视频会议系统相关产品上,我们已有两款,一款是基于MCU架构的EasyRTC-MCU版,一个是基于SFU架构的EasyRTC-SFU版,用户可以根据自身需求进行选择。 在EasyRTC-SFU软件开发过程...
  • 因为WebRTC技术是目前使用最广泛的即时通信技术,虽然在早期我们提到WebRTC、提到视频通话就会想到P2P的方式,但实际的视频通话方式背后的逻辑有很多种,p2p并不能解决所有的网络通信问题,视频通话会采用多种架构相...
  • Webrtc一对一的通信,通常采用的是端到端的方式,那如果多人通信的架构方案一般有这三种常见的方案 Mesh方案 即多个终端之间两两进行连接,形成一个网状结构。比如 A、B、C 三个终端进行多对多通信,当 A 想要共享...
  • 因为WebRTC技术是目前使用最广泛的即时通信技术,虽然在早期我们提到WebRTC、提到视频通话就会想到P2P的方式,但实际的视频通话方式背后的逻辑有很多种,p2p并不能解决所有的网络通信问题,视频通话会采用多种架构相...
  • 编者按:本文由百度智能云RTC产品技术负责人 李永兴LiveVideoStack线上分享的内容整理而成,从系统架构角度,分析了常见的开源SFU在分布式部署以及高可用、高并发方面的不足,并提出相应的解决方案。 大家好,我是...
  • 但是基于目前的直播状况,现在最合适的,也是使用比较多的是SFU架构。但是SFU架构除了客户端的webrtc需要完成,更重要的服务器也需要搭建。 如果你需要多人连麦直播   Janus-gateway-iOS是一个基于janus-gateway...
  • 如何构建分布式SFU/MCU媒体服务器?

    千次阅读 2019-07-30 17:59:53
    本文来自英特尔实时通信解决方案架构师 段先德在LiveVideoStackCon2019上海大会的分享,详细介绍了英特尔在进行分布式SFU/MCU媒体服务器的架构设计中秉...
  • 介绍 Jitsi Videobridge是XMPP服务器组件,允许进行多用户视频通信。 与昂贵的专用硬件视频桥不同,Jitsi Videobridge不会将视频通道混合到复合视频流中,而只会将接收到的视频通道中继到所有呼叫参与者。...
  • 6月14日 19:30,我们邀请到了百度智能云RTC产品技术负责人 李永兴从系统架构角度,分析常见的开源SFU在分布式部署以及高可用、高并发方面的不足,并提出相应的解决方案,对RTC云...
  • 常见的多方通信架构方案 Webrtc一对一的通信,通常采用的是端到端的方式,那如果多人通信的架构方案一般有这三种常见的方案 Mesh方案 即多个终端之间两两进行连接,形成一个网状结构。比如 A、B、C 三个终端进行...
  • 企业视频通话会议系统EasyRTC基于网络架构,各分支机构与总部之间使用IP线路连接,在总部部署服务器提供视频调度指挥服务,能够进行视频会议、远程培训、协同工作等沟通。近期更新的新版本EasyRTC-SFU更是在原有基础...

空空如也

空空如也

1 2 3 4
收藏数 69
精华内容 27
关键字:

sfu架构