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

WebRTC加深理解 - 会话流程

2019-11-22 15:08:33

基于ios native api自己写客户端得出的大概流程，WebRTC的API接口和例子都是oc版本，因为我最讨厌最恶心的语言就是oc，所以我使用swift来编写客户端。我本身不是搞ios开发的，以前稍微用过oc，至于swift前段时间看过一点，现学现卖，就是转换oc的过程实在是折磨死我了。

音视频客户端会话的整体流程
WebRTC主要是客户端技术，尽量使用p2p点对点流媒体传输。

WebRTC源码分析-线程基础概述

2019-11-22 15:12:12

WebRTC实现了跨平台(Windows，MacOS，Linux，IOS，Android)的线程类rtc::Thread，WebRTC内部的network_thread，worker_thread，signaling_thread均是该类的实例。该类的源码位于rtc_base目录下的thread.h与thread.cc中。

基础功能

rtc:: Thread及其相关类，ThreadManager、MessageQueue，Runnable等等一起提供了如下的基础功能：

线程的管理：通过ThreadManager单例对象，可以管理所有的Thread实例；
线程的常规基本功能：rtc:: Thread提供创建线程对象，设置线程名称，启动线程去执行用户代码；
消息循环，消息投递：rtc:: Thread通过继承MessageQueue类，提供了内部消息循环，并提供了线程间异步，同步投递消息的功能；
跨线程执行方法：提供了跨线程执行方法，并返回执行结果的功能。该功能非常强大，因为WebRTC在某些功能模块的使用上，有要求其必需在指定的线程中才能调用的基本要求，比如音频模块：ADM 的创建必须要在 WebRTC 的 worker thread 中进行；
多路分离器：通过持有SocketServer对象，实现了多路分离器的功能，能处理网络IO；

WebRTC源码分析-线程基础之线程基本功能

2019-11-22 15:13:08

前言

如之前的总述文章所述，rtc::Thread类封装了WebRTC中线程的一般功能，比如设置线程名称，启动线程执行用户代码，线程的join，sleep，run，stop等方法；同时也提供了线程内部的消息循环，以及线程之间以同步、异步方式投递消息，同步方式在目标线程执行方法并返回结果等线程之间交互的方式；另外，每个线程均持有SocketServer类成员对象，该类实现了IO多路复用功能。

本文将针对rtc::Thread类所提供的基础线程功能来进行介绍，Thread类在rtc_base目录下的thread.h中声明，如下（删除了其他非线程基础功能的API，其他的API将于另外的文章中分析）：

webrtc延迟分析

2019-11-22 15:13:52

1.背景

webrtc可以用于将一台机器上的桌面投射到另外一台机器上，通过浏览器实现桌面分享。然而其延迟时间是一个关键问题，即我们在源桌面上做一个操作，经过多长时间能够在目的桌面上看到。接下来，将根据查找到的资料对导致延迟的因素做简要介绍。
想了解更多可以查看：抖动和延迟之间的区别

2.延迟时间构成

以下是计算WebRTC呼叫总等待时间的关键因素：
（1）网络延时。取决于网络连接质量和通信距离（在一个国家内部应该小于50毫秒，国家之间可能大于100毫秒）。
（2）网络带宽和服务质量。丢包或者带宽不足可能触发更多的延时。
（3）声音延迟。取决于操作系统、音频硬件和驱动（在windows和ios上小于20毫秒，在android和linux上可能更多）。
（4）抖动缓冲。每种VoIP软件维持一个大小不一的抖动缓冲器，以补偿网络延迟（通常在0到100毫秒）。
（5）回声消除和前向纠错。回声消除和前向纠错可能引入一个数据包的延迟（通常在20毫秒）。
（6）其他因素。还有其他因素对延迟有影响，例如CPU占用率过高以及软件实现细节等。
如果通话双方在一个国家内部，总的延迟应当小于300毫秒，如果通过webrtc打长距离的跨国电话，总的延迟可能高达600毫秒。

兼容 WebRTC 的开源抗丢包音频编解码器SOLO

2019-11-22 15:14:27

在 RTC 2019 第五届实时互联网大会的编解码技术专场上，声网开源了自研抗丢包音频编解码器Agora SOLO。

目前，编解码器的源代码已经开源在 Github 上：https://github.com/AgoraIO-Community/Solo

这个开源项目兼容 WebRTC，可集成于多种场景下的实时音视频应用中，比如在线课堂、直播社交、游戏语音开黑、IoT 等。在分析它的特性之前，首先要讲一下它名字中的一个关键词，丢包。

丢包是什么？

尽管很多人开始使用 WebRTC 了，但是其中有不少人都对「丢包」的概念不是很熟悉。所以，首先我们要解释一下。由于 SOLO 是音频编解码器，我们接下来讲的场景，主要是指其中的实时音频部分。

webrtc P2P服务器coturn搭建说明

2019-11-22 15:15:12

rfc5766-turn-server规范

rfc5766-turn-server是谷歌推荐的turn开源项目，经常作WebRTC的服务器端使用。该开源项目是包含TURN与STUN功能于一体，默认TURN与STUN监听端口为3478。
支持tcp, udp, tls, dtls 连接.tls为基于TCP的安全层传输协议，dtls为基于udp的安全传输层协议。
注意:TLS和DTLS需要安装证书。

WebRTC拥塞控制算法——GCC介绍

2019-11-22 15:15:55

网络拥塞是基于IP协议的数据报交换网络中常见的一种网络传输问题，它对网络传输的质量有严重的影响，网络拥塞是导致网络吞吐降低，网络丢包等的主要原因之一，这些问题使得上层应用无法有效的利用网络带宽获得高质量的网络传输效果。特别是在通信领域，网络拥塞导致的丢包，延迟，抖动等问题，严重的影响了通信质量，如果不能很好的解决这些问题，一个通信产品就无法在现实环境中正常使用。在这方面WebRTC中的网络拥塞控制算法给我们提供了一个可供参考的实现，这篇小文会尽量详细的介绍WebRTC中的拥塞控制算法---GCC的实现方式。

●●●

WebRTC简介

WebRTC是一个Web端的实时通信解决方案，它可以做到在不借助外部插件的情况下，在浏览器中实现点对点的实时通信。 WebRTC已经由W3C和IETF标准化，最早推出和支持这项技术的浏览器是Chrome, 其他主流浏览器也正在陆续支持。Chrome中集成的WebRTC代码已全部开源，同时Chrome提供了一套LibWebRTC的代码库，使得这套RTC架构可以移植到其他APP当中，提供实时通信功能。

