HTTP / TCP上的低延迟Opus？

Question

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

Ogg容器当然是显而易见的选择。然而，对于低比特率Opus（<50字节/帧），如果期望低延迟流传输，则开销变得巨大。例如，对于20毫秒块中的Opus @ 8 kbps，如果每个Ogg页中只放置一帧，则开销变为58％。

Answer 1

我知道获得低延迟的唯一方法是使用WebRTC。它是为此而构建的，其中没有其他任何基于网络的。

您不一定能够选择您的编解码器（至少不能使用更高级别的API），编解码器和比特率协商是标准的一部分。但是，除了浏览器插件之外，您将获得基于Web的任何可用的最低延迟。

Answer 2

Here are some Opus streams over HTTP使用Icecast。

  

Icecast是一个流媒体服务器，目前支持Ogg   （Vorbis和Theora），Opus，WebM和MP3音频流。它可以使用   创建一个互联网广播电台或私人运行的点唱机和   介于两者之间。它的用途非常广泛，新格式可以   相对容易添加并支持开放标准   沟通和互动。

     

Icecast在GNU GPL版本2下发布。

Answer 3

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

确实可以每页发送更少的数据包，但这会导致更高的数据开销，因为您需要创建更多的ogg页，而在低级别（每页只有几个数据包）时，开销太大，以至于几乎首先取消音频压缩。

WebRTC是网络上实时Opus音频的典型解决方案。但是，它还假定您使用的是传输层，该传输层对数据报（例如UDP，WebSocket）进行操作，而不是作为连续流（例如TCP）进行操作。当我想为Microsoft语音服务实现Opus接口时，这个问题浮出水面，因为我希望通过TCP流实现低延迟以及低开销的语音。 Opus开发人员建议仅在Opus' own frame length coding之后使用简单的长度前缀协议。使用这样的协议，您只需发送原始的Opus数据包，每个数据包都以一个或两个字节作为前缀来表示数据包的长度。