火山引擎 RTC 影片效能降級策略解析

　　 1. 背景

　　隨著 RTC 使用場景的不斷複雜化，新特性不斷增多，同時使用者對清晰度提升的訴求也越來越強烈，這些都對客戶端機器效能提出了越來越高的要求 (越來越高的解析度，越來越複雜的編碼器等)。但機器效能差異千差萬別，同時使用者的操作也不可預知，高階特性的使用和機器效能的矛盾客觀存在。當使用者機器負載過高時，我們需要適當降級影片特性來減輕系統複雜性，確保重要功能正常使用，提升使用者體驗。

　　影片效能降級能做什麼？

　　一是解決因裝置效能不足、突發的效能消耗衝擊（如防毒軟體）帶來的使用者音影片體驗問題（如影片卡頓、延時高、裝置卡死）等問題；

　　二是提升一些高階功能的滲透率，例如預設情況下開啟影片超分，裝置效能不足的情況下主動關閉；

　　三是降低部分場景的裝置功耗，例如當電腦使用電池供電的時候，透過關閉影片超分、降低影片幀率等方式主動降低一些功耗。

　　 2. 前置基礎

　　RTC 提供了一種效能降級機制，在效能負載過高時，觸發降級；在效能負載降低後，觸發升級。一套完整的效能降級方案，需要產品具備一些基本的降級能力，比如：支援動態修改影片解析度、幀率，支援釋出多路影片流(simulcast)，支援 SVC，支援按需釋出/訂閱等。

　　2.1 Simulcast

　　關鍵詞：同樣的影片源，多種解析度，差異化的解析度需求

　　所謂 Simulcast，就是將一個影片源輸入編碼輸出成多個解析度的影片幀，在傳送端編碼多路不同解析度的大小流，下行接收端可以選擇訂閱其中任意一種解析度的同源影片流。它可以滿足多人通話場景，不同使用者對於解析度的差異化需求。在實際應用中，Simulcast 變得更加靈活多變，發揮的作用也越來越大。除了滿足使用者差異化的解析度需求外，還可以有效解決下行弱網/效能問題，提升使用者體驗。比如在下行使用者網路交較差或者效能較差時，可以給使用者轉發低解析度的影片，確保使用者可以擁有流暢的觀看體驗。　　

　　2.2 SVC

　　關鍵詞：單路流，分層編碼

　　SVC（Scalable Video Coding, 可適應影片編碼）是指，一條影片碼流可以分成多個層級(layer) ， 在保證整條流的可解碼性的情況下，使用者可以根據層級的優先順序選擇丟棄某些層級的全部或部分片段，得到不同幀率（temporal / 時域）/解析度（spatial / 空域）/ 畫質（quality / 質量）的影片流。　　

　　2.3 按需釋出

　　按需釋出簡單來說，就是讓釋出端知道哪些解析度的流有人訂閱，哪些解析度的流沒人訂閱，然後僅釋出那些有人訂閱的影片流。使用者沒有訂閱的流，即使效能或者頻寬再好，也不會傳送。通常情況下，按需釋出端需要配合 Simulcast 使用，但也不是必要條件。按需釋出的初衷，是為了節省效能和頻寬資源，減少不必要的資源浪費。　　

　　按需釋出

　　 3. 常見的影片效能降級手段

　　RTC 對於 CPU 和 GPU 的消耗通常較高，並且 RTC 對於實時性有近乎苛刻的要求 (通常 RTC 通話要求在 400ms 以內，雲遊戲場景甚至要求 100ms 以內)，這對演算法處理速度以及平穩性有很高的要求。單幀處理耗時的長短，意味著影片幀率的上限，而處理耗時的平穩性，也會影響影片流暢性的整體感受（因為實時性的要求，RTC 通常不會設定過大的 jitter buffer 來平滑抖動，當幀處理耗時抖動較大時，會在觀看端感受到類似影片掉幀一樣的卡頓現象）。除此之外，過高的系統消耗，甚至會影響到使用者對裝置的正常使用（比如：過度發燙/操作延時卡頓等）。

　　在視訊通話過程中，有一些引數是可動態調節的。往往不同的影片引數對應著不同的效能消耗。常見的調節引數有影片解析度、影片幀率，除此之外，還可以調節影片處理特性(比如：超分 / 降噪 / HDR 等)，甚至還可以切換不同編碼器及檔位，對於 Simulcast 還可以選擇切流 (Fallback)。

　　3.1 影片解析度降級

　　降級影片解析度是指降低影片的傳送解析度。通常來說，RTC 主要是指編碼解析度。對於一些特殊場景，降低影片解析度還包括了支援編碼解析度的回撥，採集模組收到回撥的解析度後，會主動降低採集模組輸出解析度（但通常不會直接降低 camera 採集解析度，因為調整採集引數會涉及到攝像頭重啟，切換過程會出現黑幀，重啟攝像頭也會增加出錯機率）。這種場景特效解析度也會隨之降低，收益最大化。