国内免费可用的STUN服务器(webrtc 必备）

2019-11-22 15:16:27

亲测有效的stun服务器：

我需要一个媒体服务器来进行一对多的WebRTC广播吗？

2019-11-23 00:40:30

一个字回答：要。

这是我这个星期经常被问到的问题。答案也很简单—是的，需要。

接着我收到了一个没有预料到的提问：

为什么需要？

这有点让我措手不及。倒不是因为我不知道答案。而是因为我不知道如何用简短的文字来回答他。我想这也不是一个简单的问题。

简单的答案是资源的限制，以及我们不控制大部分这些资源的事实。

WebRTC的规模会带来哪些挑战

2019-11-23 00:41:57

WebRTC直播流中，大规模所带来的挑战

1:1 != 1:1,000,000

只要是关于WebRTC的问题，规模有影响。

人们常常有这种想法，如果我能够运行一个1对1的视频通话，那么把它改进成一个三方视频通话也很简单。如果有了三方通话，那么距离四方通话也只有一步之遥了。假如我们已经到了四个人同时通话的地步，既然4和10之间没差多少，所以10个人通话肯定也是一样的。如果我们可以进行10人通话了，那么50人，甚至100人是不是也没问题了？

处理多用户之间的互动通话的做法放在实时广播方面也是正确的。

1对1的广播与1对100不同，当然与1比10,000与1比1,000,000也不同。

WebRTC的NAT及防火墙简介（上）

2019-11-23 00:43:40

什么是NAT？

NAT意为网络地址转换（https://en.wikipedia.org/wiki/Network_address_translation）。它是一种广泛使用的系统，多用于保留IPv4地址，或使本地网络管理员能够控制本地拓扑结构。实际上NAT技术多种多样，在此不多赘述。最常见的NAT设备通过改变通过它的数据包的IP报头信息得以运行。通常情况下NAT技术与防火墙结合完成，大多数家用路由器都如此，这些路由器通常在保证安全性的同时还保留了IPv4的地址空间，可谓一举两得。但正如我们所见，这也可能导致某些程序和协议出现问题，尤其是像WebRTC这样尝试进行点对点连接的。

常见的NAT 或者防火墙场景是私人或受保护的IP端点子网的场景，与公共互联网的环境不同。

WebRTC的NAT及防火墙简介（下）

2019-11-23 00:44:28

NAT和点对点通讯：有何问题？

虽然客户端或服务器能够通过NAT /防火墙顺利连接，但这样的操作会对点对点通信造成严重破坏。点对点通信通常由端点应用程序打开，或用主机操作系统上的特定IP端口侦听。之后该端口可以与准备交换数据的另一台主机发信号或进行通信。应用程序中，点对点IP端口发出的指令通常用服务器或其他对等体发现机制来完成，与实际的点对点数据有所区分。示例如下：

YouTube是如何使用WebRTC的

2019-11-23 00:45:51

我周二登录了一次YouTube，注意到右上角有一个新的摄像头图标，并写着“Go Live（New）”，所以我点了一下它试试看会发生什么。事实证明，你现在可以直接从浏览器进行直播。这听起来真的很像WebRC，所以我加载了chrome://webrtc-internals来查看，并确定它就是WebRTC。我们总是对大规模部署很好奇，所以我立即请WebRTC逆向工程大师Philipp “Fippo” Hancke进行更深入的调查。本文剩下的部分就是他对此的分析。— 编辑：chad hart

为什么你的WebRTC产品需要TURN服务器

2019-11-23 00:46:47

端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。

在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。

平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。

ICE和STUN

哪种TURN服务器正在被使用？

2019-11-23 00:48:19

原标题：What kind of TURN server is being used?

TURN作为WebRTC基础设施的重要一员，它负责帮助NAT穿透。但是使用它们有多频繁呢？以及使用情况可以告诉我们什么关于WebRTC开销的内容呢？

两星期以前，我的朋友Gustavo Garcia在推特上问有多少WebRTC通话是通过TURN传递的。因为我喜欢钻研数据，所以我回答了他，但是要想在140个字之内说明白很困难。所以我想要在这篇博文中回答以下几个问题：

# 失败率是多少？

# 通过TURN服务器传递的通话占比有多少？

# UDP，TCP和TLS TURN变体的相对占比是多少？

多方WebRTC选择3：SFU

2019-11-23 00:50:32

多方WebRTC选择3的方案是SFU，它表示选择转发单元。SFU背后的想法与MCU相同。它在中间有一台媒体服务器，所有peers向它发送流，唯一不同的是，它不会做繁重的处理，服务器将其引到其它peers，这样它们可以进行任何所需的处理。

这样服务器不需要能支持那么繁重的处理运算，你可以利用MCU提供的好处，同时避免Mesh hassles和MCU的高代价。

SFU的结构如下图所示：

利用WebRTC和TensorFlow通过网络实现计算机视觉2

2019-11-23 00:55:22

第1部分——确保Tensorflow正常工作

为确保TensorFlow对象检测API正常工作，我们首先从用于演示对象检测的官方版Jupyter Notebook经调整后的版本着手。我将此文件保存为object_detection_tutorial.py。

如果您剪切并粘贴该notebook的每个部分，得到的结果应如下所示：

WebRTC adapter.js是什么以及我们为什么需要它？（二）

2019-11-23 01:01:05

有4种力量来推动adapter.js：

1. WebRTC规范本身。这正是我们所期望的，并建议开发人员针对此点进行工作。

2. 浏览器的WebRTC的实现。目前，它排在WebRTC规范之后。在这之前，建议使用adapter.js（你也可以自己写，但为什么又要花额外的精力来维护它呢？）

3. adapter.js实现。你需要时刻关注新版本，采用新版本，并且对它们进行测试。

4. 你自己的实现，以及如何与上述3种力量来搭配。

我们会有那么一天不需要adapter.js吗？

WebRTC vs. Zoom 之外：WebRTC 的弱网模拟测试

2019-11-23 01:03:02

作为一个使用 WebRTC 独立开发者或团队，怎样才能知道自己 App 的通话质量已经“达标”了呢？如何进行合理的弱网模拟测试？介绍给开发者们三个开源工具的部署、使用方法，及其各自优缺点。

如果你是长期关注 WebRTC 的资深开发者或技术爱好者，你可能留意到了，近期圈子里出了一个不大不小的话题，引得一些知名 WebRTC 技术博主纷纷发声，表明观点。

事情是这样的。

前不久，Jitsi 在其官方博客^[1]上发布了一个 WebRTC 与 Zoom Web 客户端的视频通话对比测试。测试结果显示，WebRTC 的视频通话质量比 Zoom 还要好。一石激起千层浪，不少博主发表了自己的看法。

看似是在挑事，但 Jitsi 出此一举完全事出有因。

Jitsi 是一个开源项目，可帮开发者在 Web 、Windows、Linux、Mac OS X、Android 平台上实现实时的语音、视频通话应用。有很多独立开发者在基于这套代码开发自己的视频通话应用。这一切，都是建立于 WebRTC 的基础之上实现的。然而， Jitsi 却看到作为视频会议服务提供商的 Zoom 不但从 2015 年开始就在一些地方一再声称自己并没有使用 WebRTC，甚至不断表示“WebRTC 是一种能力非常有限的解决方案”：

WebRTC 开发实践：如何实现 SFU 服务器

2019-11-24 13:43:31

上一篇文章《WebRTC 开发实践：为什么你需要 SFU 服务器》我们了解了 WebRTC SFU 服务器的基本原理和必要性，解决了 What 和 Why，本文则更近一步，探究一下实现 SFU 服务器的关键技术点有哪些？重点解决一下 How

1 什么是 SFU ？

首先，我们再看一次 SFU 服务器的定义，什么是 SFU ？

SFU 的全称是：Selective Forwarding Unit，是一种路由和转发 WebRTC 客户端音视频数据流的服务端程序。

【WebRTC】自己做一个简单的sfu视频通讯demo

2019-11-24 13:46:36

由于p2p视频通讯不支持定向ip流量，

所以，做了一个基于mediasoup框架的sfu转发服务器和简单的web客户端（给安卓端和ios端提前踩坑）

涉及到的技术：

mediasoup(官网)
Nodejs
React
WebPack

系统：

ubuntu 16.04(mediasoup 框架需求,使用虚拟机调试)

说明：

本次尝试的demo不深入源码，仅演示sfu视频通讯基本搭建和mediasoup框架基本用法。

首先，想要知道从何入手，并不是急着去看官网文档，先看看官方demo和源代码

WebRTC 是如何进行通信的，WebRCT 的三种网络结构

2019-11-24 13:48:55

01WebRTC基础结构介绍

自从Google于2011年发布WebRTC以来，WebRTC一直是一个能够将互联网浏览器转换为强大的多媒体引擎的颠覆性技术。 WebRTC汇集了先进的实时通信技术，包括：先进的音视频编解码器（Opus和VP8/9），强制加密协议（SRTP和DTLS）和网络地址转换器（ICE＆STUN）。

根据最初的定义，WebRTC被指定为P2P（peer-to-peer）技术。自成立以来，WebRTC已经大大降低了Web开发人员通过简单的Java API构建实时通信应用程序的难度。但要清楚，WebRTC是一种技术，而不是一个完整的应用程序或服务。

虽然WebRTC最初被设想为纯粹的P2P技术，但许多日常业务应用程序需要集中式媒体功能，通过P2S（peer-to-server）架构提高可靠性、效率或扩展性。对于P2P和P2S架构之间的问题对于构建WebRTC应用程序很重要。

02P2P到P2S

WebRTC旨在通过其浏览器（也称为P2P）在客户端之间直接发送媒体流。在P2P架构中，客户端建立通信之前，首先需要建立到应用服务器（有时也成为信令服务器）的信令连接。而 WebRTC规范中没有规定信令方法或协议，它允许采用现有方法（SIP，WebSockets，XMPP等）或实现专有信令过程。应用服务器保存业务逻辑，并作为会话描述协议（SDP）交换的中介。一旦SDP交换完成，两个客户端之间的直接媒体通信即可开始。

多方WebRTC选择3：SFU

2019-11-24 13:49:42

多方WebRTC选择3：SFU

断点：WebRTC SFU负载测试(一)

2019-11-24 13:50:19

如果你允许多人加入WebRTC通话，你可能会以SFU结束。计划如何分配容量比较困难-通常会进行估计，SFU应该放在哪里，它们将会消耗多少带宽，你需要何种服务器。

为了帮助网络架构和WebRTC工程师作出决定，Alex博士和他的CoSMo Softwae团队将负载测试元件放在一起来测量负载和视频质量。他们公布了所有主流的开源WebRTC SFU的测试结果。这个元件基于KITE并且在webrtc.org上用来显示互通状态。CoSMo团队还开发了一个基于机器学习的视频质量评估框架来优化实时交流。

首先注意：问哪种SFU是最好的就相当于问哪种汽车是最好的。如果你只要求速度快，那你应该买F1赛车，但是它不能帮助你送孩子上学。供应商从来不会对这些测试感兴趣因为它将它们的功能仅仅总结成一些性能指标。这些指标可能在它们的测试中不起主要作用，并且也不是判别产品好坏的主要标准。对于WebRTC SFU,仅仅因为SFU可以负载许多流，但是可能还有别的限制条件，用户行为，花费优化等原因使得他们不能这样做。负载测试同样不会深究用户体验，开发难度，或其它对服务的成功有帮助的部分。

当建立花费模型时，有很多情况我本人都想获得数据。Alex和他的团队已经做了很多深度工作，这是WebRTC开源生态系统逐渐成熟的一个好的象征。这个测试并不完美，但是我相信它会对WebRTC社群具有参考价值。

WebRTC中的完美协商（一）

2019-11-24 13:53:48

写在前面：如果你不必担心连接状态、闪退问题（信号冲突）、角色（你处于哪一方），就可以在实时WebRTC连接中添加和删除媒体，你会怎么做呢？不受时间和地点限制，你可以很容易地调用pc.addTrack（track，stream），并且你的连接路径只会显示在另一侧，不会有终端连接失败的风险。这是个白日梦？还有很多问题亟待解决？实际上，现在Chrome已经基本完成了协商，上述操作几乎可以运行！但是这样的操作并没有广泛应用，可能是因为“几乎”这两个字。这代表该操作有5%的时间无法工作，并且若Chrome闪退，风险太高了（无法从该操作回滚，只能运用pc.close（））。但API最初的承诺仍然有效。我们只需要一个除Firefox以外的浏览器来实现回滚，并用规范允许的方法修复一些明显的竞赛问题。

WebRTC中的完美协商（三）

2019-11-24 13:54:23

但是，这并不完美！

原因有两点：

第一点：这就是为什么我这么早就对此发表博客。我提出了3个规范说明，希望这些说明可以消除对Promise.all和“stable”测试的依赖。其实归根到底是用一种与执行rollback略有不同的API，其用于以防闪退的方式设置一个新的端描述。在某种程度上它也是重启ICE的方式，且不会干扰negotiationneeded。

第二点：关键是要编写一次代码，以抽象出该状态机。一旦正确完成操作，那么我们就不必再担心这种复杂性会影响该应用程序的其余部分。可以在应用上方标明“让行端”。现在只需在对等端连接上调用方法，而无需再担心此状态机。

如果您想知道为什么WebRTC无法自动处理此问题，很大一部分原因是有些人想要一个高级API，而其他人想要一个低级API。开发组无法生成适合所有人的“一刀切”产品。具体来说，如果不借助应用程序去解决当前体系结构中的问题，需要WebRTC定义自己的信令通道方式并将其强加给每个人，而这并不能满足大家不同的需求。

好消息是，高级别的API可以跳过这一步进行编写。这篇文章会向大家说明一种编写方法。

为什么要追求完美？

通过监控发现的TURN中的bug

2019-11-24 13:55:38

“Bugzilla”上有包括Mozilla的迅速反应的全部内容。

有一天晚上我把下面这一段代码粘到了JS控制台中：

探索面部识别与WebRTC

2019-11-24 13:56:32

近几年来，面部识别技术一直在智能手机创新的周围徘徊。随着苹果公司在iPhone X上推出Face ID，人们开始更多的关注面部识别技术。

我们团队向来喜欢实验和探索未来技术的潜力。所以我们与Cristiano一同利用WebRTC做一些关于面部识别的研究和探索。

在这篇文章中，我们会分享Cristiano的一些成果，他学到的东西，以及他对这种技术挑战和局限性的看法。

什么是WebRTC？

WebRTC是一个开源的网络框架，支持浏览器中的实时通信。它包括Web上高质量通信的基础构建模块，如用于语音和视频聊天应用程序的网络，音频和视频组件。

用Cristiano的话来说就是“一种可以通过浏览器调用麦克风，音频和摄像头的方法”。

Cristiano使用WebRTC，Canvas，微软Cognitive Services以及他们的Emotion API来创建了一个原型工具，该工具可以通过网络摄像头在浏览器中通过面部表情来检测情绪。

WebRTC getStats详解－从标准、调用到实现

2019-11-24 14:00:11

前言

getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。<br />
本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。<br />

一 getStats标准

getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />

发送端采集统计：对应于媒体数据的产生，包括帧率，帧大小，媒体数据源的时钟频率，编解码器名称，等等。<br />
发送端RTP统计：对应于媒体数据的发送，包括发送数据包数，发送字节数，往返时间RTT，等等。<br />
接收端RTP统计：对应于媒体数据的接收，包括接收数据包数，接收字节数，丢弃数据包数，丢失数据包数，网络抖动jitter，等等。<br />
接收端渲染统计：对应于媒体数据的渲染，包括丢弃帧数，丢失帧数，渲染帧数，渲染延迟，等等。<br />

另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />

往返时间RTT：表示数据在网络上传输所用的时间，一般通过RTCP 的SR/RR数据包中的相关域进行计算。该度量直接反映网络状况的好坏。<br />
丢包率影响接收端音视频质量，在严重的情况下可能导致声音跳变或者视频马赛克，从侧面反映网络状况的好坏。<br />
音视频数据到达接收端之后，要经历收包、解码、渲染等过程，该过程会带来延迟。接收端延迟是数据从采集到渲染单向延迟的重要组成部分。<br />

通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />

WebRTC -- SDP格式解析

2019-11-26 10:57:08

WebRTC -- SDP格式解析

一、SDP组成

SDP是由多行文本组成的一个纯文本协议，如果将SDP从语义上分解成不同组件来描述一个多媒体会话信息，那么SDP由以下部分组成：

会话信息
网络信息
媒体信息
安全信息
服务质量和分组信息

WebRTC SDP 解析

2019-11-26 10:59:24

WebRTC -- 官方apprtc示例搭建

2019-11-26 11:00:58

一. 房间服务器搭建

1.1 安装依赖程序

apt-get install git unzip  lrzsz  nodejs npm automake autoconf libtool nodejs-legacy python-webtest golang –y

1

1.2 安装jdk8

1.2.1 下载jdk8

从http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html下载对应的版本到/usr/lib/jvm目录，然后解压到当前目录：

tar zxf jdk-8u151-linux-x64.tar.gz

WebRTC-命令行参数解析

2019-11-26 11:03:30

一、功能介绍

webrtc中命令行参数解析功能由rtc_base/flags.h中的Flag类和FlagList类提供。使用起来比较简单，支持参数中含有空格等。可以看成google开源的gflags的轻量版.
支持的命令行语法为：

The following syntax for flags is accepted (both '-' and '--' are ok):

   --flag        (bool flags only)
   --noflag      (bool flags only)
   --flag=value  (non-bool flags only, no spaces around '=')
   --flag value  (non-bool flags only)

WebRTC -- Windows平台编译

2019-11-26 11:06:27

写作本文时使用的webrtc版本为：branch heads/67

一、准备工作

1.0 请确保可以访问国外网站

1.1 系统语言切换到英文

系统Windows 7/10都可以，在“控制面板”–>“区域和语言”–>“管理”–>"更改系统区域设置"中切换到“英语（美国）”，然后重启系统。

1.2 卸载部分软件

无

1.3 安装VS2017

Visual Studio 2017现在只提供在线安装包，为了加快在线安装的速度，可以只选择如下几个安装项：

Desktop development with C++
MFC and ATL support

1.4 安装Windows 10 SDK

WebRTC：会话描述协议SDP

2019-11-26 11:10:18

什么是SDP

SDP（Session Description Protocol）是一种通用的会话描述协议，主要用来描述多媒体会话，用途包括会话声明、会话邀请、会话初始化等。

WebRTC主要在连接建立阶段用到SDP，连接双方通过信令服务交换会话信息，包括音视频编解码器(codec)、主机候选地址、网络传输协议等。

下面先简单介绍下SDP的格式、常用属性，然后通过WebRTC连接建立过程生成的SDP实例进行进一步讲解。

协议格式说明

SDP的格式非常简单，由多个行组成，每个行都是如下格式。

<type>=<value>

其中：

<type>：大小写敏感的一个字符，代表特定的属性，比如v代表版本；
<value>：结构化文本，格式与属性类型有关，UTF8编码；
=两边不允许存在空格；
=*表示是可选的；

WebRTC：一个视频聊天的简单例子

2019-11-26 11:11:51

相关API简介

在前面的章节中，已经对WebRTC相关的重要知识点进行了介绍，包括涉及的网络协议、会话描述协议、如何进行网络穿透等，剩下的就是WebRTC的API了。

WebRTC通信相关的API非常多，主要完成了如下功能：

信令交换
通信候选地址交换
音视频采集
音视频发送、接收

相关API太多，为避免篇幅过长，文中部分采用了伪代码进行讲解。详细代码参考文章末尾，也可以在笔者的Github上找到，有问题欢迎留言交流。

信令交换

信令交换是WebRTC通信中的关键环节，交换的信息包括编解码器、网络协议、候选地址等。对于如何进行信令交换，WebRTC并没有明确说明，而是交给应用自己来决定，比如可以采用WebSocket。

发送方伪代码如下：

WebRTC：数据传输相关协议简介

2019-11-26 11:12:20

对网络协议来说，需要做的通常就两件事情：1、建立连接，2、传输数据，WebRTC也不例外。

假设WebRTC应用的两端已经建立了连接，那么，剩下就是如何传输数据的问题了。

WebRTC同时支持传输音视频数据、自定义应用数据。这其中，涉及多种协议，包括UDP、RTP/SRTP、RTCP/SRTCP、DTLS、SCTP。

这些协议名字比较相似，很容易让人混淆，简单总结下：

传输音视频数据相关协议：UDP、DTLS、RTP/SRTCP；
传输自定义应用数据相关协议：UDP、DTLS、SCTP；

下面就简单介绍下，这些协议是做什么的，有什么区别，存在什么联系。

深入理解WebRTC

2019-11-26 11:17:21

Web Real-Time Communication（Web实时通信，WebRTC）由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端）的音频、视频及数据共享。

WebRTC使得实时通信变成一种标准功能，任何Web应用都无需借助第三方插件和专有软件，而是通过简单地JavaScript API即可完成。

在WebRTC中，有三个主要的知识点，理解了这三个知识点，也就理解了WebRTC的底层实现原理。这三个知识点分别是：

MediaStream：获取音频和视频流
RTCPeerConnection：音频和视频数据通信
RTCDataChannel：任意应用数据通信

WebRTC getStats详解－从标准、调用到实现

2019-11-26 11:18:30

前言

getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。

本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。

一 getStats标准

getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：

1.发送端采集统计：对应于媒体数据的产生，包括帧率，帧大小，媒体数据源的时钟频率，编解码器名称，等等。

2.发送端RTP统计：对应于媒体数据的发送，包括发送数据包数，发送字节数，往返时间RTT，等等。

3.接收端RTP统计：对应于媒体数据的接收，包括接收数据包数，接收字节数，丢弃数据包数，丢失数据包数，网络抖动jitter，等等。

4.接收端渲染统计：对应于媒体数据的渲染，包括丢弃帧数，丢失帧数，渲染帧数，渲染延迟，等等。

webrtc SDP和candidate消息生成位置学习

2019-11-26 11:20:22

SDP 和candidate消息生成代码

1 ICE消息生成及发送

ICE消息触发是由 webrtc 原生API RTCPeerConnection 中onicecandidate事件传出，在经过rtcpeerconnection做了一定的记录处理，然后触发’ice’事件将ice内容传到Peer 对象中，Peer对象再调用信令服务器接口将candidate消息发送出去。而onicecandidate事件触发来自 icecandidate事件，而icecandidate 是由RTCPeerConnection API 中setLocalDescription调用内部触发。

在这里插入图片描述

WebRTC：会话描述协议SDP

2019-11-26 11:24:19

什么是SDP

SDP（Session Description Protocol）是一种通用的会话描述协议，主要用来描述多媒体会话，用途包括会话声明、会话邀请、会话初始化等。

WebRTC主要在连接建立阶段用到SDP，连接双方通过信令服务交换会话信息，包括音视频编解码器(codec)、主机候选地址、网络传输协议等。

下面先简单介绍下SDP的格式、常用属性，然后通过WebRTC连接建立过程生成的SDP实例进行进一步讲解。

协议格式说明

SDP的格式非常简单，由多个行组成，每个行都是如下格式。

<type>=<value>

其中：

<type>：大小写敏感的一个字符，代表特定的属性，比如v代表版本；
<value>：结构化文本，格式与属性类型有关，UTF8编码；
=两边不允许存在空格；
=*表示是可选的；

常见属性

以下面的SDP为例：

webrtc

2019-11-26 11:26:55

建议看这篇之前先看一下使用WebRTC搭建前端视频聊天室——入门篇

如果需要搭建实例的话可以参照SkyRTC-demo：github地址

其中使用了两个库：SkyRTC(github地址)和SkyRTC-client(github地址)

这两个库和demo都是我写的，如果有bug或是错误欢迎指出，我会尽力更正

前面的话

这篇文章讲述了WebRTC中所涉及的信令交换以及聊天室中的信令交换，主要内容来自WebRTC in the real world: STUN, TURN and signaling，我在这里提取出的一些信息，并添加了自己在开发时的一些想法。

WebRTC的服务器

WebRTC提供了浏览器到浏览器（点对点）之间的通信，但并不意味着WebRTC不需要服务器。暂且不说基于服务器的一些扩展业务，WebRTC至少有两件事必须要用到服务器：
1. 浏览器之间交换建立通信的元数据（信令）必须通过服务器
2. 为了穿越NAT和防火墙

为什么需要信令？

自建 AppRTC

2019-11-26 11:28:16

AppRTC 是 webrtc 的一个 demo。

自建 AppRTC 可以苦其心志劳其筋骨饿其体肤，更重要的是能学会 webrtc 服务器的搭建流程……

AppRTC 的组成部分是这样的：
1、AppRTC - 房间服务器。Github
2、Collider - 信令服务器。上面 Github 工程里自带，在 src/collider 下
3、coTurn - 打洞(内网穿透)服务器。Google Code
4、还需要自己实现一个 coTurn 连接信息（主要是用户名、密码的配置）获取接口，通常叫做 TURN REST API。

搭建自己的AppRTCDemo服务器

2019-11-26 11:29:21

先搭建房间服务器AppRTC:

sudo apt-get update
sudo apt-get install git
sudo git clone https://github.com/webrtc/apprtc
sudo apt-get install nodejs
sudo apt-get install npm
sudo npm install -g npm
sudo apt-get install nodejs-legacy
sudo npm -g install grunt-cli

webrtc中的网络反馈与控制

2019-11-26 11:32:41

Alt pic

实时音视频WebRTC介绍

2019-11-27 11:58:06

在这篇文章中：

WebRTC实现p2p视频通话

2019-11-27 11:59:54

简介

目的帮助自己了解webrtc 实现端对端通信

  # 使用流程
  git clone https://gitee.com/wjj0720/webrtc.git
  cd ./webRTC
  npm i
  npm run dev

  # 访问 127.0.0.1:3003/test-1.html 演示h5媒体流捕获
  # 访问 127.0.0.1:3003/local.html 演示rtc 本地传输
  # 访问 127.0.0.1:3003/p2p.html 演示局域网端对端视屏

结合 AppRTC 源码分析 WebRTC 建立连接的过程

2019-11-28 08:08:49

这两年来，WebRTC 越来越频繁地出现在人们的视野，在在线教育、在线医疗等领域的应用也越来越多。大家研究 WebRTC 的热情也越来越高涨，不过 WebRTC 的入门门槛个人觉得稍微有些高，特别是各种概念，比如 NAT 穿越，ICE、STUN、TURN、Signaling server等，刚开始可能会觉得比较繁杂，不易理解。然后建立连接的整个过程，异步调用比较多，很容易搞混。那么这篇文章里我们会根据 WebRTC 的官方 demo AppRTC 的 iOS 版本来分析一下 WebRTC 从进入房间到建立音视频连接的过程，为了便于了解，我们本次的讨论不涉及到底层的具体实现。

1. 相关概念

我们首先来简单地了解几个概念：

1.1 NAT 穿越（NAT Traversal）

因为 WebRTC 是 P2P 的，很多时候 peer 是隐藏在 NAT 之后，没有外网的 IP 地址，如果两个 peer 都在 NAT 后面，都没有外网的 IP (或者说都不知道自己的外网 IP)，是无法建立连接的。那么 NAT 穿越就是用来解决这个问题的，NAT 穿越也俗称 “P2P 打洞”。常见的两种穿越方式是 STUN 和 TURN。

从头到脚撸一个多人视频聊天 — WebRTC 实战（一）

2019-11-27 12:17:35

【 从头到脚 】会作为一个系列文章来发布，它包括但不限于 WebRTC 多人视频，预计会有：

WebRTC 实战（一）：也就是本期，主要是基础讲解以及一对一的本地对等连接，网络对等连接。
WebRTC 实战（二）：主要讲解数据传输以及多端本地对等连接、网络对等连接。
WebRTC 实战（三）：实现一个一对一的视频聊天项目，包括但不限于截图、录制等。
WebRTC + Canvas 实现一个共享画板项目。
作者开源作品 ???Vchat — 一个社交聊天系统（vue + node + mongodb）的系列文章

WebRTC：一个视频聊天的简单例子

2019-11-27 12:24:31

在这篇文章中：

WebRTC 直播时代

2019-11-28 01:04:37

WebRTC 全称为：Web Real-Time Communication。它是为了解决 Web 端无法捕获音视频的能力，并且提供了 peer-to-peer（就是浏览器间）的视频交互。实际上，细分看来，它包含三个部分：

MediaStream:捕获音视频流
RTCPeerConnection:传输音视频流（一般用在 peer-to-peer 的场景）
RTCDataChannel: 用来上传音视频二进制数据（一般用到流的上传）

但通常，peer-to-peer 的场景实际上应用不大。对比与去年火起来的直播业务，这应该才是 WebRTC 常常应用到的地方。那么对应于 Web 直播来说，我们通常需要两个端：

主播端：录制并上传视频
观众端：下载并观看视频

这里，我就不谈观众端了，后面另写一篇文章介绍（因为，这是在是太多了）。这里，主要谈一下会用到 WebRTC 的主播端。简化一下，主播端应用技术简单可以分为：录制视频，上传视频。大家先记住这两个目标，后面我们会通过 WebRTC 来实现这两个目标。

RTMP H5 直播流技术解析

2019-11-28 01:17:08

本篇主要聚焦于 RTMP 直播协议的相关内容，也就是说，本篇将会直接进行实际操作 Buffer 的练习和协议的学习。

RTMP 是什么

RTMP 全称即是 Real-Time Messaging Protocol。顾名思义就是用来作为实时通信的一种协议。该协议是 Adobe 搞出来的。主要是用来传递音视频流的。它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。和现行的直播流相比，RTMP 主要的特点就是高效，这里，我就不多费口舌了。我们先来了解一下 RTMP 是如何进行握手的。

RTMP 握手

RTMP 是基于 TCP 三次握手之后的，所以，RTMP 不是和 TCP 一个 level 的。它本身是基于 TCP 的可靠性连接。RTMP 握手的方式如图：

image.png-50.3kB

Web 直播流的解析

2019-11-28 01:17:49

Web 进制操作是一个比较底层的话题，因为平常做业务的时候根本用不到太多，或者说，根本用不到。

老铁，没毛病

那什么情况会用到呢？

canvas
websocket
file
fetch
webgl
…

上面只是列了部分内容。现在比较流行的就是音视频的处理，怎么说呢？

如果，有涉及直播的话，那么这应该就是一个非常！非常！非常！重要的一块内容。我这里就不废话了，先主要看一下里面的基础内容。

全面进阶 H5 直播

2019-11-28 01:18:40

视频格式？编码？

如果我们想要理解 HTML5 视频，首先需要知道，你应该知道，但你不知道的内容？那怎么去判断呢？ ok，很简单，我提几个问题即可，如果某些童鞋知道答案的话，可以直接跳过。

你知道 ogg,mp4,flv,webm（前面加个点 .）这些叫做什么吗？
那 FLV，MPEG-4，VP8 是啥？
如果，基友问你要片源，你会说我这是 mp4 的还是 MPEG-4 的呢？

当然，还有一些问题，我这里就不废话了。上面主要想说的其实就两个概念：视频文件格式（容器格式），视频编解码器（视频编码格式）。当然，还有另外一种，叫做音频编解码器。简而言之，就是这三个概念比较重要：

视频文件格式（容器格式）
视频编解码器（视频编码格式）
音频编解码器（音频编码格式）

这里，我们主要讲解一下前面两个。视频一开始会由两个端采集，一个是视频输入口，是一个音频输入口。然后，采集的数据会分别进行相关处理，简而言之就是，将视频/音频流，通过一定的手段转换为比特流。最终，将这里比特流以一定顺序放到一个盒子里进行存放，从而生成我们最终所看到的，比如，mp4/mp3/flv 等等音视频格式。

视频编码格式

视频编码格式就是我们上面提到的第一步，将物理流转换为比特流，并且进行压缩。同样，它的压缩编码格式会决定它的视频文件格式。所以，第一步很重要。针对于 HTML5 中的 video/audio，它实际上是支持多种编码格式的，但局限于各浏览器厂家的普及度，目前视频格式支持度最高的是 MPEG-4/H.264，音频则是 MP3/AC3。（下面就主要说下视频的，音频就先不谈了。）

目前市面上，主流浏览器支持的几个有：

WebRTC 的前世今生

2019-11-28 09:44:12

WebRTC 技术简史

让人类通过网络进行音视频通信是网络最后的巨大挑战：实时通信( RTC )。实时通信就像网络上在文本框中输入文本一样自然，没有它，就限制了我们开发新的方式使人们互动交流起来。

从历史上看，RTC 变化很大很复杂，需要昂贵的音视频技术授权或者花费巨大代价去开发，RTC 技术与现有的内容、数据和服务整合一直都很困难和耗时，在网络上尤其如此。

Gmail 视频聊天在 2008 年开始流行，在 2011 年 Google 推出视频群聊，它使用 GoogleTalk 服务，就像 Gmail 一样。Google 收购了 GIPS，它是一个为 RTC 开发出许多组件的一个公司，例如编解码和回声消除技术。Google 开源了 GIPS 开发的技术，与相关机构 IET 和 W3C 制定行业标准。在 2011 年 5 月，爱立信实现第一个 WebRTC应用。

WebRTC 已经实现了对于实时通信，免插件音频数据传输的标准制定。需求是：
- 许多网络服务已经使用了 RTC，但是需要下载，本地应用或者是插件。包括 Skype、Facebook、Google Hangouts。
- 下载安装升级插件是复杂的，可能出错的，令人厌烦的。
- 插件可能很难部署、调试、故障排除等——可能需要技术授权，复杂集成和昂贵的技术。说服人们去安装插件是很难的。

WebRTC 项目的指导原则是APIs应该是开源的，免费的，标准化的，浏览器内置的，比现有技术更高效的。

WebRTC实战： STUN, TURN, Signaling

2019-11-28 09:52:10

原文：WebRTC in the real world: STUN, TURN and signaling By Sam Dutton

WebRTC 实现了网页点对点交流。
但是…
WebRTC 仍然需要服务器来:

交换客户端元数据协调通讯，即信令(Signaling)。
应对NATs(Network Address Translators) 和防火墙。

本文将向你展示如何建立一个信令服务器，并使用STUN和TURN服务器来处理实际应用中出现的一些怪异的连接问题。也将解释WebRTC应用是如何处理多方通讯并与类似VoIP、PSTN的服务互动的。

如果你没有了解过WebRTC，我强烈建议你在看这篇文章之前先看看这篇文章 Getting Started With WebRTC

什么是信令？

关于安装Turn服务器:coturn,TurnServer,Restund,reTurnServer

2019-11-28 09:45:56

1.Ubuntu下安装coturn：

apt-get install coturn，源码：http://turnserver.open-sys.org/downloads/

安装类似下面：

sudo -i

# ignore if you already in admin mode

apt-get update && apt-get install libssl-dev libevent-dev libhiredis-dev make -y

# install the dependencies

实际中的WebRTC：STUN，TURN以及信令（五）

2019-11-28 09:54:10

NAT给设备提供了一个IP地址以使用专用局域网，但是这个地址不能在外部使用。由于没有公用地址，WebRTC对等端就无法进行通信。而WebRTC使用 STUN来解决这个问题。

STUN服务器位于公共网络上，并且有一个简单的任务：检查传入请求的IP地址（来自运行在NAT后面的应用程序），并将该地址作为响应发送回去。换句话说，应用程序使用 STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址，然后通过信令机制将其传递给另一个对等端以建立直接链接。（实际上不同NAT工作方式都有所不同，可能有多个NAT层，但是原理是一样的）。

因为 STUN服务器不需要做太多的工作或者记特别多的东西，所以相对低规格的 STUN服务器就可以处理大量的请求。

根据webrtcstats.com的统计（2013年），大多数WebRTC通话都成功地使用 STUN进行连接，有86%。尽管对于防火墙之后的对等端之间的呼叫以及复杂的NAT配置，成功通话量会更少一些。

强制WebRTC使用转发(relay)模式

2019-11-28 09:55:25

假如你在企业内使用WebRTC，可能会遇到UDP端口被封的情况，这个时候可以强制WebRTC使用TCP转发模式。

要使用TCP转发，得配合一个 turn server，开源的 coturn 实现了 TCP 转发，我在“Ubuntu Server 14.04下配置coturn for WebRTC”一文中介绍了如何安装配置，可以参考。

配置了 coturn 后，在 Chrome 内建立 PeerConnection 对象时，做个配置，就可以实现转发了，类似下面：

Ubuntu 14.04下编译WebRTC

2019-11-28 09:56:29

这两天在Ubuntu Server 14.04下编译了一遍WebRTC，记录了过程，放在这里，有需要的朋友可以参考。

几点提示：

我使用的是Ubuntu Server 14.04，上面没开发环境，也没桌面，从零开始配置。
需要连接VPN才可以完成源码的下载和更新，以及部分依赖的安装

编译过程

首先要安装一些基础包，比如g++、python等，使用下面的命令：

sudo apt-get install g++
sudo apt-get install python

WebRTC学习资料大全

2019-11-28 09:57:26

WebRTC 介绍

官网在这里：https://webrtc.org/。然后这里有一个官方的Getting Started：https://webrtc.org/start/。

Google关于WebRTC的幻灯片：

http://io13webrtc.appspot.com/

然后是WebRTC的SPEC：

https://www.w3.org/TR/webrtc/

WebRTC项目源码地址：https://chromium.googlesource.com/external/webrtc。

Native开发文档：https://webrtc.org/native-code/development/。

JS端的API文档：http://w3c.github.io/webrtc-pc/。

维基百科对WebRTC的介绍：https://en.wikipedia.org/wiki/WebRTC。

WebRTC工作组：https://www.w3.org/2011/04/webrtc/。

WebRTC源码中turnserver的使用方法

2019-11-28 09:58:03

WebRTC的源码中自带了一个turnserver，编译之后，会在out/Default下生成一个turnserver文件，可以充当STUN和TURN server。用法如下：

./turnserver int_addr ext_addr realm auth_file

1

int_addr指的是面对turnclient，接收turnclient数据的ip和端口，形式是host:port，例如192.168.1.12:3478。

ext_addr是公共IP（可能是公网IP，内网使用则可能是相对于NAT的公共IP），例如192.168.1.12。

realm是类似example.com之类的。

WebRTC TURN协议初识及turnserver实践

2019-11-28 09:59:04

WebRTC协议栈

教你如何结合WebRTC与TensorFlow实现图像检测（上篇）

2019-11-28 10:05:22

TensorFlow是目前最流行的机器学习框架之一。TensorFlow的一大优势是，它的很多库都有人积极进行维护和更新。而我最喜欢的其中一个库就是TensorFlow对象检测API。Tensorflow对象检测API可以对一张图形上的多个对象进行分类，并提供它们的具体位置。该API在将近1000个对象类上进行了预先训练，可提供各种经过预先训练的模型，让你可以在速度与准确性之间权衡取舍。

有这些模型的指引固然很好，但所有这些模型都要使用图像才能发挥作用，而这些图像则需要你自行添加到一个文件夹中。我其实很想将其与实时的WebRTC流配合到一起，通过网络实现实时的计算机视觉。由于未能找到这方面的任何例子或指南，我决定写这篇博文来介绍具体的实现方法。对于使用RTC的人，可以将本文作为一篇快速指南加以参考，了解如何使用TensorFlow来处理WebRTC流。对于使用TensorFlow的人士，则可以将本文作为一份快速简介，了解如何向自己的项目中添加WebRTC。使用WebRTC的人需要对Python比较熟悉。而使用TensorFlow的人则需要熟悉网络交互和一些JavaScript。

本文不适合作为WebRTC或TensorFlow的入门指南使用。如需这样的指南，应参考TensorFlow入门指南、WebRTC入门指南等，网上的相关介绍与指南数不胜数。

教你如何结合WebRTC与TensorFlow实现图像检测（下篇）

2019-11-28 10:06:49

第3部分——浏览器端

开始之前，请先在项目的根目录位置创建一个static目录。我们将从这里提供HTML和JavaScript。

现在，我们首先使用WebRTC的getUserMedia抓取一个本地摄像头Feed。从这里，我们需要将该Feed的快照发送到刚刚创建的对象检测Web API，获取结果，然后使用canvas实时地在视频上显示这些结果。

HTML

我们先创建local.html文件：

在实时音视频中，基于 TensorFlow 实现图像识别

2019-11-28 10:09:27

首先，我们还是要先介绍一下 TensorFlow 的图像识别原理与方法。

WebRTC内置debug工具，详细参数解读

2019-11-28 10:10:48

要做到实时通信的质量监控，有哪些难点？

2019-11-28 10:11:29

本文整理自声网数据平台首席架构师何丰在 RTC 2018 实时互联网大会的演讲内容。他的演讲内容主要包括，如何以数据来衡量实时通信质量，质量透明化背后的数据挑战，以及声网面向开发者免费推出的通信质量诊断分析产品“水晶球”（Agora Analytics）的应用与技术难点。以下为演讲实录。

我们是提供实时音视频服务的。我们希望让开发者们使用实时通信服务，就像使用水、电一样方便。用户的设备接入了我们的云服务后，就可以直接与全球其它国家和地区的用户进行实时的语音或视频互动。

在声网的实时通信云服务上，已经有很多种应用，比如直播与社交，像参加本次大会的 MeetMe 就是美国目前最大的约会社交平台；再比如教育，有很多教育类产品为国内学生与海外老师搭建了实时互动的教学平台；再比如游戏，此前游戏比较流行一起打怪升级，现在很多手游已经集成实时通信的功能，开始变得社交化。在前不久，我们已经开始为小天才儿童手表提供了实时语音、视频的服务，实际上也是 RTC 技术应用于 IoT 领域的一个典型案例。

新媒体编码时代的技术：编码与传输

2019-11-28 10:12:54

本文整理了北京大学教授马思伟在 RTC 2018 实时互联网大会上的分享，从技术、编码与传输角度，分享了媒体编码的现状与未来，以及 AVS 编码标准的技术现状。以下为速记整理。

WebRTC基本概念（一）

2019-11-28 10:13:44

前言

WebRTC（Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架（APIs),支持浏览器（Firefox、Chrome、Opera）以及iOS、Android 原生系统（Poor WP,默哀）。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说，这是一个大大的福利。本系列文章会从WebRTC基本概念慢慢说起。

