5G時(shí)代，從生產(chǎn)端到播放端，超G清音視頻將成為主流，如何讓播放更加“智能”，讓用戶(hù)隨時(shí)隨地都有流暢觀(guān)看體驗，既“G清”又“不卡”？

本文將詳解優(yōu)酷“智能檔”的是什么、為什么以及落地效果，尤其是如何突破“傳統自適應碼率算法”的局限，解決視頻觀(guān)看體驗中G清和流暢的矛盾，并以 “熱綜熱劇”等場(chǎng)景為藍本，一睹“大項目”背后的視頻播放實(shí)踐。

本文主要分為四部分：

背景：智能檔是什么、有什么？

挑戰：傳統自適應碼率理論與播放實(shí)踐的碰撞

實(shí)踐：清晰度策略?xún)?yōu)化迭代過(guò)程——整體框架建設，從數據中分析和學(xué)習

總結：優(yōu)酷智能檔的成果和新技術(shù)的應用

優(yōu)酷“智能檔”是什么、有什么？

為了大家能夠對優(yōu)酷智能檔有一個(gè)比較直觀(guān)的了解，我這里準備了一個(gè)帶寬限速條件下播放的視頻。視頻1是傳統1080P藍光清晰度，視頻2就是今天要提到的“智能“清晰度。我們看到視頻1已經(jīng)開(kāi)始卡了，視頻2還在繼續播放，但清晰度角標已經(jīng)變?yōu)槌�清了�?

好，剛剛播放的是《長(cháng)安十二時(shí)辰》張小敬追捕狼衛的一段視頻，是在帶寬限速的情況下播放的，大致是在 1.5Mbps 左右。在這樣的條件下左側使用 1080P清晰度，當畫(huà)面變化較大，對應的碼率也波動(dòng)較大的時(shí)候，發(fā)生了卡頓，而且提示是否要切換到智能播放。而右側的“智能”清晰度則在這種情況下，發(fā)現了網(wǎng)絡(luò )不足以支撐藍光，降級變成了超清，避免了卡頓，然后在這段播過(guò)去之后又重新恢復到藍光。

▐  優(yōu)酷“智能檔”簡(jiǎn)介

看完這段視頻，我們來(lái)明確一下，關(guān)于智能檔的幾個(gè)基本問(wèn)題：

1）  什么是智能檔，這個(gè)大家剛剛也都看到了，智能檔是一種新的清晰度選項。

2）  為什么要有智能檔？我們可以從兩個(gè)角度回答：

讓播放體驗更加智能。例如，用戶(hù)在一個(gè)不確定的網(wǎng)絡(luò )環(huán)境下，不知道什么清晰度合適，選擇G清晰度，卡了；選擇低清晰度，畫(huà)質(zhì)體驗又不好。優(yōu)酷智能檔就是要解決這個(gè)選擇問(wèn)題，智能匹配合適的清晰度，避免用戶(hù)自己反復去嘗試；

避免播放卡頓。例如剛才的《長(cháng)安十二時(shí)辰》視頻，在網(wǎng)絡(luò )限速或者更常見(jiàn)的4G下，網(wǎng)絡(luò )波動(dòng)大，智能檔實(shí)時(shí)地調節清晰度，在保證用戶(hù)觀(guān)看更G清晰度的情況下，避免播放卡頓。

3）  是如何實(shí)現的呢？這就要提到自適應碼率技術(shù)，根據網(wǎng)絡(luò )環(huán)境和播放過(guò)程中的狀態(tài)，去實(shí)時(shí)決策選擇合適的清晰度。

▐  自適應碼率技術(shù)

自適應碼率這項技術(shù)，早在 2002 年前后就已經(jīng)被人提出，大致在 2010 年開(kāi)始在互聯(lián)網(wǎng)L域得到應用，逐步走向成熟。關(guān)于自適應碼率的技術(shù)方案，一般由兩部分構成：

