編者按： 伴隨著B站業(yè)務形式的不斷擴展，不同場景對視頻播放體驗的穩(wěn)定性、流暢性提出了更高的要求，為保障提供給用戶更好的播放體驗B站做出了哪些努力？LiveVideoStackCon2022上海站大會我們邀請到了嗶哩嗶哩 , 資深開發(fā)工程師陸元亙老師為我們詳細介紹B站在點播QoE優(yōu)化上的經(jīng)驗與成果。

文/陸元亙

整理/LiveVideoStack

非常榮幸能夠參加LiveVideoStackCon大會，我這次分享的主題是基于端智能的播放QoE優(yōu)化。已經(jīng)有眾多業(yè)內(nèi)同行對整體音視頻能力的增強，以及直播的時延優(yōu)化做出了很多貢獻，不過對于互聯(lián)網(wǎng)帶寬的大頭 —— 點播的優(yōu)化提及的還相對比較少。對于點播來說，移動端是最貼近用戶的一端，同時也是整個傳輸鏈路當中的最后一環(huán)。那么，如何在最后一環(huán)做好接力棒，為用戶提供更符合預期的播放體驗，就是我接下來要介紹的主要內(nèi)容。

我是2018年碩士畢業(yè)于清華大學工業(yè)工程系。作為一個B站的資深用戶，2020年我正式加入了B站的播放器團隊，主要負責整個B站的點播體驗升級。

簡單介紹一下B站，去年年底B站的月活躍用戶已經(jīng)達到了27億，預計今年月活躍用戶會更多。作為Z時代聚集的一個社區(qū)，B站為用戶提供了更多樣化的播放體驗，這里不僅有長視頻的PGC，也有短視頻的UGC。除了移動端，我們也同樣為家用電視提供服務。另外，我們也在做國際版，未來也可能會有更多海外的服務。

龐大的用戶群體代表著多種多樣的播放場景，也就會帶來多種多樣的訴求，我們首先要明確的是播放體驗優(yōu)化的目標是什么？

簡單來說有兩個目標：一個是高清，一個是不卡。用戶通常會希望分辨率是越高越好，但分辨率提高的同時，也代表著視頻碼率的增長，對網(wǎng)絡帶寬的要求也大大提高。在現(xiàn)有網(wǎng)絡傳輸條件下，網(wǎng)絡質量的不穩(wěn)定性會使得一部分地區(qū)的用戶在不同場景下出現(xiàn)弱網(wǎng)的情況。

隨著用戶對清晰度要求的提高，B站也相對應的做了很多工作。首先，我們大幅度提升用戶播放的清晰度，B站算是國內(nèi)比較早支持1080p、4k和8k碼率的廠商。另外，我們還在移動端上部署了HDR以及杜比視界的音視頻增強功能。除此之外，還有針對超分辨率算法的研究和優(yōu)化。今天我主要介紹的是在分辨率和碼率不斷提升的情況下，應該如何為用戶帶來更好的體驗。

越來越高的分辨率需要更高的網(wǎng)絡帶寬支持，如何在兩者之間做好平衡是當務之急。在清晰度不斷提高的情況下，帶寬成本也不斷提高，我們給用戶帶來的提升，用戶可以感知到嗎？另外這些升級帶來的收益與我們所投入的成本是否相匹配也是需要考慮的一個問題。在優(yōu)化QoE過程中，移動端應該如何來做？如何治理好傳輸中的網(wǎng)絡，以應對多變的網(wǎng)絡情況？如何讓用戶更加流暢的播放他想看的視頻？即使提供了我們認為的用戶希望的策略，但每個用戶的傾向由是不確定的，又該怎么滿足不同用戶之間的不同需求呢？

下面我將從如何衡量播放體驗以及如何進行全鏈路的優(yōu)化兩個方面展開講解。

1、QoE模型