What is WebRTC？

官方介绍：

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow themall to communicate via a common set of protocols.
WebRTC是一个free的开源项目，该项目提供了一组可以在浏览器、手机应用平台（再次声明，目前只支持iOS和Android。）实现实时通信的简单API(s),WebRTC的目标是将实时通信过程做得最优化。
我们的任务（指WebRTC官方）：在手机应用平台、浏览器和物联网设备之间用同一组协议实现高质量实时通信。

WEBRTC RELAY---COTUR

2019-11-28 10:28:51

WEBRTC P2P穿透不了采用RELAY策略，RELAY实现采用标准的

RFC5766(UDP Allocation)，当然少不了RFC5389，但没有实现RFC6062(TCP Allocation) RELAY采用的传输层协议，由STUN Attributes REQUESTED-TRANSPORT决定，RFC5766定义UDP ,RFC6062定义了TCP，这个REQUESTED-TRANSPOR 规定的是TURN SERVER与PEER之间的传输协议，CLIENT与TURN SERVER的协议 RFC5766规定可以为UDP,TCP,TLS;RFC6062 必须为TCP,TLS。

WEBRTC 实现RFC5766的代码为 turnport.cc/.h

1.设置SERVER 与 PEER间为 UDP传输代码：在ALLOCATE请求中指定

WebRTC+libwebsockets+Janus的秒开实践

2019-11-28 10:38:54

背景

客户端SDK集成了WebRTC和libwebsockets，服务端使用了Janus，需要支持拉流秒开。关于WebSocket

Janus作为SFU，使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择，C层主要是libwebsockets库，这个也是Janus使用的库，还有Boost的Beast库，不过比较新，不敢踩坑，IOS上有RocketSocket，但不是跨平台，因此最后采用了libwebsockets库。
libwebsockets库主要的问题是IO接口不太友好，需要自己启动一个线程轮询获取IO事件，在其回调中处理所有事件。

webrtc开源服务器janus安装

2019-11-28 10:41:22

详细安装方法可以参考官网：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

webrtc gateway janus系列（二）运行demo

2019-11-28 10:53:57

janus 执行参数

-h, --help 打印帮助信息并退出

-V, --version 打印版本信息并退出

-b, --daemon 后台运行（默认前台运行）

-p, --pid-file=path pid文件目录路径

-N, --disable-stdout 禁止日志输出到标准输出

-L, --log-file=path 日志文件路径

Ubuntu 下 Janus Server 搭建笔记

2019-11-28 10:56:02

一、简介

Janus 是一个开源的，通过 C 语言实现了对 WebRTC 支持的 Gateway；Janus 自身实现得很简单，提供插件机制来支持不同的业务逻辑，配合官方自带插件就可以用来实现高效的 Media Server 服务。
本文主要介绍如何在 Ubuntu 16.04 下搭建起 janus 服务器，实现 janus 官方 Demo 浏览器与 Android APP Demo（janus-gateway-android）之间的音视频通话。

目前浏览器仅支持 FireFox 浏览器，因为 Chrome 浏览器打开音视频采集的话需要 HTTPS 加密访问！

效果图如下：

WebRTC 发送端无法获取丢包率的解决办法，以及如何获取 RTT

2019-11-28 10:56:59

WebRTC 自 M68 版本推出新的重载方法 GetStats 以后，使用新的接口便再也获取不到发送端的丢包率了（包括所有的 Native 端和 Web 端），原因是在 void OnStatsDelivered(const rtc::scoped_refptr<const RTCStatsReport>& report) 回调中返回的结构体 RTCStatsReport 中没有 packets_lost 的定义，只有 packets_sent、frames_encoded 等信息，默认只能获取到发送的码率、帧率，而得不到丢包率、rtt 等判断网络质量的关键信息。不过 WebRTC 底层其实已经将丢包信息、rtt 等关键信息实时统计上来了，只是 PeerConnectionInterface 在获取 Statistics 时，没有将相关信息打包进 RTCStatsReport 结构体中，那么解决办法就是：在 RTCStatsReport 结构体中新增定义 packets_lost、rtt_ms 字段，并为其赋值即可，下面为 Native 源码中需要修改的相关代码。

Breaking Point: WebRTC SFU Load Testing (Alex Gouaillard)

2019-11-29 00:29:33

Posted by Alex Gouaillard on October 18, 2018

Posted in: Technology.

Tagged: janus, jitsi, kurento, load test, mediasoup, medooze, quality, sfu.

If you plan to have multiple participants in your WebRTC calls then you will probably end up using a Selective Forwarding Unit (SFU). Capacity planning for SFU’s can be difficult – there are estimates to be made for where they should be placed, how much bandwidth they will consume, and what kind of servers you need.

To help network architects and WebRTC engineers make some of these decisions, webrtcHacks contributor Dr. Alex Gouaillard and his team at CoSMo Software put together a load test suite to measure load vs. video quality. They published their results for all of the major open source WebRTC SFU’s. This suite based is the Karoshi Interoperability Testing Engine (KITE) Google funded and uses on webrtc.org to show interoperability status. The CoSMo team also developed a machine learning based video quality assessment framework optimized for real time communications scenarios.

First an important word of caution – asking what kind of SFU is the best is kind of like asking what car is best. If you only want fast then you should get a Formula 1 car but that won’t help you take the kids to school. Vendors never get excited about these kinds of tests because it boils down their functionality into just a few performance metrics. These metrics may not have been a major part of their design criterion and a lot of times they just aren’t that important. For WebRTC SFU’s in particular, just because you can load a lot of streams on an SFU, there may be many resiliency, user behavior, and cost optimization reasons for not doing that. Load also tests don’t take a deep look at the end-to-end user experience, ease of development, or all the other functional elements that go into a successful service. Lastly, a published report like this represents a single point in time – these systems are always improving so result might be better today.

That being said, I personally have had many cases where I wish I had this kind of data when building out cost models. Alex and his team have done a lot of thorough work here and this is great sign for maturity in the WebRTC open source ecosystem. I personally reached out to each of the SFU development teams mentioned here to ensure they were each represented fairly. This test setup is certainly not perfect, but I do think it will be a useful reference for the community.

Please read on for Alex’s test setup and analysis summary.

webrtc 编译linux版本的各种问题

2019-11-29 01:50:18

下载和编译参照：http://depthlove.github.io/2019/05/02/webrtc-development-2-source-code-download-and-build/

最后的编译选项：

gn gen out/linux --args='target_os="linux" target_cpu="x64" is_debug=false is_clang=false treat_warnings_as_errors=false rtc_include_tests=false is_component_build=false use_custom_libcxx=false rtc_enable_protobuf=false'

1、连接webrtc静态库时候出现：error adding symbols: Malformed archive

vi build/config/compiler/BUILD.gn

搜索 complete_static_lib

去掉arflags = [ "-T" ] ，不用-T

Centos 下安装 WebRTC

2019-11-29 01:52:05

WebRTC 开源实现：https://github.com/webrtc/apprtc

一、环境安装

安装 java
```
yum -y install java-1.8.0-openjdk*
```

安装 node.js

curl -sL https://rpm.nodesource.com/setup_10.x | bash -
yum install -y nodejs
# 确认是否成功
node --version
npm --version

# 构建 apprtc 用到
npm -g install grunt-cli
grunt --version

webrtc的linux(CentOS7)下的编译方法

2019-11-29 01:53:34

点击http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools.html

进行查看depot_tools工具的linux下的安装方式

主要是在

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

本身之前就是需要翻墙的，我是在windows下做的代理，然后将windows上的git通过设置代理以后下载的这个工具

然后传输到linux里进行下面的编译

在编译之前还需要设置这个路径为PATH中，在/etc/profile中最后设置

export PATH=$PATH:/mnt/hgfs/linuxwebrtc/depot_tools

然后执行

source /etc/profile

AV1为何有信心干掉H.265和VP9，连苹果近期也加入了它

2019-12-02 00:19:23

WebRTC in the real world: STUN, TURN and signaling

2019-12-02 07:24:20

这篇文章会教你怎么搭建信令服务，和用STUN/TURN服务去做nat穿透。另外，我们会解释WebRTC是怎么做到多端通话的。以及如何和VoIP／PSTN（电话）建立通话。
如果你对WebRTC还没有基础，我们强烈建议你先看下Getting Started With WebRTC。
一.什么是信令服务（Signaling）？信令是一个协调沟通的过程，为了让一个WebRTC应用发起一个“通话”，客户端间需要交换以下信令信息：
1.发起和关闭一个通话的控制信息；
2.错误信息；
3.媒体元数据，比如编码解码设置，带宽和媒体类型；
4.Key数据，用于确保安全通讯；
5.网络数据，比如主机在外网下的IP地址和端口。
客户端的信令处理需要一种来回传递信息的方法，这种机制没有被WebRTC定义，你需要自己去创建它。下面我们将描绘几种构建信令服务的方法。
在此之前，先讲几个概念……为什么WebRTC没有定义信令？为了避免冗余和最大化兼容已经确立的技术，WebRTC没有指定信令的方法和协议。
-------------------------------
(WebRTC设计思想是完全指定和控制媒体层，但是让signaling层尽量脱离应用，原因是不同的应用可能会使用不同的协议，比如已经存在的SIP或者Jingle呼叫协议等。
这份协议中，需要交换的关键信息是多媒体会议的描述信息，包括在媒体层确定必要的传输方式和媒体配置信息)
------------------------------------------------
JSEP的结构同样避免了让浏览器保存状态信息，如果让浏览器成为一个保存信令状态的机器，会出现一个问题，
就是每次当页面重载的时候，信令会丢失。所以更好的方案是用服务器保存信令状态。

了不起的WebRTC：生态日趋完善，或将实时音视频技术白菜化

2019-12-02 07:26:05

有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年，这并非没有根据。就在去年（2017年），

WebRTC 1.0 标准草案出炉（实际上WebRTC标准草案的早期版本早在2011年就已经发布，WebRTC并非一夜之间就出现的技术），

并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了，或许门槛如此之高的实时音视频技术终有白菜化的那一天。

补充：WebRTC标准草案的版本演进历史，请点击进入。

实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序

2019-12-02 07:27:05

2017 年 12 月，微信小程序向开发者开放了实时音视频能力，给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配，然而只有在原生的 APP 上才能保障良好的用户体验。

那时候，在微信小程序中无法进行实时音视频互动。微信小程序在去年 12 月宣布开放实时音视频能力，再加上去年 6 月苹果宣布即将支持 WebRTC，业内一下子千树万树梨花开，前途一片光明。

连麦互动直播技术和微信小程序以及 WebRTC 能产生怎么样的化学作用？开发者在微信小程序或者浏览器 WebRTC 上实现连麦互动直播技术的时候，需要知道什么和考虑什么？

连麦视频直播的客户端主要包括：原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

押宝WebRTC：技术概要和对网络架构的冲击

2019-12-02 07:27:45

WebRTC技术概要

WebRTC是一套标准的而技术，可以使用Web或者移动应用程序通过浏览器实现强大的实时语音、视频、数据和视频会议等服务（如图1所示）。

如同一个基于浏览器的多媒体电话，或软件电话，它不但可以与其他的浏览器共同使用，也可与其他通信系统使用，如PSTN和VoIP。以前，如果试图建立的实时解决方案，必须依赖于昂贵的专用硬件和定制软件，需要投入把巨大的基础设施。但由于WebRTC的出现，在浏览器平台定义必要的接口后，就可以提供各种实时通信解决方案。这都归功于速度更快，高速计算硬件的出现。

WebRTC：基于物联网的行业化应用

2019-12-02 07:28:21

根据anyRTC官方运营数据分析预测，到2020年物联网设备的数量将达到近210亿。随着工业产品，可穿戴设备和智能家用电器的不断涌现，它们的多样性正在迅速增长。物联网产品的数据收集和通信功能为企业与客户的互动创造了新的途径，并获得了新的营销数据来源。

下一代的网络将更加快速，这就是WebRTC（Web实时通信）发挥作用的地方。它专注于实时双向音频和视频通信，并通过端到端加密进行保护。这些功能可用于物联网设备用户之间的通信。

什么是WebRTC

WebRTC是Google于2011年发布的一个开源项目，它提供基于API的Web浏览器和移动应用程序之间的通信，包括音频、视频和数据的传输。它消除了对本机插件和应用程序安装的依赖，使这些连接易于使用，并得到所有主要浏览器和移动操作系统的支持。

在过去的几年中，WebRTC在技术社区中的应用迅速发展。 Facebook、Amazon和Google都是实现WebRTC的主要技术公司之一，这些公司实现了WebRTC，从而使他们的Web应用程序更快、更可靠和更安全。WebRTC还提供现成的解决方案，可以轻松地与其他软件集成。

WebRTC入门与提高-WebRTC原理(STUN/TURN/SDP)

2019-12-02 07:29:21

基于WebRTC的Android数字楼宇对讲系统回声消除

2019-12-02 07:30:00

在一般的数字楼宇对讲系统应用中，对讲双方需要进行实时的语音交流，而在室内或是楼道门E1都采用外置音箱放音的形式，这势必会产生回声H。21，即通话的一方说话后通过网络传到通话另一方的音箱进行播放，然后播放出来的声音又被另一方的传声器采集到并且通过网络传回自己。这时，回声的产生将会影响对讲的通话质量和用户对于楼宇对讲产品体验，而对于现在新兴的Android数字楼宇对讲系统。更是如此。目前Android数字楼宇对讲系统中的回声消除技术实现有以下3方面的难点和问题：

1)Android本地实时回声消除技术问题Android系统是便携式嵌入式系统，软硬件的计算资源相对有限，很多在Windows系统等PC机平台上应用很成熟的回声消除算法和技术到Android平台上可能都会出现一些适应性问题。

2)回声消除中音频采集、播放的延时问题因为Android不是实时操作系统，造成传声器的录音、音响的放音之间都有一定时延，而且这个时延每个Android设备可能都不一样，这样即便有很好的回声消除方法，由于不能将录音、放音对齐将会使得回声消除没有效果或是消去正常通话声音，这会进一步增加Android回声消除难度。

3)Android回声消除的平台移植性

目前，Android版本很多，如何使Android回声消除技术能应用于多样的终端上是一个现实问题。

为了解决以上问题，采用WebRTC的回声消除模块实现Android本地实时回声消除，并设计了多线程编程技术实现音频采集、播放的同步，解决了Android楼宇对讲系统的回声问题，最后利用JNI(Java Native Interface——JAVA本地调用)技术将Android楼宇对讲系统回声消除程序进行封装，便于不同Android平台的移植。

WebRTC源码下载及编译流程(webrtc和webrtc-android)

2019-12-02 07:34:59

注1：本文档适用于webrtc和webrtc-android源码的下载和编译；

注2：下载编译所使用的操作系统为Ubuntu 14.04.3 LTS;

Chromium和Chromium OS统一使用一个叫做depot_tools的工具的对其源码进行checkout的管理（这有点类似于Android使用repo工具对其源码进行管理一样），作为Chromium其中一个子模块的webrtc而言，也是使用这个工具对其代码进行checkout。这个depot_rools包里面包含了gclient、gcl、git-cl、repo等工具。

下载depot_tools工具包并放到标准路径PATH上：

首先确保Linux上安装了Git 2.2.1以上版本，以及Python 2.7以上版本；

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

修改HOME目录中的.bashrc文件，在最后增加：PATH="~/bin/depot_tools:$PATH"，注意一定要把depot_tools的位置放在PATH的最前面；

参考：https://dev.chromium.org/developers/how-tos/install-depot-tools

Android硬编码——音频编码、视频编码及音视频混合

2019-12-02 07:41:35

视频编解码对许多Android程序员来说都是Android中比较难的一个知识点。在Android 4.1以前，Android并没有提供硬编硬解的API，所以之前基本上都是采用FFMpeg来做视频软件编解码的，现在FFMpeg在Android的编解码上依旧广泛应用。本篇博客主要讲到的是利用Android4.1增加的API MediaCodec和Android 4.3增加的API MediaMuxer进行Mp4视频的录制。

通常来说，对于同一平台同一硬件环境，硬编硬解的速度是快于软件编解码的。而且相比软件编解码的高CPU占用率来说，硬件编解码也有很大的优势，所以在硬件支持的情况下，一般硬件编解码是我们的首选。
在Android中，我们可以直接使用MediaRecord来进行录像，但是在很多适合MediaRecord并不能满足我们的需求，比如我们需要对录制的视频加水印或者其他处理后，所有的平台都按照同一的大小传输到服务器等。
在本篇博客中，将会讲到的是利用AudioRecord录音，利用OpenGL渲染相机数据并做处理。然后利用MediaCodec对音频和视频分别进行编码，使用MediaMuxer将编码后的音视频进行混合保存为Mp4的编码过程与代码示例。
值得注意的是，音视频编解码用到的MediaCodec是Android 4.1新增的API，音视频混合用到的MediaMuxer是Android 4.3新增的API，所以本篇博客的示例只实用于Android 4.3以上的设备。

WebRTC现状以及多人视频通话分析

2019-12-02 07:46:41

WebRTC 概述

WebRTC（网页实时通信技术）是一系列为了建立端到端文本或者随机数据的规范，标准，API和概念的统称。这些对等端通常是由两个浏览器组成，但是WebRTC也可以被用于在客户端和服务器之间建立通信连接，或者在任何其他可以实施WebRTC标准的设备之间进行通信建立。

WebRTC是一个开源项目，可在浏览器中实现无插件的实时通信（RTC）。它包括用于高质量通信的基本构建模块，

例如用于语音和视频聊天应用的网络，音频和视频组件。这些组件在浏览器中实现时，可以通过JavaScript API访问，

使开发人员能够轻松实现自己的RTC Web应用程序。

WebRTC由三个API组成：

GetUserMedia（摄像头和麦克风访问）
PeerConnection（发送和接收媒体）
DataChannels（在浏览器之间直接发送非媒体）

深入理解WebRTC

2019-12-05 07:41:19

Web Real-Time Communication（Web实时通信，WebRTC）由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端）的音频、视频及数据共享。

WebRTC使得实时通信变成一种标准功能，任何Web应用都无需借助第三方插件和专有软件，而是通过简单地JavaScript API即可完成。

在WebRTC中，有三个主要的知识点，理解了这三个知识点，也就理解了WebRTC的底层实现原理。这三个知识点分别是：

MediaStream：获取音频和视频流
RTCPeerConnection：音频和视频数据通信
RTCDataChannel：任意应用数据通信

WebRTC教程—文件传输

2019-12-05 08:43:41

作者：deepstreamHub（原文链接）

翻译：刘通

原标题：WebRTC 06: File Transfer

上一篇：WebRTC教程—屏幕共享

WebRTC使得在两个浏览器间使用data-channels和二进制数据传输任意文件成为可能。

（点击图片跳转到原文查看例子）

二进制数据在浏览器中是如何工作的

目前的这代浏览器允许你发送字节数组—有八个0或1组成的集合，可以代表0到255之间的任何数字。为了完成这些，我们提供了一系列的概念—Uint8Array来储存它们，FileReader来创建它们，Blob来组合它们。像Websocket和WebRTC这样的传输工具允许传输原始字节流。

为什么很重要

WebRTC：数据传输相关协议简介

2019-12-05 08:47:14

对网络协议来说，需要做的通常就两件事情：1、建立连接，2、传输数据，WebRTC也不例外。

假设WebRTC应用的两端已经建立了连接，那么，剩下就是如何传输数据的问题了。

WebRTC同时支持传输音视频数据、自定义应用数据。这其中，涉及多种协议，包括UDP、RTP/SRTP、RTCP/SRTCP、DTLS、SCTP。

这些协议名字比较相似，很容易让人混淆，简单总结下：

传输音视频数据相关协议：UDP、DTLS、RTP/SRTCP；
传输自定义应用数据相关协议：UDP、DTLS、SCTP；

下面就简单介绍下，这些协议是做什么的，有什么区别，存在什么联系。

加密信道建立：UDP、DTLS

对WebRTC应用来说，不管是音视频数据，还是自定义应用数据，都要求基于加密的信道进行传输。DTLS 有点类似 TLS，在UDP的基础上，实现信道的加密。

DTLS的主要用途，就是让通信双方协商密钥，用来对数据进行加解密。

通信双方：通过DTLS握手，协商生成一对密钥；
发送方：对数据进行加密；
发送方：通过UDP传输加密数据；
接收方：对加密数据进行解密；

使用WebRTC实现远程屏幕共享

2019-12-05 10:43:19

