點播成本節(jié)省的點其實涉及諸多部分，例如：CDN、轉碼、存儲等，而利用播放器降本卻是很多客戶比較陌生的部分。火山引擎基于內部支撐抖音集團相關業(yè)務的實踐，播放器恰恰是成本優(yōu)化中最重要和最為依賴的部分。

火山引擎的視頻團隊做了份數據統計，在一個很經典的視頻業(yè)務中，我們在2022年至2023年大約1年半的時間里，針對這個業(yè)務進行了33次成本優(yōu)化點，其中13次是播放器主導的優(yōu)化，其余的有12次也是需要播放器強配合的優(yōu)化，也就是說在這個業(yè)務里，75%的成本優(yōu)化是直接或間接由播放器參與，可見客戶端對成本優(yōu)化的關鍵作用。

最終我們在很多實踐中也發(fā)現通過播放器的優(yōu)化可以為點播業(yè)務節(jié)省20%甚至更多的成本，本篇內容就將聚焦在播放器層面如何節(jié)省成本這一主題。

點播成本構成

在視頻點播的成本構成中，有很明顯的二八原則：

圖片

• CDN帶寬成本占絕對的大頭，80%都是帶寬成本；
• 其次是存儲和轉碼成本，二者占不到20%；
• 額外還有一些其他的周邊的成本，比如日志處理的數據成本、AI處理的成本。

我們可以將成本的優(yōu)化理解成“置換”，在點播的成本優(yōu)化中，就存在2種“置換關系”：

第1種置換關系是“成本項之間的置換”，指的是「帶寬-轉碼-存儲」之間的置換。

圖片

上圖是H.264升級到H.265編碼格式的例子，265的壓縮率相對比264要優(yōu)20%-40%，所以帶寬、存儲上265是大幅度減少；但是265的計算復雜度要復雜很多，所以轉碼成本大幅度升高。

而這個圖不是一個等邊三角形，帶寬成本要遠大于轉碼和存儲成本，所以這個置換是非常劃算的。

第2種置換是“成本和體驗的置換”，我們一般說是“蹺蹺板效應：

圖片

例如：

我們增大緩存時長，對應體驗上「卡頓率」就會降低，但是成本會增加；

抖音小視頻feed流場景，我們做預加載，這時候首屏感會更順滑，但對應的成本是增加的；

降低碼率，那么體驗上感到清晰度變差了，而成本就是減少的；

蹺蹺板中間支點是技術，我們通常是希望固定體驗、降低成本，依靠技術來支撐。

所以我們總在說降成本，那降的到底是什么呢？我們這里用一個很簡單的乘法公式來表示：

圖片

在過去，“單價”是非常明顯的因素，大家往往選擇在采購環(huán)節(jié)盡量的壓低單價；而“用量”上通常會被認為是無法改變的業(yè)務因素。

但“用量”實際上是包含2類，一類是正常用量，確實是比較難改變的業(yè)務因素，但另一類是“浪費”，是可以被優(yōu)化的。

所以如何識別出浪費、降低浪費，是播放器降本的關鍵點。

那么造成浪費的因素有哪些呢？

圖片

例如在視頻播放過程中，會包括“已播放的數據”，和“未播放但已經緩存的數據”，如果用戶中途離開播放，那其中“已緩存的數據”都是浪費了。

所以我們定義“浪費”是“已經緩存了、但不需要的字節(jié)數”。

從理想上來說，沒有浪費是最好的；但往往業(yè)務中，浪費是非常大的，大于30%是很常見的。

常見的可能帶來的浪費包括了：

?未播放離開

?向后拖拽

?切換檔位

?清晰度溢出（舉例：很小的手機屏幕播放4K的內容，肉眼感知不到清晰度的區(qū)別）

播放器的成本優(yōu)化方法

針對上述的浪費我們進行了如下的具體優(yōu)化方法：

1、緩存的浪費

圖片

承接上圖的播放器緩存示意圖，如果用戶播放過程中離開了，那么深灰色是浪費部分。很容易就想到我們減少深灰色的部分的大小，比如把播放水位降低1/3（也就是圖中淺黃色的部分減少掉），不去緩存，那么浪費就明顯的減少了。

這個就是靜態(tài)水位的思路，通過減少緩存水位來減少浪費。

但是，靜態(tài)水位是很難抉擇的，水位大了浪費多，但是水位太小了，卡頓就會明顯的增加。

