MediaPlayer.seekTo的準確性（int msecs）

爲什麼MediaPlayer.seekTo(int msec)如此不準確？MediaPlayer.seekTo的準確性（int msecs）

它有時30秒提前（與可變和恆定比特率的MP3的）！正在尋求與音頻固有問題或是這種方法打破？它是與緩衝還是什麼有關？

我也注意到，總運行時間getDuration()可能是錯誤的（這不是一個大問題），我測試了getCurrentPosition()是足夠準確的（如每n秒播放一次，它增加了一千）。我在Android 2.2上。

最後，有沒有人知道哪種格式，如果它實際上一致工作（最好是除了大概它的wav以外）？

編輯：

我主要收聽播客。即使經過轉換/重新編碼爲CBR，smodcast和Thinking Allowed也會出現多次問題。這些文件沒有損壞。

QuickMediaConverter（Windows）似乎工作正常，但聲音轉換器（Ubuntu）已經生成了一些狡猾的文件。我會嘗試堅持前...

更新：QuickMediaConverter工作得很好，但不知道爲什麼。沒有問題，因爲！

來源

2011-07-27 karnok

我不知道任何關於android。但我知道，在大多數媒體文件格式的有一個規定，即所謂的尋求項目或線索進入.. ，顯示了從這裏這個特定時刻的視頻&音頻應開始播放

如果跌破時間有線索進入 10秒
12秒
14秒

那麼如果你尋求到11秒，那麼它將永遠從10秒玩，如果你尋求12秒則總是從12秒

玩爲了更好的尋找文件應該與高提示條目進行混合。

來源

2011-08-02 05:26:15

有多種方式可以使多媒體框架在多媒體文件上執行查找操作。

尋求到關鍵幀 - 當編碼通常都會有一些所謂的I幀或關鍵幀的視頻，這意味着這個框架有大量的信息，並且可以使用的全部解碼幀。爲了減少空間量，所有的幀都不會被編碼爲關鍵幀，而是被編碼爲P（預測）幀或預測幀，這意味着您可以在關鍵幀的幫助下解碼P幀。

所以在尋找操作期間，在這種情況下，尋找在給定的持續時間內完成到最近的關鍵幀。例如，如果用戶尋求40秒，並且最接近的關鍵幀在35秒，則尋找到35秒而不是40秒。
尋求時間 - 這是尋求準確的時間，用戶的要求。

尋找仍然在最接近的關鍵幀完成，否則你會看到綠色補丁或視頻像素化是非常不可取的。因此，對關鍵幀進行搜索，然後對幀進行解碼直到所需的時間，但這些幀被丟棄並且不向用戶顯示。在上面的例子中，從第35秒到第40秒的所有解碼幀都被丟棄，只有超過第40秒的幀才顯示給用戶。

在音頻的情況下，只有文件有可能出現兩種情況（如果沒有分析器或不列入建設時間戳表，然後解析器 - ）

CBR - 恆定比特率 - 由於比特率是恆定的，我們可以跳過必要的字節數到給定的時間（比特率* timeToSeek =要跳過的字節）
VBR-可變比特率 - 比特率不是恆定的，它保持不變。因此，在這種情況下，找出文件的平均比特率，然後使用上述方法，在這種情況下，搜索將不準確。

現在回到你的問題，我可以肯定地告訴大家，它工作得很好，是準確的爲廣大mediafiles的。

您可能會遇到此類問題的唯一原因是因爲媒體文件本身已損壞。（在搜索過程中不可能有30秒的差異，你說的持續時間沒有被正確地返回，並且沒有媒體播放器API在Android 2.2中被破解）

至於Android支持哪種格式這link

所以你可以嘗試與另一個MP3文件？

來源

2011-08-02 06:47:41 bluefalcon

神聖的廢話，謝謝你一百萬次。我試圖用Phonegap來包裝我的webapp，而我的音頻小精靈則沒有辦法。我認爲這是因爲phonegap的性能...然後在學習android和製作我的第一個應用程序後，發現我得到了相同的準確性問題。經過2天的開發，我讀了這個答案，並意識到我使用了一個非常壓縮的'ogg'文件，這是有道理的。我使用了更高質量的聲音和繁榮，我所有的音頻精靈都完美運行。 – ilovett

MediaPlayer.seekTo的準確性（int msecs）

回答

相關問題