一、背景介紹，短視頻關注秒播
近幾年，短視頻一直處於流量的風口，各大平臺紛紛涉足。不同的業務形態對技術有不同的述求，傳統長視頻關注的是減少播放中的卡頓，降低用戶 seek 的耗時；直播關注的是如何保證實時性；而短視頻關注的是秒播。
爲什麼短視頻關注的是秒播？一是因爲短視頻通常只有十幾秒，一是短視頻的消費帶有很大的探索性和隨機性。如果用戶花幾秒鐘等待十幾秒的視頻，很有可能起播後還不是用戶喜歡看的，這個代價對用戶來說太大了，久而久之，就是用戶流失的時候。
二、現狀與目標
短視頻播放相關的核心技術指標有兩個：緩存命中率和秒播率。通常情況，緩存命中率越高，響應的秒播率也就越高。短視頻秒播專項優化項目啓動時，關於緩存命中率和秒播率，結合現狀，目標爲緩存命中率提升 40%，200 毫秒秒播率提升 150%，400 毫秒秒播率提升 25%。
三、困難和挑戰
首先，我們是短視頻分發消費場，屬於上層業務，底層播放器鏈路和預加載模塊對我們都是黑盒的，無法直接在底層從根本去優化；
其次，短視頻分發消費場，用戶訴求是隨機的，當用戶滑到不感興趣的視頻時，會立即滑走，以便快速探索下一個視頻。這會造成用戶停留時間很短（通常不到 1 秒），大大擠壓了預加載下一個視頻的時間，造成滑出來的視頻大概率在線起播，如果恰逢網絡不穩定，很容易造成起播慢；
再次，優酷的長視頻和短視頻共用一個播放器。長視頻場景下，更關注的是起播之後的流暢度。故播放器爲了保證起播之後的流暢度，有如下播放優先策略。
1）播放前，由於不確定本地緩存的視頻流是否足夠起播，所以開始播放時，爲了防止預加載任務搶網絡帶寬，此時會暫停所有的預加載任務，以優先保證起播。起播之後，在當前播放視頻緩存的視頻流達到配置的水位，才恢復被暫停調的預加載任務；
2）配置的時間閾值（300 毫秒）內無法起播，則會等待緩存的視頻流加載到指定水位（指定時長或者指定大小），纔會開始起播。
播放器以上兩點播放優先策略，放到在短視頻場，就不適用了，甚至是矛盾的，這無形中大大增加了短視頻秒播優化的難度。
四、行業做法
在開始優化之前，很有必要花些時間對行業做法深入調查一番。主要集中在兩個方面，一個是貨，即視頻源；一個是預加載策略。
如下表所示，從數據上可以看出，優酷和快手兩家的貨大同小異，而抖音在視頻編碼上支持 H.265。
| 平臺 | 時長(s) | 分辨率 | 碼率(mbps) | 大小(mb) |
|---|---|---|---|---|
| 優酷 | 18 | 720p | 2.45 | 5.6 |
| 抖音 | 15 | 540p | 1.11 | 1.8 |
| 快手 | 20 | 720p | 2.07 | 5.0 |
五、優化策略
視頻起播耗時，主要有兩個方面，一個是播放器準備耗時，一個是從網絡加載視頻流耗時。所以優化原則簡單粗暴，就是在播放前，想盡一切辦法，準備好播放器和將視頻流加載到本地。
- 下拉刷新優化
feed 視頻列表請求成功後，扣留列表中最後一個視頻到內存中，然後預加載其視頻流；下拉刷新時，將上次扣留到內存中的視頻放在下拉刷新列表的第一個位置，同時扣留下拉刷新列表的最後一個視頻，如此往復，保證下拉刷新播放的視頻是本地起播。
feed 場景下，向下滑動出來的視頻都是算法推薦，沒有傳統列表的分頁概念。所以 feed 場景下，用戶通常是一直向下滑動以獲取新的推薦內容，用戶沒有下拉刷新的心智，故此優化項在此業務場景下收益甚微。
- 按需預加載視頻流
現有預加載模塊，如果業務方不設置預加載 buffer 大小，則統一爲 400k，通過線上開關控制。優化後，業務方動態計算預加載 buffer 大小，計算原則就是預加載 3 秒的視頻流。如果在視頻播放時，3 秒視頻流全部加載到本地，則既能保證起播，又能保證起播後的順暢。
此項優化，收效同樣甚微，按需預加載，只在一定程度上避免造成預加載任務阻塞，並沒有從根本上提高預加載效率。
- 閒時任務
在視頻播放超過 5 秒或者重複播放時，認爲當前播放的視頻流已全部加載完成，此時網絡是空閒的，利用此網絡空閒的時間，串行預加載後面的視頻。
小視頻業務大盤數據統計用戶平均每個視頻的消費時長爲 6 秒，加上 1/3 的播放爲重複播放，所以此優化項對於緩存命中率有較大提升。
- 預加載時機提前
利用滑動切換視頻時，在滑動鬆手到滑動停止這段時間（300 毫秒），在保證滑動幀率的前提下，開啓子線程預加載後面的視頻，利用這 300 毫秒，預加載後面的視頻流，保證本地起播。相比原先預加載時機是在滑動停止，當前視頻起播後才預加載後面的視頻，假設視頻起播時間爲 500 毫秒，則相比優化前，預加載時機提前了至少 800 毫秒，這是非常可觀的提升。最後測試下來，也是此優化項對於緩存命中率的提升是最爲明顯的。
至此，關於緩存命中率的優化已經收尾，上線後大盤數據也驗證了優化的效果，緩存命中率提升了 38%。
- 雙播放器
上述的四項優化，都是業務層在有限的時間和空間裏摳細節，在預加載策略上做文章，經過一系列優化手段，緩存命中率達成目標。
雖然緩存命中率完成目標了，但是核心的技術指標秒播率並沒有完成，距離目標還有一定差距。這時候我們只能硬着頭皮，想平時不敢想，做平時不敢做的，開始實施雙播放器方案，空間換時間。雙播放器方案原理比較簡單，就是在當前視頻起播之後，預準備下一個視頻的播放器，兩個播放器循環使用。
下一個視頻的播放器一旦準備好，加上視頻流已加載到本地，則起播非常快，幾乎是視頻直出的效果。但由於播放器準備更耗時，用戶滑到下一個視頻時，並不能百分百保證此視頻的播放器已準備好。雙播放器方案上線後，效果顯著，200 毫秒秒播率提升 178%，400200 毫秒秒播率提升 29%。
至此，緩存命中率和秒播率圓滿完成任務。
註解
1）秒播：1 秒內完成播放，後來常用於泛指起播速度；
2）秒播率：指定時間內起播的次數佔全部播放次數的比例，比如 200 毫秒秒播率指的就是 200 毫秒內起播的次數佔全部播放次數的比例；
3）緩存命中率：開始播放時，本地有播放視頻的視頻流，哪怕本地緩存的視頻流只有一個字節，也認爲是緩存命中，緩存命中率指的就是緩存命中的播放次數佔全部播放次數的比例；
4）編碼格式：又稱視頻編碼規範，視頻壓縮格式。通常原始視頻非常大，不方便存儲和傳輸，所以需要將原始視頻進行壓縮。視頻編碼格式很多，這裏不累述，優酷場主要的視頻編碼格式有 H.264 和 H.265，H.264 和 H.265 的詳細區別這裏也不累述，總的來說就是，H.265 的壓縮效率更高，傳輸碼率更低，視頻畫質也更清晰。
作者 | 阿里文娛高級開發工程師 樂想