移动和网络的现场音频(无线电)流媒体的最佳协议是什么？

Question

我正在尝试为互联网广播电台建立一个网站和移动应用程序(iOS,Android).网站用户播放他们的音乐或广播,移动用户只需收听广播电台并与其他听众聊天.

我搜索了一周,使用Wowza引擎(使用HLS和RTMP)和Amazon EC2上的SHOUTcast服务器制作原型.

使用HLS有5秒的延迟,但RTMP和SHOUTcast有2秒的延迟.有了这个结果,我想我应该选择RTMP或SHOUTcast.

但我不确定RTMP和SHOUTcast是最好的协议.:(

我应该选择什么协议？我是否需要提供涵盖所有平台的各种协议？

Answer 1

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

流媒体协议

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

HLS的缺点是兼容性.iOS支持它,但这就是它.Android有HLS支持,但它仍然有问题.(也许在所有Android 3.0人员离开后的一两年内,这不会是一个问题.)JWPlayer有一些黑客可以使HLS在桌面用户的Flash中工作.

除非你只关心Flash用户,否则我不会打扰RTMP.

使用HTTP的纯粹渐进式流媒体是我几乎总是选择去的路线. 一切都可以发挥.(甚至是我12年前的Palm Pilot默认媒体播放器.)它实现起来很简单并且很好理解.

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中进行流媒体播放.这是无损的音频质量,但你需要支付8倍的带宽,就像使用中等质量的MP3电台一样.FLAC over HTTP流兼容性目前不是代码,但它在VLC中可以正常工作.

支持流的多个编解码器是很常见的.根据您的预算,如果您不能这样做,那么最好使用MP3.

最后在编码时,如果可以帮助它,请不要从有损编解码器转到另一个有损编解码器.尝试使输出流尽可能靠近输入.如果重新编码音频,每次都会丢失质量.

从浏览器录制

您提到用户从浏览器流式传输.几年前,我用Web Audio API构建了类似的东西,音频被捕获然后被编码并发送到Icecast/SHOUTcast服务器.在这里查看:http://demo.audiopump.co: 3000 / 它的工作原理的简要说明如下:https: //stackoverflow.com/a/20850467/362536

无论如何,我希望这可以帮助你开始.