我们需要用无插件解决方案替换我们的 NPAPI 浏览器插件。我们有第 3 方输入设备，以 Opus“帧”的形式为我们提供现场音频。我们使用二进制 WebSockets 将这些帧传输到浏览器；然后，将数据转发到我们的 NPAPI 插件进行解码和音频播放。看图片。

鉴于这些要求，我们应该采取什么方法将 NPAPI 插件替换为类似 HTML5 的解决方案？

1. 将端到端延迟时间降至不超过 3-5 秒(假设往返网络延迟时间为 200 毫秒)。
2. 提供一种应用音频过滤器的方法(客户端/浏览器端)

使用 html5 音频标签似乎会引入大量延迟，因为各种浏览器在开始播放之前需要一定量的缓冲(15-30 秒的音频)。我们了解 Opus 可能会或可能不会在所有浏览器上受支持。如果需要(虽然我们不想减少带宽)，我们可以在将数据发送到浏览器之前将 Opus 帧封装到 Web 服务中的 Ogg 容器中。查看来自 html5rocks 的演示之一，HTML5 Audio Playground ，似乎 #2 是可能的。

如果这里不适合提出此类设计问题，请推荐其他可能更合适的论坛/群组。

感谢您提供的任何帮助或建议。

最佳答案

我也有类似的情况。我一直在使用 WebSockets 和 Media Source Extensions 在 Google Chrome 中播放 MP3 feed，延迟很小，但是当与 MSE 一起使用时，其他一些浏览器不支持 MP3 编解码器。事实证明，大多数浏览器，至少是 Chrome、Firefox、Opera 和 Edge，都可以使用 MSE native 播放 Opus，前提是它被正确封装在 MP4 或 WebM 容器中。

在 Ogg 中打包 Opus 非常简单，我 converted some code I found from JavaScript to C# .

在 WebM 中打包 Opus 稍微复杂一些。我写了this C# code从头开始，基于 WebM/Matroska和 EBML眼镜。当通过 HTTP 提供服务时，它可以在 Chrome 和 Firefox 中正常播放，但 VLC 似乎无法通过 HTTP 流式传输 Opus/WebM。至少 Chrome 要求时间顺序从 0 开始，所以在服务器端打包不是一个好的选择，因为这需要修改分发系统。

最后我ported this to JavaScript因此每个客户端都可以在 WebM 中打包 Opus 帧，时间戳从 0 开始正确。这会在 Chrome 和 Firefox 中启动实时流，而无需在一秒钟内进行预缓冲。请注意，我在传入的 websocket 数据包上使用了 4 字节的 header ，因为现有的分发系统不保留数据包边界(它是为 MP3 流构建的)。如果您在每个作品帧中使用一个 websocket 帧并在每个帧中使用固定数量的样本，您可以删除此 header 。

现在剩下的就是为 IE11、Safari 和一些较旧的移动浏览器寻找解决方案...

关于javascript - HTML5 : Playing live Opus audio frames without browser plug-in，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28326774/