這里有個馬太效應，從原理上，緩存的本質是為了對抗網絡的抖動的。 網絡穩(wěn)定好時，只需要很少的緩存就足夠了，但是網絡好時緩存會填充的很快，大部分時間都是飽和的。反之，波動大的網絡，需要更多的水位，但總的上限也有限，無法提供有效的緩存。

為此我們實現了的動態(tài)水位算法，我們根據一些因素來動態(tài)的決策緩存水位的大小：

?1）探測用戶的網絡速度和穩(wěn)定性，對穩(wěn)定性高、速度快的，我們減少緩存；對網絡速度差、穩(wěn)定性差的網絡，就增大緩存，這樣在網絡抖動時就能夠有更大的緩存空間使用；

?2）根據用戶的播放行為，通過數據分析道，視頻觀看的前期，用戶離開的比例會更高，觀看的后期，離開的比例就會降低， 所以前期的緩存水位小一些，后期的緩存水位大一些；

?3)還有一些其他的因素，但目的是在每次播放時決策出一個盡量合理的緩存水位，來平衡卡頓和浪費；

決定了緩存水位大小之后，還有個細節(jié)點就是range請求。

圖片

Range是http協議的一個請求頭，默認是“0-請求” ，表示請求完整文件。

左側的圖示意，如果是單獨發(fā)一個“0-請求”，那么CDN服務端就會持續(xù)的返回整個文件，如果在中途斷開，從服務端視角來說，這些數據已經發(fā)送過去了，無論客戶端是否需要，都已經計費了，就構成了浪費。

在上圖，我們分成3段來發(fā)range請求，中途斷開時，是可以停止掉最后一段，那么浪費就大幅度減少了。

同樣，靜態(tài)的range是很難抉擇的，range拆分的太細會引起卡頓的提升；range過大了成本節(jié)省的效果又不夠了。

這里我們引入目標水位的概念，就是剛剛講的動態(tài)水位算法所決策出來的水位大小。

播放器Range請求的應遵循兩個原則：1. 將當前視頻盡快緩存到目標水位。2. 控制Range拆分的大小，避免太小的Range拆分。

圖片

上圖是動態(tài)水位算法+動態(tài)range拆分的效果示意圖：

?橫軸代表時間線。 縱軸上圖是視頻下載的大小，藍色塊代表一個range請求；下圖是緩存的大小，橙色的折線表示緩存隨著視頻文件下載和播放時間的波動情況，橫著的虛線是目標水位。

我們從左到右，分析下目標水位和range的關系：

? 看第1條豎著的紅線，決策出來第一條目標水位1，是啟播水位，啟播時的range會略大于后面的2個range；

? 第2條豎著的紅線，是判斷出一次水位提升，有可能是檢測到網絡波動，會提高目標水位到水位2，同時做一次略大的range請求來達到目標水位；

? 第3條豎著的紅線，是再次提升目標水位，到水位3，有可能是因為觀看時長增加到閾值，判斷離開概率較小，所以保持高水位；

?后續(xù)的播放，在目標水位3隨著時間波動，range大小也會穩(wěn)定些。

從最終效果上看，在任意一個時間點離開，都能夠保障相對合理的浪費。

?我們在不同業(yè)務上實踐了很多次動態(tài)水位+動態(tài)range的AB實驗，在體驗指標持平或更優(yōu)的前提下，帶寬降低8%；

2、預加載的浪費

在類似于抖音這種feed流下滑的場景，會提前加載好下面的視頻，能夠使滑動更順暢，我們 叫“零首幀”效果，里面作用最大的就是預加載。

一般的預加載是固定幾個視頻，每個視頻固定的大小。為了得到更好的預加載效果，會盡量多、盡量大的做預加載，也就構成了浪費。

圖片

我們做的“精準預加載策略”，在“時機、大小、個數”上做精細化的優(yōu)化：

?1） 時機上，對預加載也進行切片，這樣可以區(qū)分出來一部分是緊急的， 其他是不緊急的。比如圖里，標記P0的是要最優(yōu)先下載的，然后可以做預加載，預加載標記P1的部分，然后是當前視頻的緩存水位，之后可以選擇是否要預加載P3的部分。

?2）大小上，每個視頻也會結合視頻的長度、頭大小、碼率等因素計算出來需要預加載的大小

?3）個數上：按照feed list中的優(yōu)先級依次預加載后續(xù)N個視頻（動態(tài)計算），也會結合用戶本身的行為（比如快速滑動）來動態(tài)決策。

