Chrome网上商店已决定停止允许Chrome扩展程序的内联安装。这对WebRTC应用程序有相当大的影响，因为Chrome中的屏幕共享目前还需要扩展程序。getDisplayMedia能来解决这个问题吗？本文来自appear.in的WebRTC工程师Philipp Hancke，LiveVideoStack对文章进行了摘译。
文 / Philipp Hancke
译 / 元宝
原文 / https://webrtchacks.com/chrome-screensharing-getdisplaymedia/
在Chrome中共享屏幕
当在Chrome 33中引入屏幕共享时，需要通过扩展来实现，以解决安全问题。这比之前将这种能力置于标志之后的体验要好。
Chrome自2013年以来没有多大改变。要求扩展会增加共享过程的摩擦，但是由于内联安装，可以最大限度地减少这种摩擦：
用户点击一个按钮开始屏幕共享
Web应用程序检测到Chrome并确定未安装所需的扩展
Web应用程序触发内联安装API，获取成功回调
Chrome桌面/窗口/标签共享选择器弹出，允许用户选择要共享的内容。
有关完整实现，请参阅getScreenMedia示例扩展。
分享选择器是这里的关键元素。在没有Webstore安全网的情况下暴露给Web平台足够安全吗？
标签共享是此设置中特别关注的问题，因为它会分解跨域沙盒
在Firefox中共享屏幕
Firefox采取了不同的方法，将网站列入允许访问该API的白名单。进入该白名单的过程涉及向Mozilla询问并显示您的网站有服务条款和隐私政策。你也可以通过扩展来修改这个白名单。在Firefox 52中删除了对这个白名单的需求，允许任何安全来源使用屏幕共享。它不使用更新的getDisplayMedia的API，我们稍后将讨论它，但实现几乎完全相同：
这将被更新以最终支持该规范。
getDisplayMedia API
The W3C has been working on standardizing the API for Screen Capture. It is relatively simple and promise-based like getUserMedia :
W3C一直致力于标准化屏幕捕获API。简单，基于承诺的管理，如getUserMedia：
Microsoft Edge 今年早些时候刚刚使用此API 提供了屏幕共享。这里的用户体验做得非常好，在用户共享的显示器或窗口中添加了一个黄色边框，确保用户始终了解共享的内容。
Chrome扩展程序为您带来变化
根据经验，appear.in screen sharing extension的工作方式如上所述，它的安装非常成功。绝大多数用户都是通过内嵌安装进行安装的，因此可能会在2014年之前我们从未更新过Chrome浏览器商店中的扩展屏幕截图。
现在，Chrome网上商店正在删除内联安装，如本博文中所述。如果我正确地理解了声明，则会在另一个选项卡中打开Chrome WebStore。这会使得检测用户何时从Web应用程序安装扩展程序相当困难。帖子中的时间表如下：
6月12日，新的扩展程序不再进行内联安装。没有通知期限。
内联安装将于9月12日停用。三个月的通知期。
抱怨
这有几件事是错误的。我甚至没有谈论Google Hangouts/Meet，完全避免了其他人必须通过使用内置扩展来应对的用户体验。
我预计Chrome Webstore团队会对此进行一些推广。出现.in扩展名有超过一百万用户，使其成为最大的屏幕分享扩展之一。我们的用户与我们的网站建立了现有的信任关系 - 通常我们可以传输他们的网络摄像头和麦克风。使用这种建立的信任关系进行内联安装可以说比从Chrome网上应用店安装更安全。我们还必须要求WebStore开发人员支持不止一次地拆除由数百名用户安装的我们的扩展程序的非法复制副本。
Google的WebRTC伙伴们也提出了一个很好的建议。
转到getDisplayMedia
Chrome的前进道路是发布 getDisplayMedia API。消息传出后不久， “intent to ship”便公布了。但是，鉴于Chrome的发布周期，这将需要几周的时间。这在安全性和用户体验评论方面是一个不小的变化，这使得在9月12日截止日期之前发生这种情况令人怀疑。离Chrome 69在9月12日的稳定版本的节点是不到一个月的时间了。
Chrome中的情况比较复杂，因为它目前允许标签共享以及限制用户可以选择的显示面。由Chrome支持的音频输出共享也不由getDisplayMedia指定 。
如何准备Chrome中的最终更改
支持getDisplayMedia的实际代码更改简单。调用此API通常会进入到与使用Firefox的 getUserMedia调用和 mediaSource 参数完全相同的位置。通过检查getDisplayMedia的存在并在可用时选择它，使得特征检测很容易完成：
目前还不清楚如何指定捕获帧速率。在MediaStreamTrack上使用applyConstraints返回对getUserMedia的工作，并且可能会继续为getDisplayMedia执行此操作：
有关更多详情，请参阅规格问题。不幸的是，adapter.js无法真正地获取 getDisplayMedia，因为与扩展的通信对于每个扩展都略有不同。
我期待看看Google的WebRTC人员是否可以影响到内嵌扩展删除的最后期限或 及时发送 getDisplayMedia。Web平台的构建有时可能会变得混乱，但最终通常会产生最好的结果。我们期待着这一次的结束，并将非常高兴地向我们的扩展挥手告别。
LiveVideoStack Meet | 深圳
多媒体开发新趋势
2018年初始，音视频技术生态并不平静，Codec争夺愈加激烈，新一代标准的挑战一浪高过一浪；WebRTC的定版也为打通浏览器、移动端乃至IoT带来了机会；此外AI、区块链技术的兴起，催化着与多媒体领域的化学反应。新技术正在对安防、视频会议、社交、教育、金融等行业产生影响，这无疑对多媒体开发者带来了新的挑战。
7月14日·深圳 | LiveVideoStack携手腾讯、北京大学、魅族、即构科技、又拍云等技术大咖一同探索多媒体开发新趋势，探讨开发难点、技术转型，展现新技术在音视频领域的最新、最佳实践。
点击【阅读原文】或扫描图中二维码，了解详细信息，快来报名吧！