短視頻在過去數年內成為主流的內容創作和信息分發渠道之一， 字節跳動提供獨特的視頻播放體驗，吸引了全球數十億用戶， 一項重要的貢獻因素是其先進的個性化視頻技術。過去五年間，團隊完整開創了這一嶄新的技術領域以優化用戶體驗， 在此我們首次向業界披露個性化視頻技術區別于傳統音視頻技術的主要概念和部分方法， 希望對整個行業有所啟發。本文系“個性化播放技術”的中文精簡版，欲了解更詳細內容可參考原論文。論文鏈接：https://arxiv.org/abs/2410.17073

背景

過去的若干年間，音視頻服務重在提供基礎的視頻轉碼與分發能力，行業的注意力主要集中在四個方向。

? 編解碼器標準的演進、前后處理算法的研究與開發。例如MPEG-2、RMVB、264/AVC、 265/HEVC、266/VVC、VP9、AV1、AV2等視頻編解碼器，MP3、AAC、HEAACv1/v2、XHEAAC、OGG等音頻編解碼器，Jpeg、WebP、Heif等圖像編解碼器，以及前后處理方面的大量工作如超分、降噪、色彩增強、ROI區域分析等。

? 流媒體傳輸協議的演進。一些取得廣泛影響與應用的協議包括RTP/RTSP、MPEG2-TS、RTMP、HLS、DASH、SRT、RTC等。

? 多媒體框架。例如DirectShow（Microsoft）、Helix（Realnetworks）、MediaFramework（Google）、AVFoundation（Apple）、FFMpeg、VideoLAN、Gstreamer等。

? 云服務。許多公司往往以彈性計算平臺為基礎，提供基于容器鏡像模式或者基于serveless模式的服務，允許計算圖式的任務分配與調度，用以靈活地處理轉碼與前處理任務，并以此為核心構建包含元數據、上傳、轉碼與下發服務、CDN、播放SDK、埋點分析等在內的端到端能力集，供業務使用，相似地，Brightcove、AWS、Azure和Google Cloud等供應商也展開了基于云的音視頻服務，供各種規模的公司快速集成與應用。 

除此之外，還有一些與音視頻技術相關的重要工作，例如信號調制、DRM保護、芯片開發等，與上述各方向之間均存在關聯、其發展軌跡亦相互影響，不贅述。

在控制與決策優化方向上，工業界和學術界曾有許多嘗試，例如自適應比特率（ABR）算法方案和改進等，在編碼方面則有Netflix、Brightcove從2015年開始發表的一系列工作，讓Content Aware Encoding和Context Aware Encoding成為業界編碼優化工作的范式，但以上工作仍過于局部、零散，并不能充分解決短視頻遇到的問題。

在短視頻服務的研發方面，我們面臨前所未有的挑戰：

• 投稿數量及其差異性。短視頻應用擁有每天億級別以上的UGC投稿，其內容和質量千差萬別，真實地代表了整個世界的多樣性。許多問題及其解法、總結出的規律是在小得多的規模上進行的，但在我們的規模下卻距離理想狀態差之甚遠。
• 用戶數量及其多樣性。世界上每天有數十億用戶使用短視頻，其使用方式與人為偏好存在巨大方差，并由于給予應用的反饋信號雖然數量繁多，但蘊含的信息稀疏且有限，相關干預的效果易被掩蓋。
• 復雜業務形態帶來的收益與成本約束。短視頻應用承載了極為復雜的業務，包括廣告、電商、直播打賞、生活服務、搜索等等，同時視頻的處理、存儲與分發所帶來的成本極高，視頻技術應當聚焦提升用戶體驗，進而提升業務指標，同時平衡與成本之間的關系。

通過引入眾多在推薦、廣告、用戶增長等領域飛速發展的個性化技術，與“傳統”音視頻技術進行結合，字節跳動從2019年開始第一次構建完備的個性化視頻技術體系，帶來了根本性的范式轉變，在內部評估和市場競爭中均取得了優異的結果。

總述

1. 方法論

個性化視頻技術的理念在于，對不同用戶，根據對其偏好和習慣的理解，綜合考慮觀看內容、時間、場景、設備、網絡等所有影響維度，對音視頻領域所具有的不同技術進行重新估計與選擇性運用，提供整體最優效果。即以控制和決策為核心，強調整體最優、強調對不同用戶及其相關影響維度采用不同技術。與之對應，傳統音視頻領域的工程實踐未對不同用戶的差異化訴求予以足夠關注和滿足，往往以固化的框架和能力為核心，寄希望于發展通用、統一的技術提供給用戶，或陷于局部較優的方案，這在高用戶規模、高偏好方差的視頻應用體系中將喪失巨大的提升空間。

基于以上理解，我們重新設立了個性化視頻技術的工作流程，參考圖2-1，在此流程中將針對每次改進評估其用戶影響，這不是一個很新的思路或者方法，但將這套方法置于核心地位，以此驅動傳統的編解碼、協議、框架、服務等開發工作，則屬于首創，借助字節跳動數據驅動的文化和相應工具（例如AB實驗平臺）得以實現。

圖2-1 個性化音視頻技術工作的通用流程

