我最近和我哥哥创办了一家广播公司。我们公司严格处理音频网络直播。我们的模型允许单个广播公司同时向多点收听设备广播单向音频网络广播(本质上是在线广播网络广播)。
我们的主要目标是使用一种开发模型，使我们几乎没有音频延迟，并允许在所有浏览器和所有设备上进行网络广播。我很难找到实现这一发展的最佳方式。我们正在考虑使用adobe flash播放器将广播发送到AWS上的Wowza流媒体引擎。从那里，它将根据接收广播的设备类型进行代码转换(例如，iOS设备的HLS)。然而，该领域的其他专家告诉我们。Flash Player已过时，无法与所有设备和2配合使用。HLS代码转换协议可能会给我们带来许多苹果产品的延迟问题。
他们对Flash的看法是对的吗？哪种开发路径最适合消除所有音频延迟？本机应用程序的插件是否是消除音频延迟的最佳选择？如果是的话，是否有一个好的插件api可用于我们的概念？如何绕过HLS代码转换来消除苹果产品中的延迟？
此外，你知道有什么工程师或公司可以帮助我们开发这些框架吗？
非常感谢！
我们的主要目标是使用一种开发模型，使我们的几乎没有音频延迟
您是否确信这对您的产品的成功至关重要？为了减少延迟，您需要进行一些重要的权衡。首先，考虑从源到侦听器的显著延迟的起源：
- 音频捕获缓冲区(50-250ms)
- 编解码器缓冲区-编码端(根据编解码器和配置变化很大…5-2000ms)
- 网络传输缓冲区(0-500ms取决于比特率，以及您是否禁用了Nagle算法)
- 正常的互联网传播延迟(对于世界各地良好的连接，20ms-300ms，差异很大)
- 服务器端缓冲区(根据服务器、协议和配置而变化很大，但可以是100ms到30s左右)
- 从边缘到客户端的互联网传播(如果你的边缘服务器离你的客户端很近，5ms-80ms是典型的良好连接)
- 客户端网络缓冲区(通常非常小，几乎为零)
- 客户端编解码器缓冲区-解码端(与编码端一样，根据编解码器和配置而有所不同，但通常小于编码…5-400ms——尽管可能很高…Android大约为3s，许多桌面播放器也是如此)
- 客户端声音设备缓冲区(50-250ms)
正如您所看到的，这非常快地加起来。为了强调你可以做出的权衡，考虑几个场景：
典型的互联网收音机
对于一个典型的互联网电台来说，从编码到收听的延迟几乎毫无意义。听众通常不会立即与主持人互动，也不知道或关心现场直播的事情是现在发生的，还是10秒前，甚至一个小时前发生的。对于这种情况，我确保源端的音频捕获缓冲区足够高，这样在某个东西阻塞线程一段时间时就不会出现掉线的情况。我会选择广泛兼容的编解码器(MP3和AAC)，其设置更喜欢质量而不是延迟。我通常在服务器上设置一个20秒的缓冲区，并使用HTTP渐进式分发。
这给了我高质量的音频，几乎适用于所有东西，从我12岁的Palm Pilot到现代网络浏览器中的原生<audio>标签。不需要任何应用程序。。。只是一个现代化的浏览器。但是，拥有应用程序的用户可以使用这些流，因为它们非常兼容。延迟足够低，主持人可以在最短的延迟内对社交媒体评论做出反应。(人们阅读和回复评论所需的时间通常比缓冲区的大小要长。)拥有20秒的缓冲区，移动用户可以在没有持续故障的情况下收听。(当你转动手机时，它会周期性地失去连接。由于所有东西都有缓冲区，你不会注意到，但如果你每50毫秒需要一次数据，你肯定会注意到。)无论如何，移动网络都是出了名的高延迟网络。(用手机Ping你的媒体服务器。如果它在250毫秒内返回，你就度过了美好的一天。)在芝加哥，蓝线地铁的每一站都有手机站，但它们之间没有覆盖范围。停车点离得很近，你可以在赛道上看到一个信号，但不是一个好信号。我想能够在地铁上收听互联网广播，20秒的缓冲区使我能够在不掉线的情况下收听，即使我会在几秒钟内反复完全失去手机连接。您的用户可能会在街上遇到类似的用例。
"实时"通信
为了支持你想要做的事情，你需要将所有缓冲区降低到几乎没有。这意味着你将不得不接受低音频质量，流会在短时间内中断。您还需要选择为此设计的编解码器(如Opus)，并为低延迟(再次降低音频质量)提供适当的设置。从技术上讲，你可以使用HTTP渐进式来分发媒体，但使用它的玩家不会采用低延迟的操作模式，所以分发方法已经过时了。
WebRTC是最兼容基于web的低延迟音频/视频的方法，但其支持程度远低于普通HTTP流。此外，WebRTC通常是为少数用户之间的对等连接而开发的，用于视频聊天。(想想Google Hangout或Skype。)它只支持音频，甚至支持数据通道，但它不是为一对多通信而构建的。正因为如此，目前只有几台服务器真正支持这种分发方法。(我从未使用过它们，所以我无法提供具体的建议。)
很多人使用RTMP，但这在浏览器中并不容易。您必须使用MediaSourceExtensions。它也不会像HTTPProgressive那样减少延迟。(我应该注意的是，在许多实现中，RTMP的延迟明显低于HTTPProgressive。这与协议无关，更多地与默认配置有关。)
允许在所有浏览器和所有设备上进行网络广播
没有什么东西可以在所有浏览器和所有设备上工作。你需要弄清楚你打算支持什么浏览器和设备。真正的普遍支持是反目标的。在支持客户群使用的内容和其他目标之间找到平衡。
然而，该领域的其他专家告诉我们，1。Flash Player已过时，无法与所有设备一起使用
这是非常正确的。浏览器对HTML5方法的支持比Flash更好。
- HLS转码协议可能会给我们的苹果产品带来很多延迟问题
HLS不是代码转换协议。。。HLS是一种分发协议。HLS会给你很高的延迟，任何使用它的东西。HLS背后的概念是，你把媒体分成大块(基本上是在链上添加另一个大缓冲区)，然后上传到你的服务器上下载。这将根据您的分块配置再增加10-30。HLS的好处是你不需要任何特殊的服务器来支持它。任何静态的web服务器都可以，允许你使用常见的HTTPCDN。
什么开发路径最适合消除所有音频延迟？
同样，这在物理上是不可能的。即使我在客厅里大喊大叫，也会有延迟，这是在没有计算机或全球分组交换网络的情况下发生的。
本机应用程序的插件是否是消除音频延迟的最佳选择？
是的，如果你放弃了在许多设备上获得支持的目标，那么本机应用程序允许你将各种参数调整为reduce(而不是消除)。然而，您仍然需要在音频质量和流的可靠性之间进行巨大的权衡。最终，您不太可能将延迟降低到正常WebRTC堆栈所能达到的水平之外。
一个实验：拿起你的手机给别人打电话。让他们把你放在扬声器上。对着电话大喊几句，然后等你收到反馈。电话针对低延迟、低带宽和移动设备进行了优化，并拥有自己的专用基础设施。。。然而500毫秒的往返音频延迟是相当正常的。
A建议书
- 确定每个流将有多少人在听。(答案不可能是"1到∞"。这需要大致知道。)如果答案是<8，实现WebRTC并使用它。非常简单，支持良好，并且需要很少的基础设施，因为大多数用户都会对等连接
- 如果您需要更多的侦听器，我建议使用HTTP渐进式流媒体，在Icecast上进行调优配置或兼容。(我有一个符合要求的CDN产品。请发送电子邮件至brad@audiopump.co了解更多信息。)将服务器缓冲区设置为您愿意接受的最高。如果是2s，那就顺其自然。你的流越高，你的流就越可靠。我会选择2s作为最小值，因为这就是填充客户端缓冲区进行解码所需要的。如果你快速地向他们发送数据，他们就会很快开始播放。还要记住，随着侦听器的增加，您不希望它们都连接到一个服务器。在水平缩放时，中继数据会有额外的延迟
- 确定要支持的设备和浏览器。(答案不能是"全部"，但可以是"尽可能多"。)这将回答您想要支持什么编解码器的问题
最后一句话。。。如果可能的话，提前完成所有的编码。不要对任何内容进行转码。代码转换会增加延迟问题，但更重要的是，会显著降低音频质量。
我希望这对你的项目有帮助。