使用 Wowza 媒体服务器实时合并音频流

Question

我的公司正在使用 Wowza Media Server 实现一个音频聊天服务器，但我们需要一些指导来帮助我们解决以下带宽问题：

情况：

我们有一个音频聊天系统，用户可以通过它与其他人协作。 N 个用户发布到他们自己的音频通道，同时订阅 N-1 个音频通道（其他用户减去他们自己的）。

问题：

当您开始添加更多用户时，带宽会很快变大。例如，假设有 4 个用户在线——用户 A、用户 B、用户 C 和用户 D。如果每个用户都发布一个 8kbps 的音频通道，而所有其他用户都在订阅该通道，那么使用的总带宽将是巨大的96kbps：

用户 A = 24kbps（来自 3 个流：订阅用户 B 时为 8kbps，订阅用户 C 时为 8kbps，订阅用户 D 时为 8kbps）+

用户 B = 24kbps（来自 3 个流：订阅用户 A、用户 C 和用户 D 时为 8kbps）+

用户 C = 24kbps（来自 3 个流：订阅用户 A、用户 B 和用户 D 时为 8kbps）+

用户 D = 24kbps（来自 3 个流：订阅用户 A、用户 B 和用户 C 时为 8kbps）= 总计 96kbps

我认为我们需要做什么：

合并所有在线用户频道（除了自己的）的音频频道（实时），并让每个用户订阅那个独特的、新合并的频道，如下所示：

用户 A = 8kbps（来自用户 B、C 和 D 的 1 个合并流）+

用户 B = 8kbps（来自用户 A、C 和 D 的 1 个合并流）+

用户 C = 8kbps（来自用户 A、B 和 D 的 1 个合并流）+

用户 D = 8kbps（来自用户 A、B 和 C 的 1 个合并流）= 总计 32kbps

您可以看到这个问题在哪里可以迅速失控，因为这个例子是一次只有 4 人在线。假设您再添加一个，总共 5 个，那么在我们当前的设置下，带宽将使用 20 个不同的订阅流，总共 160kbps。而最优的合并方案只会为每增加一个用户额外增加 8kbps，所以总共 5 个用户 40kbps，6 个用户 48kbps 等等。

所以，有人对我应该如何实现这一点有任何建议吗？

Answer 1

您可能过度分析了它。在任何时间点都可能只有一个用户在说话（您可以假设一些重叠，就像在正常对话中一样）。如果您有语音活动检测（简单的阈值可能会起作用），那么如果他们不说话，您就不必在用户的流上发送数据。这应该意味着您的总带宽将是单个用户的 110%。