mediaplayer seekTo（）以字節爲單位的偏移量

我期望獲得由MediaPlayer類的seekto()方法使用的字節偏移量。mediaplayer seekTo（）以字節爲單位的偏移量

我想知道是否有任何方式直接以某種方式檢索這些信息，如果不是，如果不是我自己計算它，例如：如果媒體文件在其元數據中有註冊比特率，我想尋求10秒鐘，我可以使用以下的計算：

10(secs)*(bit rate per second)/8

我可以假設MediaPlayer檢索使用MediaMetadataRetriever類的比特率的信息？

我已閱讀以下內容： Accuracy of MediaPlayer.seekTo(int msecs) 我也意識到了與可變比特率的問題，但我不是在seekto()方法尋找準確性而是如何獲得/計算它使用的偏移值檢索新的數據。

來源

2013-03-23 Nims

基於偏移量實現seekTo()的目標是新穎的，但同樣存在多重挑戰。在進入seekTo()實施之前，有關MediaPlayer和MediaMetadataRetriever的一些說明。這兩個類都在內部使用MediaExtractor對象來檢索metadata信息。因此MediaPlayer不包括包括MediaMetadataRetriever類。

首先，我們來考慮提取比特率。 MediaPlayer是一個應支持多種文件格式的通用實現。因此，對於你的設計，你需要確保bitrate參數由般的視聽格式，如MP4，MPEG-2 TS，AVI，Matroska等，或音頻格式只喜歡WAV，MP3等。在您的系統支持所有的文件格式中提取最新的android實現，我發現只有MP3Extractor是通過kKeyBitrate鍵暴露比特率。

接下來，來到您的算法，我發現以下挑戰附加到基於大小的查找。

audio和video音軌以交錯方式存儲。因此，由於輸入數據的交錯性質，time * bitrate (in bytes)不會直接有用。
需要考慮起始偏移量。在該文件中，有一些metadata或boxes存儲在該文件開始時特定於文件格式的文件中。您將不得不考慮這種偏移，對於不同的格式也會有所不同。
如果輸入有一個像audio，video，text或者說多個audio軌道的軌道更mnumber作爲一部電影，那麼問題將變得更爲複雜。
視頻幀的大小通常不規則。即使使用恆定比特率模型，視頻幀的大小可能會根據幀的類型顯着變化。通常，與P-frame或B-frame相比，I-frame/IDR-Frame in H.264可消耗大量的位。這將對基於尺寸的seekTo()實現造成實際困難。人們可以很容易地觀察1：5的比例在外形尺寸方面爲I和P幀
有，你已經承認了可變比特率模型的一定影響。因此，我忽略了這一點。

：在上述點，沒有勸阻你，我覺得size根據實施看起來是困難的。

來源

2013-03-24 00:52:27 Ganesh

謝謝Ganesh，我仍然想知道是否有辦法從mediaplayer本身檢索這些數據。考慮一個在HTTP情況下執行搜索的流式傳輸，我假設一個範圍請求將由mediaplayer執行，並且這個數據應該在那裏。 – Nims 2013-03-24 03:16:43

當通過'http'流數據時，通過'NuCachedSource2'有一個緩存實現。因此，seekTo將首先在本地頁面緩存中被觸發。如果範圍不同，我認爲請求仍然是基於時間而不是大小。 – Ganesh 2013-03-24 03:34:58

mediaplayer seekTo（）以字節爲單位的偏移量

回答

相關問題