D一部分協(xié)議框架：支持多個(gè)不同碼率的清晰度傳輸和播放，約定服務(wù)器端、客戶(hù)端的；

D二部分算法策略：更具體地確定什么狀態(tài)下匹配哪種碼率、哪種清晰度更好。

在協(xié)議框架上，蘋(píng)果較早提出了 HLS 的方案。后來(lái) MPEG 專(zhuān)家組提出行業(yè)標準DASH；除此之外，微軟、Adobe等公司也有技術(shù)方案，但設計上比較類(lèi)似，大同小異。

在算法策略上，是百花齊放。過(guò)去幾年，學(xué)術(shù)界涌現出不少相關(guān)論文，比如右側列表中所示，歸納起來(lái)分為4類(lèi)：

D一類(lèi)，基于網(wǎng)速預測，根據網(wǎng)速帶寬和碼率的大小進(jìn)行選擇；

D二類(lèi)，基于播放器的buffer來(lái)判斷決策；

第三類(lèi)，引用一句話(huà)網(wǎng)絡(luò )名言“小孩子才做選擇，我全都要”，即融合前面兩種因素；

第四類(lèi)，更G級和L先的，將近幾年的人工智能L域的技術(shù)引進(jìn)來(lái)，根據機器學(xué)習、神經(jīng)網(wǎng)絡(luò )模型來(lái)選擇清晰度。

▐  自適應碼率技術(shù)的工作流程

自適應碼率技術(shù)在從生產(chǎn)到播放的整個(gè)鏈路，分成5步：

D一步，原始的視頻資源文件，它可能只有一個(gè)比較G的清晰度；

D二步，生產(chǎn)端對視頻進(jìn)行轉碼和切片，根據播放需要，轉碼成不同清晰度的碼流。一般清晰度越G，碼率越G，文件越大。每個(gè)碼流都切分成時(shí)間對齊的分片，一般是10s；

第三步，在轉碼和切片之后，經(jīng)過(guò) CDN 節點(diǎn)在網(wǎng)絡(luò )上進(jìn)行分發(fā)；

第四步，各自適應碼率的算法按策略選擇需要的清晰度；

第五步：客戶(hù)端下載這個(gè)清晰度的分片文件，進(jìn)行播放。

▐  自適應碼率算法：基于帶寬速率

看完框架鏈路，我們再來(lái)看算法策略，先是簡(jiǎn)單的基于帶寬的策略。

這類(lèi)算法的原理很簡(jiǎn)單，就是基于過(guò)去一段時(shí)間的網(wǎng)絡(luò )下載速度，對網(wǎng)絡(luò )情況做預測，如果比視頻某一個(gè)清晰度的碼率大，那么就可以選擇這個(gè)碼率，否則只能?chē)L試更低清晰度。右上角圖中列出了4種算法，都是基于速度進(jìn)行判斷的，清晰度和網(wǎng)速變化是正相關(guān)。

這個(gè)算法簡(jiǎn)單直接，缺點(diǎn)是如果過(guò)去網(wǎng)速G，對網(wǎng)絡(luò )的預估又過(guò)于自信，網(wǎng)絡(luò )波動(dòng)落差大時(shí)，就無(wú)法下載完預期的清晰度內容，容易卡頓。

另外，清晰度受網(wǎng)絡(luò )波動(dòng)影響大，網(wǎng)絡(luò )一波動(dòng)，就會(huì )頻繁的切換清晰度，這相當于忽略掉播放器中buffer的作用。

▐  自適應碼率算法：基于Buffer

基于buffer，就是播放器的緩沖區還能播多長(cháng)時(shí)間來(lái)選擇。這種方式直接放棄速度，只看 buffer，沒(méi)數據可播時(shí)才會(huì )卡。當buffer 低時(shí)，選擇低清晰度，buffer隨播放進(jìn)度和下載進(jìn)度一點(diǎn)點(diǎn)變化，清晰度不會(huì )有太大波動(dòng)。

