基于Web的广播和音频流服务是否使用Web Audio API进行播放? [英] Does web based radio and audio streaming services use the Web Audio API for playback?

问题描述

我正在尝试确定基于Web的音频流网站是否使用Web Audio API进行播放，或者它们是否依赖音频元素或其他内容.

I'm trying to figure out if web based audio streaming sites use the Web Audio API for playback or if they rely on the audio element or something else.

由于音频流服务的用户通常不需要启动和停止音频以外的其他功能，所以我想音频元素就足够了.如果需要VU表，那么我猜想将使用Web Audio API，因为它具有内置的分析器节点.但是，由于IE不支持API，所以我想您宁愿使用audio元素并覆盖IE用户，也不愿使用诸如VU表之类的花哨的功能.

Since the user of an audio streaming service typically doesn't need more functionality than starting and stopping the audio, then I guess that the audio element is enough. If a VU-meter is required then I would guess the Web Audio API would be used since it has an built in analyser node. But since IE doesn't support the API then I suppose you'd rather use the audio element and reach the IE users than using fancy extras such as an VU-meter.

我一直在寻找Spotifys网络播放器，Grooveshark，BBC广播和波兰公共广播的源代码，但是我找不到音频元素或Web Audio API的使用.我确实发现瑞典公共广播电台(sr.se)还是利用了音频元素.

I've been looking at the source code for Spotifys web player, Grooveshark, BBC radio and the Polish public radio but I find neither audio elements or use of the Web Audio API. I did find that the Swedish public radio (sr.se) makes use of the audio element though.

我不是要任何人为我讲解JavaScript源代码，而是让熟悉此主题的人向我指出正确的方向.

I'm not asking for anyone to go through the JavaScript source code for me, but rather if someone who is familiar with the subject could point me in the right direction.

推荐答案

我不知道目前有任何互联网广播服务使用Web Audio API播放其流，但是我不会惊讶地找到一个.我一直在自己使用 Audiocog出色的Aurora.js库进行开发，该库可启用编解码器.-浏览器，通常无法使用，方法是使用JavaScript解码音频.但是，由于您所指出的兼容性原因，今天将其视为实验性质的.

I don't know of any internet radio services playing back their streams with the Web Audio API currently, but I wouldn't be surprised to find one. I've been working on one myself using Audiocog's excellent Aurora.js library, which enables codecs in-browser that wouldn't normally be available, by decoding the audio with JavaScript. However, for compatibility reasons as you have pointed out, this would be considered a bit experimental today.

大多数互联网广播电台使用渐进式HTTP流(SHOUTcast/Icecast样式)，可以在< audio> 元素或Flash中进行播放.这很好用，但是很难解决，特别是如果您使用SHOUTcast服务器，因为它们是 AudioPump服务器，以通过HTTP渐进式获得更好的浏览器和移动浏览器支持.

Most internet radio stations use progressive HTTP streaming (SHOUTcast/Icecast style) which can be played back within an <audio> element or Flash. This works well but can be hard to get right, especially if you use SHOUTcast servers as they are not quite 100% compatible with HTTP, hurting browser support in some versions of Firefox and a lot of mobile browsers. I ended up writing my own server called AudioPump Server to get better browser and mobile browser support with HTTP progressive.

根据您可用的Flash代码和ActionScript版本，您可能还必须以创造性的方式处理内存泄漏，因为默认情况下，Flash会无限期将您所有的流数据保留在内存中，因为它从未构建为通过HTTP进行流传输.许多服务器将RTMP与Flash(服务器上的 Wowza 或类似服务器)一起使用，用于解决此问题.

Depending on your Flash code and ActionScript version available, you might also have to deal with memory leaks in creative ways, since by default Flash will keep all of your stream data in memory indefinitely as it was never built to stream over HTTP. Many use RTMP with Flash (with Wowza or similar on the server), which Flash was built to stream with to get around this problem.

iOS支持 HLS ，它基本上是HTTP服务器提供的静态文件的集合.编码器在编码发生时将流的大块写入每个文件，客户端仅下载它们并进行无缝播放.这样做的好处是，客户端可以选择要传输的比特率，并且可以随着网络条件的变化而提高和降低质量.这也意味着您可以完全切换网络(例如，从WiFi到3G)，并且由于块是独立且无状态下载的，因此仍可以保持流的传输.Android支持" HLS，但是它有故障.Safari是当前唯一支持HLS的浏览器.

iOS supports HLS which is basically a collection of static files served by an HTTP server. The encoder writes a chunk of the stream to each file as the encoding occurs, and the client just downloads them and plays them back seamlessly. The benefit here is that the client can choose a bitrate to stream and, raising quality up and down as network conditions change. This also means that you can completely switch networks (say from WiFi to 3G) and still maintain the stream since chunks are downloaded independently and statelessly. Android "supports" HLS, but it is buggy. Safari is the only browser currently supporting HLS.

兼容性检测不是您自己需要解决的问题.有很多播放器，例如 jPlayer 和 JW播放器，它可以搅乱HTML5音频支持检测，编解码器支持检测，并提供HTML5音频回放和Flash之间的通用API.如果您要快速启动并运行，它们还提供了可选的UI.

Compatibility detection is not something you need to solve yourself. There are many players, such as jPlayer and JW Player which wrangle HTML5 audio support detection, codec support detection, and provide a common API between playback for HTML5 audio and Flash. They also provide an optional UI if you want to get up and running quickly.

最后，大多数电台确实提供了链接，使您可以在自己的媒体播放器中播放流.这是通过链接到播放列表文件(通常是M3U或PLS)完成的，该文件已下载并经常立即打开(由用户及其浏览器配置).播放器软件会加载此播放列表，然后直接连接到流服务器以开始播放.在Android上，您只需链接到流URL .它将检测 Content-Type 响应标头，断开连接，并打开其配置的媒体播放器进行播放.这些天，您不得不寻找这些直接链接，但是它们在那里.

Finally, most stations do offer a link to allow you to play the stream in your own media player. This is done by linking to a playlist file (usually M3U or PLS) which is downloaded and often immediately opened (as configured by the user and their browser). The player software loads this playlist and then connects directly to the streaming server to begin playback. On Android, you simply link to the stream URL. It will detect the Content-Type response header, disconnect, and open its configured media player for playback. These days you have to hunt to find these direct links, but they are out there.

如果您想了解某个电台在使用什么而无需深入了解其编译后的源代码，只需使用 Wireshark 并查看流量.您会发现引擎盖下的内容非常简单.

If you ever want to know what a station is using without digging around in their compiled and minified source code, simply use a tool like Fiddler or Wireshark and watch the traffic. You will find that it is very straightforward under the hood.

这篇关于基于Web的广播和音频流服务是否使用Web Audio API进行播放?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！