一. 背景

隨著 RTC 使用場景的不斷復雜化，新特性不斷增多，同時用戶對清晰度提升的訴求也越來越強烈，這些都對客戶端機器性能提出了越來越高的要求 (越來越高的分辨率，越來越復雜的編碼器等)。但機器性能差異千差萬別，同時用戶的操作也不可預知，高級特性的使用和機器性能的矛盾客觀存在。

(資料圖片僅供參考)

視頻性能降級能做什么？

一是解決因設備性能不足、突發(fā)的性能消耗沖擊（如殺毒軟件）帶來的用戶音視頻體驗問題（如視頻卡頓、延時高、設備卡死）等問題；

二是提升一些高級功能的滲透率，例如默認情況下開啟視頻超分，設備性能不足的情況下主動關閉；

三是降低部分場景的設備功耗，例如當電腦使用電池供電的時候，通過關閉視頻超分、降低視頻幀率等方式主動降低一些功耗。

二. 前置基礎

RTC 提供了一種性能降級機制，在性能負載過高時，觸發(fā)降級；在性能負載降低后，觸發(fā)升級。一套完整的性能降級方案，需要產品具備一些基本的降級能力，比如：支持動態(tài)修改視頻分辨率、幀率，支持發(fā)布多路視頻流(simulcast)，支持 SVC，支持按需發(fā)布/訂閱等。

2.1 Simulcast

關鍵詞：同樣的視頻源，多種分辨率，差異化的分辨率需求

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

2.2 SVC

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

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

2.3 按需發(fā)布

按需發(fā)布簡單來說，就是讓發(fā)布端知道哪些分辨率的流有人訂閱，哪些分辨率的流沒人訂閱，然后僅發(fā)布那些有人訂閱的視頻流。用戶沒有訂閱的流，即使性能或者帶寬再好，也不會發(fā)送。通常情況下，按需發(fā)布端需要配合 Simulcast 使用，但也不是必要條件。按需發(fā)布的初衷，是為了節(jié)省性能和帶寬資源，減少不必要的資源浪費。

按需發(fā)布

三. 常見的視頻性能降級手段

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

在視頻通話過程中，有一些參數(shù)是可動態(tài)調節(jié)的。往往不同的視頻參數(shù)對應著不同的性能消耗。常見的調節(jié)參數(shù)有視頻分辨率、視頻幀率，除此之外，還可以調節(jié)視頻處理特性(比如：超分 / 降噪 / HDR 等)，甚至還可以切換不同編碼器及檔位，對于 Simulcast 還可以選擇切流 (Fallback)。

3.1 視頻分辨率降級

降級視頻分辨率是指降低視頻的發(fā)送分辨率。通常來說，RTC 主要是指編碼分辨率。對于一些特殊場景，降低視頻分辨率還包括了支持編碼分辨率的回調，采集模塊收到回調的分辨率后，會主動降低采集模塊輸出分辨率（但通常不會直接降低 camera 采集分辨率，因為調整采集參數(shù)會涉及到攝像頭重啟，切換過程會出現(xiàn)黑幀，重啟攝像頭也會增加出錯概率）。這種場景特效分辨率也會隨之降低，收益最大化。

3.2 視頻幀率降級

降級視頻幀率是指降低視頻的發(fā)送幀率。通常來說，RTC 主要是指編碼幀率。降級幀率是最不容易出錯，并且收益可觀的一種降級手段。對于一些特殊場景，還支持編碼幀率回調，采集模塊收到回調之后，會主動降低采集模塊輸出幀率。

3.3 編碼器降級

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

3.4 視頻處理特性降級

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

RTC視頻性能降級方式及優(yōu)缺點總結：

?

RTC 視頻性能降級方式及優(yōu)缺點總結

四. 火山引擎 RTC 性能降級策略4.1 性能降級策略概覽

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

火山引擎 RTC 視頻性能動態(tài)降級策略概覽

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

4.2 RTC 編碼組織方式

火山引擎 RTC Simulcast Encoder 之間采用完全并行的編碼方案，每條 Simulcast 流處在不同的 Pipeline 上，線程之間相互不影響。相比 WebRTC Simulcast Encoder 之間串行的編碼方案，并行編碼方案效率更高，并且編碼效率基本不受 Simulcast 流數(shù)的影響。

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

4.3 RTC Simulcast 流降級方案

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

火山引擎 RTC 除了降級單條流之外，還支持 Simulcast 流之間聯(lián)動。性能不足時，支持關閉高分辨率的流（Fallback），性能恢復時，可以重新開啟高分辨率的流。當發(fā)生 Fallback 時，訂閱高分辨率的用戶會自動切換為訂閱次高分辨率的流，性能恢復時，會重新切換回來。以下圖為例，如果 720p 流被關閉，訂閱 720p 的用戶將會收到最接近 720p 的分辨率的流，所示為 360p。

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

4.4 不同發(fā)布流之間的協(xié)同降級

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

典型的降級路徑

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

4.5 性能和帶寬降級關系處理

