试图找到一个合适的技术/容器，用于通过HTTP / TCP流式传输实时低延迟Opus？
Ogg容器当然是显而易见的选择。但是，对于低比特率的Opus（<50字节/帧），如果需要低延迟流，则开销会变得很大。例如，对于20毫秒块中的Opus @ 8 kbps，如果每个Ogg页中只放置一帧，则开销变为58％。
我知道获得低延迟的唯一方法是使用WebRTC。它是为此而构建的，其中没有其他任何基于网络的。
您不一定能够选择您的编解码器（至少不能使用更高级别的API），编解码器和比特率协商是标准的一部分。但是，除了浏览器插件之外，您将获得基于Web的任何可用的最低延迟。
由于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数据包，每个前缀由一个或两个字节指示数据包长度。
Here are some Opus streams over HTTP使用Icecast。
Icecast是一种流媒体服务器，目前支持Ogg（Vorbis和Theora），Opus，WebM和MP3音频流。它可用于创建互联网广播电台或私人运行的点唱机以及介于两者之间的许多东西。它的用途非常广泛，可以相对容易地添加新格式，并支持通信和交互的开放标准。
Icecast是在GNU GPL版本2下发布的。