I am trying to build a website and mobile app (iOS, Android) for the internet radio station. Website users broadcast their music or radio and mobile users will just listen radio stations and chat with other listeners.
我正在尝试为互联网广播电台建立一个网站和移动应用程序(iOS,Android)。网站用户播放他们的音乐或广播,移动用户只需收听广播电台并与其他听众聊天。
I searched a week and make a prototype with Wowza engine (using HLS and RTMP) and SHOUTcast server on Amazon EC2.
我搜索了一周,使用Wowza引擎(使用HLS和RTMP)和Amazon EC2上的SHOUTcast服务器制作原型。
Using HLS has a delay with 5 seconds, but RTMP and SHOUTcast has 2 second delay. With this result I think I should choose RTMP or SHOUTcast.
使用HLS有5秒的延迟,但RTMP和SHOUTcast有2秒的延迟。有了这个结果,我想我应该选择RTMP或SHOUTcast。
But I am not sure RTMP and SHOUTcast are the best protocol. :(
但我不确定RTMP和SHOUTcast是最好的协议。 :(
What protocol should I choose? Do I need to provide a various protocol to cover all platform?
我应该选择什么协议?我是否需要提供涵盖所有平台的各种协议?
3 个解决方案
#1
This is a very broad question. Let's start with the distribution protocol.
这是一个非常广泛的问题。让我们从分发协议开始。
Streaming Protocol
HLS has the advantage of allowing users to get the stream in the bitrate that is best for their connection. Clients can scale up/down seamlessly without stopping playback. This is particularly important for video, but for audio even mobile clients are capable of playing 128kbit streams in most areas. If you intend to have a variety of bitrates available and want to change quality mid-stream, then HLS is a good protocol for you.
HLS的优点是允许用户以最适合其连接的比特率获取流。客户端可以无缝扩展/缩小而无需停止播放。这对于视频尤其重要,但对于音频,即使移动客户端也能够在大多数区域播放128kbit流。如果您打算提供各种比特率并希望在中途改变质量,那么HLS对您来说是一个很好的协议。
The downside of HLS is compatibility. iOS supports it, but that's about it. Android has HLS support but it is still buggy. (Maybe in another year or two once all the Android 3.0 folks are gone, this won't be as much of an issue.) JWPlayer has some hacks to make HLS work in Flash for desktop users.
HLS的缺点是兼容性。 iOS支持它,但这就是它。 Android有HLS支持,但它仍然有问题。 (也许在所有Android 3.0人员离开后的一两年内,这不会是一个问题。)JWPlayer有一些黑客可以使HLS在桌面用户的Flash中工作。
I wouldn't bother with RTMP unless you're only concerned with Flash users.
除非你只关心Flash用户,否则我不会打扰RTMP。
Pure progressive streaming with HTTP is the route I almost always choose to go. Everything can play it. (Even my Palm Pilot's default media player from 12 years ago.) It's simple to implement and well understood.
使用HTTP的纯粹渐进式流媒体是我几乎总是选择去的路线。一切都可以发挥。 (甚至是我12年前的Palm Pilot默认媒体播放器。)它实现起来很简单并且很好理解。
SHOUTcast is effectively HTTP, but a poorly implemented version that has compatibility issues, particularly on mobile devices. It has a non-standard status line in its response which breaks a lot of clients. Icecast is a good alternative, and is what I would recommend for production use today. As another option, I have created my own streaming service called AudioPump which is HTTP as well, and has been specifically built to fix compatibility with oddball mobile clients, such as native Android players on old hardware. It isn't generally available yet, but you can contact me at brad@audiopump.co if you want to try it.
SHOUTcast实际上是HTTP,但实现性差的版本存在兼容性问题,特别是在移动设备上。它的响应中有一个非标准的状态行,打破了很多客户端。 Icecast是一个很好的选择,我今天推荐用于生产。作为另一种选择,我创建了自己的名为AudioPump的流媒体服务,它也是HTTP,并且专门用于修复与古怪的移动客户端的兼容性,例如旧硬件上的原生Android播放器。目前尚未提供,但如果您想尝试,可以通过brad@audiopump.co与我联系。
Latency
You mentioned a latency of 2 seconds being desirable. If you're getting 2-second latency with SHOUTcast, something is wrong. You don't want latency that low, particularly if you're streaming to mobile clients. I usually start with a 20-second buffer at a minimum, which is flushed to the client as fast as it can receive it. This enables immediate starting of the stream playback (as it fills up the client-side buffer so it can begin decoding) while providing some protection against buffer underruns due to network conditions. It's not uncommon for mobile users to walk around the corner of a building and lose their nice signal quality. You want your stream to survive that as best as possible, so if you have already sent the data to cover the drop out, the user doesn't have to know or care that their connection became mediocre for a short period of time.
你提到了2秒的延迟是可取的。如果你使用SHOUTcast获得2秒的延迟,那就错了。您不希望延迟低,特别是如果您要流式传输到移动客户端。我通常以一个至少20秒的缓冲区开始,它以尽可能快的速度刷新到客户端。这使得能够立即启动流回放(因为它填满了客户端缓冲区以便它可以开始解码),同时提供一些针对由于网络条件引起的缓冲区欠载的保护。移动用户走在建筑物的角落并且失去了良好的信号质量并不罕见。您希望您的流能够尽可能地生存,因此如果您已经发送数据以支付退出,则用户无需知道或关心他们的连接在短时间内变得平庸。
If you do require low latency, you're looking at the wrong technology entirely. For low latency, check out WebRTC.
如果您确实需要低延迟,那么您完全在看错误的技术。要获得低延迟,请查看WebRTC。
You certainly can tweak your traditional internet radio setup to reduce latency, but rarely is that a good idea.
你当然可以调整你的传统互联网收音机设置,以减少延迟,但很少这是一个好主意。
Codec
Codec choice is what will dictate your compatibility more than anything else. MP3 is easily the most compatible, and AAC isn't far behind. If you go with AAC, you get better quality audio for a given bitrate. Most folks use this to reduce their bandwidth bill.
编解码器的选择决定了你的兼容性,而不是其他任何东西。 MP3很容易兼容,AAC也不甘落后。如果你选择AAC,你可以获得比特率更高质量的音频。大多数人使用它来减少带宽费用。
There are licensing fees with MP3, and there may be with AAC depending on what you're using for a codec. Check with a lawyer. I am not one, and the licensing is extremely complicated.
有MP3的许可费用,AAC可能会根据您使用的编解码器而定。请咨询律师。我不是一个,许可证非常复杂。
Other codecs include Vorbis and Opus. If you can use Opus, do so as the licensing is wide open and you get good quality for the bandwidth. Client compatibility here though is the killer of Opus. (Maybe in a few years it will be better.) Vorbis is a mediocre codec, but is free and clear.
其他编解码器包括Vorbis和Opus。如果您可以使用Opus,请执行此操作,因为许可是敞开的,您可以获得良好的带宽质量。这里的客户兼容性是Opus的杀手。 (也许在几年后会更好。)Vorbis是一个平庸的编解码器,但是*而清晰。
On the extreme end, I have some stations doing their streaming in FLAC. This is lossless audio quality, but you're paying for 8x the bandwidth as you would with a medium quality MP3 station. FLAC over HTTP streaming compatibility is not code at the moment, but it works alright in VLC.
在极端情况下,我有一些电台在FLAC中进行流媒体播放。这是无损的音频质量,但你需要支付8倍的带宽,就像使用中等质量的MP3电台一样。 FLAC over HTTP流兼容性目前不是代码,但它在VLC中可以正常工作。
It is very common to support multiple codecs for your streams. Depending on your budget, if you can't do that, you're best off with MP3.
支持流的多个编解码器是很常见的。根据您的预算,如果您不能这样做,那么最好使用MP3。
Finally on encoding, don't go from a lossy codec to another lossy codec if you can help it. Try to get the output stream as close to the input as possible. If you re-encode audio, you lose quality every time.
最后在编码时,如果可以帮助它,请不要从有损编解码器转到另一个有损编解码器。尝试使输出流尽可能靠近输入。如果重新编码音频,每次都会丢失质量。
Recording from Browser
You mentioned users streaming from a browser. I built something like this a couple years ago with the Web Audio API where the audio is captured and then encoded and sent off to Icecast/SHOUTcast servers. Check it out here: http://demo.audiopump.co:3000/ A brief explanation of how it works is here: https://*.com/a/20850467/362536
您提到用户从浏览器流式传输。几年前,我用Web Audio API构建了类似的东西,音频被捕获然后被编码并发送到Icecast / SHOUTcast服务器。在这里查看:http://demo.audiopump.co:3000 /它的工作原理的简要说明如下:https://*.com/a/20850467/362536
Anyway, I hope this helps you get started.
无论如何,我希望这可以帮助你开始。
#2
Streaming straight audio/mpeg (mp3 packets) has worked everywhere I've tried.
直播音频/ mpeg(mp3数据包)在我尝试过的任何地方都有用。
#3
If you are developing an APP then go with AAC, if you are simply playing via web browser then you need a HTML5 Implimentation which is MP3. All custom protocols like RTMP or SHOUTcast requires additional UI to be built. There are some third party players available in open source world. You can either use them or stick to HTML5 MP3/OGG as most people now days are using chrome browser or other HTML5 complaint browsers.
如果您正在开发APP,那么请使用AAC,如果您只是通过网络浏览器播放,那么您需要一个HTML5 Implimentation就是MP3。所有自定义协议(如RTMP或SHOUTcast)都需要构建其他UI。在开源世界中有一些第三方玩家可用。您可以使用它们或坚持使用HTML5 MP3 / OGG,因为现在大多数人都在使用Chrome浏览器或其他HTML5投诉浏览器。
#1
This is a very broad question. Let's start with the distribution protocol.
这是一个非常广泛的问题。让我们从分发协议开始。
Streaming Protocol
HLS has the advantage of allowing users to get the stream in the bitrate that is best for their connection. Clients can scale up/down seamlessly without stopping playback. This is particularly important for video, but for audio even mobile clients are capable of playing 128kbit streams in most areas. If you intend to have a variety of bitrates available and want to change quality mid-stream, then HLS is a good protocol for you.
HLS的优点是允许用户以最适合其连接的比特率获取流。客户端可以无缝扩展/缩小而无需停止播放。这对于视频尤其重要,但对于音频,即使移动客户端也能够在大多数区域播放128kbit流。如果您打算提供各种比特率并希望在中途改变质量,那么HLS对您来说是一个很好的协议。
The downside of HLS is compatibility. iOS supports it, but that's about it. Android has HLS support but it is still buggy. (Maybe in another year or two once all the Android 3.0 folks are gone, this won't be as much of an issue.) JWPlayer has some hacks to make HLS work in Flash for desktop users.
HLS的缺点是兼容性。 iOS支持它,但这就是它。 Android有HLS支持,但它仍然有问题。 (也许在所有Android 3.0人员离开后的一两年内,这不会是一个问题。)JWPlayer有一些黑客可以使HLS在桌面用户的Flash中工作。
I wouldn't bother with RTMP unless you're only concerned with Flash users.
除非你只关心Flash用户,否则我不会打扰RTMP。
Pure progressive streaming with HTTP is the route I almost always choose to go. Everything can play it. (Even my Palm Pilot's default media player from 12 years ago.) It's simple to implement and well understood.
使用HTTP的纯粹渐进式流媒体是我几乎总是选择去的路线。一切都可以发挥。 (甚至是我12年前的Palm Pilot默认媒体播放器。)它实现起来很简单并且很好理解。
SHOUTcast is effectively HTTP, but a poorly implemented version that has compatibility issues, particularly on mobile devices. It has a non-standard status line in its response which breaks a lot of clients. Icecast is a good alternative, and is what I would recommend for production use today. As another option, I have created my own streaming service called AudioPump which is HTTP as well, and has been specifically built to fix compatibility with oddball mobile clients, such as native Android players on old hardware. It isn't generally available yet, but you can contact me at brad@audiopump.co if you want to try it.
SHOUTcast实际上是HTTP,但实现性差的版本存在兼容性问题,特别是在移动设备上。它的响应中有一个非标准的状态行,打破了很多客户端。 Icecast是一个很好的选择,我今天推荐用于生产。作为另一种选择,我创建了自己的名为AudioPump的流媒体服务,它也是HTTP,并且专门用于修复与古怪的移动客户端的兼容性,例如旧硬件上的原生Android播放器。目前尚未提供,但如果您想尝试,可以通过brad@audiopump.co与我联系。
Latency
You mentioned a latency of 2 seconds being desirable. If you're getting 2-second latency with SHOUTcast, something is wrong. You don't want latency that low, particularly if you're streaming to mobile clients. I usually start with a 20-second buffer at a minimum, which is flushed to the client as fast as it can receive it. This enables immediate starting of the stream playback (as it fills up the client-side buffer so it can begin decoding) while providing some protection against buffer underruns due to network conditions. It's not uncommon for mobile users to walk around the corner of a building and lose their nice signal quality. You want your stream to survive that as best as possible, so if you have already sent the data to cover the drop out, the user doesn't have to know or care that their connection became mediocre for a short period of time.
你提到了2秒的延迟是可取的。如果你使用SHOUTcast获得2秒的延迟,那就错了。您不希望延迟低,特别是如果您要流式传输到移动客户端。我通常以一个至少20秒的缓冲区开始,它以尽可能快的速度刷新到客户端。这使得能够立即启动流回放(因为它填满了客户端缓冲区以便它可以开始解码),同时提供一些针对由于网络条件引起的缓冲区欠载的保护。移动用户走在建筑物的角落并且失去了良好的信号质量并不罕见。您希望您的流能够尽可能地生存,因此如果您已经发送数据以支付退出,则用户无需知道或关心他们的连接在短时间内变得平庸。
If you do require low latency, you're looking at the wrong technology entirely. For low latency, check out WebRTC.
如果您确实需要低延迟,那么您完全在看错误的技术。要获得低延迟,请查看WebRTC。
You certainly can tweak your traditional internet radio setup to reduce latency, but rarely is that a good idea.
你当然可以调整你的传统互联网收音机设置,以减少延迟,但很少这是一个好主意。
Codec
Codec choice is what will dictate your compatibility more than anything else. MP3 is easily the most compatible, and AAC isn't far behind. If you go with AAC, you get better quality audio for a given bitrate. Most folks use this to reduce their bandwidth bill.
编解码器的选择决定了你的兼容性,而不是其他任何东西。 MP3很容易兼容,AAC也不甘落后。如果你选择AAC,你可以获得比特率更高质量的音频。大多数人使用它来减少带宽费用。
There are licensing fees with MP3, and there may be with AAC depending on what you're using for a codec. Check with a lawyer. I am not one, and the licensing is extremely complicated.
有MP3的许可费用,AAC可能会根据您使用的编解码器而定。请咨询律师。我不是一个,许可证非常复杂。
Other codecs include Vorbis and Opus. If you can use Opus, do so as the licensing is wide open and you get good quality for the bandwidth. Client compatibility here though is the killer of Opus. (Maybe in a few years it will be better.) Vorbis is a mediocre codec, but is free and clear.
其他编解码器包括Vorbis和Opus。如果您可以使用Opus,请执行此操作,因为许可是敞开的,您可以获得良好的带宽质量。这里的客户兼容性是Opus的杀手。 (也许在几年后会更好。)Vorbis是一个平庸的编解码器,但是*而清晰。
On the extreme end, I have some stations doing their streaming in FLAC. This is lossless audio quality, but you're paying for 8x the bandwidth as you would with a medium quality MP3 station. FLAC over HTTP streaming compatibility is not code at the moment, but it works alright in VLC.
在极端情况下,我有一些电台在FLAC中进行流媒体播放。这是无损的音频质量,但你需要支付8倍的带宽,就像使用中等质量的MP3电台一样。 FLAC over HTTP流兼容性目前不是代码,但它在VLC中可以正常工作。
It is very common to support multiple codecs for your streams. Depending on your budget, if you can't do that, you're best off with MP3.
支持流的多个编解码器是很常见的。根据您的预算,如果您不能这样做,那么最好使用MP3。
Finally on encoding, don't go from a lossy codec to another lossy codec if you can help it. Try to get the output stream as close to the input as possible. If you re-encode audio, you lose quality every time.
最后在编码时,如果可以帮助它,请不要从有损编解码器转到另一个有损编解码器。尝试使输出流尽可能靠近输入。如果重新编码音频,每次都会丢失质量。
Recording from Browser
You mentioned users streaming from a browser. I built something like this a couple years ago with the Web Audio API where the audio is captured and then encoded and sent off to Icecast/SHOUTcast servers. Check it out here: http://demo.audiopump.co:3000/ A brief explanation of how it works is here: https://*.com/a/20850467/362536
您提到用户从浏览器流式传输。几年前,我用Web Audio API构建了类似的东西,音频被捕获然后被编码并发送到Icecast / SHOUTcast服务器。在这里查看:http://demo.audiopump.co:3000 /它的工作原理的简要说明如下:https://*.com/a/20850467/362536
Anyway, I hope this helps you get started.
无论如何,我希望这可以帮助你开始。
#2
Streaming straight audio/mpeg (mp3 packets) has worked everywhere I've tried.
直播音频/ mpeg(mp3数据包)在我尝试过的任何地方都有用。
#3
If you are developing an APP then go with AAC, if you are simply playing via web browser then you need a HTML5 Implimentation which is MP3. All custom protocols like RTMP or SHOUTcast requires additional UI to be built. There are some third party players available in open source world. You can either use them or stick to HTML5 MP3/OGG as most people now days are using chrome browser or other HTML5 complaint browsers.
如果您正在开发APP,那么请使用AAC,如果您只是通过网络浏览器播放,那么您需要一个HTML5 Implimentation就是MP3。所有自定义协议(如RTMP或SHOUTcast)都需要构建其他UI。在开源世界中有一些第三方玩家可用。您可以使用它们或坚持使用HTML5 MP3 / OGG,因为现在大多数人都在使用Chrome浏览器或其他HTML5投诉浏览器。