使用jPlayer开发了一个互联网广播流媒体，它利用了jQuery的html5音频标签，并为不支持的浏览器提供了闪回功能。在iPhone（iOS 5.0.1）上测试播放器后，我们遇到了一个非常特殊的问题。
当iPhone连接到WiFi时，它使用HE-AAC V2流@ 64kbps 44.1kHz（Apple产品的首选编解码器）完美流式传输。然而，当iPhone连接到3G移动网络时，它会“断续续续”或每1-2分钟停止流动1-2秒（不会完全停止流式传输）。令人不安的是，当iPhone被迫以相同的比特率使用单独的MP3流时，它没有这个问题并且在3G上工作得非常好。
更新5
我们最近购买了3G / 4G Sprint移动热点设备并使用该设备测试了这个问题。当iPhone连接到移动热点时，它显示为连接到wifi设备，即使实际连接是通过3G / 4G，也不会出现问题。这可能会回到iPhone不通过HTTP直播和直接连接到移动网络处理HE-AAC的问题。
更新4
将iPhone更新为iOS 5.1但问题仍然存在。
更新3
在此处阅读有关连接到移动网络时脚本无法正确呈现的各种问题。手指似乎指向可能插入代理服务器的移动网络运营商，例如，用于缩小图像尺寸。它也可能会注入一些JavaScript页面。可以找到测试页面HERE注意：此页面使用HE-AAC，因此它只适用于iPhone ...
更新
根据Apple针对iOS设备的HTTP直播流文档，“仅音频内容可以是MPEG-2传输，也可以是带有ADTS标头或MP3格式的AAC格式的MPEG基本音频流。”我们的音乐服务器使用OddcastV3编码器向icecastV2服务器发送三个流（MP3，HE-AAC V2和Oggvorbis）。不确定编码器是否正在插入HE-AAC V2流的ADTS标头。有没有办法检查这个？
答案 0 :(得分：1)
从无线电规划的角度来看 - 这是我的两分钱：
您所描述的内容听起来像带宽整形 - 这是无线电网络（如3G网络）的常见设计和常用设计。在我工作的大多数3G运营商中，通常会优化您的网络以提供高速突发（想想下载图像，发送一封电子邮件或获取一个HTML页面） - 通过“长期运行”的高带宽服务。 这是因为这是大多数用户想要/需要的简单事实。
这种整形可以在典型的3GPP（GSM 3G）网络上导致您首先获得支持384kbit的RAB（无线电接入承载），然后只要您的设备接受它就降级。 这意味着您将从384转换为典型 - > 256 - ＆gt; 128，然后64kbit，你的设备可能开始缓慢接收数据，然后网络升级它，并在一段时间后再次降级。
那么为什么MP3文件不会出现口吃呢？我的猜测是总的kbit率可能会有所不同 - 所以你在64kb的RAB中没问题。这是一种普遍现象。
答案 1 :(得分：0)
我们已经设法完成同样的工作。移动设备上的64kbit AAC-v2。我们是流媒体文件，而不是源源不断，我认为Magnus是正确的，当他解释网络如何优先考虑流量突发时，在我们的情况下，这意味着我们立即拥有大部分文件，播放器可以继续播放直到下一个爆发进来。在你的情况下，这意味着流暂停直到下一次爆发。
如果您可以在流式传输（更大的缓冲区）中切换到更大的块，或者改为流式传输整个文件？
iOS有一个非常奇怪的现象，我们不得不将.m4a中的所有文件重命名为.aac，以便能够在iOS上进行流式传输。如果我们没有重命名它们iOS就不会播放它们。
祝你好运。