为什么要花这么长的时间Android的MediaPlayer的，以prepare一些实时流播放？ [英] Why does it take so long for Android's MediaPlayer to prepare some live streams for playback?

问题描述

我发现它采用了Android的MediaPlayer，以prepare的实时流播放不同流的时间差异很大。

I am finding big differences in the time it takes the Android MediaPlayer to prepare for live stream playback with different streams.

的硬数据

我添加prepareAsync（）和上prepared（MediaPlayer的熔点）回调并测试了流了几次每次之间登录。本次为每个数据流都非常一致（+/-一秒），而这里的结果：

I added logging between prepareAsync() and the onPrepared(MediaPlayer mp) callback and tested several streams a few times each. The times for each stream were very consistent (+/- one second), and here are the results:

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）

测试是一台Nexus S上的3G连接（〜1100 Kbps）的执行与Android 2.3.4。

The tests were performed on a Nexus S with Android 2.3.4 on a 3G connection (~1100 Kbps).

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

Playing non-streaming MP3 audio files is not an issue.

下面是片段，我怎么打流：

Here are snippets of how I am playing the streams:

prepare MediaPlayer的：

Prepare MediaPlayer:

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

然后在prepared（MediaPlayer的熔点）：

Then in onPrepared(MediaPlayer mp):

mediaPlayer.start();

为什么要花这么长的时间prepare某些流而不是其他人？上述数据似乎表明，它的也许的立足于量的数据已经被缓存，而不是的时间的缓冲音频内容。难道这真的是？

Why does it take so long to prepare some streams but not others? The above data seems to suggest that it might be based on the amount of data that has been buffered and not the duration of the buffered audio content. Could this really be?

更新：我已经测试流媒体直播上的物理设备与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秒钟内播放。

Update: I have tested live streaming on physical devices with Android 1.6, 2.2 and 2.3.4 and emulators with 1.6, 2.1, 2.2, 2.3.1 and 2.3.3. I am only seeing the long delay on 2.3.3 and 2.3.4. The older versions start playback within 5 seconds.

推荐答案

有确实出现，它是缓冲数据的一个固定量，而不是固定的时间量。对于任何人谁不知道各种类型的比特率的NPR流过他们的头顶上，数据是这样的：

It does appear that it is buffering a fixed amount of data rather than a fixed amount of time. For anyone who doesn't know the bitrates of various types of NPR streams off the top of their head, the data looks like:

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

1. MPR news stream: 27 seconds (http://newsstream1.publicradio.org:80/), 64 kbps
2. MPR classical music stream: 15 seconds (http://classicalstream1.publicradio.org:80/), 128 kbps
3. MPR The Current stream: 7 seconds (http://currentstream1.publicradio.org:80/), 128 kbps
4. PRI stream: 52 seconds (http://pri-ice.streamguys.biz/pri1), 32 kbps

除了两个128 kbps的数据流之间的差​​异，有位速率和缓冲的持续时间之间具有非常良好的相关性。

Apart from the discrepancy between the two 128 kbps streams, there is a very good correlation between bitrate and buffering duration.

在任何情况下，Android是开源的，所以你总是可以<一href="http://www.netmite.com/android/mydroid/frameworks/base/media/java/android/media/MediaPlayer.java">look在它在做什么。不幸的是， prepareAsync（）和 prepare（）是本地方法，似乎缓冲区 - 相关事件从本机进程调度为好。

In any case, Android is open-source, so you could always look at what it's doing. Unfortunately, prepareAsync() and prepare() are native methods, and it appears that buffer-related events are dispatched from a native process as well.

您是否尝试过附加一个 OnBufferingUpdateListener 到的MediaPlayer，以获取有关缓冲状态更细粒度的更新？这可能是有趣的比较，在该事件传递及相应比例的缓冲区满跨不同数据流的每个事件的速率。您可以交叉参考，对数据流的比特率，而如果4秒缓冲的32 kbps的填充缓冲相同的百分比1秒缓冲的128 kbps的话，我想你一定会找到你的答案。

Have you tried attaching an OnBufferingUpdateListener to the MediaPlayer to get finer-grained updates about the buffer-state? It might be interesting to compare the rate at which the events are delivered and by what percentage the buffer fills on each event across the different streams. You can cross-reference that against the stream bitrates, and if 4 seconds of buffering at 32 kbps fills the buffer the same percentage as 1 second of buffering at 128 kbps then I think you will have found your answer.

这篇关于为什么要花这么长的时间Android的MediaPlayer的，以prepare一些实时流播放？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！