缺點(diǎn)是buffer的變化相對緩慢，會(huì )喪失對網(wǎng)絡(luò )變化判斷的靈敏性。比如用戶(hù)網(wǎng)絡(luò )換環(huán)境立刻變好了，但是 buffer 漲到G清晰度的區間是需要一個(gè)過(guò)程的。

一個(gè)典型的案例就是 BBA 算法，我們可以右側這張圖，橫軸是 buffer，縱軸是清晰度碼率，它們之間維持一個(gè)線(xiàn)性關(guān)系，buffer越G清晰度越G，直到達到G的清晰度；同時(shí)為了保證不卡頓，低清晰度也要攢夠一定的buffer，才開(kāi)始考慮換更G的清晰度。

▐  自適應碼率算法-MPC

這類(lèi)算法有一個(gè)里程碑式的進(jìn)步，給出一個(gè) QoE 的公式化定義。QoE就是體驗質(zhì)量，包含清晰度、卡頓時(shí)間、清晰度切換3個(gè)因素。一旦確立好QoE 的計算公式，在網(wǎng)絡(luò )狀況完全確定的情況下，我們就可以將自適應碼率算法轉化為一個(gè)求大值的數學(xué)問(wèn)題。

但是網(wǎng)絡(luò )狀況完全確定需要“上帝視角”。一般情況下，網(wǎng)絡(luò )波動(dòng)是可完全預測的，在一個(gè)較短時(shí)間內，我們認為網(wǎng)絡(luò )波動(dòng)會(huì )比較小，后面網(wǎng)絡(luò )情況和前面已經(jīng)統計到的速度存在一定關(guān)聯(lián)性，所以上面的這種求全局大值的就可以退化成為一種局部的計算，并嘗試通過(guò)局部累加，達到近似全局優(yōu)解，這好比是從一個(gè)全局的動(dòng)態(tài)規劃變成一個(gè)局部的貪心思路。

所以它的具體決策過(guò)程是：

D一步，根據過(guò)去的情況，判斷網(wǎng)絡(luò )質(zhì)量，預測速度；

D二步，生成未來(lái)N片，比如5片，將所有可能的清晰度組合做列表；

第三步，逐一嘗試，找出所有可選項中 QoE 大的組合；

第四步，將選擇中下一片清晰度作為本次清晰度選項，每個(gè)分片選擇時(shí)都依次類(lèi)推。

▐  自適應碼率算法-基于機器學(xué)習

機器學(xué)習就是為計算機提供大量數據，讓計算機基于這些數據進(jìn)行計算，在特定L域做出判斷，并針對判斷給出評定標準，告知機器判斷是否正確、準確，經(jīng)過(guò)反復大量的學(xué)習過(guò)程，提G計算機判斷能力的準確性。

強化學(xué)習是機器學(xué)習的一種，是針對一個(gè)過(guò)程該如何做決策的學(xué)習。

如下圖，機器人學(xué)習養花，看見(jiàn)花要枯死了，選擇用水澆花，獲得一個(gè)正向的獎勵；如果看到花快被淹死了，還去澆花，那么就只能得到懲罰，此外還可以根據情況考慮是否施肥、打藥，訓練機器人把花養好。

近年比較火的機器學(xué)習方式就是深度神經(jīng)網(wǎng)絡(luò )。我們可以將“養花過(guò)程中機器人的動(dòng)作” 理解為一個(gè)非常復雜的數學(xué)函數，輸入是花的狀態(tài)，輸出是應該澆水還是施肥的決策選擇，花是否養好作為不斷調整函數內參數的依據，一旦參數調整好，這個(gè)函數就可以給出準確決策，神經(jīng)網(wǎng)絡(luò )就相當于這個(gè)復雜的函數，具體的一個(gè)模型實(shí)例就相當于這個(gè)函數里所需的所有系數。 

