點播降本增效中的播放器策略
在點播業務中,頻寬成本在總成本(轉碼+儲存+頻寬)中佔據絕對的大頭。B站很早就開始利用技術手段,對頻寬成本進行最佳化。
由於頻寬成本=頻寬單價*頻寬用量,一般降低成本的方式有兩種:
降低頻寬單價:例如使用更廉價的CDN服務。
降低頻寬用量:例如大家熟悉的編碼演算法最佳化,可以在同畫質的前提下,將稿件位元速率進行壓縮。
之前的最佳化主要在服務端,而頻寬消費的最終端——播放器,在成本中起到的作用,卻鮮有關注。
針對這一盲區,B站播放器團隊利用資料進行了理論分析,發現播放器在頻寬用量上有較大的最佳化空間。從2022年初至今,我們利用播放器中的端智慧策略持續降本增效,至今已降低15%的點播頻寬成本。這篇文章將詳細介紹我們播放器策略最佳化中的技術手段和思考沉澱。
1. 點播頻寬中的浪費
首先需要強調的是,降低播放器頻寬成本的前提,是必須保障使用者高畫質流暢的播放體驗。用技術指標來說,就是不論降低頻寬單價,還是降低頻寬用量,都不能劣化使用者的卡頓率、首幀時長、載入失敗率以及畫質。
因此,我們的重點是識別正常播放消耗之外的頻寬用量,並盡力減少浪費。
1.1 浪費成因
從理論上分析,浪費主要來自過多的快取:
整個CDN下行傳輸鏈路上的快取節點非常多,除了播放器中使用者觀看所必要的快取,還包括播放器未被播放的快取、邊緣節點快取、源站快取。其中播放器中未被播放的快取,是浪費中的最大組成,也是本文關注的重點。造成播放器快取浪費的場景有:
提前退出
預載入了未播放
向後拖拽進度條
切換解析度
1.2 度量播放器中的快取浪費
理論分析之後,我們來精準計算播放器中的快取浪費。該用哪個指標度量呢?
1. 首先考慮的指標是:
這個指標非常易懂,但在不同業務場景中,無法作為統一的評價標準。例如短播放時長的單次播放下載頻寬,天然比長播放更低,但這並不意味著短播放的浪費更少。
2. 因此我們試圖相容時長的影響,使用了第二個指標:
利用這個指標,我們證實了前文的觀點,發現短播放的浪費確實遠遠大於長播放。
舉個例子,使用者觀看同一個影片,快取大小一直為5秒,比較1秒退出和5秒退出兩種情況,前者的單位時長下載頻寬是後者的3倍。
不過,雖然我們可以使用單位時長下載頻寬來估算成本,但這個指標並不能指出浪費的大小。另外,單位時長下載頻寬指標,非常容易受稿件大小的影響,無法客觀評價播放器的策略是否已經做到極致。
3. 於是我們使用頻寬冗餘率,衡量使用者正常播放消耗之外的頻寬佔比:
總下載頻寬:指播放器應用層接收到的頻寬總量。傳輸層的頻寬浪費和最佳化不在本文中贅述。
總消費頻寬:指使用者實際觀看到的頻寬量。我們用送到播放器中解碼的位元組數計算。沒有送去播放的幀,不算入消費頻寬。
這個指標消除了播放時長、稿件位元速率帶來的影響,長期來看只會受到使用者播放行為和播放器快取策略的影響。由於統計學的大數定律,使用者的播放行為在長期來看是非常穩定的,所以我們可以用頻寬冗餘率來衡量播放器快取策略的好壞。
經過一段時間的資料開發、校準和分析,我們發現播放器中的浪費果然是巨大的。在沒有預載入的場景中,頻寬冗餘率超過30%,而在有預載入的場景,頻寬冗餘率甚至能達到50%。
2. 成本與體驗是否可以兼得
存在即意義,甚至在某種情況下是合理的。
播放器設定固定快取水位線的初衷,是為了抵禦網路可能存在的抖動,降低卡頓風險。這在網際網路誕生的早期,網路基礎設施不夠完善的時代,可以非常有效地提升播放體驗,增大留存。
然而,在網路基建日益完善、甚至直播都在追求低延時“0快取”的今天,點播中過多快取所帶來成本付出,已逐漸超過體驗增益。
讓我們從資料上說明這個問題。下圖列出了使用者的網速分佈、流暢播放所需的最小快取,以及固定的快取水位線:
可以看到:
區域A的使用者快取是過剩的,不會發生卡頓;而區域B的使用者快取是不足的,當網路抖動時,極有可能耗盡快取導致卡頓。
網際網路早期時,由於頻寬緊張、網路訊號不穩定、音影片編解碼技術不成熟等因素,區域B大於區域A,提高快取長度的邊際收益是顯著的。
現在,隨著4G乃至5G的普及,大多數使用者的頻寬可以滿足4K甚至8K影片的需求,區域A遠遠大於區域B。可以說只有極小部分的使用者會需要用到大快取。但是,這並不意味著我們可以直接降低快取長度,因為使用者對於卡頓的容忍度也在降低。
因此,簡單且固定的快取策略已經無法滿足成本與體驗的雙重要求了。幸運的是,我們知道一定存在那條“流暢播放所需最小快取”線,那麼就讓我們用技術手段求索這條線,既減少區域A的浪費、又減少區域B的卡頓。
3. 技術最佳化手段
3.1 智慧快取策略
我們設計實現了智慧快取策略,從網路風險和使用者習慣兩個角度實時決策“流暢播放所需最小快取”。總的原則是“強網路或不穩定播放時儘量少快取,弱網路或穩定播放時儘量多快取”,難點是如何識別網路的強弱和使用者的偏好。
網路風險
我們分析的網路風險考慮的主要是中長期的規律。一方面是因為瞬時網路變化難以預測,更重要的是快取長度的控制並不能夠立即帶來效果。在網速突降時,即使立即升高快取長度,當時的低網速也不能讓快取區快速充滿;而在網速由低變高的場景,由於網路還未穩定,也不應該立即降低快取。
我們策略中使用的中長期風險有:
1. 網速大小風險
主要考慮歷史網速的絕對值大小,以及與稿件位元速率的相對大小。
該項指標描述的是當前網速是否足夠支撐稿件位元速率的持續下載,在策略中的權重最高。
2. 網路抖動風險
主要考慮歷史網速的抖動大小、以及網路環境切換(無網/蜂窩網路/WLAN間的切換)的次數。
該項指標描述的是當前網速能夠持續保持的機率,如果網路抖動風險太高,預測的網速也需要大打折扣。
3. 多次卡頓風險
主要考慮使用者一段時間內連續發生多次卡頓的機率。
該項指標描述的是使用者體感上的真實感受,基於QoE評價對快取策略進行負反饋調整,防止出現未考慮到的最壞情況。
綜上,基於網路風險的快取可以用以下公式計算:
可以看到,在沒有任何網路風險的播放場景(佔比90%以上),僅使用最小快取即可滿足流暢播放。
使用者習慣
上面的模型僅考慮了網速,但快取大小的合理值還受使用者習慣的影響。
1. 快取命中率
主要考慮使用者接下來是否會出現影響快取命中的行為。
我們期望使用者長時間觀看,這會提高快取命中率;而未看完提前退出、拖拽進度條、手動切換解析度等,會導致快取浪費。
快取命中率指標描述的是使用者當前是否達到穩定播放的狀態。使用者最常見的不穩定狀態,就是在尋找某一特定進度位置的影片內容、或者翻看動態尋找感興趣的內容時。
如果使用者並未表現出對內容的強烈興趣,那上文所給的最小快取也是浪費。而如果使用者在一個影片中長時間觀看時,即使歷史網路很好,播放器也應該給更多的快取,以防止可能突發的網路抖動。
從全域性角度來說,提升快取命中率最好的方式是提高使用者和內容的匹配度;而從單一模組的技術角度來說,播放器的更優解是識別出當前使用者的穩定播放傾向畫像,動態調整不同傾向時的最小快取。
2. 倍速播放
主要考慮使用者多倍速場景下快速消耗快取的風險。
我們將影片當前播放的速度融入網速和解析度的計算模型中,根據播放速度來決策快取的合理值。
智慧快取策略總結
最終,我們基於使用者習慣快取+網路風險快取構建了智慧快取策略。在持續的演算法迭代、AB測試之後,實現了卡頓指標基本一致的前提下,頻寬成本最佳化10%的效果。
3.2 智慧預載入策略
預載入在B站的豎屏模式中大規模應用,給使用者提供了接近“0首幀”的流暢播放體驗。
相比於非預載入場景,預載入的主要挑戰在於多下載例項的排程管理。最初的預載入實現簡單粗暴:
在點進豎屏影片時,同時啟動多個影片的下載任務
預載入影片下載任務啟動時只載入很少的影片時長
等當前影片快取較充裕時,按照優先順序依次給後面的影片增大預載入快取
雖然上述預載入策略可以大幅度降低首幀,但我們分析發現,卡頓和頻寬消耗兩項指標都不理想,尤其是頻寬冗餘率達到了50%以上。
卡頓分析
預載入場景的卡頓原因主要是頻寬競爭,分為啟播和播放過程中兩個階段。
啟播階段的頻寬競爭是因為進入豎屏模式時的多下載任務競爭。啟播時預載入的影片越多,拉流的速度越慢,出首幀的速度甚至可能不如非預載入場景。由於B站生態中豎屏和橫屏場景之間的切換較多,因此有較多豎屏播放會面對這種啟播時的競爭,我們要最高優先順序解決。
播放過程中的頻寬競爭是因為缺少即時暫停預載入任務的機制。網速良好時,預載入的影片會持續拉取資料,而在網速變差時,如果不能及時停止其他任務的競爭,當前影片的播放就會受到影響。
綜上,我們需要更實時、更細緻、更相容的智慧策略應對網路的種種變化。
頻寬冗餘分析
主要是預載入快取過大,且未考慮使用者習慣就提前啟動多個稿件的載入。
我們的解決方案
我們構建了預載入的智慧模組,實時輸入各個下載任務的網路和稿件資訊、優先順序、使用者操作等,利用演算法實時決策每個任務的實時動作。具體決策輸出有:
是否開始下載資料
是否暫停下載資料
目標快取時長
演算法的整體最佳化思路如下:
網路極差時不進行預載入,減少競爭導致的卡頓
網路極優時或播放時長短時,只預載入啟播的一小段快取,減少頻寬浪費
網路一般且播放時間長時,需要預載入更多內容,預防可能出現的網路抖動
在實現的過程中有很多值得注意的點:
從其他場景進入預載入場景時,不論網路好壞,都不應該立即建立過多的下載任務。必須保證當前影片順利播放後,再按照優先順序對後續的影片預載入。
當使用者不習慣豎屏場景時,應減少預載入的個數。
暫停機制的實現需要及時生效,否則難以起到減少競爭的效果。因為播放器的下載任務一旦啟動後,至少存在應用層和傳輸層兩部分快取,如果只暫停應用層從傳輸層拉取資料,傳輸層的socket還會繼續從網路拉取資料。解決辦法是給預載入的任務設定較小的socket快取區長度。
長時間播放時,預載入的任務需要對連線保活,保證切換到播放狀態時能最快速度啟動下載。
最終透過演算法上的持續最佳化,智慧預載入策略全量上線,卡頓率降低了20%,同時結合智慧快取策略,節約了豎屏模式中20%的頻寬成本,實現了魚與熊掌兼得的效果。
4. 播放器策略的長期監測體系
在前述所有的最佳化中,改進策略都離不開資料的支援。可以說,一套長期穩定的資料監測體系,和能用技術語言解釋的指標,是我們改進路上的指明燈。
我們構建了完善的資料監測體系來觀測成本和體驗,按照實時性分為四大模組:
長期指標看板:記錄指標的長期走勢,用於分析不同維度對關鍵指標的影響,提煉出問題瓶頸和可最佳化點。
重要指標日報:彙總昨日各模組重要指標的變化,通知相關人員檢視,並對每日級別的資料異動進行告警。
異常指標實時告警:分鐘級別的實時告警以及分析看板,支援最快發現問題、歸類原因,並指派專人進行解決。
AB實驗實時分析:秒級資料查詢工具,幫助研發人員快速查詢實驗效果,及時調整引數和驗證,快速迭代演算法。
有了多層次、立體的資料監測體系,我們就可以在質量穩定可控的前提下,持續發現系統瓶頸,並利用AB實驗這個工具,以小步快跑的方式,更快速地對策略進行最佳化。
5. 總結與展望
現在大多數主流網際網路公司都會用到播放技術,音影片已經成為網際網路的基石。其中,不論是提升播放體驗,還是降低頻寬成本,都需要播放器做好最後一公里的最佳化。
在播放器降本增效的專案中,我們發現成本和體驗是一體兩面,兩者共同的基石是對播放過程中風險的識別。一個好的策略,能夠透過演算法調優、工程最佳化等技術手段,將播放場景進行細分,既識別出風險較高的體驗問題,又識別出風險較低的成本浪費。因此,我們撰寫此文與各位同行交流學習,歡迎各位讀者一起研討合作。
除了本文中提到的策略,播放器在音影片全鏈路中能做的事還有很多,包括端雲一體的網路傳輸最佳化、影像增強、異常資料監測等等。在元宇宙時代,使用者對位元速率、流暢度、時延等體驗的要求會更高。讓我們迎接挑戰,利用技術促進業務更好地發展。
來自 “ 嗶哩嗶哩技術 ”, 原文作者:陸元亙;原文連結:https://server.it168.com/a2024/0122/6837/000006837843.shtml,如有侵權,請聯絡管理員刪除。
相關文章
- 在Vue3中如何使用H.265流媒體播放器EasyPlayer.js網頁直播/點播播放器?Vue播放器JS網頁
- zFuse Pro for MacSPlayer Pro輕播影片播放器Mac播放器
- 網頁直播/點播播放器EasyPlayer.js網頁web無外掛播放器渲染頁面出現倒掛的原因排查網頁播放器JSWeb
- zFuse Pro for Mac SPlayer Pro輕播影片播放器Mac播放器
- 邊下載邊播放的播放器Android邊下邊播播放器Android
- 無外掛H5播放器EasyPlayer.js網頁直播/點播播放器應該怎麼使用JavaScript初始化?H5播放器JS網頁JavaScript
- H5流媒體播放器EasyPlayer.js網頁直播/點播播放器如果H.265影片在播放器上播放不流暢,可以考慮的解決方案H5播放器JS網頁
- Moon FM for Mac(mac播客播放器)v3.7.4Mac播放器
- 輕播zFuse Pro for Mac(萬能視訊播放器)Mac播放器
- zFuse Pro for Mac(SPlayer Pro輕播視訊播放器)Mac播放器
- 萬,能影片播放器:輕播zFuse Pro for Mac v1.7.30中文啟用版播放器Mac
- 親測好用的sPlayer輕播影片播放器:zFuse Pro mac中文版播放器Mac
- 萬 能影片播放器:輕播zFuse Pro for Mac 中文版播放器Mac
- sPlayer輕播視訊播放器:zFuse Pro mac中文版播放器Mac
- 萬能影片播放器:輕播zFuse Pro mac中文版播放器Mac
- Android中的廣播使用Android
- Javascript中的求值策略JavaScript
- JS中的求值策略JS
- Java中的策略模式Java模式
- 直播轉點播實踐
- ios中的多播委託iOS
- 盤點品牌傳播常用的話題方向
- 某些線上點播視訊的地址格式
- 如何找到能幫你賣貨的遊戲主播? YouTube和Twitch遊戲主播推廣策略(上)遊戲
- Netty中的策略者模式Netty模式
- 靠近阿里雲–視訊點播阿里
- Sunflower音樂播放器知識點(一)播放器
- 基於騰訊雲播 SDK 開發的 M3U8 線上播放器播放器
- 阿里雲視訊點播轉碼阿里
- 如何搭建小型影片點播網站網站
- 經驗分享:產研流程中降本增效的秘訣在這裡!
- 實體店短視訊拓客營銷策略:成交轉化與降本增效同步進行
- DataOps真能“降本增效”?
- 聊點技術|100%降本增效!Bonree ONE 透過 Clickhouse實現了
- 真正做到降本增效的方法有哪些?
- 降本增效的利器——元件化開發元件化
- JavaScript焦點圖輪播效果詳解JavaScript
- 阿里雲影片點播轉碼 舊版阿里