Android MediaPlayer seekTo（）/ getDuration（）不能按预期工作

我正在使用android MediaPlayer库播放一些MP3文件。我不负责这些文件，无法改变它们，只能播放它们。Android MediaPlayer seekTo（）/ getDuration（）不能按预期工作

我目前正在更新一个进度条，以了解用户当前所处文件有多远，将进度条的最大值设置为mediaPlayer.getDuration()。我知道由此返回的值是正确的。我post每500ms延迟一次Runnable以更新进度栏，值为mediaPlayer.getCurrentPosition。这一切都按预期正常工作。

当我尝试使用seekTo方法时，会发生此问题（但偶尔它会按我的预期工作）。我创建的媒体播放器对象有一个OnSeekCompleteListener注册。当我拨打mediaPlayer.seekTo(50000)时，使用mediaPLayer.getCurrentPosition()在OnSeekCompleteListener中输出的值是我告诉它寻找的正确值（在这种情况下，假设我们从1000ms开始到该文件为51000）。但是，当postDelayed runnable运行以更新进度栏时，mediaPlayer.getCurrentPosition()返回的值通常（95％的时间）显着低于OnSeekCompleteListener中输出的值。

似乎没有任何韵律或理由对最终被返回的值，因为即使发生完全相同的情况，它们每次都是不同的。

编辑：之后说的价值总是不同的事实证明，这是不完全正确的。如果我尝试寻找音频的最后部分，它总是会跳回到同一点（如果相信getCurrentPosition（）方法，大约在2-3小时之前）。

为了使事情更加复杂，如果我使用Audacity和LAME（使用默认设置）对原始文件进行重新编码，则此问题消失。我只能做到这一点作为测试，因为当我的应用程序上线时，我将无法控制编码文件。

如果任何人有任何想法，他们将不胜感激。

参考：下面是来自afinfo命令在Mac上获得的原始文件的值：

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

编辑：这是正在在Android 6.0上测试了索尼的Xperia

来源

2016-04-14 MultiJ

这是一个已知问题与媒体播放器，据我所知是没有解决的办法：

https://code.google.com/p/android/issues/detail?id=11590 https://code.google.com/p/android/issues/detail?id=2559

来源

2016-04-14 13:12:12 user3673952

我不是这个很肯定所描述的症状也不尽相同。他们没有描述正确的位置报告，然后随后跳回来。此外，这些文件编码为44100MHz。之前我曾经遇到过这些问题，并将它们排除在外，因为它们也被标记为过时。 – MultiJ

经过一些进一步的调查后，我在Android 4.3上测试了这个问题，它确实呈现了至少在其中一个错误报告中描述的症状。 – MultiJ

Android MediaPlayer seekTo（）/ getDuration（）不能按预期工作

回答

相关问题