導(dǎo)讀：本文根據(jù)網(wǎng)易云信資深引擎工程師戚繼躍在《MCtalk Live#4：視頻 QoE 的平衡之道—揭秘網(wǎng)易云信 NERTC 視頻質(zhì)量控制系統(tǒng)》線上直播分享整理，文末有直播視頻回顧以及 QA 整理。

文｜戚繼躍 網(wǎng)易云信資深引擎工程師

互聯(lián)網(wǎng)發(fā)展迅猛，實(shí)時(shí)通信（Real Time Communication，簡(jiǎn)稱 RTC）需求與日俱增。如何在各種復(fù)雜網(wǎng)絡(luò)服務(wù)質(zhì)量 （Quality of Serverice，簡(jiǎn)稱 QoS）下，以及參差不齊的硬件終端上取得最佳的視頻體驗(yàn)質(zhì)量 (Quality of Experience，簡(jiǎn)稱 QoE) ，是 RTC 技術(shù)的重要一環(huán)。

本文從視頻質(zhì)量控制系統(tǒng) （Video Quality Controller，簡(jiǎn)稱 VQC）模塊出發(fā)，介紹網(wǎng)易云信 NERTC 在提升視頻 QoE 方面做的一些工作。

VQC 在視頻 QoE 中的作用

視頻的 QoE 主要包含視頻的清晰度、視頻流暢度、視頻延時(shí)三個(gè)方面的指標(biāo)，整體上由網(wǎng)絡(luò) QoS、視頻處理算法、VQC 共同決定：

• 網(wǎng)絡(luò) QoS：提供盡可能充分的可使用帶寬

• 視頻處理算法：在一定的碼率下，輸出盡可能好的視頻質(zhì)量

• VQC：

  • 對(duì) QoS 負(fù)責(zé)，控制碼率，保證流暢度和延時(shí)

  • 對(duì)視頻算法負(fù)責(zé)，保證性能，平衡清晰度和流暢度

VQC 通過對(duì)視頻 QoS 狀態(tài)、視頻算法狀態(tài)的監(jiān)控，輸出控制信號(hào)，達(dá)到場(chǎng)景化的最佳 QoE 表現(xiàn)，包括平衡清晰度、流暢度、延時(shí)這幾個(gè)指標(biāo)。今天，我們主要分享網(wǎng)易云信 NERTC 上的 VQC 實(shí)現(xiàn)以及 QoE 調(diào)優(yōu)的相關(guān)工作。

網(wǎng)易云信 VQC 實(shí)現(xiàn)

網(wǎng)易云信的 VQC 模塊部分參考了 WebRTC 的模塊設(shè)計(jì)，整體結(jié)構(gòu)如圖中所示，主要包含四個(gè)監(jiān)控模塊和一個(gè)策略模塊。輸入的參數(shù)通過監(jiān)控模塊后得到當(dāng)前的各種狀態(tài)結(jié)果，然后由 VQC 策略模塊決定最終輸出的控制信號(hào)，控制視頻 pipeline 的工作。下面，我們具體介紹每個(gè)模塊。

?QualityScaller?

QualityScaller 模塊的作用是監(jiān)測(cè)當(dāng)前的編碼質(zhì)量，主要對(duì)清晰度和編碼器穩(wěn)定性負(fù)責(zé)。

該模塊輸入根據(jù)編碼器類型和編碼算法類型而確定的 QP 閾值、當(dāng)前輸出編碼幀的 QP 值、當(dāng)前丟幀的統(tǒng)計(jì)數(shù)據(jù)，輸出視頻質(zhì)量好壞的結(jié)果。

其中 QpSmoother 模塊使用指數(shù)加權(quán)累加的方式來確定 QP 的統(tǒng)計(jì)值，如下：

我們?cè)敿?xì)看一下這個(gè)公式的組成，公式中：

• sample 為當(dāng)前幀的 QP

• 輸出 y 為 QP 統(tǒng)計(jì)值

• alpha 是根據(jù)編碼器 QP 變化特性總結(jié)的一組系數(shù)值，根據(jù)上限和下限使用不同的系數(shù)值。比如我們測(cè)試下來針對(duì) OpenH264 編碼器，QP 上限系數(shù)值可以使用 0.9995， QP 下限系數(shù)值可以使用 0.9999。通過這種差異性的上下限系數(shù)，達(dá)到視頻質(zhì)量變差時(shí)（QP 增加）反應(yīng)迅速，視頻質(zhì)量變好時(shí)（QP 減小）反應(yīng)稍微遲鈍的效果