　　3.2 影片幀率降級

　　降級影片幀率是指降低影片的傳送幀率。通常來說，RTC 主要是指編碼幀率。降級幀率是最不容易出錯，並且收益可觀的一種降級手段。對於一些特殊場景，還支援編碼幀率回撥，採集模組收到回撥之後，會主動降低採集模組輸出幀率。

　　3.3 編碼器降級

　　降級編碼器指，降級編碼器檔位，或者切換到效能更好的編碼器。通常，編碼壓縮率越高的編碼器，編碼效能消耗越高。因此，當系統負載較高時，可以切換到壓縮率相對低的編碼器或者編碼檔位，降低效能消耗。

　　3.4 影片處理特性降級

　　在各業務場景下，會有一些影片前後處理特性，主要目的是為了提升畫質，比如：超分 / 降噪 / HDR 等。在效能足夠好，並且負載不高的情況下，可以開啟這些影片處理特性，提升使用者體驗。當系統效能瓶頸時，需要適當降級影片處理特性，甚至是關閉特性來確保正常的視訊通話。

　　RTC 影片效能降級方式及優缺點總結：　　

　　RTC 影片效能降級方式及優缺點總結

　　 4. 火山引擎 RTC 效能降級策略

　　4.1 效能降級策略概覽

　　火山引擎 RTC 降級策略包括了多種基礎能力和策略：　　

　　火山引擎 RTC 影片效能動態降級策略概覽

　　下面具體介紹幾種降級策略以及策略中的注意點。

　　4.2 RTC 編碼組織方式

　　火山引擎 RTC Simulcast Encoder 之間採用完全並行的編碼方案，每條 Simulcast 流處在不同的 Pipeline 上，執行緒之間相互不影響。相比 WebRTC Simulcast Encoder 之間序列的編碼方案，並行編碼方案效率更高， 並且編碼效率基本不受 Simulcast 流數的影響。

　　對於效能降級來說，並行編碼組織方式，可以選擇對單條流進行降級，也可以選擇同時對所有流進行降級，降級方式變得更加靈活。　　

　　4.3 RTC Simulcast 流降級方案

　　因為火山引擎 RTC 編碼器採用並行方案，單路 Simulcast 流的編碼延時高，降級可以選擇同時降級所有流的幀率，也可以選擇只降級編碼延時較高流的幀率，而不影響其他 Simulcast 流。　　

　　火山引擎 RTC 除了降級單條流之外，還支援 Simulcast 流之間聯動。效能不足時，支援關閉高解析度的流（Fallback），效能恢復時，可以重新開啟高解析度的流。當發生 Fallback 時，訂閱高解析度的使用者會自動切換為訂閱次高解析度的流，效能恢復時，會重新切換回來。以下圖為例，如果 720p 流被關閉，訂閱 720p 的使用者將會收到最接近 720p 的解析度的流，所示為 360p。　　

　　火山引擎 RTC 降級偏向於 畫面的流暢度和畫質的均衡（升降級路線可後臺配置）。

　　4.4 不同釋出流之間的協同降級

　　在沒有流之間(比如：螢幕流/影片流)協同的情況下，會存在不同流之間 同升同降 的問題。為了更好的解決這類問題，也為了更好的處理不同流之間的優先順序問題，火山引擎 RTC 內部採用一個 效能集中調控中心，來處理不同流之間的優先順序問題。以會議場景舉例來說，我們通常會認為，螢幕共享的優先順序比影片流更高，在效能負載較高時，我們選擇優先把影片的消耗降低，把資源儘可能讓給螢幕流。只有在影片流降級之後，系統負載依舊較高，無法滿足效能要求時，才會降級螢幕流。　　

　　典型的降級路徑

　　典型的降級路徑是：先對影片流降級，再降級螢幕流；升級順序和降級順序正好相反。

　　4.5 效能和頻寬降級關係處理

　　效能和頻寬是 RTC 系統中最重要的兩種資源。隨著系統執行，兩者會處在不斷的變化中。同時有效能以及頻寬波動的情況下，可能會出現，效能負載過高，觸發降級，但同時頻寬回升，又會觸發升級。因此，需要有一種機制保證兩者之間出現“你升我降”的問題。火山引擎 RTC 把效能和頻寬控制兩者解耦開來，把效能的輸出作為一個最大限制條件。效能升級相當於是上調水位線，降級相當於下調水位線，實際效能/頻寬升降級由一個模組統一處理。