如圖是目前業(yè)界最常見使用的一個QoE模型，這個模型主要和碼率的收益有關，分辨率越高，碼率的收益也就越高。另外，還有兩個懲罰，一個是卡頓的懲罰，一個是碼率切換的懲罰。我們可以明顯地看到，這個公式就是將碼率進行累計，將卡頓時間進行累計，對切換的次數(shù)進行了約束。

但是這個模型也存在一些問題。第一，其非常缺少權重標準。到底是碼率的收益更高還是卡頓懲罰更高，完全取決于開發(fā)者的調參，沒有一個公共的標準；第二，這個模型是一個線性模型，在面對一些復雜的情況時，很難估計用戶當時的體驗到底是什么樣的；第三，該模型是描述結果而不是描述過程的，然而播放是一個全流程的過程，過程中需要給到用戶怎樣的體驗不是這個公式就可以完全描述清楚的。

為了解決上述問題，B站召集了大量用戶進行了一個主觀的評測。實驗因子主要包括起播耗時、起播分辨率、卡頓時間點、卡頓時長、卡頓次數(shù)、過程分辨率、切換分辨率的時間點和切換分辨率次數(shù)等等。我們希望通過這樣的主觀實驗，找到用戶到底需要什么樣的體驗。

通過實驗結果，我們得出來以下的結論：隨著分辨率的不斷提升，整個QoE的主觀評分也在不斷提高。但當分辨率達到1080p，之后的提升就不那么明顯了。另外，對于用戶來說，一次長的卡頓評分會優(yōu)于多次短的卡頓。還有就是，起播和卡頓時長在3秒以內(nèi)對評分的影響較小。

通過實驗結果不難發(fā)現(xiàn)，傳統(tǒng)公式真的不行，那到底什么樣的公式才能滿足我們的需求呢？通過查閱資料，我們找到“記憶效應”一詞，用戶對于短時間內(nèi)發(fā)生的卡頓和分辨率的切換是有記憶的。這也從側面印證了一個點，用戶不僅僅以當前的分辨率作為決策，而是會根據(jù)一段時間內(nèi)的感受做出決策。

基于以上設想和數(shù)據(jù)，我們做出了自己的實時QoE模型，模型的影響因子只有分辨率和卡頓，該模型能夠實時計算用戶在播放過程中的體驗。大家可能會有疑問，如果分辨率發(fā)生變化怎么辦？計算出的分數(shù)還是連續(xù)的嗎？

答案是連續(xù)的。在分辨率發(fā)生變化時，用戶并不能立即感知到分辨率的變化，尤其是當兩個分辨率差值較低的時候。從1080p一下到360p，可以很快被感知到，但從720p到1080p，感知相對就會弱一些。我們使分辨率切換時QoE逐漸收斂到當前分辨率相對應的評分?？D的懲罰次數(shù)和時長也是模型的一個組成部分。一段時間內(nèi)，卡頓越多，盡管每次卡頓持續(xù)時間不長，但懲罰會卻越來越大。另外，間隔相對久遠的卡頓是不被記錄在內(nèi)的。最后有一點需要提出，用戶往往在低QoE的時候退出。

通過以上幾條所構建出來的模型，可以實時描述用戶的體驗。我們的核心目標是，優(yōu)化播放過程中的平均QoE，同時也盡量讓最低的QoE有所提升。

這里舉一個簡單的例子：一位用戶一開始播放選擇720p，但隨著播放過程進行，可能覺得720p畫面有些糊，所以在第10秒的時候切換到1080p。以當時的網(wǎng)絡在25秒之前（如圖左對應第3個點）是可以支持1080p的，但由于一些短暫的網(wǎng)絡抖動，導致在第25秒時發(fā)生了一次卡頓。25秒后的時間段里，網(wǎng)速雖然較低，但仍然可以支持下載一些1080p的幀，所以在經(jīng)歷兩秒卡頓之后又可以繼續(xù)播放了。直到在第30秒時再次發(fā)生卡頓，即便在第33秒時恢復正常播放，但此時用戶已經(jīng)認為他的網(wǎng)絡不太能支持1080p，所以在第35秒時手動切換分辨率到720p。基于剛剛設想的場景，可以進行一些優(yōu)化。第25秒之前沒有什么改變，我們將之后連續(xù)多次的小卡頓融合成次數(shù)更少的長卡頓，這不僅會使用戶整體的QoE得到大幅提升，并且用戶也不會覺得不耐煩。

