我使用android MediaPlayer库播放一些MP3文件。我不负责这些文件,无论如何都无法更改它们,只能播放它们。
我目前正在更新进度条,了解用户当前所处文件的距离,将进度条的最大值设置为mediaPlayer.getDuration()
。我知道这返回的值是正确的。我每隔500毫秒发布一个Runnable来更新进度条,其值为mediaPlayer.getCurrentPosition
。这一切都按预期正常工作。
当我尝试使用seekTo方法时会出现问题(但是偶尔它会像我期望的那样工作)。我创建的媒体播放器对象有一个注册的OnSeekCompleteListener。当我调用mediaPlayer.seekTo(50000)
时,使用mediaPLayer.getCurrentPosition()
在OnSeekCompleteListener中输出的值是我告诉它要寻找的正确值(在这种情况下假设我们从1000ms开始到文件中的51000)。但是,当postDelayed runnable运行以更新进度条时,mediaPlayer.getCurrentPosition()
返回的值通常(95%的时间)远低于OnSeekCompleteListener中输出的值。
最终返回的值似乎没有任何押韵或理由,因为即使出现完全相同的情况,它们每次都不同。
编辑:在说价值总是不同之后,事实证明并非如此。如果我试图寻找到音频的最后,它将始终跳回到同一点(如果要相信getCurrentPosition()方法,大约需要2-3个小时)。
为了使问题更复杂,如果我使用Audacity和LAME(使用默认设置)获取原始文件并重新编码,则此问题就会消失。我只能做这个测试,因为当我的应用程序上线时,我将无法控制文件的编码。
如果有人对此有任何想法,我们将不胜感激。
供参考:以下是从Mac上的afinfo命令获取的原始文件的值:
File: Test.mp3
File type ID: MPG3
Num Tracks: 1
----
Data format: 2 ch, 44100 Hz, '.mp3' (0x00000000) 0 bits/channel, 0 bytes/packet, 1152 frames/packet, 0 bytes/frame
no channel layout.
estimated duration: 35997.544490 sec
audio bytes: 216835607
audio packets: 1378031
bit rate: 48000 bits per second
packet size upper bound: 1052
maximum packet size: 522
audio data file offset: 1630
optimized
我重新编码的音频文件中的信息正常工作:
File: Test2.mp3
File type ID: MPG3
Num Tracks: 1
----
Data format: 2 ch, 44100 Hz, '.mp3' (0x00000000) 0 bits/channel, 0 bytes/packet, 1152 frames/packet, 0 bytes/frame
no channel layout.
estimated duration: 35997.596735 sec
audio bytes: 293659748
audio packets: 1378033
bit rate: 65000 bits per second
packet size upper bound: 1052
maximum packet size: 835
audio data file offset: 1560
optimized
audio 1587491712 valid frames + 576 priming + 1728 remainder = 1587494016
编辑:这是在Sony Xperia上的Android 6.0上进行测试
答案 0 :(得分:1)
这是媒体播放器的一个已知问题,AFAIK没有解决方案:
https://code.google.com/p/android/issues/detail?id=11590 https://code.google.com/p/android/issues/detail?id=2559