getUserMedia | WebRTC中文网-最权威的RTC实时通信平台

撸一个多人视频聊天 — 前端 WebRTC 实战（一）

前言【从头到脚】会作为一个系列文章来发布，它包括但不限于 WebRTC 多人视频，预计会有： WebRTC 实战（一）：也就是本期，主要是基础讲解以及一对一的本地对等连接，网络对等连接。 WebRTC 实战（二）：主要讲解数据传输以及多端本地对等连接、网络对等连接。 WebRTC 实战（三）：实现一个一对一的视频聊天项目，包括但不限于截图、录制等。 WebRTC + Canvas 实现一个共享画板项目。作者开源作品 Vchat — 一个社交聊天系统（vue + node + mongodb） 6 的系列文章因为文章输出确实要耗费很大的精力，所以上面计划不一定是这个发布顺序，中间也会穿插发布其它方向的文章，如 Vue、JavaScript 或者其他学习的主题。在文章里，会把我自己遇到过的一些坑点重点提示大家注意，尽量让大家在学习过程中少走弯路。当然，我的也并不是标准答案，只是我个人的思路。如果大家有更好的方法，可以互相交流，也希望大家都能有所收获。在这里也希望大家可以关注一波，你们的关注支持，也能激励我输出更好的文章。本文示例源码库 webrtc-str

Chrome 70使用getDisplayMedia()进行屏幕捕捉

在Eede之后，Chrome是第二个通过navigator.getDisplayMedia()添加符合标准的屏幕捕捉的浏览器。 Chrome70的简介在八月宣布，并在十月的discuss-webrtc Google group中确认下来。这个特点目前设置在一个标示下，你需要更新到Chrome70，然后进入chrome://flags/开启网络试验平台。之后仿照本文范例你就可以在Chrome扩展中记录你的屏幕。在以前，在Chrome中的屏幕捕捉就是有可能的，但是你需要一个分离的扩展，它需要在Chrome网络商店中下载。在二月份，我们开发出一个扩展，使用了Pipe recorder. Chrome70让我们一睹未来。为了获取Chrome70中屏幕的媒体流，只需以下几行代码： navigator.getDisplayMedia({ video: true }) .then(stream => { console.log(“Awesome”); }, error => { console.log(“Unable to acquire screen captur

使用WebRTC创建一个网络摄像头通信App

WebRTC是一个协议，允许人们使用JavaScript在两点之间创建实时通讯。我们可以用这个结构使两个或更多浏览器之间实现直接交流，而不需要中心服务器。服务器只需要在连接的时候被使用，因此每个客户端知道如何连接彼此。我们可以使用这个特性创建什么类型的App呢？例如，直接网络摄像头连接。点对点通话，文件共享，还有更多。本教程我会介绍一个当你第一次使用的时候，会发出惊呼的App：一个网络摄像头通信App. 我们不会使用原始WebRTC API,然而，我们需要注意很多细节。这就是library的作用，它们做出了很好的抽象，人们可以集中精力创建App而不是将精力花费的底层API上。其中一个library是PeerJS,它使得实时通信变得非常简单。简单来说就是WebRTC,它的抽象使得结果获取更快，之后你可以学习内部是如何运作的。建议：当你建立一个App时候使用Bit分享到一个可重复利用的集合中，并且在你所有的项目中同步它们！不妨试一下，可以加快你的工作速度。后端首先我们需要创建后端。尽管我们会实现直接点对点通信，起初的握手和合作需要中心服务器。一旦握手完成，点

Zoom的Web客户端如何避免使用WebRTC?

Zoom的Web客户端可以在用户不下载它们App的情况下加入会议。Chris Koehncke很高兴能看到它是如何工作的。这确实有效，不必花时间下载App.并且视频质量可以接受，对此我们愉快的讨论了半小时。打开 chrome://webrtc-internals只看到了getUserMedia被用来获取摄像头和麦克风，但是没有看到RTCPeerConnection的使用。这激起了我的兴趣，它们是如何不用WebRTC进行通话的？为什么Zoom不使用WebRTC? Zoom与WebRTC的关系很难说清楚，就像网站上的陈述一样： Jitsi的伙伴对此进行了比较。Tsahi Levent-Levi对此也进行了有用的评论。让我们快速看看在某些有趣的情况下的‘特性’—–在Chrome浏览器中运行。 Zoom Web客户端 Chromes网络开发工具很快展现出两点： WebSockets被用来传输数据存在wasm文件 Wasm文件名快速产生了GitHub目录，在目录里，与其它JavaScript元素并存。这些文件和产品中所用的文件几乎相同。 WebSocket上的媒体

Safari中的WebRTC教程

自Apple向Safari中加入WebRTC支持以来已经有一年多时间了，我之前关于具体实现的文章没有反映其中的一些更新。更重要的是，考虑到其中的不同和限制，对Safari来说，关于如何更好地开发WebRTC app还存在许多问题。在Cluecon上我与Chad Phillips交流，最终谈到了他在Safari上使WebRTC工作的艰难经历。对此他有许多不错的建议。 Chad经常发布一些开源代码并且也是FreeSWTICH产品的贡献者。自从2015年，他就从事WebRTC的开发工作。最近他安装了Moxiemeet，一个用来进行在线试验的视频会议平台，他是此平台的CTO，并且在本文中发表了很多想法。 2017年6月，Apple成为了最后一个发布WebRTC支持的主要供应商，为平台之间相互使用铺平了道路。但是，一年之后，对于开发者来说，关于如何集成他们的WebRTC app和Safari/iOS的指导教程依然很少。除了一些由WebKit团队发布的文章，还有StackOverflow上的一些问题，我没有看到太多对此方面的支持。本文尝试填充它们之间的间隙。我花了几个月时间来努力的使一个复杂