2. 目標定義

從通用角度看，ToC的社交媒體類業務廣泛使用LT（Life Time）表示一段時間內用戶的活躍情況，以及使用ARPU（Average Revenue Per User）表示每用戶平均收入，此處為后文討論方便，我們做一簡化，即設定短視頻業務的整體目標為LTV（Life Time Value）：

基于上述目標，我們設立二級指標，音視頻領域大家會觀測EBVS（Exist Before Video Start）、VPF(Video Playback Failures)、VST(Video Startup Time)、Rebuffering Ratio等不同QoS指標。但我們認為這并不足以刻畫用戶的信息，也并不能完整反映用戶播放過程中的狀態變化，因此會設立一個更為全面、開放的指標組QoS（Quality of Performance）表示多維度的完整性能體驗。具體定義參見表2-1 ，同時也會估計不同性能指標對業務指標的影響。

表2-1 部分性能指標定義

注意，以上表格內并非全部QoP指標，其影響幅度將隨業務發展階段與環境而變化，QoP指標組所涵蓋的指標會發生增減，變更影響幅度也可能發生大幅改變。

在評估環節，我們將對每個項目計算profit和ROI，并根據業務場景和目標設定不同的調控不同的成本價值。并令其滿足以下上線條件：

3. 端到端工作框架

傳統上端到端的音視頻技術體系將鏈路劃分成多個環節，包括投稿、轉碼、分發、調度、播放等環節，一種典型的系統架構如下圖所示：

圖2-2 AWS的VOD Streaming架構

在我們的系統上會格外強調控制與決策，以及對用戶的影響，并且我們認為每個子領域均與其他子領域存在面向個性化體驗的統籌優化空間，僅僅由于復雜的鏈路從而導致不能直接進行整體建模，但每個子領域仍需對其他環節進行深度理解和配合，逼近整體建模的效果，概念性的劃分圖如下：

圖2-3 個性化音視頻技術的概念性架構圖

在上圖所示的架構中，我們認為下發、調度、傳輸、下載與播放相關的策略應當統籌看待，因此把這一子領域命名為Personalized Streaming & Playback，對轉碼相關的決策領域命名為User-Item Aware Encoding，同時把投稿相關的編碼和傳輸策略命名為Foresight Based Publishing。

個性化從技術角度則是策略化，策略優化在個性化目標下通常包含以下角度：

• User：對不同用戶提供的策略方法不同，此處還可細分為投稿者、消費者、甚至投稿者 x 消費者等維度。
• Item：對每個Item（在短視頻應用中的視頻——其他消費體裁如圖文等類同）做差異化的處理，進而在User x Item維度上提供不同效果。
• Context：即用戶消費的場景、個人狀態、外部環境等，在User x Context、Item x Context（較少）或者User x Item x Context維度上形成差異化。

對不同決策干預點而言（上圖中每個子領域內都至少有數個乃至數十個不同的干預點，后文章節中將擇要介紹部分干預位置），其優化水平可以按粒度劃分為以下層次：

• Rule-based level：根據簡單、明確、有限的規則，對部分User、部分Item或部分Context情形下采用不同策略。
• Portrait based level：對不同的User、Item，可能會篩選出同質的群組，對不同群組采用不同的策略，畫像可以通過數據分析、挖掘，或者模型篩選的方式生成。
•  Individual level：對單一的UserItem、Context下采用不同的策略，通常需要使用機器學習、深度模型等技術。
• 其中不同層次之間可能存在交錯，例如，畫像不僅可以單獨使用，仍然可以作為Individual處理的特征輸入。
• 以上體系可由基礎數據、規則、特征、畫像、模型（或特定算法模塊）等內容組合構建，并且在服務端、客戶端均具備相應能力，用以支持各個策略模塊的統籌決策。
  
  
  
  
  
  圖2-4 支持個性化音視頻技術的方式

在上述系統的設立與構建的基礎上，可以按照優化問題的一般工作思路對整個視頻播放工作進行拆解和拓展，我們根據工作便捷性可以定義了以下維度，后文將盡力從這些視角介紹：優化目標（Object）;干預選項/動作（Treatment/Action）;信號/狀態（Feature/State）;優化方法（Method）

個性化流媒體&播放技術

在推薦算法或者用戶選擇決定了播放內容（Item List）的前提下，整個流媒體播放服務可視為主要包含Delivery，Scheduling，Streaming & Playback三個環節，根據視頻Item當時所具有的檔位（Ladder）基礎上，對調度、傳輸和播放的相關邏輯進行個性化、算法化優化，能夠有效提升播放體驗、降低成本，最終提升整體業務收益。

• 按需下發（On-Demand Delivery）
• CDN調度（Personality Quality Scheduling）
• 流媒體播放（Personalized Streaming & Playback）
  
  
  
  圖3-1 個性化流媒體播放模塊示意圖

上述播放服務的優化目標可用下式所示：

1. 個性化流媒體 & 播放

問題

