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

文/陸元亙

整理/LiveVideoStack

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

我是2018年碩士畢業(yè)于清華大學(xué)工業(yè)工程系。作為一個(gè)B站的資深用戶，2020年我正式加入了B站的播放器團(tuán)隊(duì)，主要負(fù)責(zé)整個(gè)B站的點(diǎn)播體驗(yàn)升級(jí)。

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

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

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

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

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

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

1、QoE模型

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1基于端反饋的CDN治理

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

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

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

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

當(dāng)數(shù)據(jù)傳輸?shù)娇蛻舳藭r(shí)，有可能會(huì)因?yàn)榭蛻舯旧砭W(wǎng)絡(luò)問題而造成網(wǎng)絡(luò)擁塞或網(wǎng)絡(luò)超時(shí)。B站主要運(yùn)營的是視頻業(yè)務(wù)，要下載的數(shù)據(jù)量非常龐大，很多時(shí)候網(wǎng)絡(luò)擁塞會(huì)造成視頻播放的卡頓。這主要是因?yàn)橄滦械膸挷粷M足流暢播放視頻所需的網(wǎng)速，尤其在月末會(huì)更為顯著，因?yàn)檫\(yùn)營商會(huì)對(duì)一些套餐的用戶進(jìn)行限速。另一方面，除了網(wǎng)絡(luò)擁塞，客戶端常見的另一類問題是網(wǎng)絡(luò)超時(shí)，這主要由用戶接入網(wǎng)絡(luò)到服務(wù)端鏈路上節(jié)點(diǎn)的故障造成的。

流量控制

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

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

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

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

網(wǎng)絡(luò)超時(shí)優(yōu)化

針對(duì)網(wǎng)絡(luò)超時(shí)，我們也進(jìn)行了一定的優(yōu)化。網(wǎng)絡(luò)超時(shí)應(yīng)該設(shè)置成一個(gè)固定值嗎？當(dāng)用戶的RTT較高時(shí)，設(shè)置一個(gè)高的網(wǎng)絡(luò)超時(shí)，可以保證用戶有足夠的時(shí)長等待服務(wù)端的響應(yīng)。但如果是用戶網(wǎng)絡(luò)質(zhì)量很好，高的超時(shí)可能也會(huì)造成網(wǎng)絡(luò)帶寬的浪費(fèi)，因?yàn)樵诘却倪@幾秒鐘客戶端并沒有下載數(shù)據(jù)。

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

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

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

播放預(yù)加載

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

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

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

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

自動(dòng)分辨率

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

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

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

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

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

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

3、總結(jié)

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

4、展望

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

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

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