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（）不能按預期工作

回答

相關問題