audio-streaming - 基于 HTTP/TCP 的低延迟 Opus？

Question

试图找到一种合适的技术/容器来通过 HTTP/TCP 流式传输实时低延迟 Opus？

Ogg 容器当然是显而易见的选择。但是，对于低比特率 Opus（<50 字节/帧），如果需要低延迟流式传输，开销就会变得巨大。例如，对于 20 ms 块中的 Opus @ 8 kbps，如果每个 Ogg 页中仅放置一帧，则开销将变为 58%。

Answer 1

由于 Ogg 的设计方式，OggOpus 绝对不适合低延迟流式传输。我假设您已经对此有所了解，因为您提到了页面，但为了 StackOverflow 的好处：Opus 数据包被安排到 Ogg 页面中，每个页面通常包含 255 个 Opus 数据包。每个 Opus 数据包通常是 20 毫秒的音频。每个 Ogg 页面都包含一个校验和以验证其内容，并且在计算出校验和之前，该页面无法在线发送，因此直到整个页面都被填满。20ms * 255 个数据包 = 大约 5 秒的音频必须在音频可以通过线路发送之前被缓冲，从用户的角度来看，这是一个很大的延迟。

确实，您可以每页发送更少的数据包，但这会导致更高的数据开销，因为您需要创建更多的 ogg 页面，并且在低级别（每页只有几个数据包）开销变得如此之大，以至于几乎抵消了首先是音频压缩。

WebRTC 是网络上实时 Opus 音频的典型解决方案；但是，它还假定您使用的是对数据报（例如 UDP、WebSocket）而不是作为连续流（例如 TCP）进行操作的传输层。当我想为 Microsoft 语音服务实现 Opus 接口时，我想到了这个问题——因为我想要通过 TCP 流实现低延迟和低开销的语音。Opus 开发人员建议仅使用遵循Opus 自己的帧长度编码的简单长度前缀协议。使用这样的协议，您只需发送原始 Opus 数据包，每个数据包以一或两个字节为前缀，表示数据包长度。

Answer 2

The only way I know of to get low latency is to use WebRTC. It's built for that, where nothing else web-based really is.

You won't necessarily be able to pick your codec (at least not with the higher level APIs available), and codec and bitrate negotiation is part of the standard. But, you will get the lowest latency available to you for anything web-based, short of a browser plugin.

Answer 3

下面是一些使用Icecast通过 HTTP 的 Opus 流。

Icecast 是一个流媒体服务器，目前支持 Ogg（Vorbis 和 Theora）、Opus、WebM 和 MP3 音频流。它可用于创建 Internet 广播电台或私人点唱机以及介于两者之间的许多东西。它非常通用，可以相对容易地添加新格式并支持用于通信和交互的开放标准。

Icecast 在 GNU GPL 第 2 版下分发。

Answer 4

使用 WebAssembly，我们可以在 2mbps 的连接上以 < 300ms 的时间播放新下载的音频：https ://fetch-stream-audio.anthum.com/