我正在使用Ionic 3框架开发互联网广播应用程序。我想出了这个使用HTML5音频元素的简单代码。许多人认为这种方法比使用@ionic原生/流媒体插件更好。
以下是我的实现：
.HTML
<audio id="audioStream" src="http://icecastserverIP:8000/icecastchannel" autoplay></audio>
<a href="#" id="player">
<div class="btn-play" id="con-btn-play">
<img src="assets/img/btn-play.png" alt="Play">
</div>
</a>
.JS
$(document).ready(function(){
var audio = $('#audioStream')[0]
// Preloader animation
audio.addEventListener('waiting', function () {
$('#con-btn-play').html('<img src="assets/img/preloader.gif">');
}, false);
audio.addEventListener('playing', function () {
$('#con-btn-play').html('<img src="assets/img/btn-pause.png">');
}, false);
// Play button behaviour
$('#player').click(function(){
if (audio.paused){
audio.play();
$('#con-btn-play').html('<img src="assets/img/btn-pause.png" alt="Pause">');
}else {
audio.pause();
$('#con-btn-play').html('<img src="assets/imgs/btn-play.png" alt="Play">');
}
});
});
该流在Android和iOS中运行良好。但是，在最轻微的连接中断时，音频将停止并且不会重新连接。更不用说如果我按暂停，流将继续在后台使用数据。
我的问题是：有没有更好的方法来处理冰铸流？您会推荐的第三方插件以获得更好的缓冲管理和游戏体验？
我建议的第一件事是在您的 Icecast 服务器设置中增加<queue-size>和<burst-size>的值。
默认情况下，服务器在客户端连接时只会发送 64kb 的音频流作为缓冲区，对于 320kbps mp3 流，这不到 2 秒。
将<audio>元素的预加载标记设置为 none 或元数据应该可以防止在暂停时无休止地流式传输数据，或者您可以将playbackRate参数设置为 0.0 或将src更改为 null 值，然后在 audio 元素上调用.load()以在暂停时断开客户端与流的连接。
可以通过在连接时添加额外的请求标头，让您的 Icecast 服务器将元数据直接编码到音频流中。优点是很容易将元数据更新与音频同步。
我编写了一个基本的服务工作者脚本来处理该过程，它将必要的标头添加到请求中，然后解析返回的流以提取元数据并创建一个可读流，仅包含传递给音频元素的音频数据。
代码在Github上，如果你想尝试一下。
但是，在最轻微的连接中断时，音频将停止并且不会重新连接。
可以通过处理 Audio 元素上的error事件来重新连接自己的代码。 https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/onerror
更不用说如果我按暂停，流将继续在后台使用数据。
是的，您需要创建自己的 UI 来控制此元素。 当有人暂停时，您会想改为拨打.stop()电话。 默认情况下，audio 元素假定在某个时间点结束的常规音频文件。
第三方插件...
无需插件。
。更好的缓冲管理和播放体验？
通过我在此答案中提出的两个建议，您可以为用户提供有用的体验。 但是，您还可能遇到另外两个问题。
首先，浏览器不请求常规 ICY 元数据，也不解码。
第二个问题是，由于浏览器将您的流视为常规音频文件，因此它还将所有音频数据缓冲到内存中。 这对于您永远不会返回并播放以前播放的音频的实时流不是很有用。 (这很少是您遇到的问题，因为音频数据需要相对较少的内存量，但问题确实存在。
这两个问题都可以通过使用媒体源扩展来解决。 使用 MSE，您可以直接控制检索数据、解复用元数据以及将数据推送到缓冲区进行播放。 由于代码受控制，因此可以无限期地流式传输而不会发生内存泄漏。