WebRTC开发者社区为开发者提供最新最全的WebRTC资料

Licode—基于webrtc的SFU/MCU实现

2019-11-24 13:45:38

Licode—基于webrtc的SFU/MCU实现

webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：

（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；

（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；

（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。

对webrtc的理解与使用，我认为有三个境界：

谁是最好的WebRTC SFU？

2019-11-28 10:15:53

如果你计划在WebRTC中有多个参与者，那么最终可能会使用选择性转发单元(SFU)。webrtcHacks的撰稿人 Alex Gouaillard和他的CoSMo Software团队组建了一个负载测试套件来测量负载与视频质量，并发布了所有主要开源WebRTC SFU的结果。LiveVideoStack对原文进行的摘译。
文 / Alex Gouaillard 译 / 元宝原文 https://webrtchacks.com/sfu-load-testing/

首先要注意一个重要的问题——问什么样的SFU是最好的就像问什么样的车是最好的。如果你只想快点，那么你应该买一辆一级方程式赛车，但这不会帮助你送孩子上学。供应商从不对这些类型的测试感到兴奋，因为它把它们的功能归结为几个性能指标。这些指标可能不是其设计标准的主要部分，而且很多时候他们并不是那么重要。特别是对于WebRTC SFU，因为您可以在SFU上加载很多流，所以可能存在有许多弹性，用户行为和成本优化的原因。负载测试也不会深入研究端到端用户体验、开发的易用性，或者所有其他能够成功实现服务的功能元素。最后，像这样发表的报告代表了一个时间点——这些系统一直在改进，所以今天的结果可能会更好。

Licode—基于webrtc的SFU/MCU实现

2019-11-28 10:25:26

webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：

（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；

（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；

（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。

对webrtc的理解与使用，我认为有三个境界：

Janus架构以及基本开发

2019-11-28 10:35:19

Janus架构以及基本开发

Kurento简介

2019-11-28 10:39:54

信,媒体流录制,媒体广播或媒体转码是很难实现的。基于这个原因,很多应用还是需要有媒体服务器。

![Peer-to-peer WebRTC approach vs. WebRTC through a media server](/2014th7cj/d/file/p/20170217/jhhnqlcriq1.png "Peer-to-peer WebRTC approach vs. WebRTC through a media server")
在概念上,WebRTC媒体服务器是一种多媒体中继(它位于两个通信端的中间)。媒体服务器能处理媒体流,并有各种功能,包括组通信(分发一个端生成的媒体流到多个接收端,如像Multi-Conference Unit, MCU的工作方式),混合(转换多个输入流合成一个组合流),转码(在不兼容的客户端间选择codec和格式), 录制等。

三个基于WebRTC开源MCU框架的横向对比(licode)

2019-11-28 10:42:33

1. licode
官网地址：
http://lynckia.com/licode/index.html

官方demo地址：
https://chotis2.dit.upm.es/

Github地址：
https://github.com/lynckia/licode

基于Webrtc和Janus的多人视频会议系统开发1--系统架构

2019-11-28 21:47:14

目前业界如教育行业，直播行业，低延迟音视频连麦方案基本采用声网，即构，腾讯等第三方方案，采用第三方方案最大的优点就是接入快捷，可以迅速搭建自己的产品，缺点就是完全受制于第三方，另外费用比较高，公司规模小的时候比较合适，公司规模大了后就会有顾虑，通常达到一定规模后可以考虑自研一套方案和第三方方案并行使用，避免完全受制于第三方，和华为采购高通芯片的同时也研发自有芯片一个道理。

正是基于这样的考虑，我们开始研发自研的连麦系统，作为技术方案来说，现今支持浏览器直连基本上已经是刚需，所以webrtc是必须要兼容的，所以技术方案设计上决定是以webrtc协议为基础，支持多人会议，完全从0开始做不可取，经过对现有开源框架的研究比较后，决定在janus方案的基础上研发并逐步改进以符合需要，本系列文章就是对整改系统的研发过程的记录和总结，供大家参考。

Janus Webrtc服务的搭建

2019-11-29 00:31:40

前提准备

