導讀：RTC 場景視頻的體驗指標主要包括視頻延遲、視頻流暢度、視頻清晰度。在一定條件下視頻的最佳體驗主要指延遲、流暢度、清晰度達到均衡，達到條件下的最佳主觀體驗。本文主要介紹，為了能夠調節出一個最佳的體驗效果，網易云信在工程架構和策略方面做的一些工作。

文｜戚繼躍

網易云信資深引擎工程師

RTC?的視頻體驗質量對外受用戶網絡環境、用戶使用姿勢、用戶硬件平臺影響；對內依賴我們的網絡 QoS 模塊、視頻編解碼模塊、視頻質量控制 VQC 模塊、視頻前后處理模塊的密切配合。

單獨調整或調優某一個模塊，可以得到一定的收益，但是如果幾個模塊能夠聯動調節，那么可以極大的提升使用效果，得到 1 + 1 > 2 的效果。為此我們設計了自適應調節系統（Auto Adjust System, AAS），可以根據外部因素和內部各模塊的工作狀態，自適應調節各個模塊工作參數，達到視頻的最佳體驗。

?網易云信自適應調節系統

網易云信的自適應系統 AAS 分為配置自適應和工作中的動態自適應兩部分，兩者相互配合。配置自適應是指根據當前的用戶配置、設備、網絡供應商等信息，綜合決策實際的視頻配置；動態自適應是指在運行過程中，根據各個模塊的反饋，決定視頻參數的調整。配置自適應和動態自適應沒有固定優先級關系，由具體的配置和參數自行決定。

?配置自適應?

配置自適應是指能夠根據當前的用戶配置、設備名稱、網絡服務商、所屬地區等客觀現實條件，自適應地選擇一套最適合當前條件的視頻參數。為了達到配置自適應的目的，我們設計了一套多維度層次化配置系統，包括初始默認生效參數、靜態白名單、頻道前配置下發、用戶設置、頻道內配置下發、能力協商，這些配置從前到后優先級逐步升高，即后面的配置可以強制修改前面配置的結果。

初始默認值：是指我們內部配置的默認值，如果不做任何其他設置這個配置就會使用這個值。

靜態白名單：代碼里面維護的一套設備相關以設備 device id 為索引的表，表里面存儲需要使用的配置值。

頻道前配置下發：在加入頻道前，會從服務器獲取一次配置信息，配置的信息在服務端維護，下發可以根據機型、地區、網絡類型等進行下發。

用戶設置：用戶通過接口指定一些配置。

頻道內配置下發：和頻道前配置下發類似，不同點是發生在加入頻道之后。

能力協商：比如 codec 格式這種配置，需要根據整個房間內所有人支持的解碼格式來確定，所以需要每個人在加入頻道內時候上報自己的解碼能力，然后對所有解碼能力進行綜合，得出的結果下發給所有人。

?動態自適應?

動態自適應是指在工作過程中，能夠根據當前網絡、設備性能、視頻 profile 等變化的監測，動態調整相關模塊的參數。為達到動態自適應的目的，我們設計了動態自適應模塊，目前該模塊監測的變量包括當前視頻使用的 profile（寬高幀率）、當前 codec 類型、當前軟硬件編解碼選擇、當前 QoS 反饋的碼率、當前編碼流程的性能這些參數。動態自適應的內容包括是否切換 codec 類型、前后處理算法開關、視頻大小流策略等。后續的開發的 feature 可以根據需要增加監測的指標，然后輸出動態自適應結果。

應用舉例

我們通過一個例子來展現云信的自適應調節系統的使用情況。在編碼發送端，云信的編碼器有軟件的 ne264、ne265、vp8，同時有我們也做了硬件 264， 硬件 265 的適配。發送時選用哪個編碼器，以及幾個編碼器之間如何相互切換，是個棘手的問題。

?編碼器能力分析?

在使用自適應調節系統解決編碼器選擇問題之前，我們先來分析一下各個編碼器的優劣：

• ne264?輸出標準的 264 碼流，兼容性最好，碼率最穩定，但是在高分辨率下性能是個問題，而且壓縮率也不如 265。

• ne265?輸出標準的 265 碼流，性能消耗最大，碼率也不夠穩定，很多設備性能不能支撐編碼 265 碼流，但是在高分辨率下壓縮率有明顯優勢。