?我們在不同業(yè)務上進行AB實驗，都能夠驗證這策略可以有效的提升預加載利用率、降低對應流量成本 ；

3、清晰度的浪費

現在的主干場景是在移動端看視頻，大家都會有啟播選檔的策略，就是在播放啟動時，決定所需要的清晰度，一般是跟隨網速、碼率來決策的。

圖片

經常大家面臨的場景是，在豎屏里播放橫屏視頻時，實際上在很窄的一個空間里進行播放， 這個時候，如果依然使用完整的清晰度，那么肉眼是看不出來的清晰的。而且，通常情況下小窗播放時用戶的主要關注度也并不是畫面清晰度，所以就產生了實際上的清晰度浪費。

我們對應的解決策略叫 “窄屏低清” ，就是識別出來顯示區(qū)域很窄時，播放低清晰度的視頻（比如360P），當需要橫屏時，再快速的切換為正常的清晰度。這里如果是mp4格式播放，需要轉碼也做些配合，支持mp4的幀對齊和平滑切換。

在很多應用中都是很常見的，也有常見的小窗播放，多個業(yè)務的AB實驗都能有3%以上的成本收益；

另外清晰度上還有個很棒的能力，是客戶端超分。隨著客戶端超分能力的優(yōu)化，現在很大一部分機型在客戶端向上超分一個檔位是完全沒問題的，耗電可以忽略。

對應節(jié)省成本的策略是“降檔超分”，就是分發(fā)的清晰度向下降一檔，然后再通過客戶端超分降主觀清晰度補回來。在國內當前的機型條件下，大部分業(yè)務能夠有6～8%左右的成本收益。

4、異常流量的浪費

我們根據「播放器日志是否可以識別」、「是否是正常流量」把流量分成了4類。

圖片

在非常多的業(yè)務中會發(fā)現第三種情況：流量有異常浪費，比如有部分視頻碼率過高，可能是沒轉碼，或者轉碼模版用錯了。我們開始時會認為“這些都是很明顯的失誤，業(yè)務層小心點不就行了么？ ”，但后來我們做成了單獨的異常流量分析模塊。我們跟業(yè)務嘗試分析原因，發(fā)現業(yè)務總是復雜的：

• 比如業(yè)務場景很復雜，包括短視頻、長視頻、主頁視頻、廣告視頻等等；
• 研發(fā)的迭代也通常會帶來些歷史問題；
• 并不是所有的人員都需要持續(xù)的感知成本，只要有一個環(huán)節(jié)漏掉了，那么就可能會造成很大浪費。

這里還有個問題點，如果是體驗問題或者bug，總會有用戶保障，來及時發(fā)現。但成本問題，用戶基本是無法發(fā)現的，發(fā)現時就比較晚了。

我們是通過端到端的日志分析來發(fā)現和避免這些浪費的。原理很簡單：

1）在客戶端對日志染色，

2）cdn日志里記錄的，區(qū)分是否是播放器產生的、是否是我們點播的域名。

3）對兩頭的日志進行比對和分析；

不僅如此，這里還有個副產物，是通過這些日志分析，識別到業(yè)務真實是被盜鏈了，然后做盜鏈的治理。

數據挖掘成本優(yōu)化空間

以上是火山引擎是實際業(yè)務服務過程中探索出的優(yōu)化方案，但優(yōu)化是不是有上限的，優(yōu)化到什么水平可以達到成本和體驗的平衡，更多的能力是通過數據能力持續(xù)的挖掘出來的。

先從結果上來看，我們成本優(yōu)化后通常會有2個報告：

1）AB實驗報告：里面會分析對QoE的體驗影響多少，對成本優(yōu)化的影響多少，比如人均播放時長增加多少，成本降低多少。做成本的AB實驗，依賴一個工具“客戶端成本指標”。

2）價值回溯文檔：用于核算真實收益有多少，一般發(fā)生在完整上量之后，比如1個月或2個月后。關鍵結果叫“萬分鐘播放成本”，這個對應的依賴的工具是“成本評估公式”。

客戶端成本指標

圖片

這張圖從左往右是視頻點播的數據流向。想要建設好成本埋點，有2個難點：

1、成本擬合。因為真實的計費數據是左側CDN的計費日志，在右側的客戶端側實際上是沒有成本數據的，所以我們需要把數據緩存層的對成本的埋點盡量的擬合，使之盡量的對應到CDN的計費日志。這個過程是非常艱難的，我們通過了大量的離線校驗。