我們做清晰度選擇的例子和養花的過(guò)程很像，輸入是過(guò)去的網(wǎng)速情況、buffer情況等，輸出是清晰度的選擇。

2017年開(kāi)始有論文提出類(lèi)似的方案，優(yōu)點(diǎn)是用大量的數據去訓練，訓練好了就相當一個(gè)“經(jīng)驗豐富”的人，它看過(guò)很多歷史網(wǎng)絡(luò )變化的數據和選擇結果、知道遇到特定的情況應該如何選擇。弊端是太“G深莫測”，可解釋性不強。

▐  業(yè)界應用情況

國外的視頻產(chǎn)品，Youtube 和 Netflix的手機客戶(hù)端都有對自適應碼率技術(shù)的應用。在國內，早在兩年前，優(yōu)酷就在做類(lèi)似嘗試，但初的清晰度選項叫做“自動(dòng)”，在起播時(shí)幫用戶(hù)選擇一個(gè)合適的清晰度，但是播放過(guò)程中如果網(wǎng)絡(luò )有波動(dòng)它不會(huì )變。隨著(zhù)優(yōu)酷技術(shù)體系不斷升級，現在優(yōu)酷能夠通過(guò)“智能”選項，隨時(shí)隨地的根據網(wǎng)絡(luò )情況進(jìn)行清晰度選擇和必要的切換。

實(shí)際應用中的挑戰

自適應碼率技術(shù)的理論雖好，在大規模實(shí)踐中，卻屢屢碰壁，歸納起來(lái)有如下的挑戰：

▐  實(shí)際應用中的挑戰：起播處理

起播的典型挑戰是：

典型策略：環(huán)境未知，如何避免卡頓；

網(wǎng)絡(luò )環(huán)境良好的狀態(tài)下，如何提升清晰度。按照學(xué)術(shù)界的算法論文，起播時(shí)為了避免卡頓，都是從低清晰度開(kāi)始，但實(shí)際尤其對于沒(méi)有使用過(guò)同類(lèi)產(chǎn)品的用戶(hù)，10s的模糊不能被接收的；

起播速度：如何快速播放。為了G清和起播后不卡頓，多加載一會(huì )兒，行不行？不行！快速起播是良好播放體驗的開(kāi)始。

 所以我們要遵循的原則是：

如果網(wǎng)絡(luò )足夠好，起播就提供G清晰度；

為了避免卡頓和起播太慢，需要在網(wǎng)絡(luò )差的情況，適當地選擇低清晰度；

不能為清晰度選擇而給播放帶來(lái)太大的額外開(kāi)銷(xiāo)。

優(yōu)酷是如何解決的？

首先，根據視頻是否為首次播放進(jìn)行分類(lèi)。不是首次播放的，可參考前一次播放的清晰度；是首次播放的，參考播放服務(wù)的請求耗時(shí)。在連播情況下，既然可以用上一次播放的清晰度，也可以利用上一次的播放中的速度信息，更確切知道當時(shí)的網(wǎng)絡(luò )情況；

其次，我們發(fā)現請求耗時(shí)的區分度并不大。播放器也在進(jìn)行一個(gè)網(wǎng)絡(luò )質(zhì)量評估的項目，這樣就引入了網(wǎng)絡(luò )評分機制，作為清晰度的一項參考；

后，秒播項目也多面鋪開(kāi)，在播放前下載一個(gè)分片。一方面下載過(guò)程提供了速度信息，另一方面我們也需要結合分片的清晰度進(jìn)行選擇，避免起播清晰度頻繁波動(dòng)。

▐  實(shí)際應用中的挑戰——網(wǎng)絡(luò )情況預測

D二個(gè)挑戰就是對網(wǎng)絡(luò )情況的判斷，即對帶寬的預測；雖然不少論文都提到了根據歷史下載速度求平均值，對當前或接下來(lái)速度做預測，但是關(guān)于細節基本都避而不談。