2、播放全鏈路優(yōu)化

播放全鏈路主要由客戶端、運營商和CDN三個部分組成。客戶端獲得視頻的URL進行DNS解析，解析完之后連接到CDN去請求數(shù)據(jù)。CDN將視頻和音頻流的數(shù)據(jù)，通過基站等基礎設施傳遞到用戶的設備上。雖然從表面上看整個全鏈路上不存在任何問題，但事實上從一端到另一端的傳輸過程中，每一個結點都有可能會存在很大的問題。例如CDN的部分，有可能會出現(xiàn)CDN負載過高，對客戶端的響應延遲。運營商的部分，經(jīng)常遇到的問題就是IP劫持以及DNS解析失敗。在客戶端側，用戶的網(wǎng)絡條件是千變?nèi)f化的，比如在移動端有人用的WiFi，有人用的4G網(wǎng)絡，網(wǎng)絡信號不是一直穩(wěn)定的。

針對不同部分出現(xiàn)的問題，我們提出了相應的解決辦法：運營商的問題比較容易解決，常見的就是用HTTPS、HTTPDNS規(guī)避運營商可能存在的問題。這些方法都已經(jīng)很成熟了，這里就不過多的介紹。

接下來，主要介紹下我們針對CDN的解決辦法，即端上的一些傳輸策略。在治理之前，我們需要明白為什么要從客戶端出發(fā)，對CDN進行治理。這是一個很現(xiàn)實的問題，不僅僅是B站，很多廠商也在面臨這些問題。并不是每家APP都自建了CDN，很多APP都是外購商業(yè)CDN。如果想和第三方的CDN溝通解決網(wǎng)絡問題，或者去開發(fā)一些新的傳輸優(yōu)化功能，效率是非常低的。所以，既然我們端上也有大量的數(shù)據(jù)可以去反映CDN的質量，那為何不利用這些數(shù)據(jù)去治理CDN呢？

2.1基于端反饋的CDN治理

如圖是基于端反饋數(shù)據(jù)的CDN治理框架。成百上千的客戶端會實時訪問CDN節(jié)點，同時會產(chǎn)生大量連接的數(shù)據(jù)，我們將這些數(shù)據(jù)上傳到一個數(shù)據(jù)倉庫，當有新的客戶端接入時，他會重新向網(wǎng)關申請視頻的URL，網(wǎng)關就可以從數(shù)據(jù)倉庫中拿取一些幾分鐘之內(nèi)的數(shù)據(jù)，并進行IP評估，選出一些質量較好的IP隨機下發(fā)到客戶端上。這樣可以最大程度地避免客戶端選到一些質量太差的IP，整體效率上得到提升。

該功能上線后，我們也進行了大量的測試，發(fā)現(xiàn)其在大多數(shù)情況下的提升效果并不是很明顯。這主要是因為當前CDN的質量通常都比較好，但并不排除在CDN發(fā)生劇烈波動的情況下，其提升效果是非常明顯的，客戶端可以及時的響應和感知并連接到一個合適的IP。除此之外，我們還會針對數(shù)據(jù)進行監(jiān)測和及時告警，通過這些數(shù)據(jù)反推，方便CDN提供商進行一些優(yōu)化。

2.2客戶端網(wǎng)絡傳輸優(yōu)化

通過上述步驟，我們已經(jīng)能將CDN治理的比較好，下面就介紹在客戶端傳輸方面的優(yōu)化。