使用getDisplayMedia实现在Chrome中屏幕共享

原文标题：Chrome Screensharing Blues – preparing for getDisplayMedia 作者: “Philipp Hancke“ 使用getDisplayMedia实现在Chrome中屏幕共享 Chrome网上商店已经决定停止允许Chrome扩展部件的内联安装，这对WebRTC应用有着极大的影响，因为目前在Chrome中屏幕共享需要扩展部件。GetDisplayMedia API 能不能解决这个问题呢？ Chrome中屏幕共享当Chrome33中引入屏幕共享时，需要扩展部件来解决安全问题。这比之前的做法更好，之前的做法是将这种能力置于一个标志之后，这个标志允许用户根据需求修改。自2003年之后，Chrome没有做出太大改变。需要扩展部件增加了与屏幕共享过程的摩擦，但是由于内联安装，这种摩擦被最大限度的减小了: 1.用户点击按钮开始屏幕共享。 2.Web应用检测Chrome并确定出未安装的扩展部件。 3.Web应用触发内联安装API,获得成功回调。 4.Chrome桌面、窗口、标签共享选择器弹出，允许用户选择共享哪部分。关于全部实现请查看ge

WebRTC对等连接（一）：点对点通信

原文标题：Learning WebRTC peer-to-peer communication, part 1 作者:Swizec Teller WebRTC对等通信在之前的工作中，我们使用了区块链技术来实时共享客户端模块，本次我们用RTCPeerConnection建立了一个对等连接。点击此处查看GitHub代码自iOS11之后，WebRTC可以在所有浏览器中工作了，用户可以实时使用。点击此处运行代码我嵌入了一个HTML标签，浏览器的安全保护机制不允许这样做。 WebRTC提供了三种API: 从设备中获取音频和视频(mediastream) 建立了一个对等连接(RTCPeerConnection) 传递任意数据(RTCDataChannel) 本文使用了mediastream和PeerConnection. 无服务器的实时对等连接通信客户端按照如下步骤在同一网页不同客户端之间建立连接 1.实例化两个RTCPeerConnection对象。 2.添加彼此为ICE candidates。 3.对第一个对象使用createoffer建立请求。 4.对两个对象设置本地/远程&#8

WebRTC的问题以及如何debug-4

作者：Lee Sylvester（原文链接）翻译：刘通原标题：WebRTC Issues and How to Debug Them 前文链接：WebRTC的问题以及如何debug-1，WebRTC的问题以及如何debug-2，WebRTC的问题以及如何debug-3 测试设备连接性我们可以以清晰可读的形式来描述设备网络和媒体的功能。Google提供了一个测试工具，你可以在https://test.webrtc.org/上面使用它。只需点击“Start”按钮即可以获取机器的完整描述。Xirsys在其仪表板中提供了相同的工具，但其被配置为使用STUN和TURN服务器而不是Google的服务器。 WebRTC Internals 现在，你已经完成了上文中所讲的所有内容，但仍然无法弄清楚为什么还是无法建立连接？值得庆幸的是，Chrome提供了额外的工具来帮助调试你的连接性，以及一些图表来帮助你。这些都是通过Chrome的WebRTC Internal功能实现的。想要使用WebRTC Internal的话，只需要打开一个新的标签页并输入以下协议和URL就可以了：chro

自动播放限制与WebRTC-2

作者：Dag-Inge Aas，webrtcHacks（原文链接）翻译：刘通原标题：Autoplay restrictions and WebRTC (Dag-Inge Aas) 前文链接：自动播放限制与WebRTC-1 不只是关于<audio>和<video> 现在事实证明，新的自动播放政策更改会影响<audio>和<video>标签以外的其他内容。WebRTC中常见的UX模式是向用户提供有关麦克风输入音量的反馈。为此，需要使用AudioContext来分析音频，并且AudioContext采用MediaStream将其波形以桶的形式输出。不会有音频通过扬声器播放，但由于某些原因，因为AudioContext从理论上讲允许你输出音频，所以连分析音频也是不可以的。这个问题首先在12月份报告给了Webkit，六天之后就已经添加了补丁。在页面已经捕获音频和视频的情况下，这个补丁将会允许AudioContext工作。那么既然已经有补丁了，那本文的意义又是什么呢？事实证明，Chrome犯了与Safari一样的错误。尽管这会影响许多WebR

自动播放限制与WebRTC-1

作者：Dag-Inge Aas，webrtcHacks（原文链接）翻译：刘通原标题：Autoplay restrictions and WebRTC (Dag-Inge Aas) 浏览器不希望你听到不会的东西，所以自动播放政策把媒体静音了。这可能成为WebRTC应用的一个问题。图片来源：PetrFromMoravia。如果你正在阅读本文，那么我猜测你很有可能在Safari 11以后版本和Chrome 66以后版本中遇到了与WebRTC应用程序有关的奇怪问题。这个问题可能体现在你的界面不再播放声音（来电通话的声音），你的音频波形显示器不再工作，或者你的WebRTC应用不播放任何由远端传来的声音。目前，这个bug影响了WebRTC很多主要力量，如Jitsi，Tokbox，appear.in，Twilio，Webex等等。有趣的是，Google的Meet和Chromebox会议似乎也受到了影响。我们问题的来源是自动播放政策的变化。在这篇博文中，我会告诉你都发生了什么变化，它们是如何影响WebRTC的，以及如何在应用程序中解决这个问题。首先让我们来看看，都发生了什么变化。发生了什么

Search Results for: getUserMedia – Page 3