23

使用 jPlayer 开发了一个互联网广播流媒体，它利用 jQuery 的 html5 音频标签，并为不支持的浏览器提供了闪退。在 iPhone (iOS 5.0.1) 上测试播放器时，我们遇到了一个非常特殊的问题。

当 iPhone 连接到 WiFi 时，它使用 HE-AAC V2 流@64kbps 44.1kHz（苹果产品的首选编解码器）完美流式传输。但是，当 iPhone 连接到 3G 移动网络时，它会“卡顿”或每 1-2 分钟停止流式传输 1-2 秒（不会完全停止流式传输）。令人不安的是，当 iPhone 被迫以相同的比特率使用单独的 MP3 流时，它没有这个问题并且在 3G 上运行良好。

更新 5

我们最近购买了一个 3G/4G Sprint 移动热点设备，并用该设备测试了这个问题。当 iPhone 连接到移动热点时，它显示为连接到 wifi 设备，即使实际连接是通过 3G/4G，问题也不会出现。这可能指向 iPhone 不通过 HTTP Live Streaming 处理 HE-AAC 以及直接连接到移动网络时的问题。

更新 4

将 iPhone 更新到 iOS 5.1，但问题仍然存在。

更新 3

在此处阅读有关连接到移动网络时脚本无法正确呈现的各种问题。手指似乎指向可能正在插入代理以服务网页的移动网络运营商，例如缩小图像大小。它也可能会注入一些 JavaScript 页面。测试页面可以在这里找到 注意：这个页面使用的是 HE-AAC，所以它只能在 iPhone 上运行......

更新

根据 Apple 针对 iOS 设备的 HTTP Live Streaming 文档，“纯音频内容可以是 MPEG-2 传输或 MPEG 基本音频流，可以是带有 ADTS 标头的 AAC 格式，也可以是 MP3 格式。” 我们的音乐服务器使用 OddcastV3 编码器将三个流（MP3、HE-AAC V2 和 Oggvorbis）发送到 icecastV2 服务器。不确定编码器是否为 HE-AAC V2 流插入 ADTS 标头。有没有办法检查这个？

4

2 回答 2

1

从无线电规划的角度来看 - 这是我的两分钱：

您所描述的听起来像是带宽整形——这是无线电网络（如 3G 网络）的常见且经常需要的设计。在我为您工作的大多数 3G 运营商中，通常会优化您的网络以提供高速突发（想想下载图像、发送一封电子邮件或获取一个 HTML 页面）——而不是“长期运行”的高带宽服务。这是由于一个简单的事实，即这是大多数用户想要/需要的。

这种整形可以在典型的 3GPP (GSM 3G) 网络上导致您首先获得支持 384kbit 的 RAB（无线接入承载），然后只要您的设备接受它就会降级。这意味着您通常会从 384 -> 256 -> 128 切换，然后是 64kbit，您的设备可能开始缓慢接收数据，然后网络对其进行升级并在一段时间后再次对其进行降级。

那么为什么MP3文件不卡顿呢？我的猜测是总 kbit 速率可能不同 - 所以你在 64kbit RAB 中没问题。这是一种普遍现象。

于 2012-07-01T19:08:52.847 回答
0

我们已经设法让完全相同的东西正常工作。移动设备上的 64kbit AAC-v2。我们正在流式传输文件，而不是稳定的流，我认为 Magnus 解释了网络如何优先处理突发流量时是正确的，在我们的例子中，这意味着我们立即拥有大部分文件，播放器可以继续播放，直到他下一个爆发进来。在你的情况下，这意味着流暂停，直到下一个爆发到来。

如果您可以切换到流式传输中的更大块（更大的缓冲区）或流式传输整个文件？

我们在 iOS 中遇到了一个非常奇怪的现象，我们必须将所有文件从 .m4a 重命名为 .aac 才能让它们在 iOS 上流式传输。如果我们不重命名它们，iOS 就不会播放它们。

祝你好运。

于 2012-07-15T06:00:17.370 回答