基础环境的准备，包括服务器环境、地址、证书、防火墙配置等。

环境准备

操作系统：centos 7.6 x64
一个带有SSL证书的域名
需要开放对应的端口：8088 8188 3478 3480-3500 7000-9000 443

证书转换

mkdir /etc/ssl/cert/domain.com
cd /etc/ssl/cert/domain.com

上传证书至此目录，一般用Nginx适用的证书即可。如果有pem的最好，直接上传到此处，如果没有的话，需要转换。

openssl rsa -in domain.com.key -text > key.pem
openssl x509 -inform PEM -in domain.com.crt > cert.pem

开始安装

janus（webrtc server）在阿里云centos7.4上的使用

2019-11-29 05:23:30

执行脚本

#!/bin/sh

yum install -y epel-release && \
yum update -y && \
yum install -y deltarpm && \
yum install -y openssh-server sudo which file curl zip unzip wget && \
yum install -y libmicrohttpd-devel jansson-devel libnice-devel glib22-devel opus-devel
libogg-devel pkgconfig gengetopt libtool autoconf automake make gcc gcc-c++ git cmake libconfig-devel openssl-devel

webrtc服务器janus

2019-11-29 06:03:08

基于Webrtc和Janus的多人视频会议系统开发

WebRTC Gateway Janus入门：从配置到编写插件

2019-11-29 06:06:02

janus介绍

janus是Meetecho开发的一个WebRTC网关，janus的主要作用就是它可以和你的内网设备和浏览器同时建立连接，并将浏览器发来的音视频数据包如rtp/rtcp包，通过自定义插件转发给你的内网设备，也可以将你发给janus的音视频数据包，加密后转发给浏览器。

这样就完成了内网音视频服务器和外网浏览器的互通。

janus为我们完成了与浏览器建立会话的复杂逻辑，并且提供给我们简单的插件机制来处理音视频数据。

对于PeerConnection连接的建立过程，涉及到复杂的NAT穿透的ICE协议的实现，SDP的交换，DTLS-SRTP的握手和数据包加密发送，数据包接收后解密的复杂逻辑。
janus将我们从与浏览器交互的PeerConnection建立的过程中解脱出来，更专注于音视频业务逻辑。

揭开webRTC媒体服务器的神秘面纱——WebRTC媒体服务器&开源项目介绍

2019-11-29 06:19:54

目录

WebRTC服务器——Licode 环境搭建

2019-11-29 06:22:34

目录

turn协议的工作原理

2019-12-09 02:18:51

Allocate请求

   客户端通过发送Allocate请求给STUN服务器，从而让STUN服务器为A用户开启一个relay端口。

licode 环境搭建

2019-12-17 12:02:30