當數(shù)據(jù)傳輸?shù)娇蛻舳藭r，有可能會因為客戶本身網(wǎng)絡問題而造成網(wǎng)絡擁塞或網(wǎng)絡超時。B站主要運營的是視頻業(yè)務，要下載的數(shù)據(jù)量非常龐大，很多時候網(wǎng)絡擁塞會造成視頻播放的卡頓。這主要是因為下行的帶寬不滿足流暢播放視頻所需的網(wǎng)速，尤其在月末會更為顯著，因為運營商會對一些套餐的用戶進行限速。另一方面，除了網(wǎng)絡擁塞，客戶端常見的另一類問題是網(wǎng)絡超時，這主要由用戶接入網(wǎng)絡到服務端鏈路上節(jié)點的故障造成的。

流量控制

如圖展示的是對網(wǎng)絡擁塞解決的算法。在介紹這個算法之前，想先問大家一個問題。當我們使用帶寬下載音頻和視頻流時，下行帶寬是100，音頻需要的帶寬是20，視頻需要的帶寬是80，相當于帶寬正好可以滿足音頻和視頻兩個流的下載，那么在這種情況下為什么還會發(fā)生卡頓？

視頻和音頻是兩個獨立的流，當未對這兩個流進行流量控制時，音視頻流獨立的競爭會導致兩個流各自只能拿到50的帶寬。當上層從傳輸層獲取數(shù)據(jù)時，視頻的消耗速度是80，音頻的消耗速度是20，很明顯視頻流是供不應求的，同時音頻的存儲量則是在不斷上漲的。因此我們希望將音頻所占用的部分下載帶寬分配一些給視頻，以保證視頻下載速度是80，音頻下載速度是20。相比之前的情況，視頻下載速度有大概60%的提升。

具體操作是通過控制音頻和視頻的receive buffer長度。從第圖1開始，在初始情況下，我們會給視頻和音頻設置一個相對較小的接收區(qū)長度。因為兩個接收區(qū)的長度內(nèi)都沒有內(nèi)容，所以他們的下載速度比是1:1。當音頻達到上限時，帶寬會被分配給視頻，通過這樣的操作對視頻下載進行加速。如果發(fā)生圖4的情況，當音頻和視頻的緩存都快滿時，我們會將緩存進行翻倍，不限制網(wǎng)速的加快。圖6和圖7的情況是當網(wǎng)速下降時，我們會將緩存區(qū)的長度縮小，使得視頻緩存的長度和音頻緩存的長度達到一致，以保證此時盡量將網(wǎng)速按照需要分配。

通過上述方法我們可以將網(wǎng)速的利用率提升到最大，這樣的算法并不是去產(chǎn)生帶寬，而是將帶寬搬運到它應該在的位置。在播放過程中用戶會進行很多操作，例如拖拽進度條，或切換分辨率等。通過上述優(yōu)化，整體的卡頓率優(yōu)化得到很大提升。另外，既然已經(jīng)做了音頻和視頻的控制，其實應該對APP所有占用帶寬的任務進行調度，但這不在本次所討論的內(nèi)容范圍之內(nèi)，就不再展開介紹了。

網(wǎng)絡超時優(yōu)化

針對網(wǎng)絡超時，我們也進行了一定的優(yōu)化。網(wǎng)絡超時應該設置成一個固定值嗎？當用戶的RTT較高時，設置一個高的網(wǎng)絡超時，可以保證用戶有足夠的時長等待服務端的響應。但如果是用戶網(wǎng)絡質量很好，高的超時可能也會造成網(wǎng)絡帶寬的浪費，因為在等待的這幾秒鐘客戶端并沒有下載數(shù)據(jù)。