正如我们上周报道的一样，最近有很多事情发生在我们熟知的WebRTC上。

其中一个是：基于WebRTC的屏幕共享

这是屏幕录像：youtube.com/watch?v=tD0QtBUZsF4。

这是代码：github.com/samdutton/rtcshare。

从本质上讲，我们使用RTCPeerConnection和chrome.tabCapture构建了一个实验性的Chrome扩展，以此通过浏览器标签来分享实时视频。如果你想尝试一下，你需要使用Chrome的Canary版本，并且在about:flags页面开启实验性扩展（Experimental Extension）的API。

我们的原型很大程度上依赖于强大的apprtc.appspot.com演示，坦率地说，这有点像黑客行为。但是，这是一个概念的证明，并且我们做到了。

下面是我们的实现方法：

WebRTC 连接Linux端和Android端

2019-12-05 10:44:47

跨平台连接

WebRTC的通常连接流程:
http://blog.csdn.net/qq_21358401/article/details/79190561
WebRTC SDP协议:
http://blog.csdn.net/qq_21358401/article/details/79341031

连接不同平台的PeerConnection的流程和通常流程没有什么区别.
但很容易遇到这些一个问题:
1. 不支持的音视频编解码器
   WebRTC报错: failed to set video send codecs
   意为不支持收到的SDP里声明的某个视频编码
   我在连接linux和android端时 就出现了android端不支持97和98(编码协议的RTP序号)
   所以需要在设置local或remote的SDP前 修改sdp 去掉不支持的codec
2. 不支持的传输协议
   这个错误常见于和浏览器的peer连接
   浏览器通常不支持 UDP/TLS 这两个传输选项(firefox上发现问题)
   解决方法同样是修改SDP 去除不支持的传输协议

webrtcH4cKS: ~ The Minimum Viable SDP

2019-12-05 10:53:49

One evening last week, I was nerd-sniped by a question Max Ogden asked:

That is quite an interesting question. I somewhat dislike using Session Description Protocol (SDP) in the signaling protocol anyway and prefer nice JSON objects for the API and ugly XML blobs on the wire to the ugly SDP blobs used by the WebRTC API.

The question is really about the minimum amount of information that needs to be exchanged for a WebRTC connection to succeed.

WebRTC uses ICE and DTLS to establish a secure connection between peers. This mandates two constraints:

Both sides of the connection need to send stuff to each other
You need at minimum to exchange ice-ufrag, ice-pwd, DTLS fingerprints and candidate information

WebRTC的头文件提取

2019-12-05 11:00:25

像WebRTC这样结构比较庞大的工程,在需要链接WebRTC库时是比较麻烦的.
特别是在linux代码使用到WebRTC库时的编译,不但要自行整合链接WebRTC库,
并且头文件路径也需要指向WebRTC代码目录.

项目中引用到第三方库时的做法通常是提取出库文件和头文件,添加到工程目录中供链接.
WebRTC的库文件和头文件也可以通过脚本提取出来.
库文件的打包:
http://blog.csdn.net/qq_21358401/article/details/78614211

WebRTC头文件提取的关键在于提取时保持目录结构,避免需要修改头文件来通过编译.

cp –parents

Linux cp命令加上parents参数时,可以保持目录结构

webRTC PeerConnection连接过程

2019-12-05 11:05:08

PeerConnection

PeerConnection是webRTC的顶层接口,代表一个通话对象.
要建立点对点的音视频通话需要的双方各建立一个PeerConnection并交互信令完成对接.

signal信令

webRTC的信令指的是 SDP和Candidate
    1. SDP是session description,描述local的多媒体情况
    2. Candidate是候选,包含了p2p的信息
webRTC文档中描述的需要用户自定义实现的信令交互过程其实就是两个
PeerConnection交换sdp和candidate的过程.

最简单的信令可以直接通过socket来实现,webRTC的官方demo 
PeerConnection client就是将sdp和candidate json序列化后通过socket发生出去的.

WebRTC SDP协议

2019-12-05 11:06:41

SDP

SDP Session Description Protocol 会话描述协议
SDP协议用来在SIP终端之间交换媒体信息,WebRTC标准中同样选用了
SDP协议来交换媒体信息.

WebRTC Peer之间交换SDP包括的信息有transport protocols,ports,codecs等等
相关的IETF文档:
https://tools.ietf.org/pdf/draft-nandakumar-rtcweb-sdp-08.pdf

语法

SDP由多部分信息组成 每部分信息占一行.
<type>=<value>

v= 表示版本
o= 表明会话源 ssrc
s= 表明会话名
a= 表明会话属性
m= 表明媒体协议信息

webRTC入门: 打包webRTC库应用到自己的工程中

2019-12-05 11:07:38

打包webRTC库

在linux下打包webRTC库链接到自己的工程中

webRTC Linux SDK编译静态库

webRTC指定target_os为Linux后，根据gn的编译规则并不像android那样会生成动态库so。想要使用webRTC库需要自己提取静态库

静态库分布

打开webRTC SDK目录
cd out/linux
编译目录下会生成例如peerconection_client这样的测试用例同时还有许多的webRTC模块静态库。
对 webRTC并不像常见的开源工程那样生成一个整体的库而是根据模块来生成，类似ffmpeg的做法
这样一来想要避免在cmake中手动链接如此多的静态库就需要我们自己链接生成统一的libwebrtc.a

WebRtc: PeerConnection demo测试

2019-12-05 11:08:36

系统: ubuntu14.04 工程: webrtc-linux 网络:本机localhost

webrtc工程编译过后会在out/linux目录下生成一些测试用可执行程序
其中有 peerconnection_server 和 peerconnection_client可以用于测试连接

后台执行server
./peerconection_server &
可以看到执行后提示正在监听8888端口
后台执行第一个client
./peerconnection_client &
会弹出一个ui对话框按enter键确认
执行第二个client
./peerconnection_client
执行后可以看到ui框中会出现可点击的主机名双击
注意: 由于在ubuntu下测试视频对话框并不会跳出显示在屏幕下,而是运行但不显示在屏幕上,注意在图标栏中寻找一下视频对话框

我的视频对话框图像是红色的,不正常有待解决问题.

webRTC base模块MessageQueue消息队列的实现

2019-12-05 11:09:22

MessgeQueue

MessageQueueManager

消息队列MessageQueue的管理器
全局单例类

MessageQueueManager* MessageQueueManager::instance_ = NULL; // 全局变量　确保Manager是单例
MessageQueueManager* MessageQueueManager::Instance() {
  // C++ Instance常见套路
  if (!instance_)
    instance_ = new MessageQueueManager;
  return instance_;
}

WebRTC getStats详解－从标准、调用到实现

2019-12-05 11:33:56

getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。<br />
本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。<br />

一 getStats标准

getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />

发送端采集统计：对应于媒体数据的产生，包括帧率，帧大小，媒体数据源的时钟频率，编解码器名称，等等。<br />
发送端RTP统计：对应于媒体数据的发送，包括发送数据包数，发送字节数，往返时间RTT，等等。<br />
接收端RTP统计：对应于媒体数据的接收，包括接收数据包数，接收字节数，丢弃数据包数，丢失数据包数，网络抖动jitter，等等。<br />
接收端渲染统计：对应于媒体数据的渲染，包括丢弃帧数，丢失帧数，渲染帧数，渲染延迟，等等。<br />

另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />

往返时间RTT：表示数据在网络上传输所用的时间，一般通过RTCP 的SR/RR数据包中的相关域进行计算。该度量直接反映网络状况的好坏。<br />
丢包率影响接收端音视频质量，在严重的情况下可能导致声音跳变或者视频马赛克，从侧面反映网络状况的好坏。<br />
音视频数据到达接收端之后，要经历收包、解码、渲染等过程，该过程会带来延迟。接收端延迟是数据从采集到渲染单向延迟的重要组成部分。<br />

通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />

WebRtc连接状态变化

2019-12-05 11:14:44

WebRtc连接状态变化

ICE收集完成的条件
连接状态的变化

ComputeState：一旦ICE收集完成，至少应该存在一个可用的连接

1.如果had_connection_ 为false，则状态为STATE_INIT

2.检查所有的Connection，看是否有active的

3.该函数应该是在ICE收集完成时才会调用

4.如果检查所有Connection，没有active的连接，则返回STATE_FAILED

WebRTC的优缺点

2019-12-05 11:34:30

作为Google开源的技术，WebRTC并不是一个可以拿来就用并且性能很好的产品，需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。

WebRTC的优点：

1. 方便。对于用户来说，在WebRTC出现之前想要进行实时通信就需要安装插件和客户端，但是对于很多用户来说，插件的下载、软件的安装和更新这些操作是复杂而且容易出现问题的，现在WebRTC技术内置于浏览器中，用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说，在Google将WebRTC开源之前，浏览器之间实现通信的技术是掌握在大企业手中，这项技术的开发是一个很困难的任务，现在开发者使用简单的HTML标签和JavaScript API就能够实现Web音/视频通信的功能。

2. 免费。虽然WebRTC技术已经较为成熟，其集成了最佳的音/视频引擎，十分先进的codec，但是Google对于这些技术不收取任何费用。

3. 强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。

WebRTC的缺点：

Awesome WebRTC

2019-12-05 11:36:06

A curated list of awesome WebRTC modules and resources. Inspired by awesome-python.

WebRTC的模块处理机制

2019-12-05 11:36:54

对于实时音视频应用来讲，媒体数据从采集到渲染，在数据流水线上依次完成一系列处理。流水线由不同的功能模块组成，彼此分工协作：数据采集模块负责从摄像头/麦克风采集音视频数据，编解码模块负责对数据进行编解码，RTP模块负责数据打包和解包。数据流水线上的数据处理速度是影响应用实时性的最重要因素。与此同时，从服务质量保证角度讲，应用需要知道数据流水线的运行状态，如视频采集模块的实时帧率、当前网络的实时速率、接收端的数据丢包率，等等。各个功能模块可以基于这些运行状态信息作相应调整，从而在质量、速度等方面优化数据流水线的运行，实现更快、更好的用户体验。</br>

WebRTC采用模块机制，把数据流水线上功能相对独立的处理点定义为模块，每个模块专注于自己的任务，模块之间基于数据流进行通信。与此同时，专有线程收集和处理模块内部的运行状态信息，并把这些信息反馈到目标模块，实现模块运行状态监控和服务质量保证。本文在深入分析WebRTC源代码基础上，学习研究其模块处理机制的实现细节，从另一个角度理解WebRTC的技术原理。</br>

ULPFEC在WebRTC中的实现

2019-12-05 11:37:38

在基于IP网络的多媒体通信系统(比如WebRTC)中，网络丢包对多媒体通信质量有非常严重的影响：例如造成视频的马赛克、图像模糊、帧率下降等问题，造成音频的声音失真、噪声干扰、音频中断等问题。这都会严重影响系统的通信质量，造成非常差的用户体验。

WebRTC主要采取两种手段对抗网络丢包：丢包重传(NACK)和前向纠错(FEC)。丢包重传在之前文章中有专门论述[1]，本文集中注意力于FEC。FEC是一种前向纠错技术，发送端将负载数据加上一定的冗余纠错码一起发送，接收端根据接收到的纠错码对数据进行差错检测，如果发现差错，则利用纠错码进行纠错。而ULPFEC(Uneven Level Protection FEC，直译为非均等保护前向纠错)则是WebRTC实现的FEC方案之一，本文深入学习ULPFEC的理论基础和实现细节。

教你如何结合WebRTC与TensorFlow实现图像检测（上篇）

2019-12-05 11:38:42

TensorFlow是目前最流行的机器学习框架之一。TensorFlow的一大优势是，它的很多库都有人积极进行维护和更新。而我最喜欢的其中一个库就是TensorFlow对象检测API。Tensorflow对象检测API可以对一张图形上的多个对象进行分类，并提供它们的具体位置。该API在将近1000个对象类上进行了预先训练，可提供各种经过预先训练的模型，让你可以在速度与准确性之间权衡取舍。

有这些模型的指引固然很好，但所有这些模型都要使用图像才能发挥作用，而这些图像则需要你自行添加到一个文件夹中。我其实很想将其与实时的WebRTC流配合到一起，通过网络实现实时的计算机视觉。由于未能找到这方面的任何例子或指南，我决定写这篇博文来介绍具体的实现方法。对于使用RTC的人，可以将本文作为一篇快速指南加以参考，了解如何使用TensorFlow来处理WebRTC流。对于使用TensorFlow的人士，则可以将本文作为一份快速简介，了解如何向自己的项目中添加WebRTC。使用WebRTC的人需要对Python比较熟悉。而使用TensorFlow的人则需要熟悉网络交互和一些JavaScript。

本文不适合作为WebRTC或TensorFlow的入门指南使用。如需这样的指南，应参考TensorFlow入门指南、WebRTC入门指南等，网上的相关介绍与指南数不胜数。

基于Licode的WebRTC全球分布式架构

2019-12-05 11:50:52

大家好，我是来自百家云的陈聪，今天我将为大家带来与Licode的WebRTC全球分布式架构相关的技术分享。之所以想为大家介绍这个架构，是因为我在使用WebRTC开源服务器时发现WebRTC并没有提供类似于分布式或集群的整体解决方案，希望百家云在此领域的探索能为大家带来有价值的帮助。

1. SFU

1.1 SFU简介

640?wx_fmt=jpeg

SDP协议详解

2019-12-06 13:52:45

本文将介绍WebRTC中的SDP协议，实际上SDP协议并不属于WebRTC专有协议。

一、SDP简述

ICE信息的描述格式通常采用标准的SDP,其全称为Session Description Protocol,即会话描述协议。SDP只是一种信息格式的描述标准,不属于传输协议,但是可以被其他传输协议用来交换必要的信息,如会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）等。SDP协议是基于文本的协议，协议的可扩展性比较强，其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。

流媒体协议sdp信息，附带在describe报文中有rtsp服务端发出，主要目的，告之会话的存在和给出参与该会话所必须的信息，sdp会话完全是文本形式，采用UTF-8编码的ISO 10646字符集。

图1-SDP协议例子 图2-SDP协议例子续

sdp描叙符包括：

会话名和目的
会话激活的时间区段
构成会话的媒体
接收这些媒体所需要的信息（地址，端口，格式）
会话所用的带宽信息
会话拥有者的联系信息

WebRTC中的RTP、SRTP、RTCP协议

2019-12-06 13:53:41

本文将讲述WebRTC中RTP、SRTP、RTCP协议。本文内容来自于超越RFC3550 － RTP/RTCP协议族分析

##一、前言 RF3550定义了实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对实时流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。

RTCP协议负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用，通过有效反馈使使流媒体传输效率最佳化。

IETF的RFC3550定义了RTP/RTCP协议的基本内容，包括报文格式、传输规则等。除此之外，IETF还定义一系列扩展协议，包括RTP扩展，RTCP报文类型扩展，等等。本文对这些协议进行初步归纳总结，在分析RFC3550的基础上，�重点分析RTP系列协议，并以报文类型为主线分析RTCP系列协议。

P2P网络技术-NAT的由来、类型以及优缺点

2019-12-06 13:54:29

本文将讲述WebRTC中使用的P2P技术，重点讲解NAT的由来、类型及优缺点。

##一、 IPV4协议和NAT的由来 IPv4即网际网协议第4版——Internet Protocol Version 4的缩写。IPv4定义了一个跨越异种网络互连的超级网，并为每个网际网的节点分配全球唯一的IP地址。如果把Internet比作一个邮政系统，那么IP地址的作用就等同于包含国家、城市、街区、门牌编号在内的完整地址。IP地址使用32bits整数表达一个地址，地址最大范围是2的32次方，约为43亿。在IP创始时期可被联网的设备来看，这样的一个空间很大，很难被短时间用完。然而，事实远远超出人们的设想，计算机网络在此后几十年迅速壮大，网络中断数量呈爆炸性增长。

更糟糕的是，为了路由和管理方便，43亿地址空间按照不同前缀长度分为A、B、C、D四类网络地址和保留地址。其中，A类网络地址127段，每段包括主机地址约1678万个。B类网络地址16384端，每段包括65536个主机地址。 IP地址管理机构IANA向超大型企业/组织分配A类网络地址，一次一段。向中型企业或者教育机构分配B类网络地址，一次一段。这种分配策略使得IP地址浪费极为严重，很多被分配的地址并未被真实利用，地址消耗很快。二十世纪90年代初，网络专家们意识到这样分配下去，IPv4地址很快就会耗光。于是人们开始考虑IPv4的替代方案，并采取一系列措施减缓IPv4的消耗。在这种背景下，NAT（网络地址转换）应运而生。

NAT是一项神奇的技术，它的出现几乎使IPv4起死回生。在IPv4已经被认为行将结束历史使命之后近20年时间里，人们几乎忘了IPv4的地址空间即将耗尽这样一个事实。更不用说，在NAT产生以后，网络终端的数量呈加速上升趋势，对IP地址的需求剧烈增加。此足见NAT技术之成功，影响之深远。

WebRtc中ICE原理

2019-12-06 14:17:29

webRTC支持点对点通讯，但是webRTC仍然需要服务端：
. 协调通讯过程中客户端之间需要交换元数据，
如一个客户端找到另一个客户端以及通知另一个客户端开始通讯。
. 需要处理NAT（网络地址转换）或防火墙，这是公网上通讯首要处理的问题。
所以我们需要了解服务端相关的知识：信令、Stun、trun、ice。

一、什么是信令
信令就是协调通讯的过程，为了建立一个webRTC的通讯过程，客户端需要交换如下信息：
. 会话控制信息，用来开始和结束通话，即开始视频、结束视频这些操作指令。
. 处理错误的消息。
. 元数据，如各自的音视频解码方式、带宽。
. 网络数据，对方的公网IP、端口、内网IP及端口。

[webrtc] 交互式连接建立（ICE）

2019-12-06 14:19:12

WEBRTC浅析（二） ICE 机制简介及STUN通信流程

2019-12-06 14:23:33

WEBRTC ICE 简介
在这里，我会介绍一下WEBRTC 中， ICE 的机制。主要分为三个部分。

第一部分，为ICE的协议部分介绍。
第二部分，为STUN 的信令连接图。
第二部分，为WEBRTC中代码的实现流程。

WebRTC直播技术(二)-ICE/STUN/TURN

2019-12-06 14:27:10

首先要掌握WebRTC连接建立过程，需要掌握几个知识点： NAT, ICE, STUN, TURN, DTLS等。如果之前有接触过P2P相关技术的同学可能就会比较容易理解。WebRTC是一个基于浏览器与浏览器之间的实时音视频通话方案，那么有于公网ip地址有限的问题，用户的浏览器常常位于NAT后，那么建立连接就涉及到了打洞技术。

NAT
由于当前使用的IPV4地址的长度限制只有32位，大多数终端都没有一个可以在互联网上可见的唯一IPV4地址。NAT是作为一种解决IPv4地址短缺以避免保留IP地址困难的方案，在IP数据包通过路由器或防火墙时重写来源IP地址或目的IP地址。

STUN
为了进行P2P通信，会话参与双方都需要知道其对等端的IP地址和指定的UDP端口。因此，在WebRTC通信建立之前，需要进行一定数量的信息交换。
每个对等端需要使用一个STUN服务器来探测他们的公共IP地址，这个IP在连接建立的时候会被ICE框架所引用。STUN服务器是通常是可公开访问的，WebRTC应用可以自由访问。

TURN
TURN服务指的是中继型NAT遍历服务器，其地址是一个公共ip地址，用于转发数据包给对端浏览器。当2个对等端因为NAT类型而无法建立连接时(当遇到对称型NAT会导致打洞失败)，才需要使用中继服务器。

ICE: 交互式连接建立（Interactive Connectivity Establishment）
ICE是一种标准穿透协议，利用STUN和TURN服务器来帮助端点建立连接。WebRTC当通过信令server交换完sdp, candidate后，之后依靠ICE框架在2端之间建立一个通道。

ICE的过程主要分为5步：

WebRTC下的网络连接: STUN, TURN, ICE, TCP

2019-12-06 14:27:59

实现一个WebRTC demo是比较容易的, 但如果要做一个webrtc产品, 则需要在任何网络环境下都能够建立网络连接.

Background: NAT

多数联网设备都位于局域网中, 并位于防火墙后面, 设备本身只有一个内网的私有IP, 在与外部通信时, 会经过1个或多个NAT路由器, 最终得到一个最外端的一个外部IP, 然后与远端目标机器通讯. 这一网络结构对于web应用, c/s型应用等来说不是问题, 但对于VoIP/P2P等应用就是一个问题了. 通信双方并不知道自己或对方的outermost的外网IP:Port, 如何建立直连呢?

这时就需要NAT穿透, 目前WebRTC采用的是ICE框架 (ICE+STUN+TURN), ICE也适用于非WebRTC应用, 这是目前业界用于穿透NAT的标准方案.

ICE使用了STUN, TURN等技术, 并扩展了SDP. ICE会同时尝试找出两个机器可行的连接方式, 并选择一个最高效的连接方式来穿透NAT. 参考文档:

RFC 5389 - STUN
RFC 5766 - TURN
RFC 5245 - ICE, updated by RFC 6336
RFC 6544 - TCP ICE
trickle ICE
SIP usage for trickle ICE
Tunneling WebRTC over TCP (and why it matters) - 介绍了STUN/TURN的作用
What kind of TURN server is being used?? - 提到了17.7%经过TURN中转

STUN/TURN/ICE协议在P2P SIP中的应用

2019-12-06 14:29:09

目录：

1 说明

2 打洞和穿越的概念... 1

3 P2P中的打洞和穿越... 2

4 使用STUN系列协议穿越的特点... 2

5 STUN/ TURN/ICE协议的关系... 3

6 STUN协议(RFC 5389) 3

WebRTC in the real world: STUN, TURN and signaling

2019-12-06 14:42:58

WebRTC enables peer to peer communication.

BUT...

WebRTC still needs servers:

For clients to exchange metadata to coordinate communication: this is called signaling.

To cope with network address translators (NATs) and firewalls.

In this article we show you how to build a signaling service, and how to deal with the quirks of real-world connectivity by using STUN and TURN servers. We also explain how WebRTC apps can handle multi-party calls and interact with services such as VoIP and PSTN (aka telephones).

If you're not familiar with the basics of WebRTC, we strongly recommend you take a look at Getting Started With WebRTC before reading this article.

What is signaling?

WebRTC - 我需要指定多少个STUN / TURN服务器？

2019-12-06 14:43:58

我遇到的麻烦NAT traversal和WebRTC。Videostreaming适用于某些人，但不适用于学生宿舍路由器后面的人。

我认为这应该通过使用TURN服务器来解决。我已经这样做了，它仍然无法正常工作，现在我想知道TURN服务器是否可以工作。因此，我想知道我是否可以或应该设置几台TURN服务器，如果是，如何。

现在我正在设置他们这样

为什么你的WebRTC产品需要TURN服务器

2019-12-06 14:44:36

端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。

在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。

平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。

ICE和STUN

在讨论TURN之前，我们需要定义两个缩略词。

ICE是交互式连通性建立（Interactive Connectivity Establishment）的缩写，它定义了一种系统化的方式来寻找两个端点（通过NAT和防火墙）之间可能的通信选项，包括必要时使用中继。

