點擊上方“LiveVideoStack”關注我們
增長一直是業務的訴求，和增長相關的因素很多，內容、人羣、創意玩法、性能體驗等等，本次LiveVideoStackCon 2021 音視頻技術大會 北京站 我們邀請到了火山引擎點播技術研發負責人——浩銘老師。本次分享聚焦在字節跳動視頻通過性能體驗優化促進業務增長的實踐。包括在分析方法上的探討，如何衡量和預估體驗優化對業務增長的貢獻，以及具體的體驗優化實踐分享。
文 | 浩銘
本次分享主要分爲以下三個部分：首先是將我談的話題以增長還是質量爲目標做簡單定義；然後介紹在面向視頻體驗優化能力在建設上的行動，由於公司都在用同樣方法做事，前面同學講得或多或少都有些體現，更多地談一談做的理由和背後的思考；最後由於我們對內是中臺，對外也是希望雲服務方式能夠把能力輸入出來，以推廣爲目的，把能力沉澱，更多的輸出以及一些展望。
1、目標定義：增長or質量？
首先看一下增長和質量。
1.1 目標定義的矛盾
在做雲服務的時候經常會聽到核心指標，甲方和乙方都會關注這些指標，比如起搏耗時、卡頓、畫質等。這個話題對不論是客戶和或是雲廠商都很苦惱。客戶也希望保證服務是好的，需要有衡量方式，用雲廠商的時候需要知道用什麼指標促進其不斷進步，會去想用什麼方式去衡量。對於雲廠商來說，看到這些指標就要去想優化的動作。之所以說是蠻痛苦的過程，我也經歷過這些角色，在雲廠商看到這些指標，一方面會去想如何將其優化，另一方面我也發現指標定的不完善，有很多可置換的地方，完全可以通過PK策略把指標換的很好，客戶沒有提到的指標變差，甲方也想將衡量指標變得很完整，確實有一些比較困難的點：如果更看重畫質，提升畫質，起播耗時、卡頓可能劣化；如果優化卡頓指標，畫質可能劣化；如果縮短用戶感知的起播耗時，達到秒開效果，卡頓可能劣化。
以哪個指標爲主更好可以分幾個階段看，當有能力在指標之間不用做如何制衡就能獨立優化時是最好的，用技術實力將每個做優化。但優化到一定程度進入深水區，不得不考慮制衡方式，將會是比較難的話題。大家很容易理解卡頓和首幀哪個做極致優化對用戶更好，這樣類型的問題放在面前不經會想評估標準不夠高，有可能有更頂層的指標沒有被考慮，用它衡量置換關係會更合理。
1.2 播放體驗和靈魂拷問
接觸到C端業務後，發現雖然業務方和雲廠商說的是指標之類的要求，自己其實真正關注的是業務結果，例如：業務數據不好，是不是因爲播放體驗有問題？很難回答，假如看到抖音的DAU有微弱的下降，能不能說是播放質量的問題，還是剛剛提到的很多運營、人羣的問題。剛剛說的存量業務隨着時間指標劣化原因是否與我們有關。如果花了很大的力氣，新上線的feature，對業務的貢獻如何？產品和競品之間播放體驗的差距是什麼？我們總說極致體驗，到底什麼是極致體驗是什麼，以及怎樣纔算極致？這是在做C端業務支持字節內部各個業務發展時會面臨的問題。
1.3 QoS和QoE理念
這些問題的回答很有難度，可以看到共性，業務最關心的還是業務數據。業務數據包括DAU留存、廣告收入、成本等。從業務收入往下看到與我們相關的QoE，指播放次數、播放時長、完播率、投稿量、投稿率這些指標。在最開始討論畫質時，AB在看畫質時看什麼指標，在考慮AB時不用考慮技術工作，是業務問題，不管做什麼優化動作，看的都是相關QoE指標、播放次數、播放時長。例如做一些C端玩法時不一樣，會看滲透率、評論率等，這與多媒體無關。多媒體強相關基本圍繞上圖列出的QoE來看。無論做的是卡頓優化、能力優化、畫質優化，指標都不變。
我列出了一些常見的QoS，包括播放失敗率、起播時間、卡頓指標、畫質指標，在支撐QoE上來說即使再完善QoS也不全面，因爲很多因素都對體驗項有影響。如果人羣因素（老年、年輕）、運營活動影響、以這些體驗優化，更爲可控的還是多媒體能力相關的。
本次希望聚焦在列出的和視頻能力相關QoS指標展開討論，看這些指標如何影響到QoE，以及如何去衡量和製造工作。
1.4 面向體驗優化的一些不同做法
在開始提到了AB實驗，提到的難點都是缺少更上層的指導原則，但看指標PK更像是過程指標。如果有更上層指標，過程指標的好壞有了判斷條件。這裏非常推薦AB實驗，不是說QoS不好，但可以通過QoS指標自己給出公式衡量業務是否很好，廠商提供的服務是否很好，難度非常大，在理解力不夠情況下，很難短期給出合理指標。但AB實驗對希望提升標準給了方法，直接告訴結果，無論上了何種能力，直接從業務結果看能力結果的好壞，字節有了這個能力就可以用這個方法。有了這個方法後，最大的不同會暴露出元無知（原先我們不知道自己不知道）的場景。
舉個例子最開始做AB實驗的例子：當時想要在字節內部推自研的播放器及其自研的編解碼器用來提升體驗、降低成本。我在之前雲服務時做過，在能力上沒有新的東西，沒想到推兩個能力過AB達到正向結果花了將近8個月時間，做了上百次AB實驗，再來一次我一定分別推這兩個能力而不是同時。期間經歷了很多元無知，中間AB實驗告訴我在上這兩個能力之後，用戶評價意願變低，怎麼也想不通爲什麼一個播放器功能和編碼更新升級會讓用戶不願發評論，這是一個核心指標。它告訴了我這樣的結果一定是哪裏有問題但我不知道，之前提到的首幀卡頓失敗率指標都沒有變差，我也建立不起來爲什麼會影響到評論，只能看無知的地方。突破無知的場景有很多，可以看競品或與人聊，不斷增加埋點，陸陸續續建設龐大的埋點體系，包括音畫不同步、Seek耗時、未起播、功耗、流量的浪費率、畫質。
我們之前並沒有評價畫質的能力用分辨率或是碼率代替都不是很合理。碼率升高或降低並不能對畫質做直接衡量，用線上用VQScore評價指標方便的去衡量可能出問題的地方。面向體驗和質量的兩種做法在我自己看來最大的挑戰是面向自己的元無知，承認自己有東西不會，不斷通過AB實驗找到不會的點，將其露出來，也許在一段時間後對於穩定的業務給出一個QoS組合去衡量能力好壞的方法去代替AB，但很多產品現在還做不到，比如CDN產品很成熟，業務可以用速度和成功率等指標去衡量CDN廠商做得好不好，但新的傳輸方案PCDN因爲涉及端上的能力，指標體系更復雜，在短時間內無法建立對其合理的QoS評價標準，在這個產品上我一直強烈反對用QoS打分衡量做得好不好，而是一直在用AB實驗。這是不同的理念帶來的做事方法不同。
2、視頻體驗優化能力建設
接下來我想談一談在這個理念下能做得視頻體驗優化到底有哪些。我現在主要做點播方向，舉得也是點播的例子。大家都知道點播是一個很成熟的方向了。我在2012或是2013年時在百度做點播的服務，後來經歷創業時候做直播，現在回來做點播發現其實差不多還是這些。
2.1 體驗優化的技術空間來自哪裏
上圖是能力。現場有很多友商的同學，大家做出來都是這樣，沒有太大區別，在能力都基本同質，建構細節會有所不同，很多人會疑問以更高標準，以AB實驗指導內部做事是否還有空間。
我與產品接觸比較多，邀請中臺產品做分享。他提到的一個概念：基本滿足需求和充分滿足需求，這是完全不同的兩件事情，中臺做到充分滿足是大有可爲的。如果想要基本滿足，對於一個需求實現一種功能就可以完成；如果想要充分滿足，就需要不停付諸努力，試錯優化，找到最終最優解。他舉了這樣一個例子：人類在200萬年前學會狩獵和採摘，之後基本滿足食物需求，直到近現代纔有農業機械改良後的高產作物和強大的運輸能力，這時候才稱得上完全滿足。這個理念很有意思，代入到研發上也對應的上。接下來聊一聊這幾年在字節做到充分滿足我所做的事情。我做了一些印象深刻的歸類但不全。首先是弱網弱機的優化，海外、全國、下沉業務都是字節所看重的，有很多不像一二線城市有好的機型覆蓋和好的網絡，像RTC業務也是在做白名單，對於弱網弱機有一定優化，在各類業務中都有所體現，基礎設施帶來的難度提供了在技術上更優保證體驗不受損。
新技術比如H.265的播放，如果單單要達到H.265播放不是很難，很多雲廠商包括我之前也有方案輸出，爲了方便的業務適配和快速接入軟解。實驗時發現在非常成熟大體量業務中，把軟解換成硬解都會有1%以上的時長和播放次數提升，留存也是正向的。大家也許覺得1%數不太大，在成熟的大體量業務中，這個數字已經非常可觀。H.265提升硬解覆蓋率需要很多細節優化以及策略配合。控制策略方面實驗較多，沒有太多套路。有些能力用的好不好並不是中臺的本事，而是業務方的問題，把很多能力暴露出去後，幫助業務方在不同場景下用不同參數開啓不同能力。例如單列雙列業務模式下是否要預加載，預加載的策略是什麼，加載幾個，空間的留出。我們所能做得是理解業務需求把更多能力放出來，另一方面可以參與到業務的一個個實驗中，陪着業務將受益拿到並沉澱回來，這是我們能做的一部分空間。
前文都在說如何在現有基礎上把更好的技術思路用起來，讓體驗有進一步的提升，成本優化是公司經營中重點關注的點，如果把成本控下去，可以讓公司的財務現狀更健康，很多成本優化是來自於對性能犧牲，我們的空間是如何在成本優化的同時不造成體驗的劣化。上圖中列了如果我們有50%的成本節省目標，不做成本置換情況下在能力上可以做的事情，比如編碼器的優化、節省的浪費，以點播成熟業務來看，有很多浪費，達到60%，下載到客戶端的數據根本沒人看，這個成本是業務方自己在扛。但如果將這一部分的成本省下去，可能會帶來AB實驗的負向，在策略上深耕才能在節約成本同時，體驗不下降。最後是單價優化的可能，選擇質量不好但便宜的傳輸資源，會涉及到一些節點的調用和端上切換邏輯，AB實驗蠻難通過，這些技術的難度帶來了可做事情的空間。
這裏指的是點播的，直播上會更多，有玩法帶來的壓力。
這是大概的統計數字，已經做得現狀空間內差不多有39個已有策略，有的比較成熟像26個可以推廣，還有一些在開發應用階段。做一些歸類，有編碼、設備、功能、網絡、渲染、緩存、檔位、上傳等。這裏就不展開講了。
2.2 零耗時首幀優化
舉一個簡單的例子代入剛纔說的思路驗證。首幀的例子大家理解，可以拿來演示一下。字節有對於零首幀分析優化的講解，我拿着成熟的例子介紹。首先“零耗時”首幀並不是0毫秒，而是基本用戶感知不到首幀存在，現在線上效果達到100ms以內。上圖是一個很標準的圖，很多第三方SDK和海外統計性數據平臺有類似方式，它會記錄起播時間，中間是否有未播放就退出，真正首幀結束時間，中間如果發生Seek或卡頓會將其時間點和耗時記錄再到播放結束。最開始我們也是這樣的埋點體系，這個體系對於使用就夠了，如果想拿它去下鑽深耕很無力，不知道其中哪裏藏了可被優化的地方。
2.2.1 指標建設
所以第一件事情是重新建立指標體系。前文提到用8個月時間就是不斷完善買點，看到底在改動時候，哪個指標變差，後面會有對其歸類，在建設時不知道什麼會出現問題，會有一些帶有嘗試成分，把所有能想到的都加上。其實在首幀產生時，在上下文環境之前，還有客戶那裏創建頁面與我們交互。到我們有首幀準備，數據下載（其中到底選擇CDN，P2P，解析結果是否要緩存，數據淘汰下來是否要做緩存，淘汰策略是什麼）首幀渲染。
2.2.2 能力建設
這些埋點體系建立後嘗試做歸類，在每個類別裏做什麼樣的事情。這裏分了四類：一是與業務相關的，在這一頁思路中在想有什麼能力以不做置換情況下單純靠能力提升做體驗優化，而不是用犧牲指標來換。
首先是業務和業務交互，業務可以用多實例方式與播放環節交互。Video Decoder在硬解下stop release&start是有120ms耗時，如果把複用節省是一部分首幀節省，這裏統計數據是優化首幀40ms以上，在預渲染方面會有單獨的介紹。
網絡耗時在SDN下載時有很多連接可以複用，不用釋放，好處是將重新建聯的耗時省掉。在做優化的上線之後，發起新請求，單獨靠此能力，沒有預加載的幫助開始接收數據不超過100ms。有了這個能力就有一些想象空間，用在點播只是基礎，後續用多自由度或是VR需要切換視角時候，多路流需要有儘快完成切換的動作，這些場景都是可以用的。
我還列出了硬解初始化，和一些公司聊過，會覺得硬件是好，但首幀會變差。這裏做業務初始化，業務是可控的，一些信息提前知道，不需要解析才能初始化硬解設備，可以提前做，達到硬解和軟解差不多的首幀效果。以及一些fallback，如果一些機型不支持硬解，需要fallback軟解，相比於單純使用硬解，會增加20ms耗時。結合前文機型選擇能力，提前知道哪些機型不合適走到硬解，這樣就把fallback比例控制在0.3%以內。
最後一個大維度合的有點牽強，播放器策略邏輯耗時，這一部分不是必須存在的，是爲了播放邏輯更好，人爲引入，在首幀渲染之後不一定會馬上起播，會緩存一段水位，到底需要緩存多少後續會有例子介紹，緩存多了會浪費，緩存少會卡頓。這種耗時是人爲引進，可以被優化，有些場景是低清場景，例如西瓜視頻豎屏觀看有詳情介紹，切換至橫屏可能是720P或更高，豎屏爲了保持切換流暢使用相同分辨率播放同一視頻。如此小的窗口上這麼高的分辨率沒有感官上的差異，反而會有卡頓首幀影響，這一方面是可以被優化的。在把問題拆解的時候，做一些對應的優化動作靠着之前研發水平經驗不是什麼難題。主要想要分享我們是怎樣進一步拆解，想到做這些事情的。
2.2.3 策略優化
上圖是有些能力是我們自己能做的，有些能力是第一環節組合是業務浪費的，這是聯合業務一起做的，這是業務的同學優化項目，我們來配合，類似抖音沉浸式的在划動時會切換下一個視頻，最早做了預加載，暴露能力出去，業務做了很多嘗試去知道預加載數量，每個加載時長最優。更進一步預加載後是否可以預解碼，在有空閒的時候將解碼動作做了，在用戶划動時將解碼好的那一幀投出渲染，這樣首幀可以極大的被優化，最後想了一下預渲染的時機怎麼觸發。以前是將卡片劃到下一個穩定了渲染，現在只要一鬆手就可以渲染，通過這種方式感覺不到首幀存在，這樣的好處會先展示封面，之前加載圖片也是需要帶寬的，圖片的性能優化也要做考慮，做預渲染方案圖片都可以省掉。每次一劃，下個視頻第一幀已經被截好，圖片意義不大。因爲涉及到業務方使用姿勢，無法在中臺能力沉澱，額外出了將Demo最佳實踐的方式開源，在官網和展臺獲取。
有了思路儲備能力，面對首幀和卡頓如何權衡纔是對業務最好的。實踐的結果在內部各個業務中通過調優能取得完播率和播放指標的顯著正向。但參數差異很大，沒有統一結論。介紹一下過程。我們會有緩衝水位概念，有可播數據後不一定馬上播，到緩存多大後才播是不停嘗試的。最開始用靜態拍緩存0秒或緩存1秒，分別看效果。後續明顯看到1秒的卡頓明顯好於0秒，實驗結果來看，AB結果也是1秒好於0秒。不是所有用戶都是弱網弱機，不確定這1秒有無浪費，設置成1秒有很多優化空間，逐步嘗試不止看起播，把卡頓數據也列出，這是一體的，都是調整水位的動作，是動態水位優化策略。這裏解釋一下起播是緩存多少才起播，卡頓後的水位是緩存了多少後纔出卡頓，這兩個策略是連着做的。得出經驗性結論在微調階段，可以看出1秒留多了，降的時候可以看到顯著的正向收益，但降到一定閾值後，要權衡首幀和卡頓。在AB實驗看來用戶會用卡頓更加明顯，提升首幀後緩存水位從200ms提至400ms，用戶體驗結果會更好，卡頓減少。且不是每個用戶都是靜態，可以根據自身情況做調整。端上對之前發生和網絡情況瞭解，可以在幾個值中動態選擇更好結果。對於能沉澱下來的能力經驗包括水位值和業務相關。不同業務不同，稍長的業務用戶對卡頓更能容忍，將一些優化能力在首幀。沉澱的經驗對絕大多業務都有收益，業務類型很廣。
3、能力沉澱&展望
最後說一下能力沉澱和展望。我們有很多積累性的方法，我代入了點播的例子，包括其他例子都是同樣思路，但都會有一些門檻，包括儲備能力、理解能力，建一個置信的AB平臺都需要投入。字節每天都有超過1500次的新增A/B實驗。在同一撥的用戶分層乾淨，不互相干擾各自實驗，影響雙方至信度有平臺建設性工作。如何將能力沉澱不一定需要通過完備方法，達到較好體驗結果。
3.1 能力沉澱，快速橫行復制
上圖是客戶端服務端數據結合的例子，大多數模塊並不陌生。重點是客戶端策略中心的部分，將之前沉澱經驗都放在客戶端策略中心模塊，這是產品化的一部分，是隨着點播SDK組件一起放出的，把之前積累的包括測速選檔，預加載策略，弱網弱機策略經驗放至策略中心。策略中心相對開放，業務有定製化二次開發。業務方比我們更瞭解業務，如果想要自己做更改，例如進入個人主頁預加載策略就與單列雙列不同，可在技術上做二次開發的更改，這是在產品化沉澱和之前做法思路不一樣的地方，將深入業務零散的事情找了落腳點，客戶端的策略中心能夠被持續的迭代優化來源於自己的數據上報和統計，沉澱於策略中心，通過服務端下發，完成這樣通路。不僅在內部，還具備對外輸出能力，只是能輸出客戶端策略有限，在一點點打磨。
3.2 重視QoS指標劣化診斷
QoS指標很重要，但理解力不夠，不以它爲標準，但已經知道對QoE有強關聯的QoS指標，它的劣化是不能被容忍的，在對QoS診斷上投了大量精力。包括QoS指標的監控大盤，對其自動歸因，手動歸因，單點歸因，這些能力在其他雲廠商也會有建設。不同的是我們希望把提效做到極致，發生指標劣化，第一時間沒有經驗同學也能知道發生事件的原因。我們除了完成四個能力建設以外，將連接這四個能力的線也做了產品化，讓沒有經驗的人在看到大盤的時候也能得出結論，首先用智能歸因明確問題方向，在下一步引入手動分析，對還有懷疑的地方手動看。避免自己經驗和外部干擾，其中加入了弱引導，多個維度加百分比，百分比的含義是這個維度下有多大可能出現根因，讓其儘量聚焦在引導的方向看，最後將大盤指標對應有特點的詳細數據單獨拉出，進入檢測項目列表，對各種已知問題類型，比如有播放器創建檢測、視頻黑屏檢測、劫持檢測、播放URL過期檢測，這些在日常會遇到的問題做針對性檢測，找到對應問題和修復手段。
在不斷演化過程中，智能歸因可讀性越來越好，從開始給出某個CDN異常上漲或某個版本劣化的結論，到現在可以給出類似有97%概率歸因到惡意用戶黑產導致的指標異常，理由是低端機型低版本集中，這是在提效方面做得事情。
3.3 使命&願景
這是使命願景的一部分，希望做得是數據顧問的角色，不止面向監控與排障，還想面向策略調優例如策略分析決定哪一套參數上線，沒有被完全產品化，更多的是在case by case分析中，最後面向產品洞察，由於有很多類型業務，可以抽象成不同賽道，給行業做指導。產品同學問，我們與競品相比的優劣，如果將抽象做得足夠好，就可以給出在所在賽道好壞的建議。策略中心就是剛纔提到的，和內部方法論結合較緊。把基礎達到，功能指的不是基礎功能如播放、下載，而是已有功能基礎上做深耕不得不挖出的新功能，比如連接複用、水位閥控制下載節省流量，這些屬於我說的功能，比較通用能看到業務收益，在策略層被使用在不同場景中，構建產品中心服務，這其中功能和策略屬於自身產品化部分橫向複製。場景層更多的是通過Demo開源，告訴理解到的最佳業務實踐，如何寫代碼，幫助快速實現。現在開源的包括類似抖音快速刷新場景的實踐，下一步會開源西瓜划動體驗優化。
接這兩個框圖做一個總結，雲廠商會有特別大的產品矩陣支持端到端的所有功能，希望和字節相關獨特都在這張圖中了，在支撐內部業務追求體驗時，逐漸開出了數據顧問和策略中心兩種產品，不同於雲服務產品，但也會將其作爲產品向大家開放，它不一定幫助雲廠商增加營收、控制成本，但幫助客戶做好體驗、幫助客戶把錢省下。在做字節內部業務的時候，對業務價值很大，但作爲雲服務並不多見，打磨好這個產品，是我們希望持續投入做的事情。
最後提下願景，火山引擎視頻服務希望能爲更多業務方的使用體驗、使用成本負責。
以上就是我本次分享的所有內容，謝謝。
講師招募
LiveVideoStackCon 2022 音視頻技術大會 上海站，正在面向社會公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內容對技術人有幫助，其他都是次要的。歡迎通過 [email protected] 提交個人資料及議題描述，我們將會在24小時內給予反饋。
喜歡我們的內容就點個“在看”吧！
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。