網(wǎng)速非常重要，它是對當前網(wǎng)絡(luò )判斷直接的數據來(lái)源，也是保證升降檔快速靈活的一個(gè)關(guān)鍵因素。

速度預測的難點(diǎn)是網(wǎng)絡(luò )情況是實(shí)時(shí)變化的，不同環(huán)境變化形式和方向都不同。例如，上圖中就是截然不同的兩種網(wǎng)絡(luò )條件，D一個(gè)網(wǎng)速G且穩定，D二個(gè)網(wǎng)速在J速波動(dòng)。所以預測速度的原則是盡量保守、盡量平緩，吸收掉波動(dòng)情況，即對過(guò)去一段時(shí)間的速度取平均值。平均值的計算方式，可以結合上圖的兩種情況來(lái)看：

一是，傳統算數平均數和調和平均數的方式；

二是，將對過(guò)去速度預測的誤差考慮進(jìn)去，也是robustmpc方案中提到的，更適合我們的需求。 

那么，只有速度預估就夠了嗎？當然不是。由于網(wǎng)速是可隨時(shí)波動(dòng)的，實(shí)際網(wǎng)速也可能達不到預測速度，所以我們需要兜底方案。這里采用的是超時(shí)，即在預期的時(shí)間內，如果當前清晰度分片下載不完，將自動(dòng)調整，避免 buffer 消耗后發(fā)生卡頓。

超時(shí)設置也需要精心考量，超時(shí)意味著(zhù)當前分片如果下載不完就要丟棄，那么已下載完成的部分是不能用來(lái)播放的，否則就會(huì )出現同一視頻內容用兩種不同的清晰度重復播放。所以buffer較小時(shí)，不適合超時(shí)，否則容易增加卡頓。

什么情況設置超時(shí)呢？預期超時(shí)是用來(lái)解決問(wèn)題的，首先是選擇清晰度預期它能下載完，如果下載不完，我們可以用更低清晰度來(lái)替代。我們要保證現有的buffer足夠這兩個(gè)清晰度下載完成的時(shí)間，此外要盡量留足時(shí)間，讓當前清晰度的下載能夠在較小的波動(dòng)下完成，避免頻繁切帶來(lái)的網(wǎng)絡(luò )浪費和不好體驗。

體驗衡量

隨著(zhù)智能檔的推廣和應用，我們也需要考慮帶寬成本，行業(yè)通用解決方案是使用 PCDN，在播放允許的情況下，避免直接向成本較G的CDN服務(wù)器請求轉而找到成本較低，但質(zhì)量不太穩定的節點(diǎn)，這樣就會(huì )引起速度的波動(dòng)。

這個(gè)問(wèn)題如何解決？首先，PCDN 調度的原則，是將 buffer 趨于劃分為三段：D一段是buffer較低的情況，為了避免卡頓保證服務(wù)質(zhì)量，會(huì )直接走CDN；D二段是部分從CDN下載，部分使用質(zhì)量較差的P2P節點(diǎn)；第三段是buffer較G的情況，卡頓風(fēng)險低，直接斷開(kāi)CDN，只使用P2P。

簡(jiǎn)單來(lái)說(shuō)，為了保證智能檔用戶(hù)有穩定體驗，我們在節點(diǎn)切換的過(guò)程中，始終保持使用一個(gè)較G的速度，比如使用連接CDN時(shí)的速度，如果 P2P的速度比 CDN的速度G，我們可以使用這個(gè)更G的速度，當質(zhì)量較差的節點(diǎn)滿(mǎn)足不了當前速度時(shí)，buffer就會(huì )降低，迫使PCDN逐步切換回G質(zhì)量的節點(diǎn)，這樣就做到了和 PCDN結合的自適應調整，做到了速度的相對穩定。

▐  實(shí)際應用中的挑戰——其它

在實(shí)踐過(guò)程中面臨的挑戰，如何衡量智能檔的體驗，如何評價(jià)效果。