• vp8?是 WebRTC 支持最好的格式，一些移動端的瀏覽器上只支持 vp8 解碼，兼容性超過 264。

• 硬件 264?支持設備很廣，性能有優勢，但是編碼的碼率波動可能會比 ne264 要大。

• 硬件 265?在高分辨率下壓縮率很有優勢，支持設備一般，需要 case by case 的適配，碼率波動很大，265 的解碼性能也存在問題。

可以通過以下圖片比較我們的幾種編碼器：

根據編碼器的不同特性，可以設計編碼器選擇自適應如下：

配置自適應

根據我們對硬件設備適配的結果，在靜態白名單上寫上對應的硬件設備型號，是否支持硬件 264 編碼，是否支持硬件 265 編碼，是否支持 265 軟件編碼，是否支持 265 解碼。

根據白名單的結果，按照硬件 265，ne265，硬件 264，ne264， vp8 從前到后的順序選取當前設備支持的編碼類型列表。比如某款 android 手機，通過查找白名單表我們得到 [硬件 265，硬件 264，ne264，vp8] 這樣的支持列表，使用編碼器時，按照優先級從前到后選擇編碼器，排在前面的優先使用。

在我們后續的測試中，我們發現這款 android 手機的硬件 264 不太穩定。于是我們更新白名單，去掉這款手機的硬件 264，并且在已經上線的 sdk 中，我們通過頻道前配置下發中關閉硬件 264，得到新的支持列表?[硬件 265，ne264，vp8]?，用戶設置打開了 265 優先，所以我保持 265 在列表內。

加入頻道時，我們根據白名單中解碼能力，上報了自己的解碼能力集 [265，264，vp8]，同時在頻道內的另一端某個設備不足以解碼 265，上報的解碼能力集是 [264，vp8]，服務端綜合結果后給每個端下發的編碼能力集是 [264，vp8]，于是我們支持列表變成了 [ne264, vp8]。最終這個用戶在這次通話中使用了 ne264 編碼器。

這個用戶在長時間使用后，我們后臺數據分析發現，經常會有 android 設備的硬件 264 碼率不夠穩定，這些設備使用 ne264 性能也是沒有問題的，于是我們在頻道內配置下發中，將這些 android 設備的硬件 264 關閉了，只保留 ne264。

動態自適應

某次通話，某個設備的支持列表是?[硬件265，硬件 264，ne264，vp8]，當前正使用硬件 265 編碼發送。

動態自適應模塊監測到由于性能問題，vqc 將視頻 profile 由原來的 720p，30fps 調整為 360p，20fps。這個時候由于硬件 265 在這一檔視頻 profile 上收益已經不大了，所以我們切換硬件 265 到硬件264。

動態自適應模塊監測到 QoS 的目標碼率波動很厲害，超過了我們設定的閾值，這個時候我們判斷是由于硬件 264 的碼率不穩定，有可能在這種波動下造成超發從而引起延遲拉大，所以我們切換硬件 264 到軟件 264，動態自適應模塊監測到 QoS 目標碼率變平穩后，再從軟件 264 切回硬件 264。動態自適應模塊監測到性能問題已經緩解，vqc 恢復了 720p，30fps 的視頻 profile，這時候我們再由硬件 264 切換為硬件 265。

結語

本文主要介紹了網易云信 RTC 的重要組成部分——自適應調節系統。通過配置自適應和動態自適應，可以應對各種由于使用姿勢、用戶網絡環境、用戶設備等引入的不確定性，在一定條件下達到最佳視頻體驗。

作者介紹?

戚繼躍，網易云信資深引擎工程師，長期從事音視頻相關開發工作，對 WebRTC 引擎、音視頻會議系統、視頻編解碼等有深入研究。目前主要負責網易云信 NERTC 引擎架構和視頻體驗。

?相關閱讀推薦?

• 技術干貨 | 為高音質保駕護航 - 通信中的回聲消除

• 技術實踐｜網易云信 IM SDK 服務高可用技術方案

• 技術實踐 | Web 端實現 RTC 視頻特效的解決方案
  

總結

以上是生活随笔為你收集整理的技术干货 | 视频最佳体验之自适应调节系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。