问移动和web的实时音频(无线电)流的最佳协议是什么？

EN

这是一个非常宽泛的问题。让我们从分发协议开始。

流协议

HLS的优点是允许用户以最适合其连接的码率获取流。客户端无需停止播放即可无缝扩容/缩容。这对于视频尤其重要，但对于音频，即使是移动客户端也能够在大多数区域播放128kbit的流。如果你打算有多种可用的比特率，并且想在中途改变质量，那么HLS对你来说是一个很好的协议。

HLS的缺点是兼容性。iOS支持它，但仅此而已。Android支持HLS，但它仍然有缺陷。(也许再过一两年，一旦Android 3.0的人都走了，这就不是什么大问题了。)JWPlayer有一些技巧可以让HLS在桌面用户的闪存中工作。

我不会为RTMP而烦恼，除非你只关心Flash用户。

使用HTTP的纯渐进式流媒体是我几乎总是选择的路线。一切都可以玩它。(甚至连我的Palm Pilot 12年前的默认媒体播放器也是如此。)它实现起来很简单，也很容易理解。

SHOUTcast是一个有效的超文本传输协议，但它是一个实现不佳的版本，存在兼容性问题，特别是在移动设备上。它在响应中有一个非标准的状态行，这会破坏很多客户端。Icecast是一个很好的选择，也是我现在推荐使用的产品。作为另一种选择，我已经创建了自己的流媒体服务，称为AudioPump，它也是HTTP，并且是专门为修复与奇怪的移动客户端的兼容性而构建的，比如旧硬件上的本地Android播放器。它还不能正常使用，但是如果你想试一下，你可以在brad@audiopump.co上联系我。

延迟

您提到2秒的延迟是理想的。如果你用SHOUTcast得到了2秒的延迟，那一定是出了什么问题。你不希望延迟那么低，特别是当你在向移动客户端发送流媒体的时候。我通常从最少20秒的缓冲区开始，它会以尽可能快的速度刷新到客户端。这允许立即开始流回放(因为它填满了客户端缓冲区，因此可以开始解码)，同时提供一些保护，防止由于网络条件而导致的缓冲区欠载。对于移动用户来说，走在建筑物的角落，失去良好的信号质量并不少见。您希望您的流尽可能地存活下来，因此，如果您已经发送了覆盖丢失的数据，则用户不必知道或关心他们的连接在短时间内变得平庸。

如果您确实需要低延迟，那么您使用的是完全错误的技术。要获得低延迟，请查看WebRTC。

您当然可以调整您的传统互联网广播设置，以减少延迟，但很少是一个好主意。

编解码器

编解码器的选择是决定你的兼容性的最重要的因素。MP3无疑是最兼容的，而AAC也紧随其后。如果你使用AAC，你可以在给定的比特率下获得更好的音频质量。大多数人使用它来减少他们的带宽账单。

MP3是有许可费的，而且根据你使用的编解码器，AAC也可能会有许可费。和律师确认一下。我不是其中之一，而且许可是非常复杂的。

其他编解码器包括Vorbis和Opus。如果您可以使用Opus，那么这样做是因为许可是完全开放的，并且您可以获得高质量的带宽。然而，这里的客户端兼容性是Opus的杀手。(也许几年后会更好。)Vorbis是一个平庸的编解码器，但它是免费和清晰的。

在极端的情况下，我有一些电台在FLAC中进行流媒体。这是无损的音频质量，但您需要支付的带宽是中等质量的MP3工作站的8倍。FLAC over HTTP流兼容性目前还不是代码，但它在VLC中工作得很好。

为您的流支持多个编解码器是很常见的。根据您的预算，如果您不能做到这一点，您最好使用MP3。

最后，在编码方面，如果可以的话，不要从一个有损编解码器转到另一个有损编解码器。尝试使输出流尽可能接近输入。如果你重新编码音频，你每次都会失去质量。

从浏览器录制

你提到了用户从浏览器流媒体。我在几年前用Web Audio API构建了类似的东西，其中音频被捕获，然后编码并发送到Icecast/SHOUTcast服务器。点击这里查看：http://demo.audiopump.co:3000/在这里简要解释它是如何工作的：https://stackoverflow.com/a/20850467/362536

无论如何，我希望这能帮助你入门。

流式传输audio/mpeg (mp3数据包)在我尝试过的任何地方都能正常工作。

如果你正在开发一个应用程序，那么使用AAC，如果你只是通过网络浏览器玩，那么你需要一个HTML5实现，这就是MP3。所有自定义协议，如RTMP或SHOUTcast，都需要构建额外的UI。开源世界中有一些第三方播放器可用。你既可以使用它们，也可以坚持使用HTML5 MP3/OGG，因为现在大多数人都在使用chrome浏览器或其他与HTML5有关的浏览器。