最終統(tǒng)計(jì)的上下限 QP 統(tǒng)計(jì)值，與輸入的 QP 閾值比較判斷，決定當(dāng)前畫質(zhì)的好壞。輸入的 QP 閾值也是根據(jù)編碼器不同而不同的，比如在 OpenH264 上我們測(cè)試下來使用閾值下限為 24，上限為 37；硬件 iOS 設(shè)備上硬件編碼則使用其他值，Android 上硬件編碼則又不同，這都需要根據(jù)設(shè)備的大量驗(yàn)證來獲取。

MovingAverage 為一個(gè)滑動(dòng)窗口函數(shù)，取這個(gè)窗口內(nèi)的丟幀比例，超過一定閾值認(rèn)為是質(zhì)量變差。

最終內(nèi)部周期性查詢模塊會(huì)收集 QpSmoother 和 MovingAverage 的統(tǒng)計(jì)結(jié)果，輸出兩個(gè)結(jié)果（不輸出不計(jì)入結(jié)果）：

• 視頻質(zhì)量好

  • QpSmoother 的 QP 統(tǒng)計(jì)值下限小于等于 QP 下限閾值

  • MovingAverage 統(tǒng)計(jì)的丟包率超過閾值

• 視頻質(zhì)量差

  • QpSmoother 的 QP 統(tǒng)計(jì)值上限大于 QP 上限閾值

?OveruseFrameDetector?

OveruseFrameDetector 模塊主要作用是監(jiān)測(cè)當(dāng)前的性能能否支撐當(dāng)下幀率的運(yùn)行，對(duì)視頻的流暢度負(fù)責(zé)。

該模塊輸入當(dāng)前的目標(biāo)幀率、分辨率、CPU Usage 閾值，采集和發(fā)送視頻幀時(shí)間，輸出當(dāng)前性能好或者壞的結(jié)果。

ProcessingUsage 模塊通過輸入的視頻幀采集和發(fā)送的時(shí)間，統(tǒng)計(jì)整個(gè)視頻發(fā)送鏈路即視頻采集到發(fā)送的時(shí)長(zhǎng)，用這個(gè)時(shí)長(zhǎng)做一些平滑運(yùn)算后得到一個(gè)統(tǒng)計(jì)值，用這個(gè)統(tǒng)計(jì)值和當(dāng)前幀率下幀間隔的理論時(shí)長(zhǎng)做比較，統(tǒng)計(jì)時(shí)長(zhǎng)是否超過理論值，并記錄次數(shù)。然后周期性的收集次數(shù)，超過一定次數(shù)則輸出性能差 CPU bad 的結(jié)果，低于一定次數(shù)則輸出性能好 CPU good 的結(jié)果。

在該模塊中，需要防止一些假的 CPU good 或者 bad 結(jié)果，比如：

• 樣本數(shù)量少時(shí)（比如幀率低），周期性收集數(shù)據(jù)的時(shí)間沒有變，這就容易導(dǎo)致結(jié)果誤差

• 新的幀率分辨率剛開始工作時(shí)，各個(gè)環(huán)節(jié)的處理時(shí)間還沒有問題，也需要特殊處理

?RateAllocator?

RateAllocator 模塊負(fù)責(zé)決定當(dāng)前碼率的使用，在大小流場(chǎng)景下充當(dāng)大小流使用的策略模塊。

該模塊有幾個(gè)關(guān)鍵性作用：

• 遠(yuǎn)端有多個(gè)用戶，其中有用戶訂閱了小流也有用戶訂閱了大流，該模塊會(huì)決定有限的碼率按照什么比例分配比較合適

• 同樣的場(chǎng)景，在碼率十分不足的情況下，該模塊會(huì)決策大小流合并成一條流使用，提升畫質(zhì)

• 在下行的帶寬受限情況下，該模塊會(huì)決策發(fā)送端有沒有必要降低帶寬發(fā)送

?MediaOptimization?

MediaOptimization 模塊主要負(fù)責(zé)監(jiān)測(cè)和修正實(shí)時(shí)的碼率和幀率，防止碼率超發(fā)導(dǎo)致網(wǎng)絡(luò)擁堵，因?yàn)閾矶潞缶W(wǎng)絡(luò)會(huì)進(jìn)一步惡化，導(dǎo)致畫質(zhì)、流暢度、延時(shí)全面的降低。