STUN是NAT的会话遍历实体（Session Traversal Utilities for NAT）的缩写。STUN向请求端点提供其公共IP地址。STUN是一个相对轻量级的过程，之所以是轻量级是因为一旦STUN为请求者提供了可公开访问的IP地址，它就不再参与对话了。

当一个端点在NAT后面时，它只能看到它的本地IP地址。通话中的其他端点将无法使用此本地IP地址连接到端点，因为它可能是专用地址，或者防火墙不允许进行访问。在这种情况下，该端点可以要求STUN服务器提供其公共IP地址。参与者然后使用ICE过程并尝试使用公共IP地址建立连接，并且如果连接成功建立，则媒体直接在用户之间流动，而没有任何主动中继。处于所有实际的目的，STUN就会退出，然后等待下一次使用。

但是，上述情况只对某些NAT有用。在一些NAT实现中，端口将被转换为其他端口以及它所连接的IP地址。这种情况被称为“对称NAT”。STUN过程的公共IP地址不足以建立连接，因为端口也需要进行IP地址转换。

这就是为什么TURN服务器至关重要的原因。

浅谈融合SD-RTN ——毫秒级网络加速的技术变革

2019-12-06 15:02:25

近几年网络直播视频、VR/AR、竞技游戏、大数据、4K高清视频的快速增长，正在将毫秒级网络加速技术推向历史发展的潮头。用户的预期越来越高，他们期待“最好”的在线体验，网络延迟会直接影响到应用的转化率。即有多少人可以变成你的客户，现在用户的体验和忠诚度已经不能用“分钟”和“秒”来衡量，而是用“毫秒级”来衡量，每个毫秒都会对用户的转化和体验有影响。

比如说在线教育类用户就希望视频直播的端到端延迟能够严格控制在500毫秒以内，使之具备和视频连麦相同的低延迟体验。那现在的CDN加速技术还能起作用吗？首先数据不能有cache，TCP的延迟累积必须消除，甚至RTMP协议也要切换到WebRTC的技术架构。移动互联网的实时视频应用领域正在快速演变中的一切，我们先姑且称之为网络延迟革命吧。

强制WebRTC使用转发(relay)模式

2019-12-06 15:05:05

假如你在企业内使用WebRTC，可能会遇到UDP端口被封的情况，这个时候可以强制WebRTC使用TCP转发模式。

要使用TCP转发，得配合一个 turn server，开源的 coturn 实现了 TCP 转发，我在“Ubuntu Server 14.04下配置coturn for WebRTC”一文中介绍了如何安装配置，可以参考。

配置了 coturn 后，在 Chrome 内建立 PeerConnection 对象时，做个配置，就可以实现转发了，类似下面：

WebRTC TURN协议初识及turnserver实践

2019-12-06 15:07:01

本文主要为初步接触 WebRTC 的开发者介绍 WebRTC turnserver 的原理机制，以及 Agora 在此方面的部分经验。如遇到疑问，可以点击这里，与作者直接交流。

WebRTC协议栈

turnserver穿透服务器详细配置

2019-12-06 15:08:12

1：配置需要

为webrtc配合 ubuntu系统 rfc5766-turn-server

2.下载安装包：

$ wget http://ftp.cn.debian.org/debian/pool/main/r/rfc5766-turn-server/rfc5766-turn-server_3.2.4.4-1_amd64.deb
可以根据网址从网站上直接下载

3. 安装：

$ sudo apt-get update
$ sudo apt-get install gdebi-core
$ sudo gdebi rfc5766-turn-server_3.2.4.4-1_amd64.deb
安装完后，在/usr/share/doc/rfc5766-turn-server下有很多文档可参考。

WebRTC 及点对点网络通信机制

2019-12-06 15:10:48

何为 WebRTC ？首先，字面上已经给出了关于这一技术的大量信息，RTC 即为实时通信技术。

WebRTC 填补了网页开发平台中的一个重要空白。在以往，只有诸如桌面聊天程序这样的 P2P 技术才能够实现实时通讯而网页不行。但是 WebRTC 的出现改变了这一状况。

WebRTC 本质上允许网页程序创建点对点通信，我们将会在随后的章节中进行介绍。我们将讨论如下主题，以便向开发者全面介绍 WebRTC 的内部构造：

点对点通信
防火墙和 NAT 穿透
信令，会话及协议
WebRTC 接口

WebRTC 开发实践：为什么你需要 SFU 服务器

2019-12-06 15:14:29

当你入门 WebRTC 之后，很快就会接触到一个名词，叫做：SFU，你可能很容易就在网上寻找到很多 SFU 的开源实现，并并兴致勃勃地开始编译、部署和测试这些服务器，但是可曾想过，为啥我们的 WebRTC 应用需要 SFU 服务器？

1 WebRTC P2P 通话的网络模型

WebRTC 开发实践：如何实现 SFU 服务器

2019-12-06 15:16:37

1 什么是 SFU ？

首先，我们再看一次 SFU 服务器的定义，什么是 SFU ？

SFU 的全称是：Selective Forwarding Unit，是一种路由和转发 WebRTC 客户端音视频数据流的服务端程序。

WebRTC 开发实践：编译 Android 平台源码

2019-12-06 15:17:14

前面两篇文章分别介绍了如何利用 WebRTC API 实现一对一视频通话和多人视频会议，并给出了相应的 demo 程序，该 demo 是基于官方预编译好的库开发的。如果要想深入学习和研究 WebRTC，仅仅掌握偏上层的 API 接口是远远不够的，而是应该做到能自己编译和修改 WebRTC 源码，这样才能不受限制地根据自己的需要优化和改进产品的质量和效果。

网上有很多介绍 WebRTC 源码编译的文章，我这里也不会赘述太多，只介绍些关键经验。总体来说，有下面几个点先提前说明一下：

1. 最靠谱的编译指南是官方的指导文章：https://webrtc.org/native-code/android/

2. WebRTC Android 的编译只支持在 Linux 环境中进行，推荐安装 Ubuntu 16.04 的物理机或者 VPS，不建议在 Mac/Windows 上使用 Docker 或者虚拟机等方式来编译，容易遇到很多奇怪的问题。当然，我下面也还是会介绍下 Mac 下如何利用虚拟机来编译。

3. WebRTC Android 的源码和配套工具大约 16 GB 左右，国内由于 GFW 的原因，需要配置代理来下载和同步，由此可能带来很多奇奇怪怪的问题。

4. 时间就是金钱，由于配置代理同步代码容易遇到各种坑，比较推荐的方式是在 Linode 或者 Vultr 购买一台位于国外的 VPS 虚拟机，基本上参照 WebRTC 官方文档，半天时间就可以顺利走通整个源码同步和编译流程了。

RTCStartupDemo：一款极其简单的 WebRTC 入门项目

2019-12-06 15:18:24

如今越来越多的公司投身到 WebRTC 的开发和应用之中，同时也有越来越多的开发者对 WebRTC 技术感兴趣。相对于单向传输的直播和播放器，支持“实时+双向” 音视频通话的 WebRTC 项目显然要庞大和复杂很多很多。由于 WebRTC 官方没有提供服务器的实现，自己从 0 搭建一套开源的 WebRTC 服务器、跑通并且读懂官方的 AppRTCDemo 代码还是需要很费一些周折的。

基于这些原因，我启动了一个小的开源项目：RTCStartupDemo，致力于提供一套超级简单的信令服务器，以及配套的完全基于 WebRTC 官方 API 的客户端 demo 示例代码（含：Web/Android/iOS/Windows 全平台），目标是让所有有兴趣学习 WebRTC 的同学，都能快速把项目 run 起来，看到通话效果，理解核心 API，快速入门。

Android 音视频开发入门指南

2019-12-06 15:24:40

最近收到很多网友通过邮件或者留言说想学习音视频开发，该如何入门，我今天专门写篇文章统一回复下吧。

音视频这块，目前的确没有比较系统的教程或者书籍，网上的博客文章也都是比较零散的，希望我后面能挤出时间整一个专题详细讲一讲～～目前的话，我先给出一个大的方向性的学习指南，希望对初学者有所帮助。

我一直相信带着 “任务” 去学习和实践，效率会高很多，因此我列出了一系列音视频相关的 “开发任务”，从简单到困难（当然，不一定非常严格和完美，部分任务先后可调整），大家在完成任务的过程中，遇到任何不懂的地方都要及时去 google，或者去请教身边的大牛，不放过任何一个疑点，相信大家会很快就能把音视频周边相关知识积累起来。

WebRTC 开发实践：从一对一通话到多人会议

2019-12-06 15:26:38

为了让初学者快速起步把 WebRTC demo 跑起来，我写了一个极其简单的 startup demo 项目，展示了如何基于 WebRTC API 实现一对一的视频通话。该项目地址：https://github.com/Jhuster/RTCStartupDemo

本文则主要介绍如何从一对一通话升级到多人通话，即视频会议，其中涉及到如下几个问题：

多人会议，每个 Client 是创建多个 PeerConnection 还是只有一个 PeerConnection ？

多人会议，谁来发起 OFFER，谁来作为 ANSWER，如何把多个 Client 相互间的连接分别建立起来？

首先，我们用下面这一张图来看看两个 WebRTC Peer 之间是如何建立一对一通话链路的：

WebRTC介绍

2019-12-06 15:29:09

众所周知，浏览器本身不支持相互之间直接建立信道进行通信，都是通过服务器进行中转。比如现在有两个客户端，甲和乙，他们俩想要通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过来也是一样。这样甲与乙之间的一次消息要通过两段信道，通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。WebRTC应运而生。

WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输，支持网页浏览器进行实时语音对话或视频对话。WebRTC包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，创建点对点（Peer-to-Peer）的数据分享和电话会议成为可能。它是谷歌2010年5月以6820万美元收购拥有编解码、回声消除等技术的Global IP Solutions公司而获得的一项技术。该项目是由GIPS项目和libjingle项目融合而成。其中GIPS部分主要提供媒体的处理的功能。libjingle项目部分主要提供P2P传输部分的功能。2011年5月开放了工程的源代码，与相关机构 IETF 和 W3C 制定行业标准，组成了现有的 WebRTC 项目，在行业内得到了广泛的支持和应用，成为下一代视频通话的标准。

WebRTC是一个开源项目，旨在使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间（peer-to-peer）的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频。

WebRTC并不是单一的协议，包含了媒体、加密、传输层等在内的多个协议标准以及一套基于 JavaScript 的 API。通过简单易用的 JavaScript API ，在不安装任何插件的情况下，让浏览器拥有了 P2P音视频和数据分享的能力。同时WebRTC 并不是一个孤立的协议，它拥有灵活的信令，可以便捷的对接现有的SIP 和电话网络的系统。

关键要认识到的是，点对点并不意味着不涉及服务器，这只是意味着正常的数据没有经过它们。至少，两台客户机仍然需要一台服务器来交换一些基本信息（我在网络上的哪些位置，我支持哪些编解码器），以便他们可以建立对等的连接。用于建立对等连接的信息被称为信令，而服务器被称为信令服务器。

WebRTC没有规定您使用什么信令服务器或什么协议。 Websockets是最常见的，但也可以使用长轮询甚至邮件协议。

完整WebRTC技术及应用概要

2019-12-06 15:31:18

Web Real-Time Communication（WebRTC）是最近几年非常热门的一项新的基于浏览器的技术，很多VoIP的厂家和应用集成厂家的解决方案中都逐渐支持了WebRTC技术。WebRTC技术通过对浏览器或者移动终端应用，结合API接口，实现了视频，语音功能。当然，WebRTC受到如此多重视，当然也离不开主要的推动者Google，微软，Mozilla等大牌厂家的鼎力支持，以及几个着名的协议组织，例如，W3C和IETF的协助。

　　虽然，网络上有很多关于WebRTC的文章，这些文章通过不同的角度对WebRTC做了非常详细的介绍，WebRTC官方网站也发布了有很多的文档。但是，很多网上的文章比较零散，讨论的角度都不一样。另外，很多权威的文档和纸质书基本上都是以英文出版，一些读者的英文阅读能力没有那么高的话，可能影响对技术的消化吸收。为了给中国读者提供一个比较全面的完整的关于WebRTC的技术以及应用概要，笔者希望通过一个完整的篇幅，对WebRTC技术做一个比较系统，完整地描述介绍，其内容包括从WebRTC背景知识，媒体流，相关的协议栈，NAT处理，安全以及隐身设置，WebRTC当前的问题以及未来的提升，WebRTC用户使用场景，和开源WebRTC媒体服务器以及视频会议，WebRTC测试工具等知识点，让普通读者能够通过一篇文章就对WebRTC技术有一个非常清晰的思路，为进一步学习WebRTC技术做一个有效铺垫，读者可以快速进入到真正的WebRTC技术应用开发中。在十一个章节中，笔者会根据WebRTC技术的架构以及相关的应用做一个完整的介绍。

WebRTCTURN协议初识及turnserver实践

2019-12-06 15:34:18

本文主要为初步接触WebRTC的开发者介绍WebRTC turnserver的原理机制，以及Agora在此方面的部分经验。如遇到疑问，可以点击这里，与作者直接交流。

目录

WebRTC（二）

2019-12-06 15:36:16

端对端 1V1 传输基本流程

媒体能力协商过程

WebRTC 端对端连接：

RTCPeerConnection：

基本格式

1	pc = new RTCPeerConnection([configuration]);

RTCPeerConnection 方法分类：

媒体协商
Stream/Track
传输相关方法
统计相关方法

WebRTC（一）

2019-12-06 15:38:13

WebRTC API

Node.js v10.15.3 文档

廖雪峰 - nodejs

Webrtc 笔记 - 获取源码

WebRTC 音频引擎实现分析

实时通信 RTC 技术栈之：视频编解码

开源实时音视频技术 WebRTC 中 RTP/RTCP 数据传输协议的应用

WebRTC 项目源码在国内的镜像

WebRTC（三）

2019-12-06 15:38:48

简单的 https server 服务搭建

# 二进制安装
$ apt/brew/yum install nodejs
$ apt/brew/yum install npm
$ apt-cache search xxx 		# 查看源上相关软件版本信息

# 源码安装
# 下载 Nodejs 源码 http://nodejs.cn/download/
$ wget -c https://npm.taobao.org/mirrors/node/v10.16.0/node-v10.16.0.tar.gz
# 生成 Makefile
$ ./configure --prefix=/usr/local/nodejs
$ make -j 4 && sudo make install

WebRTC 视频统计信息之延迟抖动与丢包

2019-12-06 15:40:44

最近在内网情况下测试视频会议，视频下行延时很大，很多时候超过100ms。另外，视频的上下行抖动总是稳定在30~40ms这个区间。这些统计在内网环境下是不正常的，于是决定看看是哪里导致这些问题的。

在解决这些问题的过程中，也对 WebRTC 内部视频统计数据做了一次梳理。

阅读这篇文章之前，最好对 RTP、RTCP、SR、RR 有一些了解。这里就不过多展开，可以参考以下文章：

RTP Data Transfer Protocol

RTP Control Protocol – RTC

RTP/RTSP/RTCP 有什么区别

实时音视频互动系列

2019-12-06 15:41:31

又拍云 UTUN 网络详解

如何定义实时音视频互动, 延迟 400ms 内才能无异步感

实时音视频互动如果存在 1 秒左右的延时会给交流者带来异步感，必须将视频播放延迟限制在 400ms 以内，才能给用户较好的交互体验。

当延迟控制在 400ms 以内时，两个人音视频互动是实时的，不会有异步感存在，即实时音视频互动。

webrtc - 专题 - 01-WebRTC 框架介绍

2019-12-06 15:42:23

什么是 WebRTC？

众所周知，浏览器本身不支持相互之间直接建立信道进行通信，都是通过服务器进行中转。比如现在有两个客户端，甲和乙，他们俩想要通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过来也是一样。这样甲与乙之间的一次消息要通过两段信道，通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。WebRTC 应运而生。

WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输，支持网页浏览器进行实时语音对话或视频对话。WebRTC 包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，创建点对点（Peer-to-Peer）的数据分享和电话会议成为可能。它是谷歌 2010 年 5 月以 6820 万美元收购拥有编解码、回声消除等技术的 Global IP Solutions 公司而获得的一项技术。该项目是由 GIPS 项目和 libjingle 项目融合而成。其中 GIPS 部分主要提供媒体的处理的功能。libjingle 项目部分主要提供 P2P 传输部分的功能。2011 年 5 月开放了工程的源代码，与相关机构 IETF 和 W3C 制定行业标准，组成了现有的 WebRTC 项目，在行业内得到了广泛的支持和应用，成为下一代视频通话的标准。

WebRTC 流媒体服务器（一）

2019-12-06 15:44:33

导学

WebRTC 流媒体服务器（二）

2019-12-06 15:45:27

WebRTC 流媒体服务器

TCP/IP 详解

IP 协议详解

WebRTC 流媒体服务器（三）

2019-12-06 15:46:17

各流媒体服务器的比较

多人互动架构方案

多人音视频架构：

Mesh 方案
MCU（Multipoint Conferencing Unit）方案
SFU（Selective Forwarding Unit）方案

Mesh 架构模型详解

restund

2019-12-08 22:26:10

Restund is a modular and flexible STUN and TURN Server, with IPv4 and IPv6 support.

Features

Authentication module
Binding module
MySQL module
Statistics module
Status module
Syslog module
TURN module

STUN和TURN协议解析

2019-12-09 01:05:20

在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。

STUN，首先在RFC3489中定义，作为一个完整的NAT穿透解决方案，英文全称是Simple Traversal of UDP Through NATs，即简单的用UDP穿透NAT。

在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具，而不是一个完整的解决方案，英文全称是Session Traversal Utilities for NAT，即NAT会话穿透效用。RFC5389与RFC3489除了名称变化外，最大的区别是支持TCP穿透。

TURN，首先在RFC5766中定义，英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中继穿透NAT:STUN的扩展。简单的说，TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。

TURN协议(RFC5766详解)

2019-12-09 01:38:23

摘要

如果一台主机处于NAT后面，那么在一定条件下两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。
这个规范定义了一个名为TURN(使用中继穿越NAT)的协议，它允许一台主机使用中继服务与对端进行报文传输。TURN不同于其它中继协议在于它
允许客户机使用一个中继地址与多个对端同时进行通讯。

TURN协议也是ICE(交互式连接建立)协议的组成部分，也可以单独使用。

【入门】WebRTC知识点概览 | 内有技术干货免费下载

2019-12-13 01:03:01

WebRTC 即Web Real-Time

Communication（网页实时通信）的缩写，是一个支持网页浏览器之间进行实时数据传输（包括音频、视频、数据流）的技术。经过多年的发展与改进，日臻成熟，作为浏览器网页端的通信技术，WebRTC与H5巧妙结合，使得网页端的音视频通信变的简单易行。

WebRTC有哪些优点

免费：WebRTC本身是开源的，使用WebRTC本身是免费的。此外WebRTC是可以不借助媒体服务器实现简单的点对点音视频通信，减少额外花费。

无插件：不需要安装任何软件，大家只要打开浏览器，输入一个url，即可实现多人音视频通话。

跨平台：由于是基于浏览器进行音视频通话，各个平台只要有浏览器即可。

控制灵活：WebRTC没有指定具体的信令协议，具体的信令协议留给应用程序实现，这就方便了开发者根据自己的需求方便灵活的实现各种音视频业务场景。

接合HTML5：HTML5自身的能力能够为WebRTC提供灵活快捷的音视频数据的二次处理，可以实现丰富的业务功能。

易入门：WebRTC是'JavaScript'引擎库，允许web开发者只使用几个简单的api就能够基于浏览器轻易快捷开发出丰富的实时多媒体应用，无需关注多媒体的数字信号处理过程，只需要编写简单的JavaScript即可，大大的降低了音视频开发的门槛。

WebRtc 之 STUN和TURN

2019-12-17 08:54:30

在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。

STUN，首先在RFC3489中定义，作为一个完整的NAT穿透解决方案，英文全称是Simple Traversal of UDP Through NATs，即简单的用UDP穿透NAT。

StunSrvList

2019-12-17 11:21:20