根據短視頻應用的特點，信息流播放占據絕大多數的用戶時長。在信息流播放過程中，一次信息流請求會獲取一個排序過的Item List，供用戶順序觀看（用<user，item>表示一次播放），播放器理應依據對觀看行為的預判，提前下載每個視頻最可能被看到的片段，并提前準備播放相關組件，以保障列表中的各個視頻的啟播速度、流暢度、畫質等效果，即，優化目標不再是單次播放的效果，而是用戶在整個播放序列中的綜合體驗。

方案

思路

動作空間

狀態空間

狀態空間中的狀態即是策略所需的特征信號，更大的狀態空間通常意味著更高的優化上限。為了實現個性化的目標建模與策略優化，在狀態空間的構建時應當系統化考慮Rule-based、Portrait based、Individual等不同層次的狀態，從User、Item、Context等角度構建。

基礎的特征建設只需滿足相關性即可，除卻原始數據外，也應當針對QoP各指標的維度建設能夠充分識別性能狀態的實時特征，以及對未來表現建設預測類特征。

畫像建設可以通過目標驅動，即根據期望優化的QoP指標構建對應畫像，例如流暢度敏感畫像、畫質敏感畫像、流量敏感畫像、存儲敏感畫像等等，也可以利用業務先驗信息，對用戶的投稿或消費的類別、層次建設對應畫像，更進一步說，任何User、Item、Context維度能予以劃分，并與QoP具備指標變動相關性的數據屬性均可使用。

以畫質敏感畫像為例給出一種做法，根據線上用戶的播放結果，收集用戶基礎信息、性能特征、分檔位的播放數據、歷史行為特征等，使用Uplift模型預測Treatment和播放時長的分位數回歸，根據模型表現（uplift-value）將人群劃分成不同分組U_g。顯然，該畫像將對流暢性和畫質平衡相關的決策提供關鍵信息。

Individual層次特征的構建，通常需要通過數據計算或模型預測構建所需的分類、回歸值或概率分布。以用戶對某一視頻的播放時長這樣的特征來說，歷史上有一些工作對此進行了預測和使用，其或者基于用戶過去幾次播放的結果進行預判，或者使用某一視頻被所有用戶觀看的分布代替具體用戶的觀播時長分布。但這些做法并不適用于短視頻平臺，由于短視頻消費呈現幾何分布，生命周期十分短促，同時此類做法過于粗糙，沒有充分地考慮個性化。

一種簡化的可行做法可以是從片源時長、用戶、視頻維度各自建立播放時長的分布，并利用參數的加權擬合（參考下式），融合成一個綜合的時長分布。

優化示例

 在特定時間點決策對某一視頻下載某個檔位，即選檔問題，是在流媒體領域中的常見子問題，在短視頻的信息流播放場景下的相關問題是下載控制決策，對這兩項控制算法進行優化即可視為針對兩個（組）動作的決策。由于我們所意圖優化的動作空間、狀態空間范圍遠超以往，使用的工具也極為廣泛，此處僅以選檔和下載控制為示例進行介紹。

在我們的工作中，對檔位選擇和下載控制的處理，遵循前面提及的思路，有以下不同：

1.優化不僅考慮某一個視頻的播放，而是統籌整個列表的播放體驗。考慮的性能維度拓展為完備的指標組，直接通過QoP指向Profit，同時對與此任務最相關的QoP指標建立下級指標，即拆解為多維度來表征，例如對Rebuffer亦拆解首幀卡頓、播放前中后期卡頓、緩沖區卡頓等。

2.控制的動作更為精細，例如選檔即需要區分不同選擇時機和目標（比如發現），下載不僅需要選擇“下什么”、“下多少”，同時也需要選擇“從哪兒下”、“怎么下”、“下載后的處理方式”。在此基礎上，對不同干預點進行聯合決策，除了選檔與下載動作的聯合決策外，也包含二者與其他動作如解碼、后處理增強等的聯合決策，以最大化QoP效果。若將根據輸入特征決定控制動作的具體算法，例如模型或者決策樹，稱之為決策函數Decider，這里所述的聯合決策存在幾種情況：

a.對某一控制動作的決策，其他時間線上在前的干預點，其決策結果可作為特征輸入至決策函數內，對時間線在后的干預點，亦可進行預測式決策。

b.對某一決策時機，若同時存在多個動作需要決策，可以建立聯合決策函數，輸出最優解。

c.不論決策時機是否相同，決策函數本身均可在聯合空間內，離線地搜索（訓練），得到最優（更優）方法。

3.依據一般的特征重要性判別方法進行篩選，除了常見的網絡狀態、緩沖區狀態等，加入大量個性化特征，對選檔和下載有重要意義的特征包括（但不限于）以下內容：

a.用戶對視頻的播放時長預測、...

b.用戶、視頻各自的首幀敏感畫像、畫質敏感畫像、畫質切換敏感畫像、卡頓敏感畫像、功耗敏感畫像、流量敏感畫像、...

c.用戶當前的近實時畫質與卡頓情況、設備溫度、設備音量、屏幕亮度、CPU占用率、內存占用情況、流量消耗情況、...

4.最后，依據上述特征同步更新

圖3-2 流媒體播放算法優化過程

架構 