為什么用戶網(wǎng)絡質量很好，客戶端還是可能遲遲等不到服務端的響應呢，我們前面不是對CDN進行了治理嗎。這主要有以下三個原因：第一是播放URL的下發(fā)和使用并不在一個時間點，URL可能會過期；第二是因為播放過程中CDN的質量會發(fā)生變化；第三是因為基于端反饋的CDN治理需要較大的數(shù)據(jù)量，在用戶量較小的地區(qū)是沒法使用該方案的。這三個原因都會導致網(wǎng)絡質量好的用戶連接服務器不成功，因此我們的解決方案是基于用戶歷史網(wǎng)絡信息，動態(tài)調整超時時間，來達到“弱網(wǎng)下加大超時時間減少重試，強網(wǎng)下減少超時時間規(guī)避CDN劣質節(jié)點”的效果。

2.3播放策略優(yōu)化

即便我們解決了上述的問題，用戶的網(wǎng)絡也還是會偶爾發(fā)生抖動。常見的解決策略：一種是預加載，另一種是自動分辨率。預加載是利用網(wǎng)絡條件較好的情況，提前加載后面需要播放的視頻。當網(wǎng)絡發(fā)生抖動時，后面一段時間內(nèi)的視頻內(nèi)容已經(jīng)加載好了，也就不會發(fā)生卡頓，相當于一種消峰填谷的辦法。但當用戶的網(wǎng)絡很差時，預加載的緩存也用完了，那應該怎么辦呢？當緩存不支持當前的下載速率以及分辨率時，還是需要根據(jù)網(wǎng)速調整分辨率的大小。

播放預加載

傳統(tǒng)預加載主要的應用場景是短視頻，當前的預加載策略相對比較簡單粗暴。其原理是當前視頻在下載過程中，當網(wǎng)絡條件比較好時緩存較高，系統(tǒng)會按照一定的優(yōu)先級，自動啟動后面多個視頻的下載。雖然看上去比較簡單，但實際使用時還是存在很多問題。

最主要的問題一個是網(wǎng)速的競爭，另一個是預加載帶寬。對用戶來說，原本只需拉一個視頻的流，但現(xiàn)在需要同時拉多視頻的流，網(wǎng)速的競爭實質上會劣化該場景下用戶的體驗。剛剛提到的策略會不斷的進行加載，帶寬的浪費也是非?？植赖摹?/p>

為了解決以上兩個問題，我們將用戶的網(wǎng)絡狀態(tài)和播放器的控制聯(lián)合在一起。首先保證當前播放的視頻是不容易卡頓的，其次對預加載的視頻進行一些控制，只有當允許下載的時候才可以進行下載。當前播放視頻卡頓風險較高的時候，可以通過一些手段讓其它視頻及時停止預加載的工作，總的來說就是基于優(yōu)先級對所有預加載視頻進行錯峰下載。

預加載真正適合的用戶也是有限的，傳統(tǒng)方案在用戶網(wǎng)絡好的時候不斷預加載的內(nèi)容，對于這些用戶來說降低卡頓的收益是有限的，因為就算不預加載，他們也不會卡。而一些網(wǎng)絡較差的用戶也會因為網(wǎng)速競爭的問題，導致卡頓率比較高。所以我們將用戶進行簡單的分級，傾向于為網(wǎng)絡一般的用戶進行預加載，同時也會參考用戶的播放習慣，當用戶正處于快播放的過程中，會相應的減少其預加載的量。

自動分辨率

下面簡單介紹下B站的自動分辨率算法。自動分辨率其實從流媒體技術興起以來，一直是學術界非?；馃岬囊粋€話題。從2012、2013年開始，就已經(jīng)有基于簡單網(wǎng)速平均碼率的決策，后面又出現(xiàn)基于緩存占用比的碼率決策，到再后來也有了基于網(wǎng)速和緩存的模型預測。這些算法B站也都進行了落地，但在實際使用的過程中發(fā)現(xiàn)它們還是存在不少的問題。這些算法對于網(wǎng)速的預測還是過于簡單，一方面其網(wǎng)速預測的誤差非常大，另一方面卡頓的懲罰權重比較高。例如當播放1080P視頻時非常流暢，但突然發(fā)生了斷網(wǎng)，一段時間之后緩存消耗殆盡，隨即發(fā)生了卡頓。當用戶重新連接時，其網(wǎng)速瞬時可以達到很高，傳統(tǒng)的API算法對于網(wǎng)速的預測太過保守，導致在這種場景下會降低分辨率，并經(jīng)過很長時間才能升高到1080P，對于用戶的體驗來說是大打折扣的。

