Azure blob storage 是 Azure 提供的一種服務，blob 存盤可以用來存盤一些松散結構的資料，例如各類文本檔案資料或者二進制資料（各型別格式檔案、媒體檔案以及應用安裝檔案）。
而對于在 Azure storage 存放的 mp3 等格式的媒體檔案，我們可以使用 Azure storage 提供的 url，可以通過瀏覽器訪問的形式來播放該類媒體檔案。這篇文章主要討論在使用 Azure Storage 提供的 url 播放媒體檔案時遇到的點播問題。需要注意的是，Azure Storage 主要提供的服務是存盤服務，對于媒體檔案的播放和編碼等作業，Azure 提供專業的 media services，詳細內容可以參考鏈接。
問題描述：
在 Azure 存盤中存放 mp3 檔案, 播放 mp3 檔案時, 拖動到還沒有快取好的進度時(例如已經緩沖到 10 秒, 現在拖動到 60 秒), 不能在第60秒開始緩沖接著播放, 會跳回第 10 秒播放。
問題分析：
對于視頻或者音頻檔案的播放，如果實作點播（拖拽到某一時間播放）效果可以基于兩種方式：Streaming 和 Progressive Download。
Streaming：一種實時流技術
? Streaming 不需要快取物體檔案，并且可以從任意時間點開始播放
? Streaming 在低速網路下會出現不斷卡頓緩沖問題
? Streaming 在傳輸方面會丟包
? Streaming 對網路的利用率更高
Progressive Download：一種分片后的分段式下載緩沖
? Progressive Download 需要將預下載檔案存放到本地存盤，并且默認情況下，播放器不會自動洗掉快取檔案
? Progressive Download 無法精確到幀開始播放，只能從流媒體檔案的切片點開始
? Progressive Download 在低速網路下具備更多優勢
? Progressive Download 由于需要校驗以及其他一些協議上的原因，網路利用率較低
? Progressive Download 由于基于 HTTP 協議，在傳輸方面出現丟包會重新傳輸資料
目前 Azure Blob storage 是不支持 Streaming 點播方式，但是 Azure Blob storage 可以支持 Progressive Download，也就是說我們可以使用 Blob Storage 實作 Progressive Download 形式的點播功能。
然而我們注意到一個問題是，默認情況下我們上傳到 Azure storage 中的檔案采用較低版本（2009-09-19）的 REST 協議，而低版本的協議是不支持“位元組范圍檢索（byte ranges seek）”，從而導致無法下載指定節點的位元組流，也就導致無法播放。
在播放媒體檔案時我們使用 fiddler 工具進行抓包，發現默認使用的就是最原始的版本 2009-09-19，另外可以看到客戶端有發送 Range 頭，但是服務端回傳里面沒有 accept-ranges 頭，所以就相當于沒有指定 API 版本（ un-versioned ）。
還有一些圖片資料由于篇幅關系可以通過這里來查看
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/60085.html
標籤：云存儲
下一篇：動態規劃 - 數字三角形