1

我正在使用 Icecast 从内部麦克风流式传输实时音频，并希望听众的延迟尽可能小。

一个天真的解决方案是简单地访问http://myhostname:8000/my_mountpoint以获取流，但<audio>标签在播放之前会进行内部缓冲，并导致相当高的延迟。

当前解决方案：我使用ReadableStreamsAPI来解码（使用decodeAudioDataWeb Audio API）并通过将解码后的数据路由到音频上下文目标（内部扬声器）来播放数据块。这有效并显着降低了延迟。

问题：这个流 API 虽然是实验性的，但在技术上应该可以在最新的 Chrome、Safari、Opera、FF 上运行（在设置特定标志之后）。decodeAudioData但是，除了 Chrome 和 Opera 之外，我在所有其他浏览器中都遇到了问题。我认为 FF 和 Safari 无法解码部分 MP3 数据，因为当我开始流式传输时，我通常会听到扬声器的短暂激活。在 Safari 上，decodeAudioData从不调用成功的回调，FF 只是说EncodingError: The given encoding is not supported.

如果我想至少让它在 Safari 和 FF 上工作，有什么解决方法吗？Chrome 和 Safari 上的decodeAudioData实现实际上是否不同，以至于一个可以在部分 MP3 上工作而另一个不能？

4

3 回答 3

2

如果您需要亚秒级延迟，请不要使用 Icecast！

如果您需要低于 10 秒的延迟并且无法完全控制整个软件和网络链，请不要使用 Icecast！

是的，这是一个答案，而不是评论。Icecast 不是为此类用例设计的。它设计用于通过 HTTP 以非同步方式进行 1 对 n 批量数据广播。

你所解释的听起来你真的应该考虑一些被设计成低延迟的东西，比如 web-RTC。

如果您认为您真的应该使用 Icecast，请解释原因。因为你的问题不一样。我完全支持更多的 Icecast 使用，毕竟我是它的维护者，但它的应用应该是有意义的。

于 2019-01-11T13:54:46.183 回答
0

正如@Brad 提到的，Opus 非常适合低延迟。我编写了一个可与 Streams 一起使用的低延迟 WASM Opus 解码器，并开始了另一个演示，演示如何使用以下命令播放部分文件decodeAudioData()：

于 2019-04-05T18:09:43.217 回答
0

我正在使用 Icecast 从内部麦克风流式传输实时音频，并希望听众的延迟尽可能小。

您的设置存在一些问题，可能会阻止可能的最低延迟：

  • HTTP Progressive（Icecast 和类似使用的流式传输类型）在 TCP 上运行，这是一种可靠的传输方式。如果数据包丢失，则在将数据重新传输到客户端之前，在将数据传递到浏览器之前会有一些延迟时间。这样可以确保按顺序听到每一位音频，但可能会导致延迟。对于低延迟，通常使用 UDP 数据包，以便可以跳过而不是等待任何丢失的数据包，从而导致故障，但客户端会降低延迟。

  • MP3 不是低延迟的出色编解码器。有更好的编解码器，例如 Opus，它们效率更高并且可以生成更小的片段。

  • 如您所见，默认情况下，客户端在通过 HTTP 流式传输时会缓冲更多。

但是，在理想情况下，我使用自定义服务器在 Chrome 中以小于 250 毫秒的延迟通过 HTTP Progressive 进行流式传输。我敢打赌，如果您关闭服务器端缓冲并使用不同的编解码器，您可以从 Icecast 获得类似的性能。

但是，除了 Chrome 和 Opera，我在所有其他浏览器中都遇到了 decodeAudioData 问题。我的信念是 FF 和 Safari 无法解码部分 MP3 数据

是的，decodeAudioData()用于解码整个文件。您将很难以样本准确的方式解码任意分段的块。

幸运的是，有一种方法可以做你想做的事…… MediaSource Extensions。

https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API

基本上，您可以使用完全相同的 ReadableStream 接口并将数据推送到 SourceBuffer 以最终播放普通<audio>标签。这适用于来自 Icecast 和类似服务器的普通 MP3 音频，前提是您已经解决了任何跨域问题。

于 2019-01-11T21:56:46.713 回答