性能和帶寬是 RTC 系統(tǒng)中最重要的兩種資源。隨著系統(tǒng)運行，兩者會處在不斷的變化中。同時有性能以及帶寬波動的情況下，可能會出現(xiàn)，性能負載過高，觸發(fā)降級，但同時帶寬回升，又會觸發(fā)升級。因此，需要有一種機制保證兩者之間出現(xiàn)“你升我降”的問題?；鹕揭?RTC 把性能和帶寬控制兩者解耦開來，把性能的輸出作為一個最大限制條件。性能升級相當于是上調水位線，降級相當于下調水位線，實際性能/帶寬升降級由一個模塊統(tǒng)一處理。

除了性能和帶寬之外，火山引擎 RTC 還支持按需發(fā)布能力，發(fā)布端結合三者采用如下方案進行綜合決策。

說明：因為性能原因，720p 流被關閉，訂閱 720p 的用戶將會收到最接近 720p 的分辨率的流，所示為 360p。

4.6 訂閱端的性能降級

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

火山引擎 RTC 引入訂閱端性能降級方案，聯(lián)動上下行，當系統(tǒng)負載較高或者解碼器延時較長時，訂閱端支持動態(tài)性能降級。

1）訂閱端可以根據(jù)流的優(yōu)先級，優(yōu)先選擇降級低優(yōu)先級的流，盡可能保證高優(yōu)先級流的視頻體驗。

火山引擎 RTC 支持 API 方式設置訂閱流的優(yōu)先級。

2）就單條流來說，訂閱端也可以靈活的配置，是優(yōu)先先降級分辨率還是幀率（后臺配置）。

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

4.7 基于 CPU 使用率的降級

使用特性處理耗時（比如：編碼延時或者視頻處理算法耗時）的最主要的問題在于：

僅能監(jiān)控當前特性自身的負載，如果鏈路其他消耗較高(并且不在監(jiān)控范圍內)，導致整體負載過高時，依舊無法降級。系統(tǒng) CPU 使用率較高時，無法退避，導致設備過燙，甚至用戶操作受到嚴重影響。

火山引擎 RTC 支持性能降級統(tǒng)一調控方案，可以進行上下行聯(lián)動，也可以對視頻/屏幕的性能降級聯(lián)動等，甚至可以聯(lián)動音頻及網(wǎng)絡。

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

enum RXPerfUnitType {    kRXPerfUnitUnknown = 0,    // 發(fā)布視頻流    kRXPerfVideoPubCamera = 1,    // 發(fā)布屏幕流    kRXPerfVideoPubScreen = 2,    // 發(fā)布投屏    kRXPerfVideoPubScreenCast = 3,    // 訂閱視頻    kRXPerfVideoSubCamera = 4,    // 訂閱屏幕    kRXPerfVideoSubScreen = 5,};

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

五. 總結和展望5.1 總結

我們在會議場景對上述視頻性能降級策略進行了驗證。上線這些策略后，線上高負載時間比例持續(xù)優(yōu)化，從整體 9‰左右優(yōu)化到 5‰，用戶感受高負載情況（設備發(fā)燙、界面響應慢、音視頻卡頓、甚至程序崩潰或死機等問題）變少。

當前的視頻性能降級策略也存在一些可以優(yōu)化的地方，比如：

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

降級最低視頻質量配置可以更靈活。降級至最低檔位時，應該還要關聯(lián)實際的發(fā)布訂閱情況來執(zhí)行。比如，用戶在訂閱 1080p 的流，這時候降級到 180p 可能不是一個很合適的選擇；但如果用戶本身訂閱就是 360p 的流，這時候降級到 180p 可能是一個不錯的選擇。后續(xù)將進一步探索和優(yōu)化，保證性能滿足要求的情況，質量損失最小。

支持基于GPU的性能降級。RTC 場景不光對于 CPU 的消耗大，對于 GPU 的消耗同樣也不小。后續(xù)基于 GPU 的性能降級也將上線。

5.2 展望

未來，火山引擎 RTC 還將支持更多降級策略，比如超分 / 降噪特性的性能降級、編碼器降級等；降級方案完整性進一步提升，比如根據(jù)用戶設備來推薦最佳視頻參數(shù)；另外，利用火山引擎“數(shù)據(jù)驅動”優(yōu)勢，量化性能數(shù)據(jù)，探索性能和帶寬深度融合方案。通過這些優(yōu)化，更好地平衡高級特性的使用和機器性能的矛盾客觀存在，為用戶帶來更好的體驗。

六. 加入我們

火山引擎 RTC，致力于提供全球互聯(lián)網(wǎng)范圍內高質量、低延時的實時音視頻通信能力，幫助開發(fā)者快速構建語音通話、視頻通話、互動直播、轉推直播等豐富場景功能，目前已覆蓋互娛、教育、會議、游戲、汽車、金融、IoT 等豐富實時音視頻互動場景，服務數(shù)億用戶。

關鍵詞： 的情況下 高分辨率 可以選擇 高優(yōu)先級 視頻通話