2、提升可解釋率。業(yè)務動作比較復雜（播放、預加載、拖拽、重播等等），舉個例子，重復播放，播放層是記錄2遍播放時長的，但是因為有緩存，真實的網絡請求只有1遍。我們想要兩份數據盡量對齊、可解釋，就需要涵蓋住盡量所有的業(yè)務場景。

我們當前達到了“可解釋率達到95%”，也就是說比如服務端CDN產生了100Gbps的帶寬，客戶端的日志能夠擬合解釋清楚95%。

雖然還不到100%，但日常來做成本優(yōu)化、成本歸因已經足夠了。

下圖是成本指標進入AB實驗后的結果

圖片

核心指標

圖片

歸因指標

成本數據進入AB實驗有什么用呢？

1、快速判斷客戶端的成本變化結果。大部分成本優(yōu)化的能力都是伴隨著策略的，不同策略有不同的結果置換關系，我們需要通過實驗來確定效果。假設沒有客戶端的成本數據的話，我們就需要用不同的CDN域名來實驗，這是很低效的，并且域名帶寬的波動也會引起成本的波動。而在客戶端成本指標進入了AB實驗之后，大部分場景都直接看報表數字就可以了；

2、機制上可以防蛻化。 業(yè)務的產品經理、分析師等角色也日常會關注到實驗數據的，當成本數據也進入實驗后，這些角色也可以關注到成本的變化，這樣就能夠防退化了。舉例：版本升級時，只要經歷了AB實驗，就很難有成本退化的問題。

成本評估公式

“成本評估公式” ，本質是一種單位成本的衡量方法。

圖片

我們叫“萬分鐘播放成本”，分子是點播的IT成本，分母是點播視頻消費時長。

從技術側來看，分子是“CDN、存儲、轉碼等各種成本的加和”，分子是播放的時長。

這個公式很簡單，但為什么要這么做呢？

涉及到成本優(yōu)化，就會跟采購、財務團隊打交道，采購、財務看到的都是每月的賬單，業(yè)務用量每個月都在上下波動，導致賬單每個月也都在波動。萬分鐘播放成本是單位成本，就可以刨除掉業(yè)務用量的影響因素，來衡量成本是否真的優(yōu)化了。

我們來拆解其中的萬分鐘CDN成本：

圖片

萬分鐘CDN成本的影響因子會涉及到價格、碼率、浪費率、帶寬流量比。

舉一個真實的例子：

有個客戶反饋成本增加了，但是客戶自己的業(yè)務用量在波動，不太好判斷是什么情況。我們拆解分析萬分鐘CDN成本的具體影響因子，就發(fā)現了萬分鐘CDN成本確實是漲了11%，主因是“碼率”漲了8%，“浪費率”增加了5%。

總結和展望

建標準

在服務業(yè)務的過程中，大家經常會面臨一個問題， 還能再降多少？極限是多少？

這些問題是很難回答的，因為每個業(yè)務的場景都不同，舉例緩存浪費中，每個業(yè)務的客戶中斷離開的模型可能都不一樣，那么建設統一的標準就很難了；

火山引擎目前通過3種方式來建設標準：

1）通過排名獲取標桿：將類似場景的業(yè)務進行排名，對齊當前技術做的最好的，可以作為一種標準；

2）離線的實驗來模擬：我們做了成本的自動化測試平臺，設計測試case，測試出來不同的參數的成本結果是多少，最后總結分析出來極限是多少；

3）通過“理論公式”來推算“標準” ：舉例通過“視頻播放時長、中途離開比例”的關系，然后推算出理論的優(yōu)化空間有多少；

做顧問

面對的業(yè)務越來越多，降本的能力也越來越多時，就會遇到效率問題：功能這么多，應該用哪些？每個業(yè)務的場景也不一樣，那么策略參數應該怎么配置呢？

圖片

萬分鐘播放成本分析和策略推薦

解決方法是做顧問：上圖是我們的一個萬分鐘CDN成本與理想萬分鐘成本的一個差異分析表，我們給計算出了對應的差異，然后再給出可以補足差異的策略或功能推薦。

當然，這個表只是一個總結概覽，更多的內容我們會整理成“顧問服務報告”，把各個點的差異、業(yè)務分析、解決方法與業(yè)務逐一的討論分析。

萬分鐘播放成本是一個非常簡單、容易落地、價值很大的工具，大家計算下萬分鐘播放成本，如有調優(yōu)的訴求，非常歡迎來與火山引擎交流。火山引擎視頻點播https://www.volcengine.com/product/vod。