學(xué)術(shù)論文的衡量標準是看QoE，它包含了對清晰度質(zhì)量、卡頓和清晰度波動(dòng)的因素。但它是單一值，兩次不同的播放，QoE一個(gè)G一個(gè)低，說(shuō)明前一個(gè)體驗更好，但是無(wú)法知道差的原因，是卡頓太多還是清晰度太低？所以單一值，不利于我們衡量真實(shí)效果，也不利于明確優(yōu)化方向。

所以，我們終通過(guò)和實(shí)際業(yè)務(wù)目標相結合，整體看全盤(pán)數據，同時(shí)將卡頓率、G清晰度的播放時(shí)長(cháng)占比拆開(kāi)來(lái)看�？�頓率G了，要想辦法降卡頓，策略上要相對保守；如果G清晰度少了，就要適當調整策略，讓用戶(hù)更容易升到G清晰度。

此外，播放的體驗好不好需要多維度考量，除以上兩個(gè)關(guān)鍵指標外，我們也增加了其它維度數據，比如，使用智能檔用戶(hù)的播放量占比、一次播放的清晰度切換頻次，Gbuffer降檔的反常體驗發(fā)生比率等。

實(shí)際上，我們在實(shí)踐的過(guò)程中遇到的挑戰還不止這些，比如倍速播放的情況，4G下考慮流量的問(wèn)題等。受時(shí)間和篇幅的限制，就不一一展開(kāi)了。

智能檔的設計、實(shí)現與優(yōu)化迭代

以上介紹了自適應碼率技術(shù)的一般原理和挑戰，接下來(lái)從整體分析，優(yōu)酷智能檔是如何設計的，又是如何優(yōu)化。

▐  優(yōu)酷智能檔的整體結構設計

智能檔的整體框架分為上下兩部分，下層是客戶(hù)端，上層是服務(wù)器端。

D一，清晰度選擇的控制器是在客戶(hù)端，包含一個(gè)策略引擎，支持多種策略實(shí)現運行，為策略的運行提供了統一接口；控制器需要與播放器內核的數據源處理部分打交道，從播放器內核獲取到視頻的基本信息，比如支持幾個(gè)清晰度、每個(gè)清晰度碼率多少，有多少個(gè)分片、每個(gè)分片多大，同時(shí)也從播放器收集當前的播放狀態(tài)，比如當前的buffer 狀態(tài)；此外，客戶(hù)端還需要從下載器那里得到各分片的下載速度，從全局的網(wǎng)絡(luò )監測模塊感知當前的網(wǎng)絡(luò )質(zhì)量情況，后執行策略，輸出下一個(gè)清晰度，通過(guò)內核交由下載器去下載，進(jìn)而播放；

D二，智能檔的控制器每次播放后會(huì )收集整個(gè)決策過(guò)程中的輸入/輸出信息，并上報到服務(wù)器端，服務(wù)器端用這個(gè)數據做統計、分析、優(yōu)化，然后進(jìn)一步改進(jìn)策略，形成一套完整的閉環(huán)的數據體系。

▐  策略實(shí)現-多策略支持

結合前面算法論文中的理論，我們先后嘗試過(guò)實(shí)現四種策略：

D一種：Pattaya 是我們嘗試的一種策略，將單獨基于速度的一類(lèi)策略，后來(lái)也引入了基于 buffer 策略，不斷根據數據情況增加一些經(jīng)驗規則進(jìn)去，也是早期進(jìn)行鏈路調試的一個(gè)策略；

D二種：基于強化學(xué)習的策略；

第三種：實(shí)現和調試了基于 MPC 思路的策略；

第四種：根據經(jīng)驗創(chuàng )造出來(lái)的，基于下載嘗試和超時(shí)的SBit策略。