該模塊控制實(shí)時(shí)碼率主要通過內(nèi)部的 FrameDropper 模塊，其使用漏斗算法決策當(dāng)前是否碼率超發(fā)，是否需要丟幀來穩(wěn)定碼率。

在每一幀編碼之前，將該幀的目標(biāo)碼率作為輸入放入漏斗中，編碼之后將當(dāng)前幀的實(shí)際碼率作為漏斗的輸出，然后去查看漏斗是否滿了，如果滿了就丟棄下一個(gè)編碼幀來控制碼率。漏斗的容量大小和可以容忍的延時(shí)相關(guān)，需要進(jìn)行場(chǎng)景化定義。

丟幀與否的結(jié)果也會(huì)輸出給 QpScaller 模塊，作為評(píng)價(jià)編碼質(zhì)量的依據(jù)的一方面。

?VQC 決策模型?

VQC 決策模塊根據(jù) VQC 內(nèi)部前述所有模塊的結(jié)果，結(jié)合用戶的場(chǎng)景設(shè)置，決策當(dāng)下的視頻策略。

其內(nèi)部包含兩個(gè)狀態(tài)機(jī)以及一個(gè)決策模塊。

兩個(gè)狀態(tài)機(jī)相互獨(dú)立，互不影響：

• 視頻質(zhì)量狀態(tài)機(jī)

• 性能情況狀態(tài)機(jī)

一個(gè)決策模塊，我們具體說明其中的一些重要功能：

• 根據(jù)用戶設(shè)置的場(chǎng)景以及期望視頻參數(shù)，設(shè)置各種內(nèi)部調(diào)整的閾值

• 根據(jù)狀態(tài)機(jī)的結(jié)果，決策提高或者降低視頻的參數(shù) （分辨率、幀率），以及提高或者降低的策略

• 根據(jù)其他信息，決策當(dāng)前幀編碼的其他參數(shù)，比如 simulcast 雙流場(chǎng)景下大流或者小流是否編碼

• 根據(jù)其他信息，決定算法是否需要調(diào)整，比如編碼算法，后處理算法等

通過 ?VQC 進(jìn)行視頻 QoE 調(diào)優(yōu)

VQC 通過對(duì)視頻質(zhì)量的全鏈路監(jiān)控和調(diào)節(jié)來保證良好的視頻 QoE ，下面介紹下云信 RTC 這邊在通過 VQC 調(diào)優(yōu) QoE 方面的一些工作。

?正確判斷編碼質(zhì)量?

表征編碼質(zhì)量的參數(shù)有很多：PSNR、SSIM、QP、VMAF 等，因?yàn)橛布幋a器的特殊性以及參數(shù)獲取計(jì)算成本的考慮，選用了 QP 作為評(píng)判標(biāo)準(zhǔn)。

如果選擇使用 QP 作為正確反應(yīng)編碼質(zhì)量的指標(biāo)，需要考慮如下幾點(diǎn)：

• 常規(guī)的 Slice QP 在 H264/265 編碼中，一般編碼器中只能反應(yīng)前面幾個(gè)編碼宏塊的質(zhì)量。在軟件編碼上可以使用更優(yōu)的 average QP 來作為視頻幀的 QP，這樣判斷軟件編碼質(zhì)量效果更優(yōu)。

• 不同編碼算法的 QP 閾值是不同的，比如我們?cè)?OpenH264 上可以使用 （24，37）作為 QP 好壞判斷的上下限，但是在不同的編碼器和不同的編碼算法上就需要調(diào)整，比如我們的 NE264、NE265、NEVC 編碼算法都需要做對(duì)應(yīng)的適配調(diào)整。

• 不同硬件加速平臺(tái)上編碼器的 QP 的閾值是不同的，比如 iOS 系統(tǒng)、Android 系統(tǒng)，甚至 Android 不同的芯片平臺(tái)也需要做對(duì)應(yīng)的適配。

• 不同編碼算法，不同硬件平臺(tái)，QP 質(zhì)量變化的曲線不同，為了提取特征，需要調(diào)節(jié)統(tǒng)計(jì)方法的統(tǒng)計(jì)系數(shù)。

?正確判斷性能問題?

