尝鲜:搭建一个多对多的音视频通信服务

简介: 前几天了解了 WebRTC 服务,并且基于 webrtc 官方的 apprtc 项目搭建一个1v1的音视频对话,参见 ``尝鲜:如何搭建一个简单的webrtc服务器``。有了1v1的实战,再来看多方音视频通信的方案,看看和1v1的方案的关系与不同。

前言

前几天了解了 WebRTC 服务,并且基于 webrtc 官方的 apprtc 项目搭建一个1v1的音视频对话,参见尝鲜:如何搭建一个简单的webrtc服务器。有了1v1的实战,再来看多方音视频通信的方案,看看和1v1的方案的关系与不同。

多方音视频通信三种架构方案

一、Mesh 方案

即多个终端之间两两进行连接,形成一个网状结构。这种方案是1v1 WebRTC 通信模型的扩展版,任何两个结点都可以看成一个1v1 WebRTC 通信模型。

Mesh 方案架构图

优势:不需要服务器中转数据,STUN/TUTN 只是负责 NAT 穿越,这样利用现有 WebRTC 通信模型就可以实现,而不需要开发媒体服务器。

劣势:需要给每一个参与人都转发一份媒体流,这样对上行带宽的占用很大。参与人越多,占用的带宽就越大。客户端的机器资源的占用与参与人数成正比,当参与人数过多时,此方案就不可用了。通过实践来看,这种方案在超过 4 个人时,就会有非常大的问题。 另外,由于STUN/TUTN 只是负责 NAT 穿越,如果有部分人不能实现 NAT 穿越,就无法连接。

二、MCU(Multipoint Conferencing Unit)方案

该方案由一个服务器和多个终端组成一个星形结构。MCU 主要的处理逻辑是:接收每个共享端的音视频流,经过解码、与其他解码后的音视频进行混流、重新编码,之后再将混好的音视频流发送给房间里的所有人。

MCU方案架构图

实际上服务器端就是一个音视频混合器,这种方案服务器的压力会非常大。MCU 技术在视频会议领域出现得非常早,目前技术也非常成熟,主要用在硬件视频会议领域。

三、SFU(Selective Forwarding Unit)方案

该方案也是由一个服务器和多个终端组成,但与 MCU 不同的是,SFU 不对音视频进行混流,收到某个终端共享的音视频流后,就直接将该音视频流转发给房间内的其他终端。

SFU 的拓扑机构和功能模型

它实际上就是一个音视频路由转发器,并且它可以根据终端下行网络状况做一些流控,可以根据当前带宽情况、网络延时情况,选择性地丢弃一些媒体数据,保证通信的连续性。下面详细介绍一下。

总结

相比 Mesh方案,SFU 和 MCU 都需要中转服务器。由于 MCU 方案需要将多路视频混合成一路,需要大量的运算,对 CPU 资源的消耗很大,一般需要专门的硬件进行处理。而 SFU 方案由于不需要多路视频混编,所以对 CPU 的需求没有那么大,但它可能导致在多路视频的情况下,会有在同一时刻,不同的人看到的画面不一致的问题。

所以,如果你不想用中转服务器,就选择 Mesh方案;如果你对多路视频的一致性要求高,有专门硬件,建议选择 MCU 模式;其他情况建议使用 SFU 模式。

SFU方案

SFU 方案根据在网络延时时丢弃媒体数据的方式不同,分为 Simulcast 模式和 SVC 模式,

Simulcast 模式

Simulcast 模式

所谓 Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流(一般为三路,如 1080P、720P、360P)。而 SFU 可以将接收到的三路流根据各终端的情况而选择其中某一路发送出去。

例如,由于 PC 端网络特别好,给 PC 端发送 1080P 分辨率的视频;而移动网络较差,就给 Phone 发送 360P 分辨率的视频。

SVC 模式

SVC 模式

SVC 是可伸缩的视频编码模式。它在视频编码时将视频分成多层 —— 核心层、中间层和扩展层。上层依赖于底层,而且越上层越清晰,越底层越模糊。在带宽不好的情况下,可以只传输底层,即核心层,在带宽充足的情况下,可以将三层全部传输过去。

部署多方视频会议服务

基于上面的分析,我们实现一个基于SFU 方案的项目。开源项目包括 LicodeJanus-gatewayMediaSoupMedooze。这儿我们部署基于 Medooze的 Demo 项目SFU

运行环境准备

  • 操作系统:Ubuntu 18.04
  • 语言环境:NodeJS