我們以 AB Test 的形式分桶開(kāi)啟各個(gè)策略，觀(guān)察效果逐步優(yōu)化，終形成一套統一策略，包含起播/Seek決策、播中決策、超時(shí)處理、卡頓處理等幾個(gè)關(guān)鍵組成部分。

▐  數據體系建設-信息的收集與解析

上面提到四類(lèi)策略，在衡量效果時(shí)，我們提到了一些關(guān)鍵指標，相關(guān)的統計數據在上線(xiàn)之初就進(jìn)行了支持。那么，這四類(lèi)策略是不是上線(xiàn)就表現良好，表現不好的原因是什么，這就需要對每一次播放數據的輸入和輸出都有詳細記錄，如圖中的數據結構。

D一步，早期我們考慮一次播放的決策數據量比較大，同時(shí)還不具備這種批量數據處理分析的能力，主要是以日志的方式打出來(lái)；

D二步，我們了解到阿里云的數據工場(chǎng)能夠提供這樣一種能力，通過(guò)自定義 UDF 解析結構復雜的編碼數據，并且通過(guò)一般的編程語(yǔ)言以實(shí)現插件的形式，完成各式各樣的分析，這樣我們就將客戶(hù)端上每次播放的所有相關(guān)的輸入和輸出，按照一定的格式組織起來(lái)，進(jìn)行壓縮、編碼通過(guò)埋點(diǎn)渠道報上來(lái)，需要分析的時(shí)候在數據平臺上解碼分析。

上圖，是一個(gè)經(jīng)過(guò)編碼的智能檔播放信息，報到服務(wù)器端之后，我們通過(guò)數據平臺對立面的信息進(jìn)行解析。當然這張圖立面只畫(huà)出了其中一部分信息，包含原始的輸入速度、預測的速度、播放器buffer的變化情況，這樣整個(gè)智能檔的決策過(guò)程就盡收眼底。

▐  數據體系建設-優(yōu)化應用

當完整數據體系建立之后，我們就可以進(jìn)行優(yōu)化。下面以卡頓優(yōu)化為例，我們是這樣操作的：

D一步，當版本發(fā)布后，觀(guān)察整體的大盤(pán)數據，發(fā)現卡頓超出預期，我們會(huì )分析用戶(hù)用例，對卡頓情況有初出認知。

D二步，基于已知信息做分類(lèi)規則，比如，是起播就卡，還是播了很久之后才卡；是因為網(wǎng)絡(luò )差，清晰度降底都還會(huì )卡，還是在策略上有優(yōu)化的空間？

第三步，根據規則將所有發(fā)生過(guò)卡頓的播放數據做聚合分析，知道每種可能情況的占比，有針對性分優(yōu)先級的去解決和處理問(wèn)題；

不只卡頓，還是其它像G清晰度沒(méi)有達到預期，都可以用這種方式進(jìn)行分析。這些數據除了分析這些問(wèn)題以外，還有利于我們對整個(gè)優(yōu)酷用戶(hù)播放過(guò)程有一個(gè)更多面的了解，比如說(shuō)他們的網(wǎng)絡(luò )情況分布等。

▐  智能檔的應用推廣

在智能檔完成設計、實(shí)現、優(yōu)化，我們希望它能夠在更多的場(chǎng)景上得到應用。智能檔初是在手機兩端上率先完善和放量，其次是iPad端。在過(guò)去一年，我們也在iKu OTT 等客戶(hù)端場(chǎng)景下投入使用。

這里面需要強調是大型直播場(chǎng)景，比如雙11貓晚、近期的義演直播《相信未來(lái)》，直播和點(diǎn)播場(chǎng)景有差異：

D一、直播要求低延遲，比如看球賽，不能隔壁進(jìn)球了，這里還在射門(mén)。所以這個(gè)特點(diǎn)就決定了端上播放器不能有太多buffer，智能檔的決策需要做適當的調整，更多的從網(wǎng)速上獲取信息；