static struct StunSrv StunSrvList[263] = {
{"23.21.150.121", 3478},
{"iphone-stun.strato-iphone.de", 3478},
{"numb.viagenie.ca", 3478},
{"s1.taraba.net", 3478},
{"s2.taraba.net", 3478},
{"stun.12connect.com", 3478},

WebRTC服务器——Licode 环境搭建

2019-12-17 12:03:00

目录

WebRTC getStats详解－从标准、调用到实现

2019-12-18 08:06:49

getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />

发送端采集统计：对应于媒体数据的产生，包括帧率，帧大小，媒体数据源的时钟频率，编解码器名称，等等。<br />
发送端RTP统计：对应于媒体数据的发送，包括发送数据包数，发送字节数，往返时间RTT，等等。<br />
接收端RTP统计：对应于媒体数据的接收，包括接收数据包数，接收字节数，丢弃数据包数，丢失数据包数，网络抖动jitter，等等。<br />
接收端渲染统计：对应于媒体数据的渲染，包括丢弃帧数，丢失帧数，渲染帧数，渲染延迟，等等。<br />

另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />

往返时间RTT：表示数据在网络上传输所用的时间，一般通过RTCP 的SR/RR数据包中的相关域进行计算。该度量直接反映网络状况的好坏。<br />
丢包率影响接收端音视频质量，在严重的情况下可能导致声音跳变或者视频马赛克，从侧面反映网络状况的好坏。<br />
音视频数据到达接收端之后，要经历收包、解码、渲染等过程，该过程会带来延迟。接收端延迟是数据从采集到渲染单向延迟的重要组成部分。<br />

通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />

WebRTC 及点对点网络通信机制

2019-12-19 10:10:57

何为 WebRTC ？首先，字面上已经给出了关于这一技术的大量信息，RTC 即为实时通信技术。

WebRTC 填补了网页开发平台中的一个重要空白。在以往，只有诸如桌面聊天程序这样的 P2P 技术才能够实现实时通讯而网页不行。但是 WebRTC 的出现改变了这一状况。

WebRTC 本质上允许网页程序创建点对点通信，我们将会在随后的章节中进行介绍。我们将讨论如下主题，以便向开发者全面介绍 WebRTC 的内部构造：

点对点通信
防火墙和 NAT 穿透
信令，会话及协议
WebRTC 接口

点对点通信

每个用户的网页浏览器必须按照如下步骤以实现通过网页浏览器进行的点对点通信：

同意开始进行通信
知道如何定位另一个点
绕过安全和防火墙限制
实时传输所有多媒体通信信息

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

2019-12-19 10:11:41

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

WebRTC兴起提供的方案以及遇到的问题

WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.

RTMP系统推流播放延迟分析

一个经过优化的RTMP-CDN网络端到端的延迟大概在2-3秒, 延迟大一些要在5秒甚至10秒以上. 从推流到播放, 会引入延迟的环节有编码延迟, 网络丢包和网络抖动, 视频的分段传输, 多媒体节点的relay, 播放器的缓存等等. 实际上除了网络丢包和网络抖动不太可控之外, 其他的各各环节都有一定的优化方案, 比如使用x264的-preset ultrafast和zerolatency, 可以降低编码的延迟,
分段传输部分可以把GOP减少到1秒之内, 在播放器端可以适当减小buffer, 并设置一定的追帧策略, 防止过大的buffer引起的时延.

低成本的低延迟的实现

webrtc P2P之turn协议介绍

2019-12-20 06:21:39

TURN简介

TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果终端在NAT之后，那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一个中继，对来往的数据进行转发。这个转发的协议就被定义为TURN。TURN和其他中继协议的不同之处在于，它允许客户端使用同一个中继地址（relay address）与多个不同的peer进行通信。

使用TURN协议的客户端必须能够通过中继地址和对等端进行通讯，并且能够得知每个peer的的IP地址和端口（确切地说，应该是peer的服务器反射地址）。而这些行为如何完成，是不在TURN协议范围之内的。其中一个可用的方式是客户端通过email来告知对等端信息，另一种方式是客户端使用一些指定的协议，如“introduction” 或 “rendezvous”，详见RFC5128

如果TURN使用于ICE协议中，relay地址会作为一个候选，由ICE在多个候选中进行评估，选取最合适的通讯地址。一般来说中继的优先级都是最低的。TURN协议被设计为ICE协议(Interactive Connectivity Establishment)的一部分，而且也强烈建议用户在他们的程序里使用ICE，但是也可以独立于ICE的运行。值得一提的是，TURN协议本身是STUN的一个拓展，因此绝大部分TURN报文都是STUN类型的，作为STUN的一个拓展，TURN增加了新的方法（method）和属性（attribute）。

2019-12-25 06:12:08

最近实验了下如何让WebRTC支持H264编码，记录下，供有需要的人参考。

说明一下，我是在 Ubuntu Server 14.04 下编译的 WebRTC ，使用 native（C++） api 开发 WebRTC 应用。所以我的调整都是基于 native 代码。

最终的效果是浏览器可以用H264发送视频，也可以接收H264视频。

注意，WebRTC 使用 OpenH264 来做 encoder （见 h264_encoder_impl.cc），使用 ffmpeg 来做 decoder （见 h264_decoder_impl.cc ）。

WebRTC实时通信协议详解

2019-12-28 11:20:42

这一篇我们来讲一下WebRTC协议，之前我总结过一篇各种网络协议的总结，没看过的朋友建议先看下这篇web知识梳理，有助于加深这篇关于WebRTC的理解。

基本概念

WebRTC是由Google主导的，由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端之间）的音频、视频及数据共享。WebRTC不需要安装任何插件，通过简单的JavaScript API就可以使得实时通信变成一种标准功能。

现在各大浏览器以及终端已经逐渐加大对WebRTC技术的支持。下图是webrtc官网给出的现在已经提供支持了的浏览器和平台。

WebRTC TURN协议初识及turnserver实践

2019-12-28 11:33:05

WebRTC协议栈

WebRTC源码架构浅析

2019-12-28 12:38:05

Google 在2010年花了6千8百万美元收购了大名鼎鼎的 Global IP Sound/Solutions (GIPS) 公司, 得到了它的 VoIP 相关技术的专利和软件. 第二年, Google就把这些软件开源了, 不过, 不是作为独立的软件, 而且也和原来的软件功能大不一样, 而是作为所谓的 WebRTC 方案的一部分.

GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web 相关技术(如 JavaScript, HTML5). 所以, WebRTC 的源码结构非常庞大, 单单是从 trunk 中获取的代码和数据就达到1.2G还多.

不过, 如果明白了 WebRTC 的架构, 就可以从这份开源代码中摘出我们想要的部分. WebRTC 包含下面几个部分:

WebRTC SDP协议

2020-06-20 15:47:30

SDP协议用来在SIP终端之间交换媒体信息,WebRTC标准中同样选用了
SDP协议来交换媒体信息.

WebRTC56版本SDP详细解析

2020-06-20 15:47:58

v=0

//sdp版本号，一直为0,rfc4566规定

o=- 7017624586836067756 2 IN IP4 127.0.0.1

// RFC 4566 o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

//username如何没有使用-代替，7017624586836067756是整个会话的编号，2代表会话版本，如果在会话

//过程中有改变编码之类的操作，重新生成sdp时,sess-id不变，sess-version加1

s=-

//会话名，没有的话使用-代替

WebRTC学习进阶之路

2020-06-20 15:50:33

目录：
一、 WebRTC学习进阶之路 --- 概述、原理、源码目录结构与整体架构介绍
二、 WebRTC学习进阶之路 --- 网络编程基础、TCP/IP详解
三、 WebRTC学习进阶之路 --- WebRTC网络知识详解(一)(P2P/NAT/STUN/TURN/ICE)
四、 WebRTC学习进阶之路 --- WebRTC网络知识详解(二)(加解密/SSL/OpenSSL/TLS/DTLS/SRTP)
五、 WebRTC学习进阶之路 --- WebRTC网络知识详解(三)(最全流媒体协议(RTP/RTCP/RTSP/RTMP/MMS/HLS/HTTP/ HTTP-FLV(HDL)/SDP)
六、 WebRTC学习进阶之路 --- Web服务器原理、服务器基础编程知识
七、 WebRTC学习进阶之路 --- WebRTC核心之SDP详解、媒体协商
八、 WebRTC学习进阶之路 --- 信令服务器
九、 WebRTC学习进阶之路 --- 设备管理、音视频数据采集
十、 WebRTC学习进阶之路 --- 非音视频数据传输
十一、WebRTC学习进阶之路 --- 异步I/O时间处理、epoll
十二、WebRTC学习进阶之路 --- 下载源码及各操作系统的源码编译详细步骤
十三、WebRTC学习进阶之路 --- 分析源码音视频互动peerconnection-client+server实例
十四、WebRTC学习进阶之路 --- 源码分析之WebRTC中的线程详解-ThreadManager&Thread
十五、WebRTC学习进阶之路 --- 源码分析之WebRTC中的线程详解-MessageQueueManager&MessageQueue&Message&MessageHandler
十六、WebRTC学习进阶之路 --- 源码分析之最核心的内容PeerConnection
十七、WebRTC学习进阶之路 --- 源码分析之WebRTC的数据流水线详解&模块机制核心ProcessThread与ProcessThreadImpl
十八、WebRTC学习进阶之路 --- 源码分析之视频采集和视频数据的流水线分析

RTP协议全解析（H264码流和PS流）

2020-06-20 16:02:07

写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，

其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。

互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。

WebRTC学习进阶之路 --- 七、WebRTC核心之SDP详解、媒体协商

2020-06-20 16:03:32

一、什么是SDP
SDP(Session Description Protocol)描述会话协议，它只是一种信息格式的描述标准，本身不属于传输协议，但是可以被其他传输协议用来交换必要的信息，用于两个会话实体之间的媒体协商。
SDP（Session Description Protocol）是一个用来描述多媒体会话的应用层控制协议，为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述；它是一个基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围；SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。
会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。SDP 连接好会话后，传送足够的信息给会话参与者。SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web）进行发送。SDP 文本信息包括：会话名称和意图；会话持续时间；构成会话的媒体；有关接收媒体的信息（地址等）。

聊聊WebRTC网关服务器1：如何选择服务端端口方案？

2020-06-22 08:21:50

《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。

《聊聊WebRTC网关服务器》第一篇文章将和大家分享如何选择服务端的端口方案。

标准WebRTC连接建立流程

在讨论如何选择服务器端的端口方案前，我们先来看看标准WebRTC的连接建立流程，这为我们理解这篇文章后续内容提供最基础的知识。

从入门到进阶｜如何基于WebRTC搭建一个视频会议

2020-06-22 08:25:31

导读：疫情期间，视频会议等远程办公产品备受青睐，众多互联网玩家切入视频会议市场，加剧市场竞争。但是，产品虽多，能够带来稳定可靠体验的产品却凤毛麟角，它的难点在哪里？视频会议的门槛到底有多高，又能够做到怎样的极致体验？网易智慧企业流媒体服务器天团将会从0到1，和大家分享如何基于WebRTC来搭建一个视频会议。

入门篇

先请出我们今天的主角 - WebRTC，它是由谷歌推广的实时音视频技术栈，是音视频领域搜索热度最高的技术。它有多重身份，既是W3C的标准，也是一个开源项目，还有一个对应的IETF工作组(RTCWEB)。在WebRTC出现之前，音视频通信是高不可攀的领域，需要大量的专业积累才能入门，而现在，越来越多的开发者通过WebRTC来深入了解RTC技术。

WebRTC技术的本质是构建点对点的实时通信，目前主流的浏览器，包括Chrome, Firefox, Edge等，天然就支持WebRTC协议。对入门开发者来说，选用这几款浏览器，连开发客户端的时间都省了。最简单的Web视频会议，只需要架设一个Web服务器，服务器兼具信令交换的能力(信令服务也可以独立部署)，两个浏览器通过Web Server交换会话信息，就能建立P2P通道来传输媒体流，进行1v1的视频会议。如下图所示。

ICE概要

2020-06-22 08:43:21

ICE概要

一、ICE产生的背景

基于信令协议的多媒体传输是一个两段式传输。首先，通过信令协议（如SIP）建立一个会话连接，通过该连接，会话双方（Agent）通过SIP交互所承载的SDP消息彼此学习传输媒体时所必须的信息，针对媒体传输机制达成共识。然后，通常采用RTP协议进行媒体传输。

基于传输效率的考虑，通常在完成第一阶段的交互之后，通信双方另外建立一条直接的连接传输媒体。这样就会减少传输时延、降低丢包率并减少开销。这样，用于SIP传输的链路就不再用于传输媒体。现在，问题出现了，由于不采用原来的链路，当传输双方中任一方位于NAT之后，新的传输链接必须考虑NAT穿越问题。

通常有四种形式的NAT，对于每一中NAT方式，都有相应的解决方案。然而，每一种NAT穿越解决方案都局限于穿越对应得NAT方式，对于复杂的网络环境来说，将会出现无法进行媒体传输的情况，同时这些方案给整个系统带来了在不同程度上的脆弱性和复杂性。

在这种背景下，Interactive Connectivity Establishment（交互式连通建立方式）也即ICE解决方案应运而生。ICE方式能够在不增加整个系统的复杂性和脆弱性的情况下，实现对各种形式的NAT进行穿越，使得媒体流在通信双方顺利传输。

聊聊WebRTC网关服务器2：如何选择PeerConnection方案？

2020-06-22 08:49:13

《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。

《聊聊WebRTC网关服务器》第二篇文章将和大家分享如何选择PeerConnection方案。

聊聊WebRTC网关服务器3：如何优化Server的线程方案？

2020-06-22 08:59:51

《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。

在分享完端口方案与PeerConnection的方案后，本篇文章我们将讲解如何优化WebRTC网关服务器的线程方案。这个也是网关服务器架构设计的核心部分。

我们做WebRTC网关服务器的时候，不仅要考虑功能可用，还要考虑并发性能。有三种方案可以选择：

第一种方案是一种多线程的方案，就是为每一个client或者是每一个PeerConnection建立一个独立的线程去做收发。这个方案的劣势很明显，它跨线程的流程就会很多，效率也不高。但是，这确实是某些开源服务器的方案；
第二种方案是单线程的方案，所有用户的I/O以及业务操作都在服务端的一个线程里做完，在用户量不大或者服务端硬件资源可以隔离的情况下，它是一个比较好的方案。但是这种方案也有劣势，当我们使用物理机作为服务器时，单线程是没有办法利用多核优势的；如果同时启动多个进程，则需要多个外网端口和域名，维护的成本也会比较高；
第三种方案是多线程优化方案，也是网关一期实现的方案，I/O单独在一个线程来做，同一个通话的用户在同一个业务逻辑线程做业务操作，同时创建一组业务逻辑线程为所有用户服务。

我们看一下这个方案具体是怎么做的？

聊聊WebRTC网关服务器4：QoS方案分析

2020-06-22 09:01:43

《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。

大家都知道音视频应用中的QoS策略是非常重要的部分，这里我简单为大家介绍一下WebRTC网关服务端的QoS内容，因为篇幅问题，具体的算法细节这里就不作阐述了。

本篇文章分享的内容会涉及：NACK、PLI、RTT、GCC算法、REMB与Transport-CC，ULP-FEC。

WebRTC的QoS是一个非常大的门类，也是非常重要的方向，它里面涵盖的内容非常多。有大量的QoS策略是在客户端上实现的。而对于Web来说，那些客户端侧的策略你是没办法修改的，只能通过SDP里面的配置项，来选择需要开启的策略。

即构自研WebRTC网关服务器架构实践

2020-06-22 09:06:03

Zego-Gateway架构的改进

在加入WebRTC网关之前，即构自研系统架构如下图所示，主要分成两部分，左边是低延时用户，而右边是围观用户。低延时用户主要是通过ZEGO的实时传输网络进行推拉流。

WebRTC网关服务器搭建：开源技术 vs 自行研发

2020-06-22 09:12:00

大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：

● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

在WebRTC 1.0标准还没有定稿之前，这个标准只具备雏形，在很多方面都有缺陷。而随着1.0标准的定稿，WebRTC逐渐完善，到现在已经可以在网页端使用，换句话说，已经有基于WebRTC的实际应用。下面主要结合不同的应用场景来说明为什么需要WebRTC网关。

webrtc sfu实现原理

2020-06-22 14:07:19

High-performance WebRTC SFU
基于WebRTC的SFU多人音视频通话（服务端+客户端）
--------------------------------------------------------------------------------
SFU(Selective Forwarding Unit)，如果不太了解自行谷歌。
SFU服务器起到了router的作用，已占用较小的cpu和内存实现更为灵活的多方通话，这个特
性有别于MCU。
本系统包含基于WebRTC开发的SFU服务器，以及windows端基于webrtc实现的客户端；

使用方法
--------------------------------------------------------------------------------
1、启动SFU服务器(Server.exe)，默认端口是6666。不建议修改端口，客户端不支持设置端口。
记住SFU服务器的IP地址，如：192.168.1.101。
2、分别在不同的机器上启动客户端Client.exe。然后点击加入频道，输入服务器IP地址，以及
房间号（房间号可以自己随意填写），房间号相同的人会进入相同的房间；同理，房间号不
同的人会进入不同的房间。

特性
--------------------------------------------------------------------------------
1、多个会议室、多人参与。
2、用到的协议ICE / DTLS / RTP / RTCP等协议。
3、支持IPv6。
4、高效率 (使用c++编码，考虑到内存和性能)。
5、支持录制，或者加载媒体文件分享给伙伴（未完成）

WebRTC 开发实践：如何实现 SFU 服务器

2020-06-22 14:08:08

1 什么是 SFU ？

首先，我们再看一次 SFU 服务器的定义，什么是 SFU ？

SFU 的全称是：Selective Forwarding Unit，是一种路由和转发 WebRTC 客户端音视频数据流的服务端程序。

WebRTC网关服务器单端口方案实现

2020-06-22 14:50:21

标准WebRTC连接建立流程

这里描述的是Trickle ICE过程，并且省略了通话发起与接受的信令部分。流程如下：

1） WebRTC A通过Signal Server转发SDP OFFER到WebRTC B。WebRTC B做完本地处理以后，通过 Signal Server转发SDP ANSWER到A。

2）A、B同时向STUN Server发送Binding request请求自身的外网地址，并从STUN Server回包的MAPPED-ADDRESS中得到各自的外网地址；

3）A、B收集完内外网ICE Candidate，并通过Signal Server发送给对方；

4）双方开始做NAT穿越，互相给对方的ICE Candidate发送STUN Binding Request；

5）NAT穿越成功，A、B之间的P2P连接建立，进入媒体互通阶段。在这个过程中，我们看到了有三个核心的部分，SDP协商、ICE Candidate交换、Stun Binding Req/Res的连通性检查。

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

2020-06-23 08:42:46

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

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

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

这些策略都在不断的在消减端口的使用, 但即使上面的这些策略全部开启, 单个用户还是要占用最少一个端口, 如果一个WebRTC服务器要服务1000个用户, 就要开启1000个端口.

webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU

2020-06-23 09:25:40

问题：为什么要搞这么多架构？

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

短期爆发音视频需求背后的技术与发展趋势解读

2020-06-23 10:05:18

特殊时期，音视频在短期内成为了很多人的“刚需”：在线学习、远程工作、联系亲友等众多场景下都离不开音视频技术。那么，音视频究竟是短期刚需还是未来趋势呢？3月5日采访间，为本次活动压轴专场线上公开直播，邀请到腾讯云视频通信业务总经理李郁韬、学而思网校架构师&腾讯云最具价值专家（TVP）刘连响作为嘉宾，LiveVideoStack联合创始人&主编包研作为主持人，深度剖析音视频技术发展。

文 / 李郁韬刘连响包研

整理 / LiveVideoStack

包研：欢迎大家来到「云加社区沙龙online」采访间，我是LiveVideoStack主编包研，感谢云加社区的邀请，让我作为今天活动的主持人与大家互动。同时，今天我们也有幸邀请到了两位重磅嘉宾，分别是腾讯云视频通信业务总经理李郁韬和学而思网校架构师刘连响。

下面请两位先向观众做一个简单的自我介绍。

李郁韬：大家好，我是李郁韬，目前是腾讯云视频通信业务的负责人，很高兴能在云加社区与大家见面，这也是我人生第一次做直播，有些紧张。

刘连响：大家好，我是学而思网校架构师刘连响，目前主要负责RTC和直播相关的业务，最近几年的关注方向也主要集中在这些方面，包括推动WebRTC的大规模应用以及直播应用的探索。

包研：由于业务指数级暴增和大量的新业务对接，相信过去几周大家过的并不轻松，能否和大家分享下这段经历？

刘连响：我这边从春节到现在应该可以说是各种赶节奏，需要我们对多个项目进行同步支持，功能或者模块的开发时间被压缩的非常短，基本一到两天就要求交付。又因为是远程办公，所以处于全天工作的状态。印象比较深刻的是做小程序直播的时候，我们在晚上五六点钟立项，之后找到腾讯伙伴做小程序直播权限插件的升级、CDN的配置等工作，最后在第二天上午完成了上线，整个项目从立项到上线只花了十几个小时。

可能对于大多数国人来说，这个春节过得并不轻松，可以说是非常难忘的一个春节，李郁韬那边的情况想必也是一样。

webrtc 资源收集

2020-06-23 13:28:10

webrtc 资源收集

WebRTC搭建前端视频聊天室——数据通道篇

2020-06-23 13:29:17

在两个浏览器中，为聊天、游戏、或是文件传输等需求发送信息是十分复杂的。通常情况下，我们需要建立一台服务器来转发数据，当然规模比较大的情况下，会扩展成多个数据中心。这种情况下很容易出现很高的延迟，同时难以保证数据的私密性。

这些问题可以通过WebRTC提供的RTCDataChannel API来解决，他能直接在点对点之间传输数据。这篇文章将介绍如何创建并使用数据通道，并提供了一些网络上常见的用例

为了充分理解这篇文章，你可能需要去了解一些RTCPeerConnection API的相关知识，以及STUN，TURN、信道如何工作。强烈推荐Getting Started With WebRTC这篇文章

WebRTC搭建前端视频聊天室——信令篇

2020-06-23 13:31:44

这篇文章讲述了WebRTC中所涉及的信令交换以及聊天室中的信令交换，主要内容来自WebRTC in the real world: STUN, TURN and signaling，我在这里提取出的一些信息，并添加了自己在开发时的一些想法。

WebRTC的服务器

WebRTC提供了浏览器到浏览器（点对点）之间的通信，但并不意味着WebRTC不需要服务器。暂且不说基于服务器的一些扩展业务，WebRTC至少有两件事必须要用到服务器：
1. 浏览器之间交换建立通信的元数据（信令）必须通过服务器
2. 为了穿越NAT和防火墙

为什么需要信令？

搭建WebRtc环境

2020-06-23 13:34:14

这次的需求，准备做的是一个类似与QQ视频一样的点对点视频聊天。这几天了解了一些知识后，决定使用HTML5新支持的WebRtc来作为视频通讯。客户端使用支持HTML5浏览器即可。服务器段需要提供两个主要的服务功能，一个是信令服务器(Signaling Server)，一个是NAT穿透服务器(ICE Server)。简单的框架图如下:

WebRTC TURN协议初识及turnserver实践

2020-06-23 13:42:30

图一 WebRTC stack

TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如图一所示，TURN协议是建立在UDP协议之上的一个应用层协议。如果一台主机处于NAT后面，那么在一定条件下（NAT穿透失败）两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。TURN协议允许一台主机使用中继服务与对端进行报文传输。TURN协议也是ICE（交互式连接建立）协议的组成部分，也可以单独使用。如果TURN使用于ICE协议中，relay地址会作为一个候选，由ICE在多个候选中进行评估，选取最合适的通讯地址。一般来说中继的优先级都是最低的。

TURN和其他中继协议的不同之处在于，它允许客户端使用同一个中继地址（relay address）与多个不同的peer进行通信。如图二所示。

实际中的WebRTC：STUN，TURN以及信令（五）

2020-06-23 13:45:50

NAT给设备提供了一个IP地址以使用专用局域网，但是这个地址不能在外部使用。由于没有公用地址，WebRTC对等端就无法进行通信。而WebRTC使用 STUN来解决这个问题。

STUN服务器位于公共网络上，并且有一个简单的任务：检查传入请求的IP地址（来自运行在NAT后面的应用程序），并将该地址作为响应发送回去。换句话说，应用程序使用 STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址，然后通过信令机制将其传递给另一个对等端以建立直接链接。（实际上不同NAT工作方式都有所不同，可能有多个NAT层，但是原理是一样的）。

因为 STUN服务器不需要做太多的工作或者记特别多的东西，所以相对低规格的 STUN服务器就可以处理大量的请求。

根据webrtcstats.com的统计（2013年），大多数WebRTC通话都成功地使用 STUN进行连接，有86%。尽管对于防火墙之后的对等端之间的呼叫以及复杂的NAT配置，成功通话量会更少一些。

webrtc流媒体转发服务器

2020-06-23 13:51:52

webrtc流媒体转发服务器
定义
难点
建立连接
如何转发媒体流
如何高效转发媒体流
转发后如何保证视频质量
定义
由于webrtc是基于P2P技术的一个协议栈，大多数情况下能满足1-5人的同时并发音视频通讯。但是对于多于5人乃至10、20人的并发，使用P2P技术会造成终端设备无法承受负荷。因此需要将P2P模式改造成能适应大量并发模式，即媒体转发服务（MCU）。

WebRTC 开发实践：如何实现 SFU 服务器

2020-06-23 13:55:38

WebRTC H5实现服务器转发的视频聊天

2020-06-23 14:00:22

此处使用到的WebRTC皆为H5的API，实际上调用的是封装在浏览器的WebRTC的库，用于获取实时视频数据，传输数据则是使用WebSocket实现。
其中的实例语法只用到原生JS，版本为ES6，可能需要较高版本的浏览器支持（IE一般不支持）。
1.获取音视频数据
方法：navigator.mediaDevices.getUserMedia

WebRTC H5页面实现服务器转发的视频聊天（二） -- 迁移Spring Boot

2020-06-23 14:02:23

最近一段时间，工作内容也是在迁移项目，加上之前有读者要源码，所以打算重构下。

这个项目是之前因为工作中的调研（项目最后因为难度太大放弃了 == ），需要了解关于 WebRTC H5 + Java 如何实现实现网页端的视频聊天，而编写的sample。

原理就是 WebRTC + WebSocket。使用 WebRTC 采集视频看，通过 WebSocket 截取页面的视频流转发到后台，再经过后台分发到其他的客户端网页。

项目本身使用 Spring，打成 war，直接部署到 Tomcat 的方式运行。而写这个sample的时候，MyEcplise 还是我的最爱。

现在我已经习惯了 IDEA ，所以打算改成 Spring Boot，然后用 IDEA 跑起来。

项目实现基本不变，代码实现可考古 WebRTC H5实现服务器转发的视频聊天

ZEGO的webrtc协议分析

2020-06-29 06:25:25

这里编辑文章摘要...

Sdp Plan A Plan B UnifiedPlan

2020-07-09 23:28:37

webrtc中多流的实现越来越简单，也越来越规范高效化，从planB-->到unifiedPlan，不过做的早的一些视频会议还是基于plan A做的，也是老版本的webrtc版本，planB兼容planA，不过后边的趋势一定是unifiedplan，这边刚好看到对这三个SDP多流标准的说明的博文，就记录下，转载过来了，感谢原博主。本文转自https://blog.csdn.net/gyj072001/article/details/80406106

exchange of multiple media sources (AKA MediaStreamTracks, or MSTs) between two WebRTC endpoints.
Unified Plan 和 Plan B 和 Plan A是SDP协商中，多路媒体流的协商方式。

Plan A

一个PeerConnection一路媒体流。

è¿éåå¾çæè¿°

WebRTC网关服务器单端口方案实现

2020-07-10 15:51:18

标准WebRTC连接建立流程

这里描述的是Trickle ICE过程，并且省略了通话发起与接受的信令部分。流程如下：

1） WebRTC A通过Signal Server转发SDP OFFER到WebRTC B。WebRTC B做完本地处理以后，通过 Signal Server转发SDP ANSWER到A。

2）A、B同时向STUN Server发送Binding request请求自身的外网地址，并从STUN Server回包的MAPPED-ADDRESS中得到各自的外网地址；

3）A、B收集完内外网ICE Candidate，并通过Signal Server发送给对方；

4）双方开始做NAT穿越，互相给对方的ICE Candidate发送STUN Binding Request；

5）NAT穿越成功，A、B之间的P2P连接建立，进入媒体互通阶段。在这个过程中，我们看到了有三个核心的部分，SDP协商、ICE Candidate交换、Stun Binding Req/Res的连通性检查。

WebRTC网关连接建立流程

kurento代码分析（二）rtp流的处理

2020-07-10 15:59:25

今天得闲，又翻了下kurento的代码，没忍住。学有所得，分享在这里。
kurento在处理rtp流时，需要创建一个rtpbin这样一个element。我上一篇，分析了kurento是怎么通过工厂模式，创建一个gstreamer中的element对象。
这种工厂模式，提供了很大的灵活性，有新的需求的时候，就可以继承父类，构造新的处理逻辑。例如关于webrtc的rtp流的处理，在C层，KmsWebrtcEndpoint继承了KmsBaseRtpEndpoint。

WebrRTC(4) 端对端连接

2020-07-11 13:40:55

WebRTC端对端连接
RTCPeerConnection
一个核心类，是上层的统一接口。
在底层有很多复杂逻辑，媒体协商、流轨道处理、数据接收发送、数据统计等等。

网页版WebRTC多人聊天Demo

2020-07-11 14:21:46

网页版WebRTC多人聊天Demo

本文基于Codelab中step7，在其基础上作简单修改，使其支持多人视频通讯，本文暂时只支持星状结构三人聊天，多人聊天可以在基础上扩展，原理相同。

一.源码分析

该工程包括三个文件：server.js，main.js，index.html。

1.server.js

WebRTC使用SDES代替DTLS协商

2020-07-11 21:33:57

WebRTC作为浏览器中的一个组件，在设计的时候考虑了大量了安全问题，比如要求getUserMedia在加密网页中才能打开摄像头，使用MDNS来防止IP地址的泄露，使用DTLS来加密datachannel数据，使用DTLS-SRTP来加密音视频数据等等，在带来更高的安全性的同时也带来更多的复杂性，更多的资源占用。尤其是对于开发者来说，DTLS-SRTP的引入带来很多问题，工程的复杂性，服务器资源的占用，以及音视频建立连接的延迟等，我们使用SDES来减少DTLS带来的影响，在保证兼容WebRTC协议的同时减少系统的复杂度，降低弱网下的首帧延迟。

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

2020-07-11 21:35:47

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

WebRTC兴起提供的方案以及遇到的问题

WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.

RTMP系统推流播放延迟分析

基于WebRTC构建超低延迟(500ms)的直播系统

2020-07-11 21:40:08

上周写了一篇文章基于RTMP和WebRTC 构建低延迟的直播系统(https://zhuanlan.zhihu.com/p/47302561), 只所以要基于RTMP, 还是考虑尽可能复用现有的技术和基础设施. 实际上国外已经有基于WebRTC的CDN系统, 比如 http://phenixrts.com/, https://www.millicast.com/. 比这更早的可以追溯到beam, 一个实时的游戏直播平台, 在2016年被微软收购后改名mixer(https://mixer.com). 目前国内低延迟直播的做法是在rtmp的基础调优, 比如使用可靠UDP方案替换RTMP的传输层, 目前使比较多的方案有KCP和QUIC. 但魔改RTMP的方案始终没有特别好的适配浏览器的方法. 相比有超过40亿设备支持的WebRTC来说, WebRTC的方案无疑更有想象空间.

但WebRTC天生为Peer-To-Peer而生, 并没有提供对大规模分发的支持. 为提升WebRTC分发能力, 于是有了SFU的方案, 但常见的SFU方案, 也只能让WebRTC具备几十路到几百路的分发能力. 试想在用WebRTC直播, 瞬间进入几百个观看端, 这几百观看端都在请求关键帧, 发送端的压力会非常大造成整个直播不可观看. 在这几百人中如果有几个人网络特别差, 也会造成整个直播质量的下降. 如果我们想提升WebRTC的分发能力, 我们应该切端观看端向发送端的反馈机制. 在牺牲一定视频质量的情况做到大规模的分发.

webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU

2020-07-11 21:45:20

问题：为什么要搞这么多架构？

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

点击看大图

WEBRTC浅析（二） ICE 机制简介及STUN通信流程

2020-07-11 22:27:36

WEBRTC ICE 简介
在这里，我会介绍一下WEBRTC 中， ICE 的机制。主要分为三个部分。

第一部分，为ICE的协议部分介绍。
第二部分，为STUN 的信令连接图。
第二部分，为WEBRTC中代码的实现流程。

WebRTC源码分析——呼叫建立过程之二(创建PeerConnectionFactory)

2020-07-12 06:58:40

目录
1. 引言
2 PeerConnectionFactory对象的创建
2.1 CreatePeerConnectionFactory方法解析
2.1.1 创建媒体引擎MediaEngine——CreateMediaEngine方法
2.1.2 创建实体类PeerConnectionFactory——CreateModularPeerConnectionFactory方法
1）PeerConnectionFactory的创建——构造
2）PeerConnectionFactory初始化——Initialize方法
3）PeerConnectionFactoryProxy代理的创建与返回——防止线程乱入
3 PeerConnectionFactory对象简析
3.1 PeerConnectionFactory拥有的资源——私有成员
3.1 PeerConnectionFactory提供的能力——公有方法

学习RFC3550：RTP/RTCP实时传输协议基础知识

2020-07-12 14:49:51

、前言

RF3550定义了实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对实时流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。

RTCP协议负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用，通过有效反馈使使流媒体传输效率最佳化。

IETF的RFC3550定义了RTP/RTCP协议的基本内容，包括报文格式、传输规则等。除此之外，IETF还定义一系列扩展协议，包括RTP扩展，RTCP报文类型扩展，等等。本文对这些协议进行初步归纳总结，在分析RFC3550的基础上，重点分析RTP系列协议，并以报文类型为主线分析RTCP系列协议。

开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用

2020-07-12 14:51:19

1、前言

RTP/RTCP协议是流媒体通信的基石。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在WebRTC项目中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模块的数据包后，进行解包操作，最后把负载发送到解码模块。因此，RTP/RTCP 模块在WebRTC通信中发挥非常重要的作用。

本文在深入研究WebRTC源代码的基础上，以Video数据的发送和接收为例，力求用简洁语言描述RTP/RTCP模块的实现细节，为进一步深入掌握WebRTC打下良好基础。

基于ZLMediaKit，实现一个接收多路rtp流，输出一路rtmp流的简单MCU

2020-07-14 09:24:05

做转码服务的原型时，看了看MCU的实现，考虑到如果不做转码，可以将多路rtp流直接合成为一路rtmp流输出，这样就相当于实现了多人连麦，并将多人连麦的视频转发直播了，所以做了这个简单的原型实现！

DEMO只实现了接收一路rtp流，输出一路rtmp流！

使用Janus作为对讲服务器的后台框架和业务流程

2020-07-14 09:24:35

呱牛笔记

WebRTC媒体服务器

2020-07-15 09:39:21

本文介绍了WebRTC解决方案中使用MCU和SFU模式的媒体服务器（截至2016年9月）。我希望它能够成为那些想更多地了解概念并快速开始项目的用户参考文章。这里每个产品的详细信息都没有提供，但它们的链接都在这儿。如果您愿意的话，您可以进一步阅读。而且，我几乎只提到独立的媒体服务器，并没有触及WebRTC CPaas 或 PaaS。

Introduction

可以将WebRTC系统体系结构大致分为两种类型：

不中断加密访问的媒体

p2p架构
使用TURN服务器
[未来支持PERC]

谁是最好的WebRTC SFU？

2020-07-15 09:41:21

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

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

了不起的WebRTC：生态日趋完善，或将实时音视频技术白菜化

2020-07-15 09:50:07

本文原文由声网WebRTC技术专家毛玉杰分享。

1、前言

有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年，这并非没有根据。就在去年（2017年），WebRTC 1.0 标准草案出炉（实际上WebRTC标准草案的早期版本早在2011年就已经发布，WebRTC并非一夜之间就出现的技术），并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了，或许门槛如此之高的实时音视频技术终有白菜化的那一天。

补充：WebRTC标准草案的版本演进历史，请点击进入。

WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信架构

2020-07-22 11:50:50

WebRTC 本身提供的是 1 对 1 的通信模型，在 STUN/TURN 的辅助下，如果能实现 NAT 穿越，那么两个浏览器是可以直接进行媒体数据交换的；如果不能实现 NAT 穿越，那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看，Google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。

如果你想要通过 WebRTC 实现多对多通信，该如何做呢？

其实，基于 WebRTC 的多对多实时通信的开源项目也有很多，综合来看，多方通信架构无外乎以下三种方案。

Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
MCU（Multipoint Conferencing Unit）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
SFU（Selective Forwarding Unit）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

WebRTC 开发实践：从一对一通话到多人会议

2020-07-15 15:24:38

前向纠错码(FEC)的RTP荷载格式

2020-07-16 10:05:15

本备忘录状态
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和建议。请参考最新版本的"Internet Official Protocol Standards"(STD1)来获得本协议的标准化进程和状态，此备忘录的发布不受任何限制。

版权注意
版权归因特网协会（1999）所有，保留一切权利。

摘要
本文档规定了一般性的前向纠错的媒体数据流的RTP打包格式。这种格式针对基于异或操作的FEC算法进行了特殊设计，它允许终端系统使用任意长度的纠错码，并且可以同时恢复出荷载数据和RTP头中的关键数据。由于FEC作为一个分离的数据流进行传送，这种方案可以向后兼容那些没有实现FEC解码器的接收终端。对于那样的终端来说，可以简单地将FEC数据丢掉。

目录
1    简介                        2
2    术语                        2
3    基本操作                    3
4    监督码                      3
5    RTP媒体数据包结构           5
6    FEC包结构                   5
6.1 FEC包的RTP包头              5
6.2 FEC头                       5
7    保护操作                    6
8    恢复过程                    7
8.1 重建                        7
8.2 何时进行恢复                8
9    例子                        11
10   冗余编码中使用FEC的用法     13
11   在SDP中表示FEC              14
11.1 FEC作为独立的流传输         14
11.2 在冗余编码中使用FEC         15
11.3 在RTSP中的用法              16
12   安全性问题                  16
13   致谢                        17
14   作者地址                    17
15   参考书目                    17
16   版权声明                    18
     致谢                        18

WebRTC+libwebsockets+Janus的秒开实践

2020-07-20 14:29:09

背景
客户端SDK集成了WebRTC和libwebsockets，服务端使用了Janus，需要支持拉流秒开。

关于WebSocket
Janus作为SFU，使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择，C层主要是libwebsockets库，这个也是Janus使用的库，还有Boost的Beast库，不过比较新，不敢踩坑，IOS上有RocketSocket，但不是跨平台，因此最后采用了libwebsockets库。
libwebsockets库主要的问题是IO接口不太友好，需要自己启动一个线程轮询获取IO事件，在其回调中处理所有事件。

秒开要考虑的问题
libwebsockets IO的优化
主要是写数据的处理。
libwebsockets需要调用者自己维护发送队列，调用者调用lws_callback_on_writable来告知libwebsockets有数据要写，然后数据放入发送队列，libwebsockets会通过LWS_CALLBACK_CLIENT_WRITEABLE事件通知可写，这个时候调用者才可以从发送队列取出数据发送，这个是一个异步的过程。
在libwebsockets的IO事件循环中，lws_service用于阻塞等待IO事件，但是lws_callback_on_writable并不会让lws_service退出阻塞状态，lws_service有一个最大等待时间，如果等待lws_service超时才处理待发送的数据无疑会增加整体接续时间。这里可以通过在调用线程中调用lws_cancel_service方法强制lws_service退出阻塞来立刻处理发送队列中的数据。这里需要用互斥锁对发送队列做一个同步。

Janus源码分析（4）——信令交互过程

2020-07-21 00:59:21

1. Janus插件交互流程
Janus中所有插件都遵循以下基本数据流程：

客户端发送create创建一个Janus会话；
Janus回复success返回Janus会话句柄；
客户端发送attach命令在Janus会话上attach指定插件；
Janus回复success返回插件的句柄；
客户端给指定的插件发送message进行信令控制；
Janus上的插件发送event通知事件给客户端；
客户端收集candidate并通过trickle消息发送给插件绑定的ICE通道；
Janus发送webrtcup通知ICE通道建立；
客户端发送媒体数据；
Janus发送media消息通知媒体数据的第一次到达；
Janus进行媒体数据转发。

Janus源码分析（5）——echotest分析

2020-07-21 01:01:46

1、运行效果图
Echo测试演示的是发送给服务器网关的音频和视频，服务器会回传给你，效果如下图所示：

2、代码分析
2.1 代码结构

2.2 源码分析
2.2.1 创建线程
在janus = new Janus()时，调用Janus(gatewayCallbacks)在其中有函数createSession，并且传入下面的回调函数：

createSession创建请求，成功建立一次httpAPICall，输出Created handle: 1747107217737787

Janus源码分析（7）——videoroom分析

2020-07-21 01:02:50

1. 运行效果
https://janus.conf.meetecho.com/videoroomtest.html?simulcast=true

包含：Simulcast功能

视频高等质量（分辨率：1280*720，带宽1.5M+）
视频中等质量（分辨率：640*360，带宽500K左右）
视频低等质量（分辨率：320*180，带宽150K左右）

WebRTC+libwebsockets+Janus的秒开实践

2020-07-21 01:08:29

客户端SDK集成了WebRTC和libwebsockets，服务端使用了Janus，需要支持拉流秒开。

关于WebSocket
Janus作为SFU，使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择，C层主要是libwebsockets库，这个也是Janus使用的库，还有Boost的Beast库，不过比较新，不敢踩坑，IOS上有RocketSocket，但不是跨平台，因此最后采用了libwebsockets库。
libwebsockets库主要的问题是IO接口不太友好，需要自己启动一个线程轮询获取IO事件，在其回调中处理所有事件。

秒开要考虑的问题
libwebsockets IO的优化
主要是写数据的处理。
libwebsockets需要调用者自己维护发送队列，调用者调用lws_callback_on_writable来告知libwebsockets有数据要写，然后数据放入发送队列，libwebsockets会通过LWS_CALLBACK_CLIENT_WRITEABLE事件通知可写，这个时候调用者才可以从发送队列取出数据发送，这个是一个异步的过程。
在libwebsockets的IO事件循环中，lws_service用于阻塞等待IO事件，但是lws_callback_on_writable并不会让lws_service退出阻塞状态，lws_service有一个最大等待时间，如果等待lws_service超时才处理待发送的数据无疑会增加整体接续时间。这里可以通过在调用线程中调用lws_cancel_service方法强制lws_service退出阻塞来立刻处理发送队列中的数据。这里需要用互斥锁对发送队列做一个同步。

自研WebRTC网关服务器架构的实践之路

2020-07-27 12:43:22

我们对他的演讲内容做了整理,整理后的文章分为上下两篇，本文为第二篇，欢迎阅读。

前面我给大家分享了：

第一，为什么需要WebRTC网关。对于即构来说，目前所使用的系统已经较为成熟，也经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

第二，WebRTC通信模型对比。分析了目前的WebRTC通信模型以及不同模型的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

第三，开源VS自研。分享了目前市面上的一些开源系统及其特点以及即构自研WebRTC网关的目的和出发点。

下面，我将结合即构自研的WebRTC网关服务器方案，分享在开发过程中遇到的难点和解决办法。

WebRTC网关服务器搭建：开源技术 vs 自行研发

2020-07-27 12:44:16

作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。

大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：

● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

WebRTC网关服务器搭建：开源技术 vs 自行研发

2020-07-27 12:44:27

作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。

大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：

● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API

2020-07-30 10:15:15

There’s new functionality with the new API and the Unified Plan SDP format:

Early media: after an offer is sent, the calling side can receive media before receiving the answer

Support for multiple or no media streams for a given track

With sender objects you can control media with sender.setParameters()

With transceiver objects, you can more directly control certain aspects of SDP generation.

不需要SFU实现WebRTC联播实践

2020-08-03 02:19:16

文 / Philipp Hancke

译 / 元宝

审校 / Ant

原文：

https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/

同步联播是WebRTC用于多方会议的一个很有趣的方面。简而言之，它意味着可以同时发送三种不同的分辨率（空间可伸缩性）和不同的帧速率（时间可伸缩性）。

通常，需要一个SFU才能利用联播。但是有一个方法可以使在两个浏览器之间或在单个页面内效果可见。这对于做单页测试或使用联播功能是非常有用的，特别是能够只启用某些空间层或控制特定流的目标比特率。

Playground

Playground有两种变体，一种用于Chrome，另一种用于Firefox。Chrome版本使用了我们在2014年夏天的谷歌环聊中首次看到的旧的SDP munging hack 。Firefox 使用‘RTCRtpSender.setParameters’来启用同步联播。两者都没有遵守最新的规范，但这并不会影响任何人对它的使用。

两种变体都可以显示视频图像，首先是发送者图像和总体比特率/帧速率图，其后是三个不同的空间流，每个空间流具有用于比特率和帧率的对应图。

由于我们不想涉及到服务器的内容，所以我们需要破解一些东西。幸运的是，有一个Chrome的测试验证了这个想法。Chrome和Firefox都使用一个数据包的RTP SSRC将其路由到某一个特定的媒体流。这些SSRC可以在SDP提供中找到：

原始的Chrome SDP

WebRTC+libwebsockets+Janus的秒开实践

2020-10-10 13:37:33

背景

客户端SDK集成了WebRTC和libwebsockets，服务端使用了Janus，需要支持拉流秒开。

关于WebSocket

Janus作为SFU，使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择，C层主要是libwebsockets库，这个也是Janus使用的库，还有Boost的Beast库，不过比较新，不敢踩坑，IOS上有RocketSocket，但不是跨平台，因此最后采用了libwebsockets库。
libwebsockets库主要的问题是IO接口不太友好，需要自己启动一个线程轮询获取IO事件，在其回调中处理所有事件。

janus Streaming插件推流指南

2020-12-31 05:57:37

在janus Steaming插件中，官方提供了三种不同的流传输方法，即：

由文件（歌曲）产生的按需流：访问此流的不同用户都会从头开始播放该音频文件。
仍由文件（广播）产生的伪实时流：访问此流的不同用户都将收到相同的音频。
由gstreamer发起的实时流：对于伪实时流，不同的用户将获得相同的视频画面。

前两个在我们安装完janus后是可以直接播放出来的，第三种则需要我们额外部署rtp推流的程序。

官方使用的是使用GStreamer，但使用了FFmpeg，LibAV或其它也可以。

考虑到FFmpeg在流媒体圈子里名气最大，所以就选它了。

音视频相关的书籍，多媒体技术

2021-01-08 02:16:26

对播放器架构演进、流媒体存储传输、视频编解码标准及图像声音信号处理，既对数学要求较高又与当时全民IT热相结合的专业——(计算机)信息安全，精妙绝伦的数论及密码学。既能应用密码学的知识技能又能和声色并茂的多媒体场景结合起来的信息隐藏和数字水印，音视频技术是互联网品质生活的连接器。连接器”的另一头则连接且聚合着信息论、最优化理论、图形图像学、声学、人类视觉系统等一众根基深厚、源远流长的学派。

-- 多媒体技术

基础知识方面推荐岗萨雷斯的《数字信号处理》，东南大学的《信息论与编码》；

编码基础方面推荐Wiley的《THE H.264 ADVANCED VIDEO COMPRESSION STANDARD》或国内毕厚杰老师的《新一代视频压缩编码标准H.264》；

最新的标准可以看相关的标准文档。

audio语音相关的基础知识-VAD,ASR,AEC,AGC,BF等

2021-02-21 07:16:55

一. VAD

1. 什么是VAD

VAD，也就是语音端点检测技术，是Voice Activity Detection的缩写.

这个技术的主要任务是从带有噪声的语音中准确的定位出语音的开始和结束点，因为语音中含有很长的静音，也就是把静音和实际语音分离开来，因为是语音数据的原始处理，所以VAD是语音信号处理过程的关键技术之一。

语音识别系统在识别或者声学模型训练阶段所遇到的第一个技术就是端点检测，把静音和噪声作为干扰信号从原始数据中去除，并且端点检测对于语音识别系统的性能至关重要。

静音抑制，又称语音活动侦测。静音抑制的目的是从声音信号流里识别和消除长时间的静音期，以达到在不降低业务质量的情况下节省话路资源的作用，它是IP电话应用的重要组成部分。静音抑制可以节省宝贵的带宽资源，可以有利于减少用户感觉到的端到端的时延。

2. VAD的作用

现在流行的语音识别系统大部分，或者是相当一部分都是基于统计和训练的原理所构建的系统，因此对数据来源和训练环境都是很敏感的。在识别的过程中，经常存在实际语音因背景噪声的干扰而与训练失配的情况，实际这也是造成语音识别系统鲁棒性差的一个根本原因（另一个主要的是无法处理非预期的输入），从而导致识别错误，性能下降。哪怕是两段内容上是完全一致的语音信号，可能由于语速不一样，所以语音信号的时间也不相同，音素之间的时间间隙也就不一样，对于时变而非平稳的语音信号来说，其特征就完全不相同了。有音素之间的间隙，也有静音和语音本身的间隙，为了对数据从时间上进行相对的校准，语音端点检测技术就应运而生了，因此端点检测技术可以决定这种校准的相对精度，使得同一内容的特征更趋于相同，当然，一般情况下是不可能完全相同的。大量研究表明，如果环境是安静的环境，没有太多背景噪声，此时语音识别系统的主要错误来源于端点检测技术不精确。

但在实际应用中，不可能没有背景噪声，另外由于麦克风的录制和信号增益也会带来噪声，所以语音识别系统的错误是由多方面影响的，至少包括：端点检测、特征提取、语音模型、声学模型、解码器等多个方面。

提纲挈领webrtc之vad检测

2021-02-22 01:47:47

顾名思义，VAD（Voice Activity Detection）算法的作用是检测是否是人的语音，它的使用

范围极广，降噪，语音识别等领域都需要有vad检测。vad检测有很多方法，这里我们之介绍一

下webrtc里面的vad检测。

　　webrtc的vad检测原理是根据人声的频谱范围，把输入的频谱分成六个子带

（80Hz~250Hz，250Hz~500Hz,500Hz~1K,1K~2K,2K~3K,3K~4K。）分别计算这六个子带的、

能量。然后使用高斯模型的概率密度函数做运算，得出一个对数似然比函数。对数似然比分为

全局和局部，全局是六个子带之加权之和，而局部是指每一个子带则是局部，所以语音判决会

先判断子带，子带判断没有时会判断全局，只要有一方过了，就算有语音。

WebRTC研究：WebRTC M89关键更新

2021-03-18 09:14:14

最近更新了M89代码，看了下Release Notes，有几个需要关心的地方。

Plan B SDP语法后续处理计划

WebRTC 1.0已经正式成为W3C标准，推荐使用标准SDP格式：Unified Plan，主流浏览器基本都支持Unified Plan SDP。Plan B SDP后续将会不赞成使用，直到移除掉。官方后续时间计划如下：

M89 (2021.02)：在开发者控制台增加不赞成使用警告
M93 (2021.08): Plan B被移除掉, 但是增加了选项，可以延长移除的截止日期
M96 (2022.01): 不再允许延长截止日期，Plan B将彻底移除

rtp payload类型增加新范围

M89中RTP payload类型增加了新的值范围：35-65。

首先根据RFC3551，回顾下目前用于标准音视频编码器的RTP payload类型。

音频编码器的payload类型

游戏实时语音解决方案是怎么炼成的

2021-04-25 23:20:53

在棋牌游戏中，一起打牌的玩家有吹牛唠叨的社交需求。在MMORPG竞技游戏中，一起并肩作战的队友有团队协同的通讯需求。实时游戏语音是网络游戏的标配，这早已经是业界共识。

现在的问题是，不管是自行研发实时游戏语音方案,还是采用第三方游戏实时语音SDK，都必须要先为游戏量身订造一套解决方案。这套解决方案必须是和游戏本身的用户需求、考量因素、及应用场景紧密结合的。把通用的语音视频通讯方案直接拿来给游戏用是不适合的。

今天，我们就一起来深度聊一聊，怎么针对游戏的应用场景订造游戏实时语音解决方案。

人声 or 音乐声

人声场景是指语音通讯中大部分或者全部时间都是人声在说话的场景。典型的例子包括Skype网络电话、和微信语音。音乐声场景是指语音通讯中有相当一部分内容是涉及到音乐和表演等娱乐环节的场景。典型的例子包括花椒直播的连麦K歌海选赛。

游戏实时语音的场景基本是人声在说话。现在，让我们来了解一下人声语音的特点。人类的听力感知范围是从20Hz到20kHz。这个频宽范围被划分成四个频宽类别：窄带、宽带、超宽带和全带。

深入浅出 WebRTC AEC（声学回声消除）

2021-04-25 23:46:17

WebRTC AEC 存在的问题：

（1）线性部分收敛时间较慢，固定步长的 NLMS 算法对线性部分回声的估计欠佳；
（2）线性部分滤波器阶数默认为 32 阶，默认覆盖延时 132ms，对移动端延时较大设备支持不是很好，大延时检测部分介入较慢，且存在误调导致非因果回声的风险；
（3）基于相干性的帧状态依赖严格的固定门限，存在一定程度的误判，如果再去指导非线性部分抑制系数的调节，会带来比较严重的双讲抑制。

优化的方向：
（1）算法上可以通过学习 speex 和 AEC3 的线性部分，改善当前线性滤波效果；
（2）算法上可以优化延时调整策略，工程上可以新增参数配置下发等工程手段解决一些设备的延时问题；
（3）另外，有一些新的思路也是值得我们尝试的，如开头提到的，既然回声也可以是视为噪声，那么能否用降噪的思路做回声消除呢，答案是可以的。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。

扩展 GRTN：云原生趋势下的 RTC 架构演进

2021-04-25 23:57:10

因为有些朋友不是做服务器的，我还是先介绍下 RTC 服务是什么吧。

直播经过这些年的发展，大家都理解需要后端服务，比如 OBS 推流，是不能直接推给播放器的，而是经过 CDN 转发，CDN 就是直播的后端服务了。

RTC 是大不相同的，比如 WebRTC 本身设计是通话，通话场景大部分时候都是一对一的对话，所以 WebRTC 设计了多种传输方式，比如直接 P2P、通过 STUN 转发、通过 SFU 或 MCU 转发。

如果只是跑 DEMO，那么不用 RTC 服务器，直接 P2P 也是可以跑起来的。真实线上，肯定是要经过服务器，现在使用最广的是 SFU 转发。主要原因如下：

P2P 打不通：有些网络是对称 NAT，两个客户端在各自的内网无法通过 P2P 打通，就必须使用服务器中转流。
跨网远距离传输：比如跨国传输，或者跨运营商，客户端直接 P2P 就算能连通，效果也不好，如果经过服务器可以优化传输线路。
会议转直播：如果需要对媒体进行处理，比如将 RTC 转直播，广播给更多观众，就需要转码和转协议，这也必须要服务器处理。
录制精彩片段：目前的录制和剪辑等内容的处理，在互联网上还是 RTMP 对接比较多，将 RTMP 流送到录制或剪辑系统。
不同客户端网络状况不同：有些客户端网络好，有些差，通过服务器可以精确计算不同客户端的网络情况，给客户端传输不同的质量的流。
兼容老客户端和协议：线上客户端的版本非常多，随着迭代，可能支持的协议也不一样，需要服务器做兼容处理。

各家云厂商都有自己的后端服务，比如阿里云的 GRTN，声网的 SD-RTN 等等。实际上传输网络并不等于传输服务器，而是一个传输的系统，包括调度、路由、协议处理、发布和维护、问题排查、数据分析等等。

AliRTC（阿里云 RTC）的传输网络，传输协议使用 GRTN，除了 GRTN (CDN) 的网络，我们还扩展实现了 GRTN (Tenfold)；GRTN (Tenfold) 补充了 BGP 专线、ENS、专有云网络、第三方云支持 K8S 的云网络等，适应多种不同场景的传输要求。

其中 GRTN (Tenfold) 就是基于 SRS 做的，增加了很多能力，有些已经反馈给了 SRS 社区。

RTC QoS 弱网对抗之变分辨率编码

2021-04-26 08:48:21

变分辨率在弱网场景的实际应用中非常常见，网络状况不好的时候降低分辨率可以降低码率，减少块效应，网络好的时候增加分辨率可以提升清晰度及主观体验。

目前主流的视频编码标准，比如 H.264、H.265，在编码过程中如果要进行分辨率切换，则必须要先编码一个 I 帧，而 I 帧只能使用帧内预测，编码效率低下。这在弱网变分辨率的时候就容易造成卡顿。下图中展示了每秒钟切换分辨率的码率波动效果，高低两个分辨率，每秒钟切换一次。

理论 + 标准 + 工程 —— 阿里云视频云编码优化的思考与发现

2021-04-26 08:49:20

2010 年毕业于华中科技大学，此后投身多媒体方向的技术开发，从流媒体、视频编码、视频处理到质量评价均有涉及，并从零开始打造了一款广泛商用的视频编码器及其前后处理系统。加入阿里云视频云后，负责视频编码与增强算法，团队聚焦在视频编码、视频前后处理以及质量评价方向，并重点研发演进窄带高清技术。

此次作为 LiveVideoStackCon 2021 的讲师，王豪与我们分享其对编码优化的思考与发现。

Q1.你最近关注的技术趋势？有哪些是你认为比较有发展前景的？

我个人的技术栈一直聚焦在视频编码和处理方向，也一直在思考，在这个方向上，我们短期和长期的布局是什么，中短期布局如何保证竞争力，以及长期布局如何避免系统性踏空。

利用 AI 辅助视频压缩是业界非常关注的方向，它有这几种思路：

私有编码模式：端到端的视频压缩，基于深度学习的模块级视频压缩优化；
基于实时图像生成的视频压缩，因为 GAN 生成人脸和人体比较成熟，但在其他场景成熟度不够，因此这个方向在会议场景比较火，我们也在持续关注和尝试。
基于标准编解码器的视频编码与处理联合优化，包括两部分：利用视频处理提升编码压缩率和利用视频编码提升视频处理效果。

这其中，我最关注 “基于标准编解码器的视频编码与处理联合优化”。针对视频后处理，还有如何进行编码决策优化（包括模式和码率），同时扩展到分层编码，这个方向是整个端云联合优化的核心，对工业界应用有很大价值，希望到时候和大家一起探讨。

亮相 LiveVideoStackCon，透析阿里云窄带高清的现在与未来

2021-04-26 08:50:26

阿里云的窄带高清

1.1 窄带高清技术

窄带高清是阿里云视频云的技术品牌，是属于内容自适应编码里的。窄带高清是修复增强 + 压缩的问题，主要目标是追求质量、码率、和成本的最优均衡。在这个方向我们有两代不同版本。

第一代是均衡版，主要作用是如何用最少的成本去实现自适应的内容处理和编码，达到质量提升同时节省码率的目的。所以，我们在窄高 1.0 充分利用编码器里的信息帮助视频处理，即成本很小的前处理方法，从而实现低成本的自适应内容处理和编码。同时，在编码器里，主要时间是基于主观的码控。

第二代（窄高 2.0），与窄高 1.0 相比会有更多的、更充分的、复杂度更高的技术来保证自适应能力，同时我们在窄高 2.0 里增加了修复能力，比较适用于高热内容，比如优酷世界杯。对这种重要的比赛用窄高 2.0 进行处理，在质量提升的同时，码率节省也更多，具体内容我在后面会一一展开。

WEBRTC中VAD算法及思想的数学解析

2021-04-26 08:51:56

0 概述
VAD(Voice Activity Detection), 活动语音检测技术在语音信号处理有着重要的作用，如语音增强中估计噪声、语音识别中进行语音端点检测，在语音信号传输中用于非连续传输等等。

本文全面解析WEBRTC 中VAD 算法，该算法主要原理是将信号在频谱上进行子带划分为 80~ 250Hz，250~ 500Hz，500Hz~ 1K， 1~ 2K，2~ 3K，3~4KHz ，6个频带，计算每个频带能量为特征；通过假设检验，构建了噪声和语音两个假设，从而对每个子带构建由2个高斯分布组合的噪声和语音的混合高斯分布模型。通过极大似然估计对模型进行自适应学习优化，并通过概率比判决推断。

该算法重点涉及了子带划分技术、极大似然估计、假设检验等知识，本文将通过信号与系统、统计学习的知识解析代码中所蕴含的数学。

1 子带划分滤波器 SplitFilter
1.1 全通滤波器 AllPassFilter

VAD-开源工具-webrtc

2021-04-26 08:52:27

1. 可以成功检测到最低能量的语音(灵敏度)。
2. 如何在多噪环境下成功检测（漏检率和虚检率）。
漏检反应的是原本是语音但是没有检测出来，而虚检率反应的是不是语音信号而被检测成语音信号的概率。相对而言漏检是不可接受的，而虚检可以通过后端的ASR和NLP算法进一步过滤，但是虚检会带来系统资源利用率上升，随之系统的功耗和发热会进一步增加，而这会上升为可移动和随声携带设备的一个难题。

摘要：

unimrcp中vad算法的诸多弊端，但是有没有一种更好的算法来取代呢。有两种方式 1. GMM 2. DNN。

其中鼎鼎大名的WebRTC VAD就是采用了GMM 算法来完成voice active dector。重点介绍WebRTC VAD算法。介绍WebRTC的检测原理。

原理：

首先呢，我们要了解一下人声和乐器的频谱范围，下图是音频的频谱。

H.264视频码流解析

2021-06-23 00:16:01

一些基本概念

YUV/RGB处理以及PCM处理处于对视音频原始数据的处理，但是视音频在传输的过程中是以视音频码流传输的。接下来介绍一下视频码流：

H.264的标准定义如下：同时也是MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。

什么是H.264

先通过PR编辑软件的导出列表形象生动地感受一下H.264格式：

H264--2--语法及结构

2021-06-23 00:21:50

名词解释
场和帧：视频的一场或一帧可用来产生一个编码图像。在电视中，为减少大面积闪烁现象，把一帧分成两个隔行的场。

片：每个图象中，若干宏块被排列成片的形式。片分为I片、B片、P片和其他一些片。

I片只包含I宏块，P片可包含P和I宏块，而B片可包含B和I宏块。

I宏块利用从当前片中已解码的像素作为参考进行帧内预测。

P宏块利用前面已编码图象作为参考图象进行帧内预测。

B宏块则利用双向的参考图象（前一帧和后一帧）进行帧内预测。

片的目的是为了限制误码的扩散和传输，使编码片相互间是独立的。

某片的预测不能以其它片中的宏块为参考图像，这样某一片中的预测误差才不会传播到其它片中去。

宏块：一个编码图像通常划分成若干宏块组成，一个宏块由一个16×16亮度像素和附加的一个8×8 Cb和一个8×8 Cr彩色像素块组成。

视频编解码学习之一：理论基础

2021-06-23 00:31:03

第1章介绍

1. 为什么要进行视频压缩？

未经压缩的数字视频的数据量巨大
存储困难
- 一张DVD只能存储几秒钟的未压缩数字视频。
传输困难
- 1兆的带宽传输一秒的数字电视视频需要大约4分钟。

2. 为什么可以压缩

去除冗余信息
- 空间冗余：图像相邻像素之间有较强的相关性
- 时间冗余：视频序列的相邻图像之间内容相似
- 编码冗余：不同像素值出现的概率不同
- 视觉冗余：人的视觉系统对某些细节不敏感
- 知识冗余：规律性的结构可由先验知识和背景知识得到

3. 数据压缩分类

无损压缩（Lossless）
- 压缩前解压缩后图像完全一致X=X'
- 压缩比低(2:1~3:1)
- 例如：Winzip，JPEG-LS
有损压缩（Lossy）
- 压缩前解压缩后图像不一致X≠X'
- 压缩比高(10:1~20:1)
- 利用人的视觉系统的特性
- 例如：MPEG-2，H.264/AVC，AVS

stun信令

2021-06-25 13:08:25

1. 简介
stun协议本身是用来进行NAT穿透使用，其本身实际上是NAT内部设备获取外部IP地址的一种协议。STUN协议在RFC上目前经过三种演变，其中RFC3489上定义的STUN和之后的RFC5389和8489上定义的stun在概念上存在明显区分：
RFC3489定义：Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN)
RFC5389和RFC8489：Session Traversal Utilities for NAT (STUN)
可以看到STUN协议的英文描述本身就已经发生了变化，3489中定义的是通过UDP进行NAT穿越的方式，而在RFC5389上定义的是对于NAT穿越的一整套工具集，这个工具集不在局限于UDP而是同时适用于UDP和TCP协议。

SDP中H264 RTP Payload各项参数含义

2021-06-28 02:05:30

仅个人理解，如有错误之处，还请指正。

SDP中H264的参数很多，仅介绍总结实际产品中常用到的几个。下面是实际使用中常见的H264参数：

a=fmtp:108 profile-level-id=420014;packetization-mode=1;max-mbps=108000;max-fs=3600;max-fps=3000;max-br=1500;max-dpb=891;level-asymmetry-allowed=1

1.profile-level-id:
profile-level-id是16进制表示的3个字节的整数，按顺序分成3个字节，每个字节分别表示不同的含义。

profile_idc
profile-iop: 前6位分别是constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, 最后两位为保留位
level_idc
接收端默认支持哪种sub-profile由profile_idc和profile-iop中的几个bit共同决定。如下表：

【WebRTC】几个重要sdp参数描述

2021-06-28 07:08:09

o=- 2833773620626745940 2 IN IP4 127.0.0.1
s=-
t=0 0

WebRTC RTP Header Extension 分析

2021-06-28 07:09:19

0x00 WebRTC RTP Header Extension 格式说明
在 RTP协议 rfc3550 section 3.5.1 中定义 RTP header extension 结构如下图所示：

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |

WebRTC入门（三）---- 目录结构

2021-07-03 16:40:51

目录结构说明

在本节中将介绍WebRTC的目录结构以及各个目录的作用
通过阅读本节将会在未来需要修改源代码时为你提供帮助

外层目录结构

1.api
接口层，外部通过调用本层来使用WebRTC的核心功能

2.call
管理层，通过本层可以对数据流进行管理

3.video
视频相关的逻辑，包括处理、编解码等

ncnn_example

2021-07-05 15:36:09

这里编辑文章摘要...

libnice调用流程分析

2021-07-06 10:59:08

libnice介绍：

libnice库是基于ICE协议实现的一套通信连接库。
主要功能是实现p2p连接及媒体数据流发送接收。其类似于webrtc源码中自带的libjingo。我们可在我们的项目中使用libnice库来实现端到端的ICE连接和数据流发送接收。以及candidates(候选地址)和SDP（媒体描述文件）的相互交换。
libnice库是基于glibc语言的，跨平台，在linux和手机端都可使用，但需依赖于glib库。

libnice调用流程分析

2021-07-06 10:59:08

libnice介绍：

libnice库是基于ICE协议实现的一套通信连接库。
主要功能是实现p2p连接及媒体数据流发送接收。其类似于webrtc源码中自带的libjingo。我们可在我们的项目中使用libnice库来实现端到端的ICE连接和数据流发送接收。以及candidates(候选地址)和SDP（媒体描述文件）的相互交换。
libnice库是基于glibc语言的，跨平台，在linux和手机端都可使用，但需依赖于glib库。

WebRTC ICE 状态与提名处理

2021-07-06 13:14:23

大家都知道奥斯卡有提名，其实在 WebRTC 的 ICE 中也有提名，有常规的提名，也有激进的提名，而且提名的候选人不一定是最优秀的候选人喔，本文就带你一探其中玄妙。文章内容主要描述 RFC 5245 中 ICE 相关的状态和 ICE 提名机制，并结合 libnice(0.14) 版本进行分析。

Webrtc delay-base-bwe代码分析(2): InterArrival模块

2021-07-06 14:24:42

Webrtc delay-base-bwe代码分析(2): InterArrival模块
0. 参考文档
[1] google congestion control
[2] Rtp payload format for h264

1. 功能
该模块主要对到达的时间进行小范围内的统计、采样，并根据一定的时间间隔计算出对应的延迟、传输大小变化。

The arrival-time filter. The goal of this block is to produce an estimate m(ti) of the one way delay gradient. For this purpose, we employ a Kalman filter that estimatesm(ti) based on the measured one way delay gradient dm(ti) which is computed as follows:
dm(t(i) = (t(i) - t(i-1))-(Ti - T(i-1))
where Ti is the time at which the first packet of the i-th video frame has been sent and ti is the time at which the last packet that forms the video frame has been received.

WebRTC - ICE 过程简述

2021-07-06 14:38:29

1. ICE介绍

1.1.ICE 的角色
分为 controlling和controlled。

Offer 一方为controlling角色，answer一方为controlled角色。

1.2.ICE的模式
分为FULL ICE和Lite ICE：

FULL ICE:是双方都要进行连通性检查，完成的走一遍流程。

Lite ICE: 在FULL ICE和Lite ICE互通时，只需要FULL ICE一方进行连通性检查， Lite一方只需回应response消息。这种模式对于部署在公网的设备比较常用。

完整SIP/SDP媒体协商概论-ICE初始offer发送详解

2021-07-06 14:41:44

在前面的章节中，我们主要讨论了ICE概览，介绍了ICE的基本处理流程和候选地址配对的算法概论和轻量级ICE部署（Lite Implementations）的讨论。和前面介绍中讨论的SIP中offer的处理一样，在此文章中，笔者也将首先介绍ICE处理过程中初始offer的发送处理。因为轻量级的ICE部署场景不是RFC5245推荐的场景，本身协商也忽略了很多检查流程，所以笔者还是按照规范的的重点内容来讨论全部署场景（Full Implementations）中关于初始offer的处理，结尾部分将讨论轻量级ICE部署的场景和SDP解码。

完整SIP/SDP媒体协商概论-ICE初始offer发送详解

2021-07-06 14:43:17

在前面的章节中，我们主要讨论了ICE概览，介绍了ICE的基本处理流程和候选地址配对的算法概论和轻量级ICE部署（Lite Implementations）的讨论。和前面介绍中讨论的SIP中offer的处理一样，在此文章中，笔者也将首先介绍ICE处理过程中初始offer的发送处理。因为轻量级的ICE部署场景不是RFC5245推荐的场景，本身协商也忽略了很多检查流程，所以笔者还是按照规范的的重点内容来讨论全部署场景（Full Implementations）中关于初始offer的处理，结尾部分将讨论轻量级ICE部署的场景和SDP解码。

基于WebRTC构建超低延迟(500ms)的直播系统

2024-06-12 12:02:46

上周写了一篇文章基于RTMP和WebRTC 构建低延迟的直播系统(https://cloud.tencent.com/developer/article/1409975), 只所以要基于RTMP, 还是考虑尽可能复用现有的技术和基础设施. 实际上国外已经有基于WebRTC的CDN系统, 比如 http://phenixrts.com/, https://www.millicast.com/. 比这更早的可以追溯到beam, 一个实时的游戏直播平台, 在2016年被微软收购后改名mixer(https://mixer.com). 目前国内低延迟直播的做法是在rtmp的基础调优, 比如使用可靠UDP方案替换RTMP的传输层, 目前使比较多的方案有KCP和QUIC. 但魔改RTMP的方案始终没有特别好的适配浏览器的方法. 相比有超过40亿设备支持的WebRTC来说, WebRTC的方案无疑更有想象空间.