apt-get update && apt-get install -y nodejs npm git-core

安装依赖

git clone https://github.com/medooze/sfu.git
cd sfu
npm install

生成证书

生成证书这部分参考尝鲜:如何搭建一个简单的webrtc服务器。证书这块未来有时间集成整理一下。

启动服务

node index.js IP

Docker 服务

Dockerfile 文件

FROM ubuntu:18.04

WORKDIR /
RUN apt-get update && apt-get upgrade && apt install -y nodejs npm git-core python3 wget curl && npm install -g n && n stable
RUN hash -r && npm install -g npm@8.5.5
RUN git clone https://github.com/medooze/sfu

WORKDIR /sfu
RUN npm install
RUN openssl req -x509 -out ./server.cert -keyout ./server.key   -newkey rsa:2048 -nodes -sha256   -subj '/CN=*'
ENTRYPOINT ["node" "index.js"]

Docker 镜像

// 可以用上面的 Dockerfile 文件自己打镜像,也可用用我已经打包好的镜像
docker pull zhaowg/sfu:v1

Docker 版使用方法

docker run -it --net=host  zhaowg/sfu:v1 <IP>

参考

相关实践学习
搭建简易多人在线视频会议系统
本场景将介绍使用音视频服务单间一个简易的视频会议室。
目录
相关文章
|
Web App开发 编解码 算法
发现一个非常好用的RTC(实时音视频通信)方案,做直播和视频通话都很牛
HaaS RTC是阿里云IoT联合视频云开发的IoT设备端上的实时通讯服务,主要面向直播,音视频通话等各种场景。
2277 15
发现一个非常好用的RTC(实时音视频通信)方案,做直播和视频通话都很牛
|
机器学习/深度学习 编解码 人工智能
HaaS RTC(实时音视频通信)总体方案简介
RTC(Real Time Communication)实时通信业务,目的是在设备端实时的转发音视频多媒体数据,让用户能实时的进行音频和视频的会话。
948 15
HaaS RTC(实时音视频通信)总体方案简介
|
缓存
RTC-实时音视频通信技术介绍与应用
疫情打乱了我们的生活节奏,也改变了我们生活工作的方式。自疫情爆发以来,为了减少人员的聚集,避免疫情扩散传播,居家办公、远程办公变成一种办公常态。云视频会议凭借其低成本、灵活性强等优势迅速抢占视频会议市场份额,也深入走进老百姓的日常生活。那么网络云会议背后的技术力量是什么呢? 答案是:RTC-实时音视频技术。
897 0
RTC-实时音视频通信技术介绍与应用
|
机器学习/深度学习 编解码 人工智能
HaaS RTC(实时音视频通信)总体方案简介
RTC(Real Time Communication)实时通信业务,目的是在设备端实时的转发音视频多媒体数据,让用户能实时的进行音频和视频的会话。
HaaS RTC(实时音视频通信)总体方案简介
|
开发工具 Android开发
音视频通信 RTC - SDK V1.9发布
信息摘要: 优化音视频传输质量、弱网传输、通信稳定性和设备兼容性,全平台音视频通信体验大幅提升。适用客户: 适用于在线教育、互动娱乐、多媒体社交及音视频通信行业应用开发者版本/规格功能: 1. 视频质量优化,降低画面像素破损发生率 2.
8760 0
|
Web App开发 开发工具 Android开发
|
小程序 PHP
微信公众号开发(一)打通服务器与微信之间的通信
说来惭愧PHP做了这么久,好像就没有从头开发过一个微信公众号,这次刚好有机会从头接入开发一个完整的公众号,也不能说完整,但是这些微信的接口我基本上都试一试~看看大概是什么情况。 首先:打通服务器与微信之间的通信。
137 0
|
Web App开发 开发工具 Android开发
Android平台不需要单独部署流媒体服务如何实现内网环境下一对一音视频互动
我们在做内网环境的一对一音视频互动的时候,遇到这样的技术诉求:如智能硬件场景下(比如操控智能硬件),纯内网环境,如何不要单独部署RTMP或类似流媒体服务,实现一对一音视频互动。
|
7月前
|
Web App开发 编解码 监控
RTSP协议探秘:从原理到C++实践,解锁实时流媒体传输之道
RTSP协议探秘:从原理到C++实践,解锁实时流媒体传输之道
2529 0
|
7月前
|
Web App开发 移动开发 前端开发
WebRTC 入门:开启实时通信的新篇章(上)
WebRTC 入门:开启实时通信的新篇章(上)