以最小延迟解码来自Icecast的HTTP音频流

Question

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

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

当前解决方案：我使用ReadableStreams API解码（使用Web Audio API的decodeAudioData）并通过将解码数据路由到音频上下文目的地（内部扬声器）来播放数据块。这样可以显着降低延迟。

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

如果我想至少让它在Safari和FF上工作，是否有任何变通方法？ decodeAudioData的实现在Chrome和Safari上实际上是不同的，这样一个可以在部分MP3上运行而另一个不在吗？

Answer 1

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

• opus-stream-decoder已准备就绪
• fetch-stream-audio是一个非维护的POC演示，应该指向正确的方向。

Answer 2

Don't use Icecast if you need sub-second latency!

Don't use Icecast if you need sub-10-second latency and don't have full control over the whole chain of software and network!

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

您解释的内容听起来像是您真的应该考虑设计为低延迟的内容，例如web-RTC。

如果你认为你真的应该使用Icecast，请解释原因。因为你的问题不然。我需要更多的Icecast使用，毕竟我是它的维护者，但它的应用应该是有意义的。

Answer 3

我正在使用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音频，只要您解决了任何跨源问题。