為了防止性能問題導(dǎo)致的視頻 QoE 降低，我們需要能準(zhǔn)確的甄別出性能問題并作出正確有效的調(diào)整。當(dāng)前我們的 VQC 中，使用視頻幀處理時(shí)間來表征性能狀態(tài)，想要正確甄別性能狀態(tài)，需要考慮以下幾個(gè)方面：

• 能判斷編碼和前處理的整個(gè)流程的性能

• 一些硬件有 pipeline 延時(shí)需要考慮

  如果幀間隔不均勻，會(huì)導(dǎo)致誤判定性能問題，需要識(shí)別出這種特征

為了進(jìn)行有效的調(diào)整，我們主要需要考慮以下幾個(gè)方面內(nèi)容：

• 根據(jù)測(cè)試中性能消耗的優(yōu)先級(jí)來調(diào)整，比如我們測(cè)試下來部分模塊的優(yōu)先級(jí)是：前處理 > 編碼算法 > 幀率調(diào)整 > 分辨率調(diào)整

• 如果做了相應(yīng)的調(diào)整，統(tǒng)計(jì)的性能狀態(tài)還是沒有變化，我們需要有相應(yīng)的處理手段，反饋調(diào)整內(nèi)容和結(jié)果給狀態(tài)機(jī)，讓狀態(tài)機(jī)報(bào)告給決策模塊進(jìn)行下一步?jīng)Q策

• 如果性能狀態(tài)變化過大，需要拉大調(diào)整步長(zhǎng)

?最優(yōu)化調(diào)整?

有效的調(diào)整就是是調(diào)整后視頻 QoE 提升明顯，我們主要可以通過以下幾個(gè)方面進(jìn)行調(diào)整：

• 分辨率調(diào)整

• 幀率調(diào)整

• Simulcast 流的調(diào)整

• 前處理的一些算法開關(guān)

• Codec 調(diào)整?

VQC 是如何進(jìn)行最優(yōu)化調(diào)整的呢，如下：

• 支持用戶可配置多種場(chǎng)景和策略

  • 通信模式，直播模式

  • 用戶高可定制化：特殊場(chǎng)景模式，分辨率不變模式，幀率不變模式，最小幀率最小碼率等設(shè)置

• 內(nèi)部自適應(yīng)調(diào)整，根據(jù)大量測(cè)試試驗(yàn)確定某個(gè)具體場(chǎng)景下的參數(shù)組合，調(diào)整步長(zhǎng)以及最佳路徑，比如如下視頻分辨率和幀率調(diào)整步長(zhǎng)和路徑

結(jié)語(yǔ)

本文主要介紹了網(wǎng)易云信 RTC 中視頻質(zhì)量控制系統(tǒng) VQC 的設(shè)計(jì)，以及在 QoE 調(diào)優(yōu)方面的一些工作。沒有一種策略是完美無缺的，魚和熊掌不可兼得。我們?cè)?QoE 調(diào)優(yōu)中做的工作就是在一定的條件下，通過一些列手段平衡清晰度、流暢度、延時(shí)這些指標(biāo)，趨利避害。通過互相配合的策略以及大量的數(shù)據(jù)測(cè)試驗(yàn)證，尋找出最優(yōu)的策略。

?QA 整理?

以下內(nèi)容，根據(jù)線上直播群內(nèi) QA 記錄整理：

1. @一葦以航 提問：

Q：請(qǐng)問 ratecontroller 的時(shí)候，一般都是 SFU 轉(zhuǎn)發(fā)模式，這個(gè)時(shí)候的 simulcast 是從服務(wù)端考慮所有訂閱端反饋給發(fā)送者去調(diào)整大小流的碼率嗎？

A：我們服務(wù)端做了各種場(chǎng)景下的策略，默認(rèn)是走可配置的 TopN 策略，部分頭部觀眾盡量使用高清高流暢的大流，少量網(wǎng)絡(luò)質(zhì)量不好的用戶使用小流，服務(wù)端會(huì)根據(jù)下行所有觀眾的網(wǎng)絡(luò)情況，算出一個(gè)合適的反饋碼率。

Q：恩，我還想問發(fā)送端在大小流的碼率調(diào)整策略，你們談 ratecontrol 這個(gè)模塊的時(shí)候說到了一點(diǎn)，發(fā)送端收到一個(gè) cc 的帶寬反饋，同時(shí)發(fā)送端提供了 simulcast，你們好像還能夠考慮到不同的接收端網(wǎng)絡(luò)狀態(tài)，進(jìn)行大小流的碼率調(diào)整，是有這個(gè)能力？