1、根据安装指南安装(参考：http://licode.readthedocs.io/en/master/from_source/ 即可)，如果顺利的话，应该都能正常过去，有失败可能是网络问题，所以先得有个好的网络；

2、运行basicExample，发现起来后看不到视频，主要是ice等服务器信息配置不对，修改licode根目录下的配置文件licode_config.js，主要需要搭建一个本地的turn服务器（参考：http://www.cnblogs.com/lingdhox/p/4209659.html），然后修改其中的stun服务器的配置：
config.erizoController.iceServers = [{'url': 'stun:192.168.2.229'}, {'url':'turn:192.168.2.229', 'username':'lly', 'credential':'1234'}];

3、运行基本例子
./scripts/initLicode.sh

licode学习之erizo篇

2019-12-17 12:14:36

licode学习之erizo篇--Pipeline_handle

摘要：erizo的pipeline的handle，是媒体数据处理的基本操作，handle分为3类：IN，OUT，BOTH IN：数据进入handle，handle需要read数据并传递给下一级 OUT：数据进入handle，handle需要write数据并传递给下一级 BOTH：可以同时进行read和wr 阅读全文

posted @ 2018-12-05 18:54 media_myself 阅读 (563) | 评论 (0) 编辑

licode学习之erizo篇--Pipeline_service

摘要：Pipeline是媒体处理的核心流程逻辑。 Pipeline里面定义了两个主要的概念：Service和Handler。 Service负责处理那些不仅要看当前数据包，还要分析之前的数据包的那些业务，比如丢包重传；Handler处理当前的数据包的情形，比如生成填充字节。在Pipeline里面，Han 阅读全文

posted @ 2018-12-05 16:26 media_myself 阅读 (676) | 评论 (0) 编辑

基于Webrtc和Janus的多人视频会议系统开发2---Janus建立连接过程的角色关系图

2019-12-17 12:25:54

基于Webrtc和Janus的多人视频会议系统开发2---Janus建立连接过程的角色关系图
原创睏哥RTC 发布于2018-08-08 14:36:08 阅读数 1982 收藏
展开

本篇文章开始讲解如何开发windows和mac下的原生c++的janus客户端SDK。

项目组几个人搜编百度，谷歌，bing，一直没找到Janus的c++原生SDK的demo，只有ios,android和web的demo, 但是我们windows和Mac下都要支持原生APP的SDK接入，最后无奈之下只好自己动手丰衣足食。

根据资料参考，webrtc源码的example下有个peerconnection_client和peerconnection_server，可以演示c++的webrtc视频p2p通话，只要这个连通了，在加上Janus协议的支持，应该就可以支持janus的C++客户端，不过开始时是对整个连通过程一头雾水，下图是正确的客户端和Janus服务器关系的正确关系，帮助初入坑的兄弟们理解：

Android WebRTC完整入门教程04: 多人视频

2020-07-11 12:00:33

多人视频有三种理论方案, 如下图所示, 从左到右分别是Mesh,SFU,MCU.

基于WebRTC技术的多人音视频解决方案

2020-07-15 09:48:49

本文主要讨论如何使用WebRTC技术来实现可扩展的，高效的多人音视频解决方案，介绍现有的多人音视频通讯模型，给出一种在Agora.io中使用的网页端技术方案。

WebRTC是一种基于点对点(peer to peer, P2P)的用于交换音视频媒体流以及数据流的技术，基于WebRTC的技术我们可以很容易的实现一对一场景的音视频通话以及数据流的传输并且有着不错的质量控制。但是如果要实现多人的音视频通话或者是一对多的直播应用，那么使用WebRTC就会面临一些困难和挑战，下面我们讨论两种常见的多方通讯模型。

1、网状模型

流媒体服务器

2020-12-31 05:46:50

针对流媒体播放服务器和客户端做的一个调查汇总。

Janus源码分析（6）——Streaming分析

2020-12-31 05:59:19

在这里插入图片描述

SFU级联解决方案——Licode

2020-12-31 06:00:32

文章目录

SFU级联解决方案——Jitsi

2020-12-31 06:01:36

部署WebRTC的媒体服务器有两个主要挑战，从一台服务器开始扩展，并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展，在用户体验中，媒体延迟是一个关键因素，在这方面，此方法还远远不能达到最优效果。
将视频会议分布在距离用户很近的许多服务器上并且保持相互连接，同时解决了两个问题。本文深度描述了级联SFU存在的问题并且展示了解决方法和遇到的其它问题。

在这里插入图片描述

实时交流的App非常依赖网络环境，例如吞吐量，延迟，丢失。低比特率导致低视频质量，导致了视频音频中的传输延迟更高。丢包可以导致视频跳帧，进而导致‘波浪音’和视频冻结。

由于这些原因，在会议中，在两个端点之间选择最优路径是很重要的。当只有两个参与者时，这很直接—WebRTC使用ICE协议在两端建立连接，交换多媒体。如果可能的话，两端直接连接，不然的话，在少数情况下使用 TURN传递服务器。WebRTC支持分解域名来获得 TURN服务器地址，这使得选择基于DNS的本地 TURN服务器相对简单，例如，使用AWS Route53的布线选项。

然而，当一个视频会议的参与者通过中心媒体服务器来发送时，情况变得更复杂。许多WebRTC服务像Hangouts，appear.in, Slack和meet.jit.si，使用SFU来在参与者人数多于3人时更有效的传递音频视频。

Licode—基于webrtc的SFU/MCU实现

2021-07-06 10:56:31

webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：

（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；

（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；

（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。

licode 学习总结

2021-07-06 10:58:14

抽取的代码没有webrtc自带的音视频处理框架(voice engine/video engine/media engine)，这是由于SFC只在RTP层进行转发并不解码，只需要check一下媒体流属性(如I帧头)即可。

抽取代码的亮点在于将webrtc强大的抵抗网络时延和丢包的网络适应性算法和协议都提炼出来了，可以供广大研究视频传输的网络适应方向的开发者们单独学习、实验并快速集成到自己非webrtc-based的产品中来。

libav是从ffmpeg中分离出来的开发者发布的开源工程，代码量更小、第三方依赖库更少、编译简单。目前FFmpeg的使用更广泛。

libnice基于ICE协议实现的网络层库，Licode使用libnice库来实现端到端的ICE连接和数据流发送接收，以及candidates(候选地址)和SDP（媒体描述文件）的相互交换。（但是配置文件中默认使用nicer，此配置文件仅是example的配置）

libsrtp库主要是是用来加密rtp/rtcp的。

licode服务端总结

2021-07-06 11:00:09

cloudHandler提供了nuve对EC的调用：获取房间中的所有用户，删除房间，删除指定用户；以及EC对nuve的调用：删除token，EC的添加、状态更新，删除以及保活。

调用方法通过RPCMQ实现，他们共同维护了两个队列，队列A用来传递调用消息，Nuve发布调用消息后，并且会维护一个调用方法和回调函数的字典；EC从队列A中获取调用消息后执行调用方法，并将结果消息push进队列B；Nuve从队列B中获取调用结果消息，并从字典中得到回调函数并执行callback，删除对应字典值。

2.3服务、房间、用户管理

1.只有superService才有权限进行service的相关操作，即配置文件中的superService = config.nuve.superserviceID

2.在room模块中currentService即当前请求的service，会维护一个rooms列表，且创建房间的时候可携带房间的媒体信息：room.mediaConfiguration

3.Nuve中的user管理仅仅提供查询和删除功能，通过房间id，对EC发出获取当前房间用户信息，或者删除该用户

TensorFlow 中的通信机制 ——Rendezvous（二）gRPC 传输

2022-06-27 11:54:26

本篇是 TensorFlow 通信机制系列的第二篇文章，主要梳理使用 gRPC 网络传输部分模块的结构和源码。如果读者对 TensorFlow 中 Rendezvous 部分的基本结构和原理还不是非常了解，那么建议先从这篇文章开始阅读。TensorFlow 在最初被开源时还只是个单机的异构训练框架，在迭代到 0.8 版本开始正式支持多机分布式训练。与其他分布式训练框架不同，Google 选用了开源项目 gRPC 作为 TensorFlow 的跨机通信协议作为支持。gRPC 的编程和使用其实是相对复杂的，TensorFlow 为了能让 gRPC 的调用更加平滑，在调用链封装和抽象上面做了较多工作，甚至有些工作例如创建和管理 gRPC channel 涉及到了 GrpcSession 模块。从个人角度来看，利用 gRPC 进行 Tensor 通信的过程已经足够丰富，所以我们只针对 gRPC 传输 Tensor 过程进行梳理，至于涉及到 gRPC 管理方面的内容会在另一篇介绍分布式 Session 创建和管理的文章中集中梳理。

WebRTC 媒体服务器中使用单端口

2024-06-12 12:01:11

WebRTC在进行互通的时候需要开放很多端口, 一个音/视频通道就要开启多个通道, 如果是多人音视频通话需要开通的端口更多. 对端口资源照成了很大的浪费, 一些防火墙会限制多udp端口的开放. 如果要部署在服务端, 多端口的开发会给运维照成极大的不方便.

目前为止已经有几个减少端口使用的策略:

rtp/rtcp复用端口的方案rtcp-mux.
音视频的boundle, 可以让音视频复用连接通道.
包括后面出现的多路流复用单peerconnection的plan b和unified plan方案, 最新的webrtc标准都已经转向了unified plan.

基于RTMP和WebRTC开发大规模低延迟(1000毫秒内)直播系统

2024-06-12 12:02:09

问题

随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.