正在尝试寻找合适的技术/容器来通过 HTTP/TCP 实时传输低延迟 Opus？
Ogg 容器当然是显而易见的选择。然而，对于低比特率 Opus(<50 字节/帧)，如果需要低延迟流，开销会变得巨大。例如，对于 20 ms block 中的 Opus @ 8 kbps，如果每个 Ogg 页面中仅放置一帧，则开销将变为 58%。
最佳答案
由于 Ogg 的设计方式，OggOpus 绝对不适合低延迟流媒体。我假设您已经对此有所了解，因为您提到了页面，但为了 StackOverflow 的好处:Opus 数据包被排列到 Ogg 页面中，每个页面通常包含 255 个 Opus 数据包。每个 Opus 数据包通常是 20 毫秒的音频。每个 Ogg 页面都包含一个校验和来验证其内容，并且在计算出校验和之前无法通过网络发送该页面，因此直到整个页面被填满为止。 20 毫秒 * 255 个数据包 = 大约 5 秒的音频，在通过线路发送音频之前必须缓冲该音频，从用户的角度来看，这是显着的延迟。
确实，您可以每页发送更少的数据包，但这会导致更高的数据开销，因为您需要创建更多的 ogg 页面，并且在低级别(每页仅几个数据包)开销变得如此之大，以至于几乎首先取消音频压缩。
WebRTC 是通过网络实现实时 Opus 音频的典型解决方案；但是，它还假设您使用的是对数据报(例如 UDP、WebSocket)而不是连续流(例如 TCP)进行操作的传输层。当我想要实现 Microsoft 语音服务的 Opus 接口(interface)时，我就提出了这个问题 - 因为我想要通过 TCP 流实现低延迟和低开销的语音。 Opus 开发人员建议仅使用简单的长度前缀协议(protocol)，如下 Opus' own frame length coding 。使用这样的协议(protocol)，您只需发送原始 Opus 数据包，每个数据包都以一或两个字节作为前缀，指示数据包长度。
关于audio-streaming - HTTP/TCP 上的低延迟 Opus？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25692895/