傳統上類似DirectShow、Gstreamer、FFMpeg等多媒體框架的設計理念在于模塊化各類組件，利用統一的接口，靈活構建有向無環圖式的pipeline，提升復用性和一致性，以支持廣泛的不同需求。

但在前文所定義的Personalized Streaming & Playback相關問題上，由于以極致提升用戶體驗為最優先目標，則與基于傳統多媒體框架的播放器相比出發點有所不同，我們由此設立了如下的播放器架構。

圖3-3 播放器架構示意圖

• 設立統籌決策的策略中心組件 策略中心組件負責提供對播放和下載的控制決策，包括實時的算法決策和后臺預計算等，主要目的在于策略算法化是長期、頻繁發生的事情，將各組件自行決策的部分（即前文Action Space段落中的A_top）遷入策略中心并進行統籌優化。
• 設立全局可見的配置和數據中心 配置和數據中心負責提供全局可見的配置訪問與數據訪問能力，即簡化了不同組件間的數據訪問過程，此處所談及的數據應包含各自模塊內部的運行狀態數據、中間計算結果等，此處可視為State空間的具象。
  
• 設立抽象的Framework 統一各組件的設計，使用同一套線程池、鎖、消息機制、數據結構、內存Buffer池等基礎能力，這部分與傳統多媒體框架類似。
  
• 提供面向性能指標的動態配置能力 傳統多媒體框架中的組件同樣會提供若干選項，以此帶來一定靈活度，例如Gstreamer的libde265dec組件僅提供最大線程數配置，我們認為這還遠為不足。由于不同用戶在不同場合下所需的“最優”性能表現各自不同，即，假設存在低內存高cpu占用的一種程序寫法，和另一種高內存占用低cpu消耗的程序寫法，可能應隨用戶設備的不同狀態進行選擇相應運行分支。更進一步，我們認為對所有組件，均應當提供面向主要二級性能指標的改進（與兌換）版本，或其局部過程的更精細配置選項，即對一個提供Demux能力的組件，應當存在高/中/低內存占用，高/中/低CPU使用版等，對于其中關鍵元素，其配置參數應當支持開放可調——意味著策略中心內算法可以動態對其調整。從優化視角看，此處可認為是在提升a_{（i，k）,j}與其所對應的QoP_{（i，k）,j}，擴大選擇空間。

Overall speaking，我們的設計以一定程度的程序復雜度增加，換取了更高的性能兌換的空間和策略統籌控制的空間，使用這種算法中心化的設計，可以提供給用戶更為個性化、更極致的流媒體下載與播放體驗。

2. 個性化質量調度

通常一家視頻平臺為內容分發和容災考慮會使用數個CDN供應商，作為短視頻平臺方，則需要考慮如何利用CDN廠商資源下發內容以提高播放體驗和節約帶寬成本。