A：我們有下行的 cc，服務(wù)器會(huì)根據(jù)下行 cc 輸出的估計(jì)帶寬，然后綜合出一個(gè)合適的帶寬反饋給發(fā)送端。Simulcast 是端上根據(jù)總的碼率，在我們模塊里面做決策，是發(fā)大流還是小流，還是雙流。服務(wù)端也會(huì)根據(jù)每個(gè)端的情況，決定給下行發(fā)送大流還是小流。

Q：美顏跟超分會(huì)帶來多大的延遲？

A：關(guān)于美顏跟超分會(huì)帶來多大的延遲的問題：小于幀間隔，不會(huì) delay 我們 pipeline，我們做了動(dòng)態(tài)適配，如果大于幀間隔，會(huì)動(dòng)態(tài)關(guān)閉掉，對(duì)整個(gè)流水線的延時(shí)小于一個(gè)幀間隔，如果 30 fps 就是小于 33ms。

Q：一般做這一塊的都是基于 WebRTC 去做的，好像中途要切換 codec 的話，要么就重新創(chuàng)建 peerconnection 重新協(xié)商，你們支持是因?yàn)樽匝刑砑拥膯?#xff0c;還是 WebRTC 本身支持呀？

A：我們有部分參考了 WebRTC，codec 切換這塊不需要重新協(xié)商，我們做了頻道內(nèi)的能力協(xié)商，是私有協(xié)議，不需要像 WebRTC 那樣做 sdp 交換，我們有自己的能力協(xié)商協(xié)議，然后音視頻引擎內(nèi)部做切換。

Q：還有一個(gè)問題，你們?cè)?RTC 會(huì)議房間里如何處理關(guān)鍵幀請(qǐng)求，每一個(gè)新加入的用戶如果都發(fā)關(guān)鍵幀請(qǐng)求，會(huì)導(dǎo)致房間的流量很大，但是不發(fā)的話等到下一個(gè) GOP 會(huì)很久，你們采用了什么樣的策略去均衡？

A：1. 一般邏輯是每個(gè)新加入的用戶都會(huì)有 intra request 發(fā)出來，然后接收端有一個(gè) key frame 發(fā)送間隔的控制。這樣不會(huì)有太多 key frame，也不會(huì)導(dǎo)致出圖很慢。2. 當(dāng)然我們?yōu)榭焖俪鰣D做了些優(yōu)化，提前服務(wù)器 intrarequest, 保存近期的 key frame 等操作。這些都是我們實(shí)際調(diào)整的一些細(xì)節(jié)，需要根據(jù)自己的場(chǎng)景去適配，我們也是分場(chǎng)景的。直播和通信策略就不一樣。

2. @galen 提問：

Q：請(qǐng)教下怎么檢測(cè)卡頓呢， 一般檢測(cè)卡頓幀間隔時(shí)間有講究嗎？

A：卡頓我們會(huì)統(tǒng)計(jì) 200ms 卡頓和 500ms 卡頓，檢測(cè)實(shí)際渲染的幀率間隔，超過 200ms 或者 500ms，統(tǒng)計(jì)小卡頓或者大卡頓。

?作者介紹?

戚繼躍，網(wǎng)易云信資深引擎工程師，長(zhǎng)期從事音視頻相關(guān)開發(fā)工作，對(duì) WebRTC 引擎，音視頻會(huì)議系統(tǒng)，視頻編解碼等有深入研究。目前主要負(fù)責(zé)網(wǎng)易云信 NERTC 引擎的視頻體驗(yàn)。

視頻回顧地址（或點(diǎn)擊閱讀原文）：

https://mctalk.yunxin.163.com/details-live/13

?延伸閱讀?

• 技術(shù)系列課回顧 | 直播點(diǎn)播窄帶高清之 JND 感知編碼技術(shù)

• 技術(shù)系列課回顧 | 淺談 Serverless 開發(fā)和應(yīng)用

• 云信技術(shù)系列課 | RTC 系統(tǒng)音頻弱網(wǎng)對(duì)抗技術(shù)發(fā)展與實(shí)踐

• 云信技術(shù)系列課回顧視頻｜視頻直播關(guān)鍵技術(shù)和趨勢(shì)

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的技术系列课回顾 | 视频 QoE 的平衡之道的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。