WebRTC技术（语音和视频通话）之所以不错，是因为它直接内置于Web中，这当然是WebRTC的完美选择。 但是，当WebRTC的需求与使用浏览器的一般要求背道而驰时，有时Web会很麻烦。 最后一个示例是音频/视频的自动播放（以下称为“自动播放”），当许多用户突然失去声音时。 webrtcHacks的前作者-Dag
-Inge Aas-亲自遇到了此问题。 以下是他的想法：浏览器在自动播放方面的期望，Chrome 66+的最新变化以及如何忍受这些限制的一些技巧。
浏览器不想听到邪恶的声音，因此自动播放政客会关闭任何媒体中的声音。 对于WebRTC应用程序，这可能是个问题。如果您阅读此书，则很有可能在Safari 11+和Chrome 66+浏览器中遇到了一个奇怪的错误。 我们正在谈论突然变得听不见的界面声音（例如，来电信号），或者音频可视化器损坏，或者谈论如何不听到对话者。
目前，该错误已影响几乎所有流行的WebRTC播放器。 这很有趣，但是看起来来自Google和Chromebox的会议开会也会受到影响。
万恶之源：自动播放政策的变化。 在本文中，我将讨论创新，创新与WebRTC的关系以及如何在您的应用程序中进行处理。
年度错误：未捕获的错误：不允许启动AudioContext。 用户在页面上进行手势操作后，必须恢复（或创建）它。 https://goo.gl/7K7WLu变化
这一切始于2007年，当时iPhone和iOS出现了。 如果您过去使用过iOS的Safari，则可能已经注意到Safari需要用户参与
才能播放带声音的<audio>和<video>元素 。 后来，当iOS 10允许视频元素自动播放但没有声音时，此要求稍有缓解。 这已成为WebRTC的问题，因为 <video>元素必须“看到”和“听到”媒体流。 在WebRTC的背景下，让视频自动无声启动是没有用的，因为在视频通话期间，您需要默认情况下听到对话者的声音，而不是按“播放”来执行此操作。 尽管如此，很少有WebRTC开发人员参与iOS的Safari，因为该平台
直到最近才支持WebRTC。 在iOS 11.之前
当我测试针对iOS的视频通话的最新（当时）工作实现时，我首先遇到了一个错误。 令我惊讶的是，它并不起作用，而我并不孤单。 Github
用户 kylemcdonald 报告了 iOS上
的 getUserMedia错误 。 解决办法？ 向video
元素添加一个
新的 playsinline
属性 ，该
属性允许视频播放声音。 不幸的是，开发人员在原始文章中并未提及有关在Safari中更改自动播放的
WebRTC ，但在发布之前，他们仍然单独
撰写了有关WebRTC的文章。 本文介绍了有关
MediaStreams和音频播放的以下内容：
- 如果网页已使用摄像头/麦克风，则使用MediaStream的媒体将自动播放；
- 如果网页已经在播放声音，则使用MediaStream的媒体将自动播放。 为了开始声音回放，仍然需要用户参与。
因此，本文档没有提及
playinline ，但是，如果
将这两个声明结合在一起，则可以理解如何使WebRTC应用程序在iOS的Safari中工作。
为什么自动播放完全受限制？
最初，他们希望保护用户免受不必要的流量费用。 在2007年，数据传输非常昂贵（并且在世界大部分地区仍然如此），并且只有少数几个站点适用于移动设备。 此外，自动播放声音一直是并且仍然是网络上最令人讨厌的东西。 因此，要播放（和下载）视频，需要用户采取行动； 这样可以确保用户知道发生了什么。
然后是GIF。 GIF只是<img>中的动画，因此它们不需要用户的“许可”。 但是，它们
可能很困难 ，因此给移动Internet用户带来痛苦。 视频可节省流量，但需要同意下载-因此网页继续使用GIF。 Safari在关闭声音的情况下自动播放时，iOS 10中的所有内容都发生了变化。 从那时起，负载优化就是允许的视频和三分钟gif消失的问题。
桌面浏览器中的自动播放限制
如果您寻找如何停止自动播放声音，您会发现很多方法。 最近，新闻通讯社发现，当页面加载后使用REALLY LOUD音频时，用户会在网站上花费更多时间并点击广告。 当然，这是值得的，但他们仍然会这样做。 因此，桌面浏览器遵循Safari的示例，并禁止自动播放声音-尤其是Chrome浏览器，该浏览器在版本66中推出了
新的自动播放策略 。
但是，Chrome突然转向原始的
媒体参与度索引 （MEI）。
媒体参与度指数（MEI）
MEI是Chrome衡量用户允许在页面上自动播放的意愿的方式； 此索引取决于页面上的先前行为。 您可以在此处看到外观：
chrome：// media-engagement / 。 对于每个用户个人资料，MEI都是分开考虑的，并且以隐身模式工作（因此，对于开发人员来说，在推出量产之前很难用MEI值为零测试页面）。 有谁猜猜接下来会发生什么？
chrome内部页面的屏幕截图：//媒体互动/（来源： developers.google.com/web/updates/2017/09/autoplay-policy-changes ）不仅<audio>和<video>
事实证明，新策略不仅影响<audio>和<video>标签。 WebRTC的一种流行的UX模式是向用户
显示麦克风的音量级别 。 为此，
通过AudioContext分析声音，该声音接受
MediaStream并以直方图的形式输出其信号。 在这种情况下，声音不会播放，但是由于
AudioContext ，音频分析仍然受阻，从理论上讲，它可以让您输出声音。
麦克风测试示例该问题最初是
在12月在
Webkit Bug跟踪器中报告的，六天后，
Webkit收到了
修复程序 。 更正？ 如果页面已在接收音频和视频，请不要阻止
AudioContext 。
那么，为什么还要阅读本文呢？ 事实证明，
Chrome犯了与Safari相同的错误 。 尽管这影响了许多WebRTC服务，但Google对此保持沉默。 已经进行了很多尝试，让他们
就自动播放对WebRTC的影响
发表公开声明 ，但这尚未发生。
MEI值会干扰测试
我们是怎么陷入困境的？ 当然，即使在影响每个用户的Chrome 66更改之前，开发人员也必须测试
AudioContext 。 MEI来了； 您知道，与页面的频繁交互会给您带来更高的MEI，并且由于长期以来一直允许播放和分析音频，因此开发人员遇到错误的可能性较小。 是的，隐身模式无济于事，因为MEI继续在此被计算在内。 只有使用新帐户启动Chrome才能检测到错误-即使是
经验丰富的Google质量检查工程师也可以轻易忘记这一事实。
浏览器制造商应该怎么做？
核心功能的更改很难以正确的方式实现。 Chrome浏览器发布了许多自动播放策略更改，但都与WebRTC或
MediaStreams不相关。 显然，被遗忘的
Permissions API没有更新，因此开发人员无法测试自定义操作的请求。 另外，如果该页面已经可以使用摄像头/麦克风工作（如Safari一样），则可以允许
AudioContext输出声音，但它看起来更像是骇客而不是解决方案。 当不使用
getUserMedia时，在其他声音分析情况下也无济于事。
对于浏览器制造商而言，一种增强的具体解决方案是允许
媒体权限影响MEI。 如果用户不断访问他的摄像头和麦克风，则可以合理地假设该网页可以被信任，足以产生声音而无需采取其他操作，无论该网页是否与摄像头/麦克风一起工作。 最后，用户认为您不会在无知的情况下与数百万人共享他的相机和麦克风。 在这种情况下，播放界面声音是最少的问题。
如何帮助您的申请
幸运的是，有一些技巧可以帮助您。 这是我们在iOS的Safari中遇到问题时向Confrere添加的内容的列表。
添加了playinline
要将声音返回到视频，请将
playsinline属性添加到video元素。 该属性已被很好地证明，可以在Safari和Chrome中使用，并且在其他浏览器中没有副作用。
用户动作
要“治愈”音频可视化器，只需添加自定义动作。 我们很幸运，因为我们可以在测试屏幕中添加（并添加）很多步骤，这意味着用户的明确参与。 您可能不太幸运。 在Google进行修复之前，没有其他方法可以让用户参与。
无法修复界面声音
目前这是不可能的。 有人试图创建一个可在应用程序中重用的
AudioContext ，并且所有声音都通过它，但是我尚未测试此方法。 Safari稍微简单一些：如果您已经使用相机/麦克风，则可以播放传入消息和呼叫的声音。 但我认为您不希望仅使用摄像头/麦克风来不断提醒用户来电。
如您所见，在找到长期解决方案之前，已经有解决问题的方法。 是的，不要忘记
订阅该错误以接收更新。