前言
隨著短視頻的興起，短視頻在各大app中隨處可見，比如feeds流、詳情頁等等。如何讓用戶擁有良好的視頻觀看體驗變得越來越重要。大部分提要滑動觀看視頻時，有明顯的等待感，體驗不是很好。針對這個問題，我們發起了一波優化，目標是：視頻播放秒，視頻播放體驗好。圖中無真。上一張對比圖，左圖為優化前，右圖為優化后：
問題分析
視頻格式的選擇
在正式分析問題之前，有必要說明一下，我們首頁的視頻是320p H.264編碼的mp4視頻
H.264 H.265H.264也稱為MPEG-4AVC(高級視頻編解碼器)，是一種視頻壓縮標準，也是一種廣泛用于錄制、壓縮和發布高精度視頻的格式。H.264作為藍光光盤的編碼和解碼標準而聞名。所有藍光播放器都必須能夠解碼H.264，與之前的編碼標準相比，H.264有一些新的特性，例如多參考幀運動補償、可變塊大小運動補償、幀內預測編碼等。通過使用這些新功能，H.264比其他編碼標準具有更高的視頻質量和更低的比特率。H.265/HEVC的編碼架構與H.264/AVC大致相似，同樣包括幀內預測、幀間預測、變換、量化、去塊濾波、熵編碼等模塊。然而，在HEVC編碼體系結構中，整個系統分為三個基本單元：編碼單元(CU)、預測單元(PU)和變換單元(TU)。一般來說，H.265的壓縮效率更高，傳輸速率更低，視頻質量更好。看起來使用H.265是一個明智的選擇，但是我們這里選擇H.264。原因是：H.264支持的機型范圍更廣。PS:閑魚H.265視頻將于近期在寶貝詳情頁上線，敬請關注體驗！TS FLV MP4TS是日本高清相機拍攝的一種打包格式，稱為MPEG2-TS。TS“傳輸流”的縮寫。MPEG-2 TS格式的特點是要求視頻流的任何一段都可以獨立解碼。以下命令可以將mp4轉換為ts格式。從結果來看，ts文件(4.3MB)比mp4文件(3.9MB)大10%左右。
mpeg-I輸入. mp4-c復制輸出。ts FLV是FLASH VIDEO的縮寫，FLV流媒體格式是隨著Flash MX的引入而開發的視頻格式。由于其極小的文件和極快的加載速度，使得在互聯網上觀看視頻文件成為可能。它的出現有效地解決了視頻文件導入Flash后，導出的SWF文件體積龐大，不能很好地在互聯網上使用的問題。FLV只支持一個音頻流和一個視頻流，不能在一個文件中包含多個音頻流。音頻采樣率不支持48k，視頻編碼同樣編碼格式下不支持H.265，文件大小和mp4幾乎沒有區別。
Mpeg-I輸入. mp4-c復制輸出。flvmp4是一種眾所周知的視頻打包格式，mp4或MPEG-4 Part 14是一種標準的數字多媒體容器格式。MPEG-4的第14部分的擴展稱為. mp4，主要存儲數字音頻和視頻，但也可以存儲字幕和靜止圖像。因為可以容納支持比特流的視頻流，所以MP4在網絡傳輸時可以使用流傳輸。它的兼容性非常好，幾乎所有的移動設備都支持，也可以在瀏覽器和桌面系統中播放。綜合以上包裝格式的特點，我們最終選擇的是MP4。
播放流程
在客戶端播放一個視頻的流程是怎樣的？開播慢在哪里花時間？耗時點能否快速低成本解決？了解視頻的播放過程，有助于找到問題的突破口。視頻從加載到播放可以分為三個階段：
讀取(IO):獲取內容-從本地或服務器獲取解析器：理解內容-參考格式協議理解內容渲染：顯示內容-通過揚聲器/屏幕顯示內容010-6999
可以看出，內容獲取由“服務器端”改為“本地端”，會節省大量時間，成本較低。這是一個很好的起點。事實也是如此，我們的優化就是圍繞這一點展開的。
PS:我們使用的網絡庫和播放器都是集團內部的，他們做了很多優化。本文不涉及網絡協議和播放器的優化討論。
技術方案
鑒于以上分析，我們要做的就是：提前緩存一些mp4文件，在提要滑動播放的時候播放本地的mp4文件。由于用戶可能會繼續觀看視頻，因此在本地數據播放完畢后，需要從網絡上下載數據進行播放。這
里需要解決兩個問題：應該提前下載多少數據緩存數據播放完成后該怎么切換到網絡數據MOOV BOX的位置
對于第一個問題，我們不得不分析一下mp4的文件結構，看看我們應該下載多少數據量合適。MP4是由很多Box 組成的，Box里面可以嵌套Box：
這里不詳細介紹MP4的格式信息。但是可以看出moov box對播放很關鍵，它提供的信息如：寬高、時長、碼率、編碼格式、幀列表、關鍵幀列表等等。播放器沒有獲取到moov box是沒辦法進行播放的。所以下載的數據應該要包含moov box再加上幾十幀的數據。
做了一個簡單的計算：閑魚短視頻一般最長是30s，feeds里面的分辨率是320p，碼率是1141kb/s，ftyp+moov這個視頻的數據量在31kb左右(打開文件可以看出mdat是從31754byte的位置開始的)，所以，頭部信息+10幀的數據大約是：(31kb + 1141kb/3)/8 = 51KB
Proxy
第二個問題：緩存數據播放完成后該怎么切換到網絡數據呢？在本地數據播放完成之后，設置一個網絡地址給播放器，告訴播放器下載的offset是多少，然后繼續從網絡下載數據播放。這樣看起來可行，但是需要播放器提供支持：本地數據播放完成的回調；設置網絡url并支持offset。另外，服務端需要支持range參數，而且切換到網絡播放的時候需要新建立網絡連接，很可能會造成卡頓。
最終，我們選擇了proxy的方式，把proxy作為中間人，負責預加載數據、給播放器提供數據，切換邏輯在proxy里面來完成。未加入proxy之前流程是這樣的：
加入了proxy之后流程是這樣的：
這樣做的好處很明顯，我們可以在proxy里面做很多事情：例如本地文件緩存數據和網絡數據的切換工作。甚至是和CDN使用其它的協議進行通信。我們這里假定預加載工作已經完成，看看播放器是怎么和proxy進行交互的。播放的時候會用Proxy提供的一個localhost的url進行播放，這樣代理服務器會收到網絡請求，把本地預加載的數據返回給播放器。播放器完全感知不到proxy模塊、預加載模塊的存在。播放器、預加載模塊都是Proxy的client，調用邏輯都是一樣。圖示說明如下：
下面逐步解釋一下，數據的加載過程：
Client發起http請求獲取數據，箭頭1所示文件緩存如果存在所請求的數據則直接返回數據，箭頭2所示若本地文件緩存數據不夠，則發起網絡請求，向CDN請求數據，箭頭3所示獲取網絡數據，寫入文件緩存，箭頭4所示返回請求的數據給Client，箭頭2所示
實現模塊
預加載模塊確定了技術方案后，預加載模塊還是有很多工作要做的。在列表網絡數據解析完成后會觸發視頻預加載，首先會根據url生成md5值，然后去查看這個md5值對應的任務是否存在，如果存在則不會重復提交。生成任務后會提交到線程池，在后臺線程進行處理。網絡從Wifi切換到3G的時候，會把任務取消，防止消耗用戶的數據流量。
預加載任務在線程池執行的時候，其流程是這樣的：首先會獲取一個本地代理的url。然后發起http請求。Proxy會收到http請求進行處理，開始做真正的數據預加載工作。預加載模塊讀取到指定的數據量后終止。到此，預加載的任務就已完成。流程圖如下所示：
在用戶快速滑動的時候，怎么能保證視頻還能繼續秒開呢？預加載模塊對于每一個任務都會維護一個狀態機，在Fling的時候會把劃過的任務暫停下，把最新要顯示的任務優先級提高，讓其優先執行。
Proxy模塊
Proxy內部有個local的httpServer負責攔截播放器和預加載模塊的http請求。client在請求時會帶入CDN的url，在本地緩存數據沒有的時候會去CDN獲取新鮮數據。因為有多個地方向Proxy請求數據，所以用線程池來處理多個client的連接很有必要，這樣多個client可以并行，不會因為前面有client在請求而阻塞。文件緩存使用LruDiskCache，在超過指定文件大小后，老的緩存文件會刪除，這是一個在使用文件緩存時很容易忽視的問題。由于我們的場景視頻是連續播放的，不存在seek的情況，所以文件緩存相對比較簡單，不用考慮文件分段的情況。Proxy內部對于同一個url會映射到一個client，如果預加載和播放同時進行，數據只會有一份，不會去重復下載數據。再來一個Proxy內部構造示意圖：
遇到的問題
在測試中發現，有的視頻還是會播放很慢，仔細查看本地的確緩存了期望的數據大小，但是播放的時候還是有較長的等待時間，這種視頻有個特點：moov box在尾部。對于moov在尾部的視頻，是整個文件都下載完成后才進行播放的，原因是moov box里面存了很多關鍵信息，前面分析mp4格式的時候有提到。對于這個問題有兩個解法：
解法一：服務端在進行轉碼的時候保證moov的頭部在前面，發現moov位置不正確的視頻服務端進行訂正。
PS:查看moov在文件中的位置可以用hex文本編輯器打開，按字符搜索moov所在的位置即可，MAC上面還可以使用MediaParser , 另外還可以用ffmpeg命令生成moov在頭部或者尾部的mp4文件。
例如： 從1.mp4 copy一個文件，使其moov頭在尾部 ffmpeg -i 1.mp4 -c copy -f mp4 output.mp4 從1.mp4 copy一個文件，使其moov頭在頭部：ffmpeg -i 1.mp4 -c copy -f mp4 -movflags faststart output2.mp4解法二不用修改moov box的位置，而是在播放端進行處理，播放端需要檢測流信息，如果moov前面沒有，就去請求文件的尾部信息。具體就是：發起 HTTP MP4 請求，讀取響應 body 的開頭，如果發現 moov 在開頭，就接著往下讀mdat。如果發現開頭沒有，先讀到 mdat，馬上 RESET 這個連接，然后通過 Range 頭讀取文件末尾數據，因為前面一個 HTTP 請求已經獲取到了 Content-Length ，知道了 MP4 文件的整個大小，通過 Range 頭讀取部分文件尾部數據也是可以的。示意圖如下
這個方案的缺點是：對于moov box在尾部的視頻會多兩次http connection。
結語
本文介紹了常見的視頻編碼格式，視頻封裝格式，介紹了moov頭信息對于視頻播放的影響。隨著對于播放流程的分析，我們找到了問題的切入點。簡單說就是圍繞著數據預加載展開，把網絡請求數據的工作提前完成，播放的時候直接從緩存讀取，而且后續的視頻回看都是從緩存讀取，不僅解決了視頻初始化播放慢的問題，還解決了播放緩存問題，可以說是一箭雙雕。Proxy是這個方案的核心思想，本地localhost的url是一個關鍵紐帶，視頻預加載模塊和播放器模塊解耦徹底，換了播放器照樣可以使用。到此為止，視頻feeds秒開優化就已完成。上線后的數據來看視頻打開速度在800ms左右。
回過頭來，或許我們還可以更進一步，可以對預加載收到的數據進行驗證，確保緩存了準確的信息，而不是固定的數值。還可以進行更加深度的優化，讓用戶觀看視頻的體驗更加順滑。
參考文獻
*
