導語：近幾年來短視頻領域成為互聯網的風口，美拍作為最早的短視頻APP，從2014年開始就對短視頻技術有持續地投入和研究。
本文將從成本優化，成功率優化，播放體驗優化等幾個方面，整體介紹下美拍短視頻成本減半以及毫秒起播優化實踐之路。
內容概要
近幾年來短視頻領域成為互聯網的風口，美拍作為最早的短視頻APP，從2014年開始就對短視頻技術有持續地投入和研究。4年多來，隨著4G網絡的發展以及普通家庭寬帶有跨越式地發展，人們對互聯網信息的獲取從簡單的文本過渡到內容生動豐富的流媒體內容，極大的促進了流媒體視頻技術的發展，同時也給用戶體驗提出更高的要求。
本文將從成本優化，成功率優化，播放體驗優化等幾個方面，整體介紹下美拍短視頻成本減半以及毫秒起播優化實踐之路。除了這些基礎的用戶體驗改造方面的落地，我們還在持續推進更加極致的用戶體驗優化。
技術背景
1.從痛點出發
在早期，快速落地階段，我們的關注點更加側重產品的需求和用戶增長，以快速滿足用戶需求為主作為我們的產品主要發展目標，這也是互聯網產品基本的發展規律。在早前快速落地階段，短視頻播放的情況是：
- 觀看體驗不佳，每個視頻在加載前都會有一個比較煩人的1-3秒的轉菊花的過程，即使視頻很快起播，菊花也是一閃而過。部分視頻還會出現必須要全部下載完之後才能開始播放的情況；
- 起播速度慢，短視頻的長度一般在十幾秒到幾分鐘之內，起播速度的快慢直接影響了用戶持續觀看的意願。如上所提到的，在沒有做特殊優化的情況下，正常起播時間需要1-3秒以上；
- 下載成本高，CDN帶寬成本是所有視頻類服務最大的一筆費用支出，同時也是用戶比較關注的敏感問題。如何最大限度的降低帶寬成本，對企業和用戶體驗而言都是雙贏的。
2.數據驅動
基於上述情況，我們在成本和體驗等方面做了相應的改造，我們的核心評估標準是數據，必須堅持以數據驅動來推動整體優化工作。優化類的工作，我們的挑戰在於必須做的比原來更好，並且不能因為優化工作給業務帶來可用性方面的風險。因此，構建一套客觀公正的數據體系是我們最重要的工作前提，數據決定方向，用數據來做調度調整決策。
我們的數據體系不是以產品化為目標，總體的建設目標包括：
- 準確性，數據必須要準確，數據不準確，一切都沒有意義；
- 快速落地，在人力有限的情況下，必須要保證足夠快速的落地性；
- 可複製體系，我們不追求完美的產品體驗，標準化的處理流程可以保證讓我們可構建不同維度類型的數據。
有了客觀公正的數據，我們可以利用它來做：
- 優化效果評估，用數據來評估優化效果是最為直接的，特別是幾十到幾百毫秒的差別依賴人工的判斷通常是比較無感的；
- 實時故障報警，出現故障時，第一時間報警，第一時間處理干預；
- 質量反饋決策，通過質量我們可以對各種服務提供商的質量有更好評估，作出及時調整；
- 用戶問題排查，用戶反饋的問題如果沒有日誌等信息，我們無法分析判斷問題。利用一些關鍵的信息，可以讓我們更好的排查和處理用戶問題。
3.融合調度系統
基於我們對線上問題的核心痛點的分析，結合我們所要做的一些調度策略，我們構建了一套點播融合調度系統。我們希望通過這套系統的建設，可以更好的與業務松耦合的結合，通過調度服務，提供更加靈活的策略支持，利用質量系統給整體的調度提供可靠的數據支撐。融合調度系統的主要模塊和功能包括：
- 調度服務，提供多CDN容災和多碼率等調度分發機制，同時以後還可以加入更多的策略支持；
- 質量系統，利用客戶端上報的數據，實時處理分析，給調度服務提供自動調度切換決策；
- 雲處理系統，利用熱門文件分析，對熱門視頻做多碼率文件處理，提供分發H265，不同分辨率文件等支持。
[圖一：點播融合調度總體架構圖]
成本優化
成本優化，最直接體現在降低CDN成本，同時也可以降低用戶觀看視頻時的數據流量，對平臺和用戶而言是雙贏的。
降低帶寬的手段，最簡單粗暴的手段是通過壓縮降低熱門視頻的碼率。通過碼率的壓縮，在降低帶寬的同時，也會降低視頻的畫質，對用戶體驗以及平臺的聲譽均會帶來較大的負面影響。
我們希望在畫質不變的情況下，降低CDN成本。為此我們做了一個前提假設：用戶有很大的概率是沒有完全播放視頻就退出播放，同時如果在出現二次播放的時候，我們希望能夠讓用戶直接通過本地緩存可以直接播放，避免多次下載所帶來的帶寬浪費。
要實現限制帶寬目標，也有多種不同的手段包括：
- 利用碼率信息，通過限制用戶的下載速度，儘量保持讓用戶以視頻匹配的碼率下載文件。這種特性一般的CDN都會提供支持，好處是改造簡單。可能帶來的問題就是在部分場景下可能會帶來卡頓，忍受網速波動方面會比較有限。需要保持長HTTP連接，對服務端，請求錯誤率監控，客戶端耗電等方面都會帶來一些影響。
- 通過控制播放器的緩衝區長度，降低用戶無謂的內容下載。比如一個視頻長度是60秒，正常情況下播放到10秒的時候，如果沒有限制，可能整個視頻都會已經下載完成，如果用戶此時退出，就浪費了後面50秒的下載帶寬。通過緩衝區長度控制，我們可以降低中斷播放所帶來的帶寬浪費，平衡每次下載的時間開銷，合理評估緩衝的長度。
[圖二：基於分片下載和播放器緩衝區控制的下載方案]
通過這個改造，我們取得了超出預期的效果，基本上能夠做到在畫質不變的情況下，整體的帶寬成本下降50%以上。
在此基礎上，還可以通過分發編碼效率更高的多碼率文件，比如H265(未來包括AV1)，來降低視頻碼率。多碼率文件，依靠我們視頻調度服務來做策略分發。依賴於客戶端請求調度的決策信息，包括：客戶端設備信息，分辨率，網絡速度，是否支持H265等判斷調整來整體上做調度決策。
[圖三：融合調度多碼率策略總體流程]
成功率提升
對成功率提升，我們需要把握一些主要的關鍵點：
- 重試是關鍵，公網請求一定會受到各種情況下的波動影響。對於公網的用戶請求，短超時，有重試是提高成功率的基礎；
- 規避單點服務問題，CDN業務每天都會有一些區域性的波動，在業務上，儘量需要有容災服務備用方案，降低因為單點問題帶來的區域性和波動性影響；
- 各種技術手段，降低客戶端網絡請求的錯誤率。
在提高成功率方面，我們做了一些事情：
- 通過融合調度，下發多CDN，在每個地區至少同時提供兩家以上的CDN服務，在其中一家出現問題後，可以快速切換到另外一家CDN。確保客戶端在非本地網絡問題的情況下可以播放成功；
- 通過減少網絡請求，降低網絡錯誤概率；
- 接入FastDNS，提高解析成功率，降低解析延遲。總體上可以降低60-100ms的網絡請求延遲，降低了40%的網絡請求失敗率。
通過這些技術改造，提高服務的整體抗波動性，區域性故障甚至是全局性的CDN故障能力，將總體的播放錯誤率從1%，降低到0.1%。同時也降低了網絡的請求延遲，主動提高了請求成功率。
[圖四：融合調度多CDN請求流程]
播放體驗優化
播放體驗優化的核心目標是加快起播速度，降低卡頓發生。為此，我們做了一些針對性的技術改造，總體上也取得了比較不錯的效果。
1.faststart
目前主流的流媒體格式基本上都是MP4格式，MP4文件的格式封裝是以box為基礎，整個文件的封裝格式是有不同類型的box一級一級嵌套組成。其中，每個MP4文件必須要有的區段有：
- FTYP，mp4文件的基礎元數據，包括版本號，兼容特性等信息；
- MOOV，包含了流媒體信息的關鍵基礎信息，包括編碼信息，時長等等；
- MDAT，真正的音視頻流媒體數據。
如果沒有特殊的調整，MOOV一般會放在視頻文件的最後部分，在播放視頻時可能會需要完整下載視頻後才能開始播放，這樣就會很大程度上影響到起播時間。
將MOOV調整到文件的前部分，可以讓播放器最快拿到起播的元數據信息。
[圖五：moov調整]
2.播發器調整
因為我們所使用的ijkplayer機制關係，在檢測是否可以開始起播，是有一個定時的檢測機制去做數據是否滿足播放標準檢查。這個時間閾值之前是每500ms檢測一次，這樣極大可能就會浪費500ms的時間重新檢測數據是否滿足播放要求。
在ijkplayer 0.8.1 引入FAST_BUFFERING_CHECK_PER_MILLISECONDS配置，將首次的檢查間隔縮短到50ms，從數據表現上可以降低300ms的起播時間。
3.預批量調度
引入融合調度，提高策略的靈活性，提高服務的整體容災能力的同時引入了另外一個問題就是下載視頻前需要做一次額外的調度請求，會增加大概300ms左右的時間，這個是非常敏感的一個體驗下降。
預批量調度是利用業務刷新feed列表到開始播放視頻的時間差，最大限度的做視頻批量調度，將批量調度結果緩存到本地，使用戶在播放視頻的時候直接就可以開始播放。由此就可以解決實時調度所帶來的額外請求問題，同時也可以通過批量調度，合併調度請求，降低調度請求數量。
預批量調度適用於任何的業務場景，不受業務場景限制。在引入預批量調度後，幾乎可以抹平因為融合調度所帶來的300ms的起播時間增加，當然因為部分場景下可能還來不及做預批量調度還是會有一點點影響，不過影響面基本可以接受。
4.預加載
對於提高起播時間來說，預加載是最後的殺手鐧。前面的優化都是在利用一切可能的技術手段，降低請求延遲。受限於網絡請求本身就會有優化的天花板，能夠達到最快起播速度的做法就是播放時不要去做網絡請求。在此思路下，我們也逐步引入了預加載策略，也是整個優化手段中的最後一環。
預加載，首先需要分析適用場景，預加載實際，成本開銷評估等方面。從場景分析來看，單列feed的直接播放場景是最為合適的預加載場景，雙列feed也是可以做，只是加載緩存的使用命中率上可能會偏低，浪費部分帶寬成本。
[圖六：預加載場景]
對於預加載需要加載字節數，上圖公司已經給出。 600 bytes 是怎麼評估的？因為MOOV的長度是每個視頻都不固定的，而且會跟視頻的內容長度有直接關係。我們做了一個簡單的調研評估，MOOV大體的每秒字節數如下：
[圖六：MOOV每秒字節數]
由此大概推測一個相對比較折中的數字 600 bytes。
總體來看，預加載策略的引入，是我們做到極致用戶體驗非常關鍵一環。通過這個環節的優化，我們將50% 左右的播放起播時間降低到0-250ms的分佈區間之內，數據改善極為明顯。
總結
為了控制篇幅，每個優化點都不可能介紹的太細，而且細節點有點多，非常適合做一個總體的小結，每個優化環節的數據都能夠體現它的重要性：
- 通過下載優化，CDN帶寬成本在視頻畫質沒有明顯變化的前提下下降50%；
- 減少一次range 0-1 的請求，減少100-200ms左右；
- FastDNS接入，減少60-100ms左右；
- 融合調度請求，增加300ms左右。播放錯誤率從 1% 左右下降到 0.1% 左右；
- 播放器參數調整，減少300ms左右；
- 批量預調度，減少200-300ms左右；
- 預加載，45%視頻在250ms之內，85%視頻在750ms之內開始播放。
當前我們也根據我們業務的發展情況，持續在做一些更深層次的優化。也希望能夠在畫質優化、窄帶高清等新興技術方面有更多的嘗試和發展。
閱讀更多 美圖技術團隊 的文章
