问题描述
我发现 Android MediaPlayer 准备使用不同流进行实时流播放所需的时间存在很大差异.
I am finding big differences in the time it takes the Android MediaPlayer to prepare for live stream playback with different streams.
硬数据
我在 prepareAsync() 和 onPrepared(MediaPlayer mp) 回调之间添加了日志记录，并且每个流都测试了几次.每个流的时间都非常一致(+/- 一秒)，结果如下:
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:
- MPR 新闻流:27 秒 (http://newsstream1.publicradio.org:80/)
- MPR 古典音乐流:15 秒 (http://classicalstream1.publicradio.org:80/)
- MPR 当前流:7 秒 (http://currentstream1.publicradio.org:80/)
- PRI 流:52 秒 (http://pri-ice.streamguys.biz/pri1)
测试是在配备 Android 2.3.4 的 Nexus S 上通过 3G 连接 (~1100 Kbps) 进行的.
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:
准备媒体播放器:
...
mediaPlayer.setDataSource(playUrl);
mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
mediaPlayer.prepareAsync();
...
然后在 onPrepared(MediaPlayer mp):
Then in onPrepared(MediaPlayer mp):
mediaPlayer.start();
为什么准备一些流而不是其他流需要这么长时间?上述数据似乎表明它可能基于已缓冲的数据量而不是缓冲音频内容的持续时间.真的会这样吗?
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:
- MPR 新闻流:27 秒(http://newsstream1.publicradio.org:80/), 64 kbps
- MPR 古典音乐流:15 秒(http://classicalstream1.publicradio.org:80/)、128 kbps
- MPR 当前流:7 秒(http://currentstream1.publicradio.org:80/)、128 kbps
- PRI 流:52 秒(http://pri-ice.streamguys.biz/pri1)、32 kbps
- MPR news stream: 27 seconds (http://newsstream1.publicradio.org:80/), 64 kbps
- MPR classical music stream: 15 seconds (http://classicalstream1.publicradio.org:80/), 128 kbps
- MPR The Current stream: 7 seconds (http://currentstream1.publicradio.org:80/), 128 kbps
- 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 是开源的，因此您始终可以看看它在做什么.不幸的是，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 以获得有关缓冲区状态的更细粒度的更新?比较事件传递的速率以及缓冲区在不同流中的每个事件上填充的百分比可能会很有趣.您可以将其与流比特率进行交叉引用，如果 32 kbps 的 4 秒缓冲填充缓冲区的百分比与 128 kbps 的 1 秒缓冲相同，那么我想您会找到答案.
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 准备一些直播流进行播放需要这么长时间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！