问基于HTTP/TCP的低延迟操作？

EN

由于Ogg的设计方式，OggOpus绝对不适合低延迟的流媒体。我假设您已经对此有所了解，因为您提到了页面，但为了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数据包，每个数据包的前缀为一个或两个字节，表示数据包的长度。

据我所知，获得低延迟的唯一方法是使用WebRTC。它就是为此而构建的，没有其他基于web的东西是真正意义上的。

您不一定能够选择您的编解码器(至少不能使用更高级别的API)，并且编解码器和比特率协商是标准的一部分。但是，对于任何基于web的浏览器插件，你都会得到最低的延迟。

使用Icecast的Here are some Opus streams over HTTP。

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

Icecast是在GNU GPL版本2下分发的。