有4种力量来推动adapter.js：
1. WebRTC规范本身。这正是我们所期望的，并建议开发人员针对此点进行工作。
2. 浏览器的WebRTC的实现。目前，它排在WebRTC规范之后。在这之前，建议使用adapter.js（你也可以自己写，但为什么又要花额外的精力来维护它呢？）
3. adapter.js实现。你需要时刻关注新版本，采用新版本，并且对它们进行测试。
4. 你自己的实现，以及如何与上述3种力量来搭配。
我们会有那么一天不需要adapter.js吗？
WebRTC adapter.js是什么以及我们为什么需要它？（二）
2019-11-23 01:01:05WebRTC adapter.js是什么以及我们为什么需要它？（一）
2019-11-23 01:00:14
这里的主要概念是展示WebRTC与传统VoIP的不同之处。
在传统VoIP中，你有多个供应商实施该规范，希望实现能够相互协作。如果你知道一个VoIP的实现，它也不代表你也能了解另一个VoIP的能力。
WebRTC有所不同，它有很多概念都没有规定，但也规定了HTML5；我的意思是让每个开发人员都可以使用一个API将交互式语音和视频添加到他的应用程序中。
getUserMedia，PeerConnection和数据通道都是WebRTC中指定的API。而这也创造了一个生态系统。传统的VoIP不可能有这样的力量。
但问题是，你可以只将WebRTC API视为一种建议。这是因为直到今天，规范的1.0版本也没有成为现实。WebRTC的浏览器实现更像是同一种语言的方言。你自己说一种方言，你可以听懂另外一种方言，但又不能完全理解。如果说着两种不同方言的人试图在没有耐心或彼此理解的情况下进行交谈，就会发生不好的事情。
这也许就是adapter.js发挥作用的地方。
在我们问自己adapter.js在今天是否需要之前（是的我们需要），我们首先应该花点时间理解它发展过程。
利用WebRTC和TensorFlow通过网络实现计算机视觉3
2019-11-23 00:55:51原标题：Computer Vision on the Web with WebRTC and TensorFlow
前文连接：利用WebRTC和TensorFlow通过网络实现计算机视觉1；利用WebRTC和TensorFlow通过网络实现计算机视觉2
第3部分——浏览器端
开始之前，请先在项目的根目录位置创建一个static目录。我们将从这里提供HTML和JavaScript。
现在，我们首先使用WebRTC的getUserMedia抓取一个本地摄像头Feed。从这里，我们需要将该Feed的快照发送到刚刚创建的对象检测Web API，获取结果，然后使用画布实时地在视频上显示这些结果。
HTML
我们先创建local.html文件：
利用WebRTC和TensorFlow通过网络实现计算机视觉2
2019-11-23 00:55:22
第1部分——确保Tensorflow正常工作
为确保TensorFlow对象检测API正常工作，我们首先从用于演示对象检测的官方版Jupyter Notebook经调整后的版本着手。我将此文件保存为object_detection_tutorial.py。
如果您剪切并粘贴该notebook的每个部分，得到的结果应如下所示：
基于网页的语音命令识别
2019-11-23 00:54:37原标题：Web-based voice command recognitions
上一次我们将音频buffer转成了图像，这一次，我们将采取这些图像，并使用deeplearn.js训练一个神经网络。结果是一个浏览器上的demo，你可以说出“yes”或者“no”的指令，然后像这样实时的显示出识别结果：
虽然它离完美还差的很远，但却是在网上进行各种音频识别的一个很好的起点。现在让我们深入了解一下这是如何工作的。
快速入门：培训和测试一个指令识别器
下面是如何训练yes/no分类器的方法：
1. 跳转到模型训练页。这会花一点时间来下载训练数据（yes/no）。
2. 点击训练按钮，你会看到一个显示训练进度的图表。一旦你准备好了（会花一点时间，具体时间长短取决于你的硬件），停止训练，并且点击保存权重（文件）按钮。这会下载一个JSON文件。
使用WebRTC创建一个网络摄像头通信App
2019-11-23 00:53:24WebRTC是一个协议，允许人们使用JavaScript在两点之间创建实时通讯。
我们可以用这个结构使两个或更多浏览器之间实现直接交流，而不需要中心服务器。
服务器只需要在连接的时候被使用，因此每个客户端知道如何连接彼此。
我们可以使用这个特性创建什么类型的App呢？例如，直接网络摄像头连接。点对点通话，文件共享，还有更多。
本教程我会介绍一个当你第一次使用的时候，会发出惊呼的App：一个网络摄像头通信App.
我们不会使用原始WebRTC API,然而，我们需要注意很多细节。这就是library的作用，它们做出了很好的抽象，人们可以集中精力创建App而不是将精力花费的底层API上。
其中一个library是PeerJS,它使得实时通信变得非常简单。简单来说就是WebRTC,它的抽象使得结果获取更快，之后你可以学习内部是如何运作的。
建议：当你建立一个App时候使用Bit分享到一个可重复利用的集合中，并且在你所有的项目中同步它们！不妨试一下，可以加快你的工作速度。
WebRTC SFU中发送数据包丢失反馈
2019-11-23 00:51:49
多方WebRTC选择3：SFU
2019-11-23 00:50:32
多方WebRTC选择3的方案是SFU，它表示选择转发单元。SFU背后的想法与MCU相同。它在中间有一台媒体服务器，所有peers向它发送流，唯一不同的是，它不会做繁重的处理，服务器将其引到其它peers，这样它们可以进行任何所需的处理。
这样服务器不需要能支持那么繁重的处理运算，你可以利用MCU提供的好处，同时避免Mesh hassles和MCU的高代价。
SFU的结构如下图所示：
哪种TURN服务器正在被使用？
2019-11-23 00:48:19
为什么你的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