在剛剛舉例的場景下，主要存在的問題是對網(wǎng)速的預測不夠準確。在機器學習技術興起后，B站使用Pensieve訓練出一個相對更加準確的神經(jīng)網(wǎng)絡模型。它可以通過歷史的網(wǎng)速更精準的預測未來的速度。該模型主要由三個部分組成：Actor是需要訓練的神經(jīng)網(wǎng)絡，Critic負責為整體神經(jīng)網(wǎng)絡打分，Environment決定Action當時的環(huán)境變量、分辨率等。

整個模型的驅動力是Critic中的QoE公式，該模型可以基于QoE公式，訓練出最高QoE的決策模型。該模型最主要的問題是QoE制定不合理。在使用原始QoE的模型線上測試的時候，我們發(fā)現(xiàn)模型分辨率的決策非常兩極化，容易導致用戶的不好體驗。

因此，我們需要解決的第一個問題是QoE到底該怎么定。對此，B站給出的解決辦法是一定要采集自己用戶的網(wǎng)速數(shù)據(jù)，并利用前文提到的QoE模型得到用戶的傾向，這樣才能有的放矢。第二個問題是神經(jīng)網(wǎng)絡模型傳統(tǒng)是部署在服務端的，這會導致很難及時決策客戶端多變的網(wǎng)絡，而且部署成本高，我們要盡可能將ABR算法部署在客戶端。

19年的時候，有一篇名為PITREE的論文，這篇論文中提到可以將神經(jīng)網(wǎng)絡的一個模型轉化成決策樹的模型，然后決策樹的模型又可以轉化成C++、 Java的代碼，把這一個復雜的模型轉換成幾百行代碼，部署在客戶端上，這樣可以讓QoE的損耗降到最低。

總的來說，我們構建了一套完整的端智能播放策略矩陣，輸入信息需要包含網(wǎng)絡信息以及用戶的習慣，之后基于歷史網(wǎng)絡信息進行網(wǎng)速的預測，再輸入到算法模塊中決策它當前應該有多大的分辨率和多大的緩存。通過上面的方法就可以實現(xiàn)千人千面的播放器控制。

3、總結

在所有播放體驗的優(yōu)化中最重要的一點就是讓數(shù)據(jù)說話。一方面我們要優(yōu)化QoE的目標，對在播放鏈路各個環(huán)節(jié)上評價的質量要進行標定和設定。除此之外，有了數(shù)據(jù)之后需要對其進行自動化的質量看護。最后一點，在不斷迭代演化的過程中，很多的算法需要進行調優(yōu)，合理的AB實驗可以保證數(shù)據(jù)的可信性。在全鏈路治理上，我們要深刻理解鏈路上各方的角色和影響體驗的痛點，站在全局的角度共同做好一件事。最后站在客戶端的角度，我們需要更貼近用戶，了解用戶的訴求和實際場景，利用精準的數(shù)據(jù)和策略提供用戶想要的體驗。

4、展望

未來我們還會進一步優(yōu)化用戶的播放體驗，或許未來播放的場景不止是會在手機端，還可能會有家用電視，智能汽車等等，這些用戶對播放體驗的要求也會有所不同。

如圖是全球2022年1月份下行網(wǎng)速的平均值，我們可以看到國內(nèi)目前的網(wǎng)速在全球來說是比較好的。未來，我們也考慮走向海外，而海外相應的一些地區(qū)，大部分的網(wǎng)絡條件是相對比較差的，也就需要我們在該地區(qū)做一些精細化的工作。

以上就是本次分享的全部內(nèi)容，謝謝大家。