D二、直播是實(shí)時(shí)性的，生產(chǎn)端生產(chǎn)出視頻流是實(shí)時(shí)進(jìn)行的，而且通常的直播時(shí)長(cháng)比一集電視劇時(shí)間還要長(cháng)，所以存在技術(shù)風(fēng)險，這時(shí)候智能檔就有了用武之地。

和直播場(chǎng)景有關(guān)的D一個(gè)問(wèn)題是流量控制，某一場(chǎng)直播開(kāi)始前，會(huì )預估流量，但實(shí)際可能因為某個(gè)節目特別火爆，新用戶(hù)源源不斷地涌進(jìn)來(lái)。在服務(wù)器流量壓力大時(shí)，智能檔可以通過(guò)實(shí)時(shí)下發(fā)配置適當的調整用戶(hù)的清晰度，例如，必要情況下，降低一個(gè)清晰度，實(shí)時(shí)緩解服務(wù)器帶寬和流量壓力。這是傳統清晰度所做不到的，傳統清晰度可能從進(jìn)入直播間到看完就固定在一個(gè)清晰度碼率上。

另外一個(gè)常見(jiàn)問(wèn)題是直播時(shí)，在生產(chǎn)端可能會(huì )出現某一路流轉碼失敗，智能檔發(fā)現問(wèn)題后，可以直接標記這路流不可用，在后面的播放切到其它相近的清晰度時(shí)，保證整體直播效果不會(huì )受到太大的影響。

智能檔的應用總結及未來(lái)

在過(guò)去一年，優(yōu)酷智能檔已經(jīng)逐漸走向成熟：

優(yōu)酷智能檔在過(guò)去一年的建設過(guò)程中，覆蓋了移動(dòng)端約30%的播放量，甚至比播放某些傳統的清晰度播放量都G；

從智能檔內的各個(gè)清晰度播放時(shí)長(cháng)來(lái)看，能夠讓用戶(hù)在90% 以上的時(shí)間觀(guān)看比較G的清晰度，同時(shí)保持著(zhù)比一般清晰度更低的卡頓率，尤其在 4G 網(wǎng)絡(luò )下，能夠做到傳統清晰度的一半；

智能檔為優(yōu)酷整體的播放體驗優(yōu)化提供了工具，也在直播等場(chǎng)景成為了技術(shù)保障的必要手段；

重要的，經(jīng)過(guò)過(guò)去一年的優(yōu)化，獲得了用戶(hù)的認可。

對于未來(lái)，主要有兩點(diǎn)思考：

隨著(zhù) 5G 的發(fā)展，越來(lái)越多的用戶(hù)將移動(dòng)蜂窩網(wǎng)絡(luò )下觀(guān)看視頻，智能檔會(huì )得到更多應用�？赡艽蠹乙獑�(wèn)了，5G網(wǎng)速那么快，還需要智能檔嗎？這里我想到了一句話(huà)，"What Andy gives Bill takes away"，“安迪比爾定律”，這里面 Andy 是 Intel 的 CEO， Bill就是比爾蓋茨了。意思是無(wú)論 Intel的 CPU 造的多么先進(jìn)，都會(huì )被新的 Windows 系統消耗掉�；氐讲シ艌�(chǎng)景，網(wǎng)絡(luò )技術(shù)是在發(fā)展，但人們對G清視頻的需求也在不斷提G，所以智能檔是必要的；

另外，一定會(huì )出現新的手段，讓自適應碼率技術(shù)的效果更好。比如今天提到的Pensieve，利用強化學(xué)習來(lái)進(jìn)行清晰度選擇。這個(gè)原作者在 2019 年又發(fā)表了一篇新論文，大致內容是他又改進(jìn)了算法模型，開(kāi)始在 Facebook 進(jìn)行實(shí)驗，這是個(gè)未來(lái)的方向，現在的可解釋性等等問(wèn)題應該都會(huì )逐步得到解決。

查看更多相似文章