为什么Android的MediaPlayer要花这么长时间才能准备一些实时流来播放呢？

Question

我发现在安卓MediaPlayer为不同流的实时播放做准备的时间上有很大的不同。

硬数据

我在prepareAsync()和onPrepared(MediaPlayer mp)回调之间添加了日志记录，并对每个流进行了几次测试。每个流的时间非常一致(+/- 1秒)，以下是结果：

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

这些测试是在Nexus和Android2.3.4的3G连接(~1100 Kbps)上进行的。

播放非流式MP3音频文件不是一个问题。

下面是我如何演奏溪流的一些片段：

准备MediaPlayer：

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

然后在onPrepared(MediaPlayer Mp)中：

mediaPlayer.start();

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

更新:我已经用Android1.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. 新闻流: 27秒(http://newsstream1.publicradio.org:80/)，64 kbps
2. MPR古典音乐流:15秒(http://classicalstream1.publicradio.org:80/)，128 kbps
3. 当前流: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以获得有关缓冲区状态的更细粒度的更新？比较事件的传递速度和缓冲区在不同流中对每个事件填充的百分比可能会很有趣。您可以对照流比特率交叉引用，如果32kbps的4秒缓冲填充缓冲区的百分比与128kbps的1秒缓冲的百分比相同，那么我认为您已经找到了答案。

Answer 2

MediaPlayer by FFmpegMediaPlayer比MediaPlayer要好得多，如果您想测试您的流，您可以通过它们拥有的演示来完成它。

Answer 3

我最近在一个流媒体音频提供商中调试了同样的问题。这个问题与32 32kbps和更低的流媒体资源有关。我们以24，32，48，64和128 kbps的速度通过相同的流测量响应时间。

• 24 -> 46秒开始播放
• 32 -> 24秒启动流
• 48 -> 2秒开始播放
• 64 -> 2秒启动流
• 128个-> 2秒启动流

这是从一个一致的，无线连接平均超过10次尝试在每个比特率。正如特拉维斯所指出的，关键是舞台上的人无法计算出需要多长时间来缓冲音频。有时我会看到一条‘错误: 1，-21492389’左右的信息，这似乎让舞台上的玩家安静地崩溃了。我试图追踪这一点，并最终得出结论，非常慢的流(低于24 kbps)似乎会导致缓冲区溢出，因为它们会缓冲，直到设备耗尽音频流的空间。

我想补充的是，在整个测试过程中，OnBufferingUpdateListener根本没有为我开火。我不知道那是为了什么。我认为唯一的方法，你可以知道如何加载是代理加载，以类似的方式，以上提到的NPR应用程序。