流式传输音频文件与静态提供音频文件
我有一个网站，用户可以在其中上传音频文件（aac 类型）。用户可以通过网络浏览器或移动设备（例如 iPhone 或 Android）播放音频文件。对于网络浏览器，我希望支持最新的 HTML5 音频标签，并为旧版浏览器提供 Flash 后备功能。
我做了一些研究，mp3 看起来像是向网络浏览器提供音频文件的最佳格式，因为一些现代浏览器本身支持 mp3，而对于不支持 mp3 的浏览器（FireFox）可以回退到 flash。用户上传 aac 文件后，我将创建音频文件的另一个版本作为可用于服务的 mp3。
提供这些音频文件的最佳方式是什么？流式传输还是静态服务？有什么优点或缺点吗？也许有一种灵活的服务器技术。我了解 Icecast，但我认为它不适合我的特定用例。
我还有一个关系数据库，它存储每个静态音频文件的链接。我想使用 HTTP 流而不是专有协议。最重要的是，我希望尽可能高效地做到这一点，因为带宽可能会变得昂贵。
I have a website where users can upload audio files (of type aac). The users can playback their audio files through a web browser or mobile devices such as a iPhone or an Android. For web browsers, I would like to support the latest HTML5 audio tag and have a flash fallback for older browsers.
I did some research and mp3 looks like the best format for serving audio files to a web browser because some modern browsers support mp3's natively and for browsers that don't (FireFox) can fallback to flash. Once the user uploads an aac file I will create another version of the audio file as an mp3 that can be used to serve.
What is the best way to serve these audio files? Streaming or statically serving? Are there any advantages or disadvantages? Perhaps there is a flexible server technology. I know about icecast but I don't think it fit my specific use case.
Also I have a relational db which stores a link to each static audio file. I would like to use HTTP streaming and not a propriety protocol as well. Most importantly I would like to do this as efficiently as possible since bandwidth may get expensive.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
认为 iDevices（iPhone、iPad、iPod）和 Android 手机支持的流媒体协议并不相同。 iDevices 支持 HTTP Streaming，而 Android 手机仅支持 RTSP 协议。
因此，如果您想使用流媒体协议为多个设备提供服务，则认为您必须为每种类型使用编码器/服务器（iDevices 的分段器和网络服务器，Android 的 RTSP 服务器）。
就效率而言，我认为您不会提高很多，但是使用 HTTP 流式传输您可以获得其他好处，例如可以使用多比特率文件，这允许您提供同一音频的不同编码版本，以根据不同的情况提供不同的音频质量用户→服务器连接速度。
实现 HTTP 流非常便宜。事实上，您可以使用 ffmpeg 对文件进行编码，并使用 Apple 提供的免费分段器来完成此操作。但是，请记住，这不适用于 Android 设备。
Think that the streaming protocols supported by iDevices (iPhone, iPad, iPod) and Android phones, are not the sames. While iDevices support HTTP Streaming, Android phones only support RTSP protocol.
So, if you want to serve multiple devices with a streaming protocol, think you will have to use encoders/servers for each type (segmenter and a webserver for iDevices, RTSP server for Android).
In terms of efficience I don't think you will improve a lot, but using HTTP streaming you get others benefits like the possibility to use multibitrate files, that allow you to serve different encoded versions of the same audio to serve different audio qualities depending on the user<->server connection speed.
Implement HTTP Streaming is very cheap. In fact, you can use ffmpeg to encode the files and the free segmenter provided for Apple to do it. But, remember that won't work for Android devices.