我的公司正在使用 Wowza Media Server 实现一个音频聊天服务器，但我们需要一些指导来帮助我们解决以下带宽问题:
情况:
我们有一个音频聊天系统，用户可以通过它与他人协作。 N 个用户发布到他们自己的音频 channel ，同时订阅 N-1 个音频 channel (其他用户减去他们自己的)。
问题:
当您开始添加更多用户时，带宽会很快变大。例如，假设有 4 个用户在线——用户 A、用户 B、用户 C 和用户 D。如果每个用户都发布一个 8kbps 的音频 channel ，而所有其他用户都在订阅该 channel ，那么使用的总带宽将是巨大的96kbps:
User A = 24kbps (from 3 streams: 8kbps from subscribing to user B, 8kbps from subscribing to user C, & 8kbps from subscribing to user D) +
User B = 24kbps (from 3 streams: 8kbps from subscribing to user A, user C, & user D) +
User C = 24kbps (from 3 streams: 8kbps from subscribing to user A, user B, & user D) +
User D = 24kbps (from 3 streams: 8kbps from subscribing to user A, user B, & user C) = 96kbps total
我认为我们需要做什么:
在线合并所有用户 channel (除了自己的)的音频 channel (实时)，并让每个用户订阅那个独特的、新合并的 channel ，如下所示:
User A = 8kbps (from 1 merged stream of users B, C, & D) +
User B = 8kbps (from 1 merged stream of users A, C, & D) +
User C = 8kbps (from 1 merged stream of users A, B, & D) +
User D = 8kbps (from 1 merged stream of users A, B, & C) = 32kbps total
你可以看到这个问题在哪里可以迅速失控，因为这个例子一次只有 4 人在线。假设您再添加一个，总共 5 个，那么在我们当前的设置下，带宽将使用 20 个不同的订阅流，总共 160kbps。而最佳的合并解决方案只会为每个额外的用户增加额外的 8kbps，因此总共 5 个用户为 40kbps，6 个用户为 48kbps，以此类推。
所以，有人对我应该如何实现这一点有任何建议吗？
最佳答案
你可能过度分析了它。在任何时间点都可能只有一个用户在说话(您可以假设一些重叠，就像在正常对话中一样)。如果您有语音事件检测(简单的阈值可能会起作用)，那么如果他们不说话，您就不必在用户的流上发送数据。这应该意味着您的整体带宽将是单个用户的 110%。
关于audio - 使用 Wowza 媒体服务器实时合并音频流，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7971852/