傳統做法是基于流量的成本約束和負載均衡情況做隨機分配，更進一步的是結合資源質量進行動態調度。但該方式沒有考慮到實際用戶特性，例如不同用戶在觀看視頻過程中對當前網絡質量的需求差異，以及視頻特性(如熱度）。

我們的做法大致包括，基于用戶所處的播放狀態、對的偏好，對每個用戶每次網絡請求進行優先級定義，在成本約束下為其匹配最佳的網絡資源進行個性化質量調度，整體圖景如3-4所示。

圖3-4 個性化調度示意圖

優化目標:

優化思路和動作：

CDN質量調度需要解決的主要難題是在動態網絡下，預測資源的服務質量，同時在滿足成本約束下，結合用戶需求做最優分配。成本約束主要限制了不同資源的服務帶寬比例，此外還有邊際質量下降、單廠商容量天花板等問題。另外，不同用戶在不同視頻消費階段對網絡質量的需求不同。

具體而言在CDN質量調度問題上，主要需解決兩個問題：

1. 1. 對于不同網絡下載請求，如何定義其對網絡質量的需求度（例如速度、延遲、丟包）。
2. 2. 對于一次網絡下載請求，如何評價、預測網絡資源的質量（不同廠商、節點的預期服務質量），決策分配結果。

p,b存在關聯，與實際商務談判有關，例如，提高某廠商的服務量級可能會得到價格優惠。

除了直接為用戶提供下載產生的邊緣帶寬，CDN帶寬的另一部分成本來自于回源帶寬，短視頻應用每天需處理億級別的新視頻發布，同時邊緣網絡節點存儲有限，因此邊緣網絡的視頻文件緩存命中率遠不如長視頻平臺。通常網絡供應商的文件存儲是基于過去視頻文件的訪問量完成的，但在短視頻平臺隨機/質量調度策略下，同一個視頻文件會被分配給不同的廠商，這會導致單廠商視角下部署的文件無法得到充分利用，造成邊緣緩存命中率下降。

由于冷文件的邊緣命中率更差，簡化起見，會希望利用視頻文件的熱度變化信息做針對性的冷熱調度，即冷文件集中調度到有限的廠商、節點，從而提高邊緣緩存命中率。需說明的是，冷熱調度和質量調度存在沖突，因此一種可能的劃分是，只對冷文件做定向調度，熱文件做個性質量調度。

視頻請求的回源帶寬可以表示為

如上文提及的質量調度或者業界的成本調度，都會將視頻文件請求隨機/均勻的請求到廠商/節點上，這會降低廠商視角下視頻文件的熱度，從而命中率進一步下降，通過調度提高視頻文件的邊緣命中率，從而對回源帶寬優化，思路是將視頻文件只定向分發給單一或有限個廠商、節點。但如果對所有視頻都做定向調度，那么很有可能造成廠商/節點的負載突然過大，因此應主要針對冷文件做定向調度。合理的方案是將視頻文件熱度作為文件價值進行預測，基于預測結果劃分文件冷熱，例如選擇出top N%的冷文件做定向調度，或者使用一致性hash算法。

CDN廠商部署文件的通常做法是基于過去短時間的文件訪問量進行緩存（例如LRU策略），前人曾嘗試從流量分配角度將更多請求分配到有緩存的CDN節點上，或者通過歷史流行度分析視頻請求后的部署策略。為提高邊緣請求命中率，一種可行的思路是通過預測視頻流行度，決策是否需要在邊緣節點提前進行文件緩存部署。

以月95峰計費方式舉例，假如全天的帶寬波形變化存在峰谷，我們可以利用低谷閑置的帶寬資源來做視頻文件的提前部署，從而提高未來尤其是晚高峰的CDN邊緣命中率。

合理的方案包括：

1. 實現視頻檔位價值計算，并進一步拆分區域運營商進行預測（節點服務通常不會跨運營商、跨區域，會帶來一定質量損失和成本上升）。
2. 為了避免熱文件的集中部署帶來節點負載過高，使用知識圖譜技術對文件進行相似度刻畫，將需要預熱的視頻文件按照整體文件相似度最大的原則進行部署。

對于CDN供應商，峰值計費的方式通常比流量計費方式更劃算。在多CDN峰值計費的情況下，成本是各廠商的95峰之和。因此對于視頻平臺，存在動力通過分配用戶下載請求，控制各家CDN帶寬波形做進一步的成本優化。即在總帶寬T給定情況下，降低各家廠商的計費值，定義帶寬調度復用率（Scheduling Reuse Rate）如下

對于時段的篩選，根據計費方式，預測月粒度帶寬95峰內的時間區間，詳見下文Context服務部分，作為每天堆高的時間段。堆高的方式可以有如下三種，考慮到實現復雜度同時盡量減少廠商節點的單天帶寬抖動，考慮使用隔天錯峰的方式。

圖3-5 CDN錯峰堆高方法示意圖

3. 按需下發

 下發服務

將視頻的更多可用檔位下發到客戶端，有助于提升客戶端策略的決策空間，但同時下發/傳輸/數據解析本身具有開銷，如果下發對客戶端無用的檔位文件給客戶端，對整個系統性能會有負向的影響。所以問題在于，如何在下發側選擇最優的“可能組合”給客戶端，平衡服務端、客戶端決策的差異，同時考慮下發動作本身的代價。

方案 可以設立該問題的形式化公式如下：

其中，

在實際優化中，由于一般不會很大，例如<100，所以在適當剪枝后遍歷是相對容易的。主要的工作在于在狀態下對、以及的估計。

 Context服務

Context Service主要是針對某一性能相關的全局指標，給出未來趨勢的預測，例如，預測未來5分鐘的帶寬，以及帶寬在全天帶寬中的分位值，其他指標可以有全局視頻播放量、網速分布變化等，服務的輸出主要作為其他算法的輸入，即給出相應的時序預測結果，可以：

• 用于影響前文調度和下發工作的結果，例如在下發前根據預測結果進行下發內容的重排或過濾。
• 將預測結果嵌入下發內容，供客戶端進行算法決策。
• 將預測結果傳輸至服務端模型使用（例如UIAE的各算法環節）。

用戶-內容感知編碼

1. 問題背景與解決框架

圖4-1 基于用戶-內容感知的編碼（UIAE）

即在某一時刻，用戶觀看視頻時，轉碼策略應當感知當前時刻每個用戶所處的Context，并結合用戶個性化特征，計算出來最適合每個用戶的檔位并實時轉出。但由于轉碼成本高、轉出延遲長、搜索空間廣等原因，實踐中直接按此邏輯設計并不可行。

為了應對上述挑戰，可考慮做如下近似：

1. 聚焦熱門視頻：分析發現短視頻應用往往Top 1%的視頻占到70%+的播放量，同時尾部視頻生命周期短，轉碼ROI低，基于熱門視頻，可以將視頻處理量從數十億級別壓縮到千萬級別。
2. 提前轉碼：可以首先預估視頻未來一段時間的消費用戶分布U_g。基于U_g，計算該視頻最合適的檔位組L。為應對視頻消費分布快速變化，需持續更新最優檔位組L，以適應用戶的最新播放需求。
3. 基于轉碼資源Quota限制和吞吐限制，轉碼隊列采用Weighted-batch模式。

基于以上近似，更新優化公式：

圖4-2 UIAE技術詳細框架

下文中我們將首先介紹Video Value Prediction，構建視頻價值模型以預估視頻的未來價值，該模型不僅用在UIAE上，在其他場景也有貢獻；其次將詳細介紹UIAE算法，即如何從個性化角度計算檔位組合；再次介紹如何統籌轉碼資源，從全局視角最大化Reward，最后介紹相關的實驗能力。

2. 視頻價值預測

 問題

價值預測的建模方法主流可分為兩種，一種是基于時序預測其預測目標，更適合有一定周期性的領域場景， 另外一種是使用DNN等深度網絡直接回歸建模，通用性更強。

在短視頻轉碼場景，視頻價值判斷所面臨挑戰主要在于：

• 長尾效應嚴重。高熱視頻占比極低，但同時占據了絕大多數播放量，這就導致在回歸建模中，容易被高價值視頻帶偏，需要謹慎設計目標函數。

• 短視頻生命周期短同時消費趨勢呈現多樣性。絕大多數的視頻生命周期都很短，不同內容的視頻消費隨時間分布也呈現很大差異。這就需要我們要獲取更多特征。

 方案

為了增加視頻價值模型的通用性，建模目標包括但不限于未來多個時間段的播放量、播放時長、點贊量、下載量等，我們統一用表示預測目標，y表示真值。

• 視頻價值建模使用到的特征：

作者側特征組：作者ID、活躍度、發文量、粉絲量、觀看量等。

視頻側特征組：音樂ID、內容、時長，當前播放量，點贊量，播放增速、原創度、投放設置等。

Context特征：時間、節假日等。

可選的Loss設計如MSE和Huber Loss以及Weighted log loss等常見的loss函數。模型結構：這里給出線上使用過的一種視頻價值模型結構，DNN + LHUC + BIAS，如圖4-3所示：

圖4-3 視頻價值預估價值模型

評估指標：如Regression-AUC和MAE等。

下文給出了此種設計與Rule-based的Topvv策略（依據當前播放量）和大v策略（依據作者粉絲數）的對比效果：

表 4-1 效果評估

3. 用戶-內容感知編碼

若認可用戶會因為客觀因素（如機型性能，網速）和主觀傾向不同而對播放的檔位存在差異化需求，如4-4所示。

圖4-4 用戶觀看視頻的不同檔位

那么對某一個具體的視頻，針對消費群體，應當轉碼為哪些版本才是最優？這個是User-Item Aware Encoding（UIAE）需要去解決的問題。

不同于推薦可以得到較為精準的反饋信號，播放場景下很難精準得到關于一個視頻的最優檔位組的反饋。因此一種可行的做法是類似于梯度上升的迭代思路，在視頻的整個消費周期內設定消費窗口，在每個窗口下都計算未來最合適的檔位組，以此不斷地迭代檔位組, 確保其不斷逼近理想值。

圖4-5 檔位組收益曲線示意圖

基于此思路，我們給出一種技術方案如下圖所示：

圖4-6 User-Item Aware Encoding整體方案

建模算法思路如下：在轉碼側，通常重在關注流暢體驗和畫質體驗，即：

所控制的編碼選項包括但不限于以下維度，對不同視頻的相關性能（畫質、碼率、編碼速度）表現可預計算（預測）出（即CAE編碼的常用工作方式）并供UIAE和Resource Allocation Model決策使用：

表 4-2 編碼控制參數

4. 資源分配模型

當一個視頻通過UIAE決策得到檔位組，即可進行轉碼并消費，但從全局角度看，轉碼調度并非一個簡單All-in操作。

• 轉碼資源的有限性：不可能同時滿足所有視頻的轉碼請求，且不同的短視頻的轉碼成本差異巨大。
• 轉碼資源的異構性：不只有x86 CPU，還有Arm CPU、FPGA、GPU、定制編碼芯片等硬件，各自具備不同的轉碼效率和轉碼成本。
• 轉碼資源的延伸影響：對應不同轉碼產物的CDN帶寬影響與存儲成本影響。

對于轉碼調度，全局優化目標可以設置為：

仔細觀察優化目標，是帶有約束條件的最優化問題（背包問題），但直接求解會遇到如下問題：

仔細觀察優化目標，是帶有約束條件的最優化問題（背包問題），但直接求解會遇到如下問題：

• 精準量化可用轉碼資源非常困難，轉碼資源機房之間調度、負載均衡、buffer策略都會有影響可用資源計算。
• 熱門視頻也有千萬級別，求解最優化問題復雜度過高。

因此可采用近似流式處理方式，每此處理一個小批次，并重新定義可用資源。

圖4-7 轉碼流程示意圖

5. 實驗方法

與常見的AB實驗不同，在視頻類實驗中需要進行諸多額外實驗能力的設計以支持前述算法的迭代工作。首先，由于資源約束，通常轉碼類實驗需要針對部分視頻進行，僅影響一小部分視頻，因此需要設計策略標簽能力，對用戶層AB實驗與視頻策略間建立映射關系，示例如下圖：

圖4-8 視頻策略AB實驗示意圖

一些基礎的需求如下：

1. 1. 對不同轉碼產物標記其策略。
2. 2. 對不同轉碼產物能根據轉出時機，對齊用戶組進行過濾。
3. 3. 支持區分轉碼時機的策略。
4. 4. 對不同請求可以根據AB實驗用戶分組返回不同轉碼標簽的內容。
5. 5. 支持轉碼資源池的動態劃分以保證實驗公平性。

其次，應當支持摒除推薦內容影響的實驗方式，并在實驗過程中盡量區分出對不同用戶的影響，借鑒搜索場景常見的interleaving實驗方式在經常會提到，把要對比的兩個排序結果混插到一起，發給同一個用戶，在某些場景下將能帶來較好的評估作用：

圖4-9 AB Testing與interleaving示意圖

上圖是Interleaving實驗的大致流程，最終返回給用戶的是merge之后的結果，即同一個用戶在一次feed中既看到了實驗組的結果，也看到了對照組的結果。對于一次feed請求，有兩種方式進行點播策略interleaving：

1. 1. balanced_assign：純均勻分配，思路就是先選一個策略交給第一個視頻，之后的視頻交替使用AB策略。
2. 2. team_draft_assign：每個視頻選擇必從A或B中抽出一個策略，且每次選取都會隨機進行A優先或者B優先。由于觀看視頻被隨機地播放，可近似認為這是同一用戶對兩種不同轉碼策略的觀看效果比較。

最后，上述做法在評估某種轉碼策略的效果時，會對某一個源文件的不同對比策略各自轉碼，隨后比較實驗組和對照組的業務效果，所需資源較大、實驗周期較長。此處介紹一種新的實驗方法，稱之為“Quasi Experimental”，能夠在節約轉碼資源的情況下，快速準確的評估轉碼策略的價值。

該方案主要是基于現有觀測數據人為構造實驗組、對照組以及相應的播放行為，業務指標/性能指標。以轉碼策略評估為例，具體方案如下：

• 用戶維度：實驗組和對照組用戶盡可能隨機分布。
• 視頻維度：選取待轉碼視頻，隨機分為兩個子集A和B，對兩個video集合進行調整，使其滿足關鍵維度分布一致，例如當日播放時長、觀看視頻品類、視頻消費分辨率等。
• 調整觀看記錄：對當日的播放記錄進行調整，刪除實驗組中用戶對集合A中視頻的觀看記錄，刪除對照組中用戶對集合B中視頻的觀看記錄，以保證了對照組用戶的觀看視頻都來源于轉碼策略A（線上策略），實驗組用戶存在部分觀看視頻來源于轉碼策略B（待評估策略）。
  
  圖4-10 準實驗方案

基于預見的投稿發布

1. 問題背景與解決框架

由于一般的投稿的選取與剪輯過程過于私人化，此處假設用戶已經完成視頻的編輯，重點介紹一些較為通用的決策問題，依據合成編碼、上傳和優先級設置劃分成三部分，參考圖5-1：

圖5-1 投稿體驗優化過程

由于投稿視頻的編碼質量會影響轉碼后的產物，進而影響播放消費，因此投稿優化時應當對端到端進行統籌考量，即除提升投稿場景的業務價值外，也考慮投稿體驗帶來的消費價值。整體的優化目標參考下式：

同時，投稿場景也存在多種優化影響路徑，試分析幾例如下：

同時，投稿場景也存在多種優化影響路徑，試分析幾例如下：

2. 基于預見的合成

當用戶創作完畢后，需要對素材進行合成編碼，傳統做法是根據預配置的合成編碼參數對素材、濾鏡、特效等進行編碼等處理。但預配置的合成編碼參數是一種平權參數，忽視了每個用戶對視頻編碼結果預期，同時用戶所處的環境會改變用戶預期，如使用不同機型、在不同網速條件下也有不同，基于此思考，我們充分挖掘用戶和視頻特征，采用個性化的技術方案對編碼方式以及編碼參數做智能預測。

在合成階段，主要基于路徑1和2以最大化收益，一種可行的思路是將過程拆解為我們稱之為Smart Encoding Model和Dynamic Encoding Parameter兩個模塊，逐次優化，每個模塊可以互不干擾，Smart Encoding Model需要解決的問題是選擇編碼模式，Dynamic Encoding Parameter需要解決的問題是在已經決定了編碼模式的情況下選擇具體的編碼參數，此處由于兩個子問題優化目標一致，也可以嘗試聯合決策。

智能編碼模型

圖5-2展示了該編碼模式選擇的思路：

5-2 智能編碼決策

動態編碼參數選擇

5-3 動態編碼參數決策

3. 精細化上傳發布

在對文件進行上傳的過程中，同樣存在若干可以決策的環節，例如從所有可用上傳節點中選擇較高質量的節點，開啟分片上傳（Chunked Mode）或者流式上傳等，分片上傳是一種常見手段，即將文件切分成不同大小，分別進行上傳，流式上傳把整個文件劃分較小的Range持續發送。常見的上傳過程如圖5-4所示：

圖5-4 發布上傳過程簡要

分片上傳的主要影響因素在于，過小的分片會導致整體建連耗時增加，但分片失敗率降低，過大的分片則相反，同時分片大小往往不易及時調整，此外，由于分片上傳通常利用普通的文件上傳協議，對上傳節點友好，易于使用并行、多節點上傳等更復雜的技術。流式上傳通過斷點續傳機制減少重試，同時減少分片之間等待Ack和Response時間，從而降低文件的上傳時長，相當于等于1的分片上傳，優點是傳輸過程控制靈活，缺點是容錯實現稍為復雜，且不易并行。不同的方法各有其優缺點，因此需要個性化決策（圖中的Upload Decider）的內容包括：

1. 選擇流式還是分片上傳模式
2. 假設選取了分片上傳模式，則需要進一步決策分片大小和并行數、上傳節點等 在本問題上，包括CDN節點的網絡列表、各個網絡節點的上傳失敗率在內的先驗知識能夠較大地影響決策效果。

圖5-5 基于個性化的動態上傳參數決策流程

明顯可見，如果用戶在發布前猶豫過久，甚至可以達成點擊即發布成功的效果，但這一方法也存在明顯代價，用戶可能取消發布動作或回退修改，導致浪費，因此還需要對同一用戶的多次投稿行為進行估計，以使相應節約帶來的收益大于某次預判錯誤帶來的損失。

4. 自適應優先級

當端上用戶點擊發布視頻之后，往往會切到其他頁面繼續瀏覽視頻，甚至切換到其他app使用，這樣會導致系統上傳進程優先級降低甚至被殺死，進而引發上傳失敗。簡單的做法是強制提高上傳進程優先級（比如將進程從后臺切換到前臺），但這種方法雖然能提升發布成功率，卻可能劣化其他體驗（如消費側卡頓，系統功耗上升等），引發用戶不滿，因此，如何更合理的分配進程優先級成為一個可以進行個性化決策的問題。如圖5-6所示：

圖5-6 上傳優先級決策示例

例如，當應用執行視頻上傳動作時，用戶將app切換到后臺，則我們可能應當將后臺上傳進程轉至前臺進程（提高優先級），確保上傳的成功率，提升用戶體驗。但當用戶正在其他頁面行動時，則不應提升上傳優先級，甚至應當暫停合成或傳輸，為用戶其他出讓CPU、內存或網絡帶寬資源，雖然投稿本身的失敗率可能增加，但用戶更即時的興趣得到較好滿足，整體體驗是提升的。

效果與結論

1. 效果評估

在過去數年的工作中，以上體系的工作與傳統音視頻優化工作相比較，額外收益幅度如下（即不計入如編碼器升級、傳輸協議優化、工程改造等常規音視頻工作內容），也即該體系帶來的增量優勢：

表6-1 各個方向收益概覽

競爭視角看，字節跳動自2019年以來，在不同市場均已逐步成為Tier 1的短視頻服務提供商，側面印證了上述技術的成功。

2. 結論

在本文中，我們介紹了字節跳動自2019-2023年間短視頻服務的部分工作及其成果，系統性地闡釋、構建了個性化播放這一前沿、交叉的技術域，明確地定義了該領域中的一系列子問題，并給出了部分問題的實際解法。在這一新技術領域中，我們認為應當：

• 建立完整的技術工作流程，重點在于使用AB實驗等精確評估技術，保證每個技術項目均帶來業務指標提升。
• 運用個性化技術范式進行決策優化，包括：

拓展常規的指標為更全面的性能指標組。

從建模上直接面向業務收益指標，并構建個性化的中間指標。

拓展使用全面而非簡化的User、Item、Context特征。

使用與推薦、計算廣告等領域前沿對齊的深度神經網絡、強化學習、因果推斷、運籌學等技術，用于決策方法本身或用于特征、畫像建設。

• 以個性化決策為核心，重新評估、規劃音視頻領域的各項工作：

• 重新設計多媒體框架、播放器方案和服務系統，承載復雜的決策控制能力，并拓展決策點。

• 重新設計編解碼和前后處理組件、視頻質量評估方法，拓展個性化調整能力。

• 重新設計網絡傳輸方法、CDN功能，乃至商務談判策略，拓展個性化調整能力。

本文雖以短視頻播放相關技術為例，但其思想也完全適用直播等其他音視頻領域的工作，例如，與點播相比較，直播在技術指標上將關注額外的實時性要求，在技術重點上關注拓撲，在此之上同樣應當將系統整體抽象為面向業務目標的優化問題，以個性化決策驅動各環節工作的演進。又例如，本文主要討論的優化范圍集中在應用內部，但各種相關、衍生的問題也完全適用同樣的方法進行改造。

音視頻技術領域的廣泛開展若自微軟的DirectShow技術發表計，已接近30年，服務數十億用戶，基于編碼與視頻處理技術、傳輸協議、工程框架、云服務等環節展開的工作雖然不斷演進，提升難度卻與日俱增，邊際價值逐年減少，但這并非說明該領域已然日薄西山，由我們開拓的個性化視頻技術體系，改變了該領域的邊界與工作重心，其可以更具想象力地容納多種傳統音視頻技術以外的技術發展與其交叉（包括流行的LLM/AIGC技術），可以拓展出新的、廣闊至近乎無限的提升上限，讓世界上數十億用戶都能更好地享受音視頻技術帶來的生活提升。