这是一个非常广泛的问题。让我们从分发协议开始。
流媒体协议
HLS 的优势在于允许用户以最适合其连接的比特率获取流。客户端可以在不停止播放的情况下无缝地放大/缩小。这对于视频尤其重要,但对于音频,即使是移动客户端也能够在大多数区域播放 128kbit 流。如果您打算提供各种可用的比特率并希望在中途改变质量,那么 HLS 对您来说是一个很好的协议。
HLS 的缺点是兼容性。iOS 支持它,但仅此而已。Android 支持 HLS,但仍然存在问题。(也许再过一两年,一旦所有 Android 3.0 的人都离开了,这不会是什么大问题。) JWPlayer 有一些技巧可以让 HLS 在 Flash 中为桌面用户工作。
除非您只关心 Flash 用户,否则我不会打扰 RTMP。
使用 HTTP 的纯渐进式流式传输是我几乎总是选择的路线。 什么都可以玩。(甚至是我的 Palm Pilot 12 年前的默认媒体播放器。)它易于实现且易于理解。
SHOUTcast 实际上是 HTTP,但实施不佳的版本存在兼容性问题,尤其是在移动设备上。它的响应中有一个非标准状态行,这会破坏很多客户。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
无论如何,我希望这可以帮助您入门。