Android的MediaPlayer为什么需要这么长时间来准备播放的实时流？

Question

我发现Android MediaPlayer准备使用不同的流进行实时流播放所花费的时间差异很大.

硬数据

我在prepareAsync()和onPrepared(MediaPlayer mp)回调之间添加了日志记录,并且每次都测试了几个流.每个流的时间非常一致(+/- 1秒),结果如下:

1. MPR新闻流:27秒(http://newsstream1.publicradio.org:80/)
2. MPR古典音乐流:15秒(http://classicalstream1.publicradio.org:80/)
3. MPR当前流:7秒(http://currentstream1.publicradio.org:80/)
4. PRI流:52秒(http://pri-ice.streamguys.biz/pri1)

测试是在带有Android 2.3.4的Nexus S上进行的3G连接(~1100 Kbps).

播放非流式MP3音频文件不是问题.

以下是我如何播放流的片段:

准备MediaPlayer:

...
mediaPlayer.setDataSource(playUrl);
mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
mediaPlayer.prepareAsync();
...

然后在onPrepared(MediaPlayer mp):

mediaPlayer.start();

为什么要准备一些流而不是其他流需要这么长时间？上述数据似乎表明它可能基于已缓冲的数据量而不是缓冲的音频内容的持续时间.真的可以吗？

更新:我已经使用Android 1.6,2.2和2.3.4以及1.6,2.1,2.2,2.3.1和2.3.3的仿真器测试了物理设备上的实时流媒体.我只看到2.3.3和2.3.4的长时间延迟.旧版本在5秒内开始播放.

Answer 1

看起来它似乎缓冲固定数量的数据而不是固定的时间量.对于那些不知道各种类型的NPR流的比特率的人来说,数据看起来像:

1. MPR消息流:27秒(http://newsstream1.publicradio.org:80/),64kbps的
2. MPR古典音乐流:15秒(http://classicalstream1.publicradio.org:80/),128 kbps的
3. MPR当前流:7秒(http://currentstream1.publicradio.org:80/),128 kbps的
4. PRI流52秒(http://pri-ice.streamguys.biz/pri1),32 kbps的

除了两个128 kbps流之间的差异外,比特率和缓冲持续时间之间存在非常好的相关性.

在任何情况下,Android都是开源的,因此您可以随时查看它正在做什么.不幸的是,prepareAsync()并且prepare()是本机方法,并且似乎也从本机进程调度与缓冲区相关的事件.

您是否尝试将附加OnBufferingUpdateListener到MediaPlayer以获得有关缓冲区状态的更细粒度的更新？比较事件传递的速率和缓冲区填充不同流中每个事件的百分比可能会很有趣.您可以针对流比特率进行交叉引用,如果以32 kbps的速度缓冲4秒,填充缓冲区的速度与1秒的128 kbps缓冲相同,那么我认为您将找到答案.

Answer 2

MediaPlayer通过FFmpegMediaPlayer 切换比MediaPlayer你想要测试你的流你可以通过他们拥有的演示来做更多的工作.

Answer 3

我最近使用流音频提供商调试了相同的问题。该问题与舞台惊吓和32kbps及更低的流媒体源有关。我们逐步完成了相同的流传输，以24、32、48、64和128 kbps的速度测量了响应时间。

• 24-> 46秒开始流式传输
• 32-> 24秒开始流式传输
• 48-> 2秒开始流式传输
• 64-> 2秒开始流式传输
• 128-> 2秒开始流式传输

这来自于每个位速率平均经过10次尝试的一致的无线连接。正如Travis所指出的那样，关键是Stagefright无法确定缓冲音频的时间。有时我会看到一条消息“错误：1，-21492389”左右，这似乎使stagefright播放器无声地崩溃。我试图对此进行跟踪，最终得出的结论是，非常慢的流（低于24 kbps）似乎会导致缓冲区溢出，因为它们会一直缓冲到设备用尽音频流的空间。

我想补充一点，OnBufferingUpdateListener在整个测试过程中，这对我完全没有用。我不知道它有什么用。我认为，您可以知道加载进行情况的唯一方法是代理加载，与上述NPR应用程序类似。