　　除了效能和頻寬之外，火山引擎 RTC 還支援按需釋出能力，釋出端結合三者採用如下方案進行綜合決策。　　

　　說明：因為效能原因，720p 流被關閉，訂閱 720p 的使用者將會收到最接近 720p 的解析度的流，所示為 360p。

　　4.6 訂閱端的效能降級

　　訂閱端效能在某些場景下可能會成為效能瓶頸，比如多人會議，或者高解析度解碼。這種情況下，如果不能有效處理，可能會導致卡頓/延時逐漸拉大等問題；

　　火山引擎 RTC 引入訂閱端效能降級方案，聯動上下行，當系統負載較高或者解碼器延時較長時，訂閱端支援動態效能降級。

　　1）訂閱端可以根據流的優先順序，優先選擇降級低優先順序的流，儘可能保證高優先順序流的影片體驗。

　　火山引擎 RTC 支援 API 方式設定訂閱流的優先順序。

　　2）就單條流來說，訂閱端也可以靈活的配置，是優先先降級解析度還是幀率（後臺配置）。　　

　　上圖展示了 Client 使用者同時訂閱 3 條 720p 30fps 的流，但是流的優先順序不同，Stream1 為高優先順序流，Stream2 / Stream3 為低優先順序流。當客戶出現效能問題時，會首先降級低優先順序的 Stream2 / Stream3。以上圖為例，Stream2 / Stream3 降級到了 180p 8fps。優先順序最高的 Stream1 沒有降級。直到低優先順序的流降無可降，才考慮降級高優先順序的流。

　　4.7 基於 CPU 使用率的降級

　　使用特性處理耗時（比如：編碼延時或者影片處理演算法耗時）的最主要的問題在於：

　　僅能監控當前特性自身的負載，如果鏈路其他消耗較高(並且不在監控範圍內)，導致整體負載過高時，依舊無法降級。

　　系統 CPU 使用率較高時，無法退避，導致裝置過燙，甚至使用者操作受到嚴重影響。

　　火山引擎 RTC 支援效能降級統一調控方案，可以進行上下行聯動，也可以對影片/螢幕的效能降級聯動等，甚至可以聯動音訊及網路。　　

　　火山引擎 RTC 以流維度拆分成幾個 降級單元，單元的排列情況，可以表示優先順序（優先順序可配置）。

　　enum RXPerfUnitType { kRXPerfUnitUnknown = 0, // 釋出影片流 kRXPerfVideoPubCamera = 1, // 釋出螢幕流 kRXPerfVideoPubScreen = 2, // 釋出投屏 kRXPerfVideoPubScreenCast = 3, // 訂閱影片 kRXPerfVideoSubCamera = 4, // 訂閱螢幕 kRXPerfVideoSubScreen = 5,};

　　NOTE: 一個降級單元表示一種流型別，一條流內部可能有多種降級手段，比如編碼和影片處理演算法等。

　 　5. 總結和展望

　　5.1 總結

　　我們在會議場景對上述影片效能降級策略進行了驗證。上線這些策略後，線上高負載時間比例持續最佳化，從整體 9‰ 左右最佳化到 5‰，使用者感受高負載情況（裝置發燙、介面響應慢、音影片卡頓、甚至程式崩潰或當機等問題）變少。

　　當前的影片效能降級策略也存在一些可以最佳化的地方，比如：

　　基於 CPU 的效能降級存在誤傷。類似編譯場景，在 CPU total usage 佔用較高，但 App usage 佔用很低的情況下，降級收益很小，但實際中這種場景可能會存在；針對這種場景，應該做區分，不是一味降級，退避是保障在一定的影片質量基礎。

　　降級最低影片質量配置可以更靈活。降級至最低檔位時，應該還要關聯實際的釋出訂閱情況來執行。比如，使用者在訂閱 1080p 的流，這時候降級到 180p 可能不是一個很合適的選擇；但如果使用者本身訂閱就是 360p 的流，這時候降級到 180p 可能是一個不錯的選擇。後續將進一步探索和最佳化，保證效能滿足要求的情況，質量損失最小。

　　支援基於 GPU 的效能降級。RTC 場景不光對於 CPU 的消耗大，對於 GPU 的消耗同樣也不小。後續基於 GPU 的效能降級也將上線。

　　5.2 展望

　　未來，火山引擎 RTC 還將支援更多降級策略，比如超分 / 降噪特性的效能降級、編碼器降級等；降級方案完整性進一步提升，比如根據使用者裝置來推薦影片引數；另外，利用火山引擎“資料驅動”優勢，量化效能資料，探索效能和頻寬深度融合方案。透過這些最佳化，更好地平衡高階特性的使用和機器效能的矛盾客觀存在，為使用者帶來更好的體驗。