精华内容
下载资源
问答
  • webrtc开源服务器
    2022-03-06 19:24:39


    1.掌握深度学习图像处理(基于keras、tensorflow、opencv)
    2.掌握web前后端设计(基 于flask框架)
    3.开发基于web端的深度学习图像,把web端应用与人工智能相结合

    视频教程:
    https://edu.csdn.net/course/detail/28400/391614?pre_view=1

    详细安装方法可以参考官网:https://github.com/meetecho/janus-gateway

    依赖库

    编译运行 Janus Server 需要依赖较多的一些第三方库,而这些依赖库在 Ubuntu 下主要通过 aptitude 进行安装,首先通过安装 aptitude:
    sudo apt-get install aptitude

    安装依赖库:
    sudo aptitude install libmicrohttpd-dev libjansson-dev libnice-dev
    sudo aptitude install libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev
    sudo aptitude install libopus-dev libogg-dev libcurl4-openssl-dev pkg-config gengetopt libtool automake

    liblua5.3-dev找不到,所以我也没有装了。

    使用命令确定是否安装libs nice:pkg-config --cflags --libs nice


    安装 WebSocket

    janus 支持 WebSocket 是可选项,如果不安装,编译 janus 时,默认不支持 WebSocket 的链接请求,而 Android APP Demo 是通过 WebSocket 与 janus 进行通信的,因为我们希望 Android APP Demo 能与浏览器(HTTP)进行视频通话,所以就必须要在编译 janus 时支持 WebSocket。
    依次执行以下命令,分别进行下载,编译,安装:
    git clone git://git.libwebsockets.org/libwebsockets
    cd libwebsockets
    mkdir build
    cd build
    cmake -DLWS_MAX_SMP=1 -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS="-fpic" …
    make && sudo make install


    编译Janus

    通过 Git 下载 Janus 源码,并编译安装:
    git clone https://github.com/meetecho/janus-gateway.git
    cd janus-gateway
    sh autogen.sh
    ./configure --prefix=/opt/janus --enable-websockets --disable-plugin-lua
    make
    make install

    运行Janus

    安装后执行目录:/opt/janus/bin/janus –help
    WebSocket 的配置放在:
    vim ./janus-gateway/conf/janus.transport.websockets.cfg.sample
    配置插值打开cfg放在此目录
    cd /opt/janus/etc/janus
    janus.cfg.sample

    启动时需要配置文件,可以自己拷贝:
    cp janus.cfg.sample janus.cfg复制一份,然后可以自动找到此文件。
    然后也可以使用脚本全部一次性拷贝.
    make configs//如果不执行此命令,会报找不到插件。
    启动 Janus:
    /opt/janus/bin/janus --configs-folder=/opt/janus/etc/janus/
    注意上面的启动是不带打洞功能的。那么如果两个异地视频聊天,那么需要配置对应的turn服务器。而且必须在此配置,之前我一直在js文件中配置是有问题的。我是用阿里云服务搭建coturn穿透服务器,至于怎么搭建turn服务器,请看我另一篇文章https://blog.csdn.net/bvngh3247/article/details/80742396。
    /opt/janus/bin/janus --configs-folder=/opt/janus/etc/janus/ --stun-server=1.1.1.1:3478

    访问Janus的demo,其安装位置是:
    cd /opt/janus/share/janus/demos
    cd到这个目录后,使用以下命令用python搭个临时的web服务:
    python -m SimpleHTTPServer 8080

    打开网址:http://1.1.1.1:8080/ 就可以看到可以浏览访问了,其中1.1.1.1是我的公网IP地址。如下是用手机,两台电脑,使用firefox浏览器测试。


    ————————————————
    版权声明:本文为CSDN博主「风口上的传奇」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/bvngh3247/article/details/80648584

    更多相关内容
  • WebRTC及其发展前景 WebRTC,名称源自网页即时通信(Web Real-Time Communication)...WebRTC是一个免费的开源项目,它通过简单的API为浏览器和移动应用程序提供实时通信(RTC)功能。 WebRTC虽然冠以“web”之名,但并

    WebRTC及其发展前景

    WebRTC,名称源自网页即时通信(Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音通话或视频通话的API,旨在建立一个互联网浏览器间的实时通信的平台。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。WebRTC官网的介绍如下:

    在这里插入图片描述

    WebRTC是一个免费的开源项目,它通过简单的API为浏览器和移动应用程序提供实时通信(RTC)功能。

    WebRTC虽然冠以“web”之名,但并不受限于传统互联网应用或浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备(Android或iOS)还是IoT设备,只要IP连接可到达且符合WebRTC规范就可以互通。这一点释放了大量智能终端(或运行在智能终端上的app)的实时通信能力,打开了许多对于实时交互性要求较高的应用场景的想象空间,譬如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。WebRTC也当之无愧的变成了当前实时音视频领域内的宠儿。

    社区中的WebRTC开源服务器

    WebRTC作为当前实时音视频领域的宠儿,开源社区对WebRTC服务器的支持也很多,下面是几个比较出名的开源项目:

    · Jitsi:开源的视频会议平台,对标zoom,googlemeeting包括Jitsi Videobridge(媒体中继),Jitsi Meet(会议web客户端),Jicofo(Jitsi Conference Focus),Jigasi(Jitsi Gateway to SIP)

    · Kurento:它是功能比较强大的一个多媒体处理框架,支持WebRTC协议栈。它可以作为Media server,后台有转码的能力,并且有OpenCV处理能力, 不仅仅是一个媒体服务器,且构建了一整套工具包。

    · Licode:可以作为WebRTC的轻量通信平台,是纯转发的服务器处理模式。

    · Janus:可以作为WebRTC通信网关,比较轻量。

    · Red5Pro:专注于视频直播和媒体流转发处理的WebRTC媒体服务器,支持服务器端和客户端SDK开发,支持的编码方式较多。

    · Ant-Media-Server:Ant-Media-Server是从red5pro 克隆出来的开源项目,它目前支持两个不同的版本:开源版本和企业版本。

    · Mediasoup: 一个相对较新且有趣的媒体服务器,它与其他媒体服务器的不同之处在于它被设计为一个Library(用于Node),允许它集成到更多的应用程序中。

    WebRTC开源服务器商业化需要踩的坑

    开源社区的支持让开发者可以很快搭建一个基于WebRTC开源服务器的demo,比如一个视频会议系统,用开源的项目,搭建的速度很快,搭建完毕在web端就能使用,很容易让人产生可以快速产品商业化的感觉。一个商业化的产品,从最开始的Demo,到最后的成型商业化运作, 需要踩哪些坑,经历哪些挑战呢?

    • 多平台:WebRTC主要是面向web应用的,虽然也能用native开发,但开源社区对手机端的支持几乎没有,在安卓或者IOS端,编译调试WebRTC的工程项目复杂过高,搭建编译环境时都会遇到很多意想不到的问题,特别是在大陆复杂的网络环境下。

    • 多用户&级联:WebRTC服务器商用一般都使用SFU组网,大量用户接入单台服务器承载能力有限,需要考虑服务器集群之间的级联,音视频流需要在多台服务器间级联,开源服务器在这块缺乏整体的服务器设计和部署方案。

    在这里插入图片描述

    • 弱网接入:WebRTC有一套自己的传输策略,比如重传,带宽监测,动态码率等,但是我们一但在中间加上一个转发节点,就做不到完整的端到端传输链路,WebRTC自有的传输策略效果不怎么好。如何在客户端和服务器的上下行链路上分别做优化,如何在弱网的情况下尽力保障视频和音频的流畅性,有很多难题需要解决。

    • 信令和媒体的分离:如果流媒体服务和信令服务混在一起,服务器高负载情况下媒体服务会占用非常多的系统资源,将影响到信令服务的正常工作,这两个服务的职责完全不一样,应该把服务的每个模块解藕分离开,每个服务专做一件事,提高服务器资源利用率。但不幸的是在WebRTC开源服务器中,它们是耦合在一起的。

    • 单一端口:WebRTC开源服务器在进行互动通信的时候,每一个音视频流需要占用一个端口,如果是n路视频需要n个udp端口,对端口资源造成极大浪费,一些政企、金融等安全要求高的单位会对防火墙多udp端口的开放做限制,实际互联网运维中多端口也会给运维造成极大的不便,从海量用户和运维的角度都需要把音视频流端口改造为单一端口模式。

    • 兼容性:视频和音频设备的适配问题,比如如回声、录音失败、摄像头打不开、屏幕录制失败等问题层出不穷,单厂商的苹果系统,都要考虑iPhone2G到iPhone13这么多机型和版本的兼容性。更别提厂商混战的安卓,众多安卓厂商都会在标准的安卓框架上进行定制化,会有层出不穷的兼容性问题,调节音量失败,啸叫,摄像头镜像等等问题。还有各种IoT设备的兼容性适配。

    在这里插入图片描述

    • 边缘接入&调度:之前提到WebRTC缺乏完整的服务器方案,面对多地多用户接入的场景,单节点是难以满足业务要求的,必须要引入多地部署的分布式服务器方案,这样就需要考虑多地部署的服务器之间数据流转路由,需要一套好的路由算法做支撑。

    在这里插入图片描述

    • 可用性/可定位性:为了产品商业化,WebRTC的服务端逐步演进成了多地多机部署的分布式服务器架构。如何保证服务的高可用性,如何解决海量并发,如何监控这么复杂的组网,发生了掉线,卡顿,时延,怎么去定位问题原因,这些都是复杂的问题。

    WebRTC作为实时音视频领域最流行的框架,在开放源码中也提供了很多高技术含量的功能,但从一个demo演进到一个成熟商业化产品,需要一个集合音频,视频,运维等领域方面专家的团队,去日积月累的打磨特性,持之以恒的累积经验,才能高效稳定的提供基于WebRTC的成熟商业化实时音视频产品方案。

    实时音视频通讯解决方案,底层基于WebRTC,客户端Sdk兼容性强,音视频处理算法、音频3A、降噪、网络传输、服务集群技术全部自研,极好的解决了开源WebRTC服务面临的痛点。实时音视频服务集群,不仅仅能在公有云上部署运行,像金融、政企、安防等对数据比较敏感的客户,还可提供私有化部署方案,保障数据的安全性。不管多复杂的网络环境,服务架构灵活,只要客户所处环境需要实时音视频服务,可保障“有网即可达”。

    在这里插入图片描述

    展开全文
  • 那么如果两个异地视频聊天,那么需要配置对应的turn服务器。而且必须在此配置 /opt/janus/bin/janus –configs-folder=/opt/janus/etc/janus/ –stun-server=1.1.1.1:3478 访问Janus的demo,其安装位置是: cd /opt/...

    依赖库

    编译运行 Janus Server 需要依赖较多的一些第三方库,而这些依赖库在 Ubuntu 下主要通过 aptitude 进行安装,首先通过安装 aptitude:

    sudo apt-get install aptitude

    安装依赖库:

    sudo aptitude install libmicrohttpd-dev libjansson-dev libnice-dev

    sudo aptitude install libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev

    sudo aptitude install libopus-dev libogg-dev libcurl4-openssl-dev pkg-config gengetopt libtool automake

    liblua5.3-dev找不到,所以我也没有装了。

    使用命令确定是否安装libs nice:pkg-config –cflags –libs nice

    安装 WebSocket

    janus 支持 WebSocket 是可选项,如果不安装,编译 janus 时,默认不支持 WebSocket 的链接请求,而 Android APP Demo 是通过 WebSocket 与 janus 进行通信的,因为我们希望 Android APP Demo 能与浏览器(HTTP)进行视频通话,所以就必须要在编译 janus 时支持 WebSocket。

    依次执行以下命令,分别进行下载,编译,安装:

    git clone git://git.libwebsockets.org/libwebsockets

    cd libwebsockets

    mkdir build

    cd build

    cmake -DLWS_MAX_SMP=1 -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS=”-fpic” ..

    make && sudo make install

    编译Janus

    通过 Git 下载 Janus 源码,并编译安装:

    git clone github.com/meetecho/ja…

    cd janus-gateway

    sh autogen.sh

    ./configure –prefix=/opt/janus –enable-websockets –disable-plugin-lua

    make

    make install

    运行Janus

    安装后执行目录:/opt/janus/bin/janus –help

    WebSocket 的配置放在:

    vim ./janus-gateway/conf/janus.transport.websockets.cfg.sample

    配置插值打开cfg放在此目录

    cd /opt/janus/etc/janus

    janus.cfg.sample启动时需要配置文件,可以自己拷贝:

    cp janus.cfg.sample janus.cfg复制一份,然后可以自动找到此文件。

    然后也可以使用脚本全部一次性拷贝.

    make configs//如果不执行此命令,会报找不到插件。

    启动 Janus:

    /opt/janus/bin/janus –configs-folder=/opt/janus/etc/janus/

    注意上面的启动是不带打洞功能的。那么如果两个异地视频聊天,那么需要配置对应的turn服务器。而且必须在此配置

    /opt/janus/bin/janus –configs-folder=/opt/janus/etc/janus/ –stun-server=1.1.1.1:3478

    访问Janus的demo,其安装位置是:

    cd /opt/janus/share/janus/demos

    cd到这个目录后,使用以下命令用python搭个临时的web服务:

    python -m SimpleHTTPServer 8080

    有需要Java资料的可以加我微信号

    展开全文
  • 最原始的直播系统其实并没有想象的那么复杂,无非就是主播端将音视频数据推送到服务器,观众端则从服务器拉取数据播放。

    1 直播基础知识

    最原始的直播系统其实并没有想象的那么复杂,无非就是主播端将音视频数据推送到服务器,观众端则从服务器拉取数据播放。

    1.1 基本常识

    1.1.1 基础概念

    • 推流  推流,是直播中的一个术语,意思是将流媒体数据推送到服务器。如何推流,关键就在于使用的推流协议。
    • 拉流  拉流,指的是 观众端 流媒体数据的拉取,同样也需要通过约定的拉流协议来拉取。
    • 视频帧  帧,是视频的一个基本概念,表示一张画面,如上面的翻页动画书中的一页,就是一帧。一个视频就是由许许多多帧组成的。
    • 帧率  帧率,即单位时间内帧的数量,单位为:帧/秒 或fps(frames per second)。如动画书中,一秒内包含多少张图片,图片越多,画面越顺滑,过渡越自然。 帧率的一般以下几个典型值:
    • 24/25 fps:1秒 24/25 帧,一般的电影帧率。
    • 30/60 fps:1秒 30/60 帧,游戏的帧率,30帧可以接受,60帧会感觉更加流畅逼真。
    • 85 fps以上人眼基本无法察觉出来了,所以更高的帧率在视频里没有太大意义。

    色彩空间这里我们只讲常用到的两种色彩空间。

    • RGB RGB的颜色模式应该是我们最熟悉的一种,在现在的电子设备中应用广泛。通过R G B三种基础色,可以混合出所有的颜色。
    • YUV YUV是一种亮度与色度分离的色彩格式。早期的电视都是黑白的,即只有亮度值,即Y。有了彩色电视以后,加入了UV两种色度,形成现在的YUV,也叫YCbCr。 Y :亮度,就是灰度值。除了表示亮度信号外,还含有较多的绿色通道量。 U :蓝色通道与亮度的差值。 V :红色通道与亮度的差值。

    因为人眼对亮度敏感,对色度不敏感,因此减少部分UV的数据量,人眼却无法感知出来,这样可以通过压缩UV的分辨率,在不影响观感的前提下,减小视频的体积。

    • 采样率采样率即采样的频率。采样率要大于原声波频率的2倍,人耳能听到的最高频率为20kHz,所以为了满足人耳的听觉要求,采样率至少为40kHz,通常为44.1kHz,更高的通常为48kHz。

    • 采样位数采样位数涉及到声波的振幅量化。波形振幅在模拟信号上也是连续的样本值,而在数字信号中,信号一般是不连续的,所以模拟信号量化以后,只能取一个近似的整数值,为了记录这些振幅值,采样器会采用一个固定的位数来记录这些振幅值,通常有8位、16位、32位。位数越多,记录的值越准确,还原度越高。 由于数字信号是由0,1组成的,因此,需要将幅度值转换为一系列0和1进行存储,也就是编码,最后得到的数据就是数字信号:一串0和1组成的数据。

    • 声道数声道数,是指支持能不同发声(注意是不同声音)的音响的个数。  单声道 :1个声道  双声道 :2个声道  立体声道 :默认为2个声道  立体声道(4声道) :4个声道

    • 码率码率,是指一个数据流中每秒钟能通过的信息量,单位bps(bit per second)  码率 = 采样率 * 采样位数 * 声道数

    1.1.2 视频编码

    编码可以大大减小音视频数据的大小,让音视频更容易存储和传送。视频编码格式有很多,比如H26x系列和MPEG系列的编码,这些编码格式都是为了适应时代发展而出现的。 其中,H26x(1/2/3/4/5)系列由ITU(International Telecommunication Union)国际电传视讯联盟主导。MPEG(1/2/3/4)系列由MPEG(Moving Picture Experts Group, ISO旗下的组织)主导。

    1.1.3 音频编码

    原始的PCM音频数据也是非常大的数据量,因此也需要对其进行压缩编码。 和视频编码一样,音频也有许多的编码格式,如:WAV、MP3、WMA、APE、FLAC等等。 在MP4视频中的音频数据,大多数时候都是采用AAC压缩格式。AAC是新一代的音频有损压缩技术,一种高压缩比的音频压缩算法。

    1.1.4 音视频容器

    我们熟悉的视频格式,如mp4、rmvb、avi、mkv、mov...,其实是包裹了音视频编码数据的容器,用来把以特定编码标准编码的视频流和音频流混在一起,成为一个文件。 例如:mp4支持H264、H265等视频编码和AAC、MP3等音频编码。

    1.1.5 硬解码和软解码

    在手机或者PC上,都会有CPU、GPU或者解码器等硬件。通常,我们的计算都是在CPU上进行的,也就是我们软件的执行芯片,而GPU主要负责画面的显示(是一种硬件加速)。

    所谓软解码,就是指利用CPU的计算能力来解码,通常如果CPU的能力不是很强的时候,一则解码速度会比较慢,二则手机可能出现发热现象。但是,由于使用统一的算法,兼容性会很好。

    硬解码,指的是利用手机上专门的解码芯片来加速解码。通常硬解码的解码速度会快很多,但是由于硬解码由各个厂家实现,质量参差不齐,非常容易出现兼容性问题。

    1.2 基础直播流程

    通过下面这个数据流程图,能清晰地看到整个直播的过程。

    可以看到, 主播客户端 处理的事情,其实就是 短视频开发 中最重要的内容:

    唯一不一样的地方,短视频会将封装好的数据保存到本地,直播则是通过  推流协议 将数据推送到服务器。

    1.3 直播中的重难点

    在直播中,有几个非常重要的地方,会直接影响直播效果,导致用户流失。

    1.3.1 首屏时间

    首屏时间,即从观众打开直播,到看到画面呈现出来的时间。影响这个时间的是 H264 编码中的一个概念: GOP 。 GOP :Group of Picture,即一组帧组成的一个序列。在 H264 中,分别有 I帧、P帧、B帧 三种帧类型。 GOP 就是由一个 I帧 和多个 P帧 或 B帧 组成的一组相近的画面 。

    在H264中,三种类型的帧数据分别为 I帧 :帧内编码帧。就是一个完整帧。 P帧 :前向预测编码帧。是一个非完整帧,通过参考前面的I帧或P帧生成。 B帧 :双向预测内插编码帧。参考前后图像帧编码生成。B帧依赖其前最近的一个I帧或P帧及其后最近的一个P帧。

    解码器可以直接解码 I帧 ,但是 P帧 和 B帧 必须依赖 I帧 ,或者前后的 P或B 才能解码。首次连上直播间时,需要抛弃掉 P 和 B 帧,等待 I帧 。所以,影响首屏时间最重要的因素就是 I帧 ,也就是两个 GOP 之间的间隔时间。

    GOP 间隔的设置并非越小越好,太小则两个 I帧 之间的 P/B帧 越少,压缩率越低,画面质量越差,需要做好权衡。

    1.3.2 稳定性问题

    我们知道网络是不稳定的,经常会出现网速慢,甚至断网的问题,所以稳定性优化也是非常重要的。 比如以下几个方面:

    • 码率控制 同样分辨率下,码率越高,视频越清晰,同时需要的带宽也越大。相反,码率越低,视频越模糊,数据越小。
    • 弱网优化 根据不同的网速切换不同的码率进行播放等。
    • 断线重连 网络断开时的重联机制。

    1.3.3 全局负载均衡

    随着业务的发展,如果主播和观众的数量越来越多以后,系统可能会面临高并发情景,直播卡顿,甚至系统奔溃,解决这种情况的一个好办法就是使用 CDN 。

    CDN内容分发解决因分布、带宽、服务器性能带来的访问延迟问题,适用于站点加速、点播、直播。

    加入 CDN 后,整个直播系统架构如下:

    1.3.4 其他

    除了以上提到的内容,当今的直播系统还要包括以下内容:录制、转码、鉴黄、截屏、权鉴防盗、回声消除、连麦 等等,整套下来,需要非常多的知识储备,以及大量的时间精力,才能完成。

    1.4 几种常见的流媒体网络传输协议

    直播协议包含了上面提到的 推流 和  拉流 协议。

    1.4.1 RTP

    **实时传输协议( Real-time Transport Protocol ,缩写RTP)**是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。

    RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用,而且它是创建在 UDP 协议上的。

    1.4.2 RTMP

    **实时消息协议( Real-Time Messaging Protocol ,缩写RTMP)**也称实时消息传输协议,是最初由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体音频、视频和数据而开发的一个专有协议。Macromedia后被Adobe Systems收购,该协议也已发布了不完整的规范供公众使用。 RTMP协议有许多变种:

    1. 默认使用TCP端口1935的纯粹(plain)协议。
    2. RTMPS ,通过一个TLS/SSL连接传输RTMP。
    3. RTMPE ,使用Adobe自有安全机制加密的RTMP。虽然实现的细节为专有,但该机制使用行业标准的密码学原函数。
    4. RTMPT ,用HTTP封装以穿透防火墙。RTMPT通常在TCP通信端口80和443上使用明文请求来绕过大多数的公司流量过滤。封装的会话中可能携带纯粹的RTMP、RTMPS或RTMPE数据包。
    5. RTMFP , 使用UDP而非TCP的RTMP,取代RTMP Chunk Stream。Adobe Systems开发了安全的实时媒体流协议包,可以让最终用户直接地相互连接(P2P)。

    1.4.3 WebRTC标准

    WebRTC是一个由谷歌、Mozilla和Opera等支持的开源技术。它通过简单的api为浏览器和移动应用程序提供实时通信(RTC)功能。为浏览器、移动平台和物联网设备开发丰富、高质量的RTC应用程序,并允许它们通过一组通用协议进行通信。 支持的浏览器和平台:

    • Chrome
    • Firefox
    • Opera
    • Android
    • iOS

    特点:

    • 基于浏览器,且主流浏览器都支持,跨平台能力强
    • 默认P2P,但是需要TURN服务器作为fallback
    • 自适应码率

    1.4.4 HLS

    HTTP Live Streaming (缩写是HLS)是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载,每次只下载一些。当媒体流正在播放时,客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源,允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时,客户端会下载一个包含元数据的extended M3U (m3u8) playlist文件,用于寻找可用的媒体流。 HLS只请求基本的HTTP报文,与实时传输协议(RTP)不同,HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络(CDN)来传输媒体流。

    2 WebRTC技术

    2.1 为什么选择WebRTC

    目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在内的所有平台的 API,保证了 API 在所有平台的一致性。使用 WebRTC 的好处主要有以下几个方面:

    1. 免费的使用 GIPS 先进的音视频引擎;
    2. 由于音视频传输是基于点对点传输的,所以实现简单的 1 对 1 通话场景,需要较少的服务器资源,借助免费的 STUN/TURN 服务器可以大大节约成本开销;
    3. 开发 Web 版本的应用非常方便,使用简单的 JS 接口,无需安装任何插件,即可实现音视频互通;
    4. WebRTC 适用的场景非常广泛,如当下比较火的社交、游戏、体育、电视、相亲类的直播,以及互动连麦、在线教育、在线医疗、金融证券在线开户、智能硬件(如无人机)、智能家居设备如摄像头监控以及智能语音设备;
    5. WebRTC还可以录制音视频到本地文件;
    6. WebRTC提供音视频加密功能;
    7. WebRTC最大的优势就是“标准化”,它解决的问题就是给所有需要进行实时通信的终端提供一套统一的、开放的实时通信能力描述和连接建立标准;

    2.2 什么是打洞服务器

    P2P(peer to peer)对等通信。 即在p2p的网络中,所有网络节点都是同等地位,没有服务端和客户端之分,一个节点即是服务端也是客户端。客户端之间可以进行直接的通信,不需要在经过服务端的中转,从而提高网络传输速度和减小服务器压力,这是非常有用的。P2P虽然通信模式非常理想,但是有一些问题需要解决:

    1. 客户端通信之前,必须知晓接受端的公网IP和端口
    2. 客户端的p2p通信数据包必须能够穿透NAT(network address translate) 网络地址翻译

    解决方案:

    1. 第一个问题比较简单,可以通过一台拥有公网IP的节点来记录在线客户端的公网IP和端口,所有客户端可以通过该节点读取接受客户端的IP和port
    2. 第二个问题比较复杂,主要针对私有网络之间的通信,由于ip的匮乏,所以网络上不可能所有节点都位于同一个网段(即拥有公网IP)

    事实上,大部分的节点都处于常规网络的边缘,甚至在DNS所能查询的范围之外,所以在处于网络的边缘的节点不能直接通信的。

    为了能让客户端在不同的网络之间通信,我们就需要穿过防火墙,而且我们还要面对ISP所设置的种种限制。所以为了绕开这些限制,以及在接收端的防火墙上打开一个口让媒体通过,我们就需要依赖STUN/TURN服务器,目的是找到一条正确的路径(STUN),或者是作为一个中继服务器用来传输媒体(TURN)

    上图中的Relay server即为TURN中继服务器,而STUN server的作用是通过收集NAT背后peer端(即:躲在路由器或交换机后的电脑)对外暴露出来的ip和端口,找到一条可穿透路由器的链路,俗称“打洞”。STUN/TURN服务器通常要部署在公网上,能被所有peer端访问到。

    2.3 什么是WebRTC服务器

    WebRTC被认为是一种点对点技术,浏览器可以直接通信而无需任何类型的基础设施。此模型足以创建基本应用程序,但难以在其之上实现诸如组通信,媒体流记录,媒体广播或媒体转码之类的功能。因此,许多应用程序都需要使用媒体服务器。

    从概念上讲,WebRTC媒体服务器只是一种“多媒体中间件”,从源到目的地时,媒体流量会通过该中间件。媒体服务器能够处理媒体流并提供不同的类型,包括组通信(将一个对等方生成的媒体流分配给多个接收方,即充当多会议单元,MCU),混合(将多个传入流转换为一个单一的复合流) ,转码(在不兼容的客户端之间适应编解码器和格式),录制(以持久的方式存储对等体之间交换的媒体)等。 媒体服务器的好处有如下几点:

    1. 扩展了系统性能和功能,来支持更为复杂的应用场景;
    2. 所有媒体流经由媒体服务器的一个好处是可以进行记录,这对于一些需要保留会议纪要的场景是非常有用的;
    3. 可以方便的和第三方系统进行集成;
    4. 可以对媒体流进行额外的加工处理,比如通过人工智能人脸识别来给播客添加虚拟的帽子。

    2.4 WebRTC通信模式

    当媒体服务器充当媒体中继时,它通常被称为SFU(Selective Forwarding Unit选择性转发单位),这意味着其主要目的是在客户端之间转发媒体流。还有一个MCU(Multipoint Conferencing Unit多点会议单元)的概念,MCU服务器不仅可以转发,而且可以对媒体流进行混合和编码压缩(比如把各个客户端的数据打包转发,和SFU相比,这样将大幅度降低转发数据的带宽需求,但对CPU有更高的要求)。

    2.4.1 Mesh架构

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

    优点:

    • 逻辑简单,容易实现
    • 服务端比较 “轻量”,TURN 服务器比较简单,一定比例的 P2P 成功率可极大减轻服务端的压力

    缺点:

    • 每新增一个客户端,所有的客户端都需要新增一路数据上行,客户端上行带宽占用太大。因此,通话人数越多,效果越差
    • 无法在服务端对视频进行额外处理,如:录制存储回放、实时转码、智能分析、多路合流、转推直播等等

    2.4.2 MCU (MultiPoint Control Unit)

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

    以前在电信行业做视频会议一般都使用MCU(Multipoint Control Unit),也就是多方推流在MCU上进行合流,在拉流的时候只有一路合流,这样的好处是无论几方推流,拉流只有一路,下行带宽比较小。但是问题也比较多,只要推流方一多,MCU的压力就比较大,而且分布式的部署也比较难,成本又很高。

    2.4.3 SFU(Selective Forwarding Unit)

    上图右侧部分,咋一看,跟MCU好象没什么区别,但是思路不同,仍然有中心节点服务器,但是中心节点只负责转发,不做太重的处理,所以服务器的压力会低很多,配置也不象MUC要求那么高。但是每个端需要建立一个连接用于上传自己的视频,同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5,消耗的带宽也是最大的,如果每个连接1M带宽,总共需要25M带宽,它的典型场景是1对N的视频互动。 SFU 服务器最核心的特点是把自己 “伪装” 成了一个 WebRTC 的 Peer 客户端,WebRTC 的其他客户端其实并不知道自己通过 P2P 连接过去的是一台真实的客户端还是一台服务器,我们通常把这种连接称之为 P2S,即:Peer to Server。除了 “伪装” 成一个 WebRTC 的 Peer 客户端外,SFU 服务器还有一个最重要的能力就是具备 one-to-many 的能力,即可以将一个 Client 端的数据转发到其他多个 Client 端。

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

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

    现在互联网行业比较流行的是SFU(Selective Forwarding Unit),简单说就是只负责转发流,不负责合流,压力很小。这样的模式可以依托CDN进行分布式的部署,不过拉流的方数限于客户端的带宽和处理能力。

    2.4.4 为啥推荐选择 SFU ?

    纯 mesh 方案无法适应多人视频通话,也无法实现服务端的各种视频处理需求,最先排除在商业应用之外。

    SFU 相比于 MCU,服务器的压力更小(纯转发,无转码合流),灵活性更好(可选择性开关任意一路数据的上下行等),受到更广泛的欢迎和应用,常见的开源 SFU 服务器有:Licode,Kurento,Janus,Jitsi,Mediasoup等。

    当然,也可以组合使用 SFU + MCU 的混合方案,以灵活应对不同场景的应用需要。

    3 开源方案

    3.1 流媒体选型要考虑的主要因素

    1. 你是否深刻理解其代码?

    2. 代码版本是否足够新?

    3. 有谁在使用它?

    4. 它的文档是否齐全?

    5. 它可以debug吗?

    6. 它可以伸缩吗?

    7. 它使用哪种语言? 对于媒体服务器而言,这种语言的性能是否足够? 团队是否足够了解这门语言?

    8. 是否适应你现有的Signaling范式? 你在看的Media Server是否容易与你决定使用的STUN/TURN服务器集成

    9. 许可证是否适合你?

    10. 谁在提供支持? 很多成功的、被良好维护的开源项目背后都有一个商业模式,尤其是中小型的项目,这意味着有一个团队以此为谋生手段。 具备可选的付费支持意味着:

      • 有人愿意全职来改善这东西,而不是作为爱好来维护。
      • 如果你需要紧急帮助,只要花钱就能得到。

    3.2 Jitsi

    github.com/jitsi/jitsi Jitsi是一个免费的开源音频/视频和聊天通信器,它支持SIP、XMPP/Jabber、AIM/ICQ、IRC和许多其他有用的特性。

    Jitsi不仅是WebRTC媒体服务器,而且还有一个完整的平台。 Jitsi系列产品包括Jitsi Videobridge(媒体中继,SFU),Jitsi Meet(会议网络客户端),Jicofo(Jitsi Conference Focus),Jigasi(Jitsi Gateway to SIP)和Jitsi SIP Phone。借助Jitsi我们能在几个小时之内迅速搭建一个完整可用的通信平台。 它还使用Jingle(XMPP)和功能齐全的Web界面实现自己的信令控制。 然而,令人遗憾的是,它对于媒体录制没有提供稳定易用的解决方案。

    3.3 Kurento

    github.com/Kurento/kur… Kurento是WebRTC媒体服务器和一组客户端API,可简化针对WWW和智能手机平台的高级视频应用程序的开发。Kurento Media Server的功能包括组通信,音视频流的转码,记录,混合,广播和路由。

    作为一项与众不同的功能,Kurento Media Server还提供了高级媒体处理功能,包括计算机视觉,视频索引,增强现实和语音分析。Kurento模块化体系结构简化了第三方媒体处理算法(即语音识别,情感分析,面部识别等)的集成,可以由应用程序开发人员透明地用作Kurento的其余内置功能。

    Kurento Media Server通过称为Kurento API的RPC API公开其所有功能。可以通过任何与JSON兼容的客户端直接查询该API,但是推荐的使用方法是通过Kurento客户端库。目前为 Java , Browser Javascript 和 Node.js 提供了这些工具。

    如果您喜欢其他编程语言,则可以遵循基于 WebSocket 和 JSON-RPC 的Kurento协议的规范来编写自定义客户端库。

    Kurento被设计为可插入框架,Kurento中的每个插件都称为一个模块,可以使用新的自定义模块扩展Kurento Media Server。更多信息,请阅读Kurento模块部分。

    Kurento模块分为三类:

    • 主要模块与Kurento Media Server开箱即用合并:

      • kms-core:Kurento Media Server的主要组件。
      • kms-elements:Kurento Media Elements的实现(WebRtcEndpoint,PlayerEndpoint等)
      • kms-filters:Kurento过滤器的实现(FaceOverlayFilter,ZBarFilter等)
    • 内置模块Kurento团队开发的额外模块,用于增强Kurento Media Server的基本功能。到目前为止,有四个内置模块,分别是:

      • kms-pointerdetector:基于颜色跟踪检测视频流中指针的过滤器。
      • kms-chroma:过滤器,它在顶层使用颜色范围并使之透明,从而在后面显示另一个图像。
      • kms-crowddetector:用于检测视频流中人聚集的过滤器。
      • kms-platedetector:用于检测视频流中的车牌的过滤器。
    • 定制模块Kurento Media Server的扩展,提供了新的媒体功能。

    3.4 Licode

    github.com/lynckia/lic… Licode基于WebRTC技术。它与Google Chrome的最新稳定版本100%兼容。您的用户将无需安装任何内容即可通过其Web浏览器进行交谈。无需关心复杂的实时基础架构。它提供了基于HTML5的视频会议功能的快速开发,使它100%可扩展。Licode允许您在网络上包括电视会议室。但是您也可以实现流媒体,录制和您梦dream以求的任何其他实时多媒体功能!

    主要模块及实现语言:

    • Erizo:这是WebRTC多点控制单元(MCU)。它是用C ++编写的,并且与WebRTC标准及其协议100%兼容。

    • ErizoAPI:Erizo的Node.js插件包装器。它可以从Node.js应用程序配置和管理Erizo的各个方面!

    • Erizo控制器:这是服务的核心。它向用户提供会议室以进行多方会议。它还提供了足够的安全性机制和附加功能:数据,用户列表,事件等。

    • Nuve:该视频会议管理API提供会议室管理,用户对第三方应用程序的访问控制和服务注册。它还为服务提供了云可扩展性。

    3.5 Janus

    github.com/meetecho/ja…

    Janus是由Meetecho开发的WebRTC服务器,被认为是通用服务器。因此,除了实现与浏览器建立WebRTC媒体通信,与之交换JSON消息以及在浏览器与服务器端应用程序逻辑之间中继RTP / RTCP和消息的手段之外,它本身不提供任何功能。服务器端插件提供了任何特定的功能/应用程序,然后浏览器可以通过Janus与之联系,以利用它们提供的功能。此类插件的示例可以是诸如回声测试,会议桥,媒体记录器,SIP网关等应用程序的实现。

    这样做的原因很简单:我们想要的东西将具有 small footprint (因此是C实现),并且只能配备以前的东西 really needed (因此可插入模块)。就是说,这使我们能够在云上部署成熟的WebRTC网关,或者使用小型的nettop / box来处理特定的用例。

    其最显着的特征之一是其插件架构,可以增强服务的核心功能。有一些有趣的Janus用例,例如SIP Gateway,屏幕共享等。

    3.6 Mediasoup

    github.com/versatica/m… 由于其多功能性,性能和可伸缩性,mediasoup成为构建多方视频会议和实时流应用程序的理想选择。它具有联播,SVC,传输BWE和其他更多先进功能。

    除了创建另一个自带服务器之外,mediasoup是一个Node.js模块,可以将其集成到更大的应用程序中。mediasoup提供了一个低级API,该API支持您的应用程序使用不同的用例。

    mediasoup带有mediasoup-client(JavaScript库)和libmediasoupclient(C ++库),用于构建使用统一API在任何浏览器或设备中运行的应用程序。或者只使用知名软件,例如FFmpeg或GStreamer。

    设计目标mediasoup及其客户端库旨在实现以下目标:

    • 成为SFU(选择性转发单元)。
    • 支持WebRTC和普通RTP输入和输出。
    • 在服务器端成为Node.js模块。
    • 在客户端成为小型JavaScript和C ++库。
    • 极简主义:只处理媒体层。
    • 与信号无关:不要强制使用任何信号协议。
    • 是超低级的API。
    • 支持所有现有的WebRTC端点。
    • 启用与知名多媒体库/工具的集成。

    架构

    特征

    • ECMAScript 6低级API。
    • 多流:通过单个ICE + DTLS传输的多个音频/视频流。
    • IPv6就绪。
    • UDP / TCP上的ICE / DTLS / RTP / RTCP。
    • 同播和SVC支持。
    • 拥塞控制。
    • 使用空间/时间层分布算法的发送者和接收者带宽估计。
    • SCTP支持(基于纯UDP的WebRTC数据通道和SCTP)。
    • 极其强大(在libuv之上用C ++编码的媒体工作程序子进程)。

    它与其他媒体服务器的不同之处在于它被设计成一个用于Node的开发库,这允许它可以被容易的集成到更大的应用程序中。

    3.7 我们最后为啥选择了Kurento?

    • 开源
    • 支持SFU和MCU
    • 支持音视频流的转码,记录,混合,广播和路由
    • 内置模块我们将来可以直接用
    • API公开其所有功能,与语言无关,可以使用任何语言
    • 可拔插框架,容易扩展
    • 文档丰富,demo多
    • 社区活跃度高
    展开全文
  • 这里我也想给大家说一定,用了开源的解决方案,快速的搭建起业务,但是无疑也欠下了技术债,因为开源的解决方案肯定没有自己实现的要熟悉,因为不熟悉很多时候出现了问题,并不能马上解决,甚至解决不了,导致业务受...
  • 开源webrtc服务器对比

    千次阅读 2020-03-30 17:18:37
    开源系统是目前市面上比较常见的,分别从服务器类型、编解码能力、文档的完整性和开发商来进行对比。大家都知道WebRTC服务器模型有两种,分别是SFU和MCU,SFU实现的是简单转发的路由功能,而MCU可以提供更多扩展性...
  • Ubuntu 16.04 webrtc开源服务器janus安装

    千次阅读 2018-07-06 13:29:45
    在前面博文: ... 介绍了ubuntu 14.04上面的安装,按照步骤非常顺序。 但是在Ubuntu 16.04上面遇到不少问题。我在Ubuntu 16.04搭建的是一个局域网的网关。...这样不需要打洞服务器就可以实现本地局域网的通信。
  • 开源WebRTC服务器列表 2021年3月,我正在寻找可在自定义应用程序中使用的WebRTC服务器。 吉西 目前尚不清楚如何创建新房间。 参见 许可证:Apache 可以通过IFrame包含在自定义应用程序中。 OpenVidu React和...
  • 开源WebRTC 服务器介绍

    千次阅读 2019-01-30 22:48:39
    开源WebRTC 服务器介绍 WebRTC 服务端分析 通信优化 WebRTC 未来展望 结语 1. 引言 近年来,直播竞答、网络游戏直播等新的实时音视频通讯场景不断推陈出新,并成为引领互联网娱乐风向的弄潮儿。实时音视频应用的...
  • 文章主要介绍了如何基于WebRTC开源框架搭建私人实时通信服务。
  • 文章目录 webrtc 服务器架构 0 前言 1 服务器架构 2 Mesh 、MCU、SFU的优缺点 2.1 Mesh 2.2 MCU 2.3 SFU 3 开源服务器 4 学习和感受 5 参考博客 webrtc 服务器架构 0 前言 推荐一个零声学院免费教程,个人觉得老师讲...
  • WebRTC信令服务器Ayame 关于Shiguredo的开源软件 我们不会回应PR或在Discord上尚未讨论的问题。 另外,Discord仅提供日语。 使用前请阅读 。 时雨堂のオープンソースソフトウェアについて 利用前にをお読みください...
  • 示例webrtc信令服务器实现(android客户端)服务器端//github.com/nkming2/webrtc-signaling-server浏览器的客户端//github.com/nkming2/webrtc-signaling-client
  • OWT的媒体服务器提供基于WebRTC的高效视频会议和流媒体服务。 它将单个WebRTC流扩展到许多端点。 同时,它还支持媒体流的媒体分析功能
  • 由于最近在研究webRTC视频推流,查了很多webRTC的资料,准备搭建rtsp的流媒体推送服务器,属于个人研究,非团队。进度慢之又慢!资料查了又查,始终找不到webrtc推送rtsp流的开源项目,自己后续慢慢研究吧! 虽然没...
  • WebRTC[42]- WebRTC 常见开源方案综述

    千次阅读 2022-01-09 11:59:13
    近两年,由于新冠疫情的影响,实时音视频通讯相关行业发展迅速,特别是视频会议、在线直播等行业场景。因此,也涌现出了很多关于 ...今天就来聊一聊比较常见的一些 WebRTC 流媒体服务器。 常见开源方案 一、Kurento
  • WebRTC服务器搭建

    千次阅读 2021-06-19 09:04:37
    前言 在前面的WebRTC介绍中我们已经...为了方便后续的开发和测试,今天我们来搭建WebRTC服务器环境。 安装环境 笔者使用的云服务器是Ubuntu 16.04。 注意尽量使用与笔者相同版本的系统,不然可能因为安装的各种环境
  • 当前开源WebRTC项目技术选型

    千次阅读 2021-04-10 22:15:09
    对SFU流媒体服务器的选择,没有最好,只有最合适。每个开源实现都有其各自的特点,都可以应用到实际产品中,只不过作为开发人员都有自己独特的技术背景,你需要根据自身特点以及项目特点选一个最合适的。
  • 用于Webrtc的媒体流转发服务器不计其数,开源与免费的也不计其数,有基于C++开发的,有基于Java开发的,有基于Go开发的,但以笔者的实践经验,mediasoup是性能最好的转发服务器。Mediasoup其实是一个框架,其应用层...
  • java写一个webrtc信令服务器,coturn
  • WebRTC服务器 WebRTC测试服务器
  • 十大必知开源WebRTC服务器

    千次阅读 2020-07-07 14:36:08
    十大必知开源WebRTC服务器 2020-06-01 09:31:54作者:james.zhu 来源:Asterisk开源派评论:0 点击:16080  WebRTC是一个非常新的技术,很多用户仍然在初步摸索阶段。有一些用户是不清楚WebRTC的用户场景,不...
  • 选择开源 WebRTC 媒体服务器架构的十二条建议 您是否理解代码 代码是否持续维护 有人使用吗 该项目有文档吗 它是否是 Debuggable 的 是否易于服务横向扩展 该媒体服务器使用什么语言开发的 它是否符合您的信令模式 ...
  • WebRTC开源项目一览之二

    千次阅读 2015-07-28 19:02:02
    他主要用来作为webrtc的流媒体服务器,因为BUG多,目前不适于商用,不过前景可期,  图1: 说明: 1、看到这里您可不要讲他的功能和ICE服务器的功能给搞混了哦,后者主要用来做NAT穿透和转发的。  
  • 使用和构建的开源webrtc代理服务器,它允许webrtc客户端拨打或接听其VoIP提供商的呼叫。 可以选择将服务器配置为针对需要摘要身份验证的SIP中继处理身份验证(否则,摘要质询将传递回客户端)。 安装 如上所述,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,776
精华内容 1,510
关键字:

webrtc开源服务器