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

WebRTC API深度解析——getUserMedia

WebRTC由多个执行不同功能以建立媒体会话的API组成。我们将在本系列中回顾WebRTC的那些API。首先，我们从getUserMedia开始。getUserMedia使浏览器与媒体设备（即麦克风和摄像头）进行交互。调用getUserMedia时，它会提示是否允许访问媒体设备。该提示仅在安全环境中可用，比如本地主机和在HTTPS下提供服务的站点。调用getUserMedia API 最初，我们可以在navigator.getUserMedia上找到getUserMedia。尽管在某些浏览器上这个操作仍然可行，我们不建议这样做。因为它被标记为已弃用。我们的首选选项是navigator.mediaDevices.getUserMedia。 getUserMedia的基本语法为： navigator.mediaDevices.getUserMedia(constraints) 默认情况下，此代码会返回一个promise，该promise会被解析为媒体流。用户可以直接使用它，也可以与async / await一起使用。 //getUserMedia using raw promises

getUserMedia()音频约束

作者：addpipe.com（原文链接）翻译：刘通原标题：Supported Audio Constraints in getUserMedia() 相关文章：getUserMedia()视频约束 getUserMedia()音频约束媒体捕捉和流规范管理着所有浏览器应该实现的跨浏览器音频选项，并且在最新的候选推荐标准中，定义了不少的音频约束。下面是完整的清单，还附有说明和我对数字声音工作原理的解释： # sampleRate：指定一个所需的采样率，不确定它应该被用作编码设置还是作为硬件要求，越高越好（比如CD的采样率就是44000 samples/s或44kHz）。 # sampleSize：每个采样点大小的位数，越高越好（CD的采样大小为16 bits/sample） # volume：从0（静音）到1（最大音量）取值，被用作每个样本值的乘数 # echoCancellation：是否使用回声消除来尝试去除通过麦克风回传到扬声器的音频 # autoGainControl：是否要修改麦克风的输入音量 # noiseSuppression：是否尝试去除音频信号中的背景噪声 # l

getUserMedia()视频约束

作者：addpipe.com（原文链接）翻译：刘通原标题：getUserMedia() Video Constraints WebRTC在持续不断地发展，它其中最广为人知的一个函数就是getUserMedia()。有了它，你就可以访问设备的摄像头和麦克风，并且可以请求视频流，音频流或者两者同时请求。在本篇文章中，我们会聚焦于通过getUserMedia()请求视频流时可用的视频约束。 MediaStreamConstraints getUserMedia()函数仅接收一个参数，MediaStreamConstraints对象用于指定要请求的轨道类型（音频，视频或二者）以及（可选）每个轨道的任何要求。下面是一个基本的示例，展示了这个对象是如何发送给更新的、基于promise的getUserMedia(): 约束项可以具有下面这两个属性中的一个或两个： # video—表示是否需要视频轨道

getUserMedia()出现的常见错误

作者：Pipe（原文链接）翻译：刘通原标题：Common getUserMedia() Errors 在你的getUserMedia()开始运行的那一瞬间，就会遇到各种各样的错误： 1. 用户没有摄像头，只有一个麦克风 2. 用户（不小心地）拒绝了浏览器的使用摄像头请求 3. 用户在你的getUserMedia()代码已经初始化之后才将摄像头/麦克风插到电脑上 4. 媒体设备已经被其他的应用所占用了 5. 只针对Firefox：设备已经被Firefox浏览器的其他标签页所占用了为了解决这些状况，在管

使用getUserMedia在安卓设备上录屏

作者：Paul Kinlan（原文链接）翻译：刘通我一直坚信在几乎所有的科技报告中展示直播demo是一件非常好的事情。它给人一种真切的感觉，也不是很难实现。在实现过程中，肯能会遇到很多的困难，比如说Demo出错了，网络连接突然断掉，代码中的错误显现出来，服务配额问题等等。为了解决实时Demo中潜在的这些问题，我经常会对Demo实现进行屏幕录制，展示如何使用它。它实际上就是想要进行现场展示的demo，只不过是事先录好放在了幻灯片里而已。这会让我将精力更好地集中在输出上，而不是放在编写代码或者担心demo会出错上。当然这个办法不适用于所有人，但是对我来说是十分不错的。为了完成屏幕录制，我已经创建了一些工具来帮助屏幕录制，有设备框架的屏幕录制，以及一个整洁的网页应用可以将一个设备框

关于getUserMedia提示窗的讨论

Philipp Hancke 又来死磕数据了。。。这次我们来探讨一下从调用getUserMedia到成功回调之间的时间。为什么这点这么重要值得单独拿出来讨论呢？绝大多数情况中这是用户与WebRTC所进行的第一次交互行为。而且就像我之前的同时Lynn Fisher在一篇超精彩的博客中所写到的那样，“为用户做好这次交互的准备是十分重要的，并且对了解每个浏览器的quirks模式（怪异模式）也同样重要”。当一个网页调用getUserMedia的时候，这时浏览器就会特别地弹出提示窗口询问用户是否授权网页使用摄像头和麦克风。在Chrome和Firefox上，浏览器可以记住这项授权并且一直保留已授权的状态。我们先暂时忽略失败的情况。因为Firefox和Chrome在这点上有着迥然的UI，所以我们需要在仔细观察前把数据分一下类：同样也可以在Firefox中用这个查询方法。进一步向分开Chrome和Opera

在 WebRTC 应用中，通过 Capture Handle 识别共享标签页

我一直不太赞同在演示的同时共享屏幕。大家进入视频会议应用程序，跟大家打招呼，然后开始分享自己在另一个标签或窗口的ppt。那你要看什么呢？ppt吗？但我更想面对观众并与其互动。确实，有些工具可以让你预览所分享的内容，但你仍然需要来回滑动每张ppt。理应采用一个更好的办法，那就是capture handle。 Capture Handle是origin trial中一个用于屏幕共享（getDisplayMedia）的新的API。它可以让屏幕共享app识别，与用户选择的标签相协调。 Elad Alon是一位对接webrtc.org团队的谷歌员工。他负责整理capture handle规范，并推动其通过W3C的标准化过程。在这篇文章中，Elad向我们介绍了capture handle，并列举了一些关于防止“镜室（hall of mirrors）效应”的例子。另外他也回答了我在文章开头所说，屏幕共享时切换幻灯片的问题。capture handle也有很多其他用途。下面会对此进行详述。在过去的一年里，屏幕共享逐渐成为大家生活中必不可少的一部分。其原因自然不言而喻。对于基于Web的产品，该操作

FaceTime终直面WebRTC：deep dive实现（上）

在今年的WWDC演讲中，苹果宣布FaceTime在web浏览器中可用，同时支持Android和Windows用户端。我们上次研究FaceTime还是六年前（详见此篇文章），现在是时候更新了。FaceTime肯定使用了WebRTC，这篇文章中我会给大家解释为什么很大程度上能确定它使用了WebRTC。摘要 FaceTime Web确实在媒体服务中使用了WebRTC，并使用Insertable Streams API进行端对端加密。它还使用了一种有趣的方法来避免simulcast。感谢Dag-Inge Aas抽出时间组织了一次会议，帮助我利用必要数据进行分析。那之后我的工具更加实用了。所以除了WebRTC内部转储之外，我还从Chrome日志中获取了RTP转储和SCTP转储，以及一些进行端对端加密（E2EE）的JavaScript。加入会议当我把邀请链接粘贴到浏览器上时，它要求我输入名字，然后加入会话。但接入需要由发起会话的人接受才行。另外到目前为止，好像还不能直接从web上发起会话。设备测试急需能显示音频状态的仪器，我们实在要花太多时间才能弄清楚，是谁的麦克风没有正常工作。在由W

MediaStreamTrack的Insertable streams

本文中MediaStreamTrack主要指可以操作或用于生成新内容的媒体流。背景在Media Capture和Streams API中，MediaStreamTrack接口代表流中的单媒体轨道，通常是音频或视频轨道，但也可能存在其他轨道类型。MediaStream对象由零个或多个MediaStreamTrack对象组成，代表各类音频或视频轨道。每个MediaStreamTrack可以有一个或多个通道。通道是媒体流的最小单位。比如与给定扬声器相关的音频信号，以及立体声音频轨道中的左声道或右声道。什么是MediaStreamTrack的insertable stream？ MediaStreamTrac的insertable stream背后的核心思想是将MediaStreamTrack的内容作为（WHATWG Streams API所定义的）流集合公开。这些流经操作可以用于引入新的组件。授予开发者对视频（或音频）流的直接访问权，允许他们直接对流进行修改。相比之下，用传统方法实现同样的视频操作任务，需要开发者使用<canvas>元素这样的中介。（关于上述过程的细节，请

开源十年，WebRTC 的现状与未来

本文首发于 InfoQ，由声网 Agora 开发者社区与 InfoQ 联合策划，并由 InfoQ 审校。 WebRTC 在今年 1 月被 W3C 和 IETF 发布为正式标准。从开源至今，十年的时间，倾注了众多开发者的贡献。本文由 Google WebRTC 产品经理 Huib Kleinhout 基于在由声网举办的 RTE 大会上的分享汇总整理，并增加了其近期对于 WebRTC 前景的看法。 2020 年，WebRTC 发生了很多变化。WebRTC 其实就是一个客户端库。大家都知道它是开源的。尽管 Google 大力地在支持 WebRTC，但社区的力量同样功不可没。 WebRTC 对于桌面平台、浏览器端实现音视频交互来讲十分重要。因为在你可以再浏览器上运行任何一种服务，并进行安全检查，无需安装任何应用。这是此前开发者使用该开源库的主要方式。但 2020 年，浏览器的发展方向变了。首先讲讲 Microsoft，它将自研的浏览器引擎替换为基于 Chromium 的引擎，同时它们也成为了 WebRTC 的积极贡献者。Microsoft 贡献之一是 perfect negotiation

Search Results for: getUserMedia