阿里雲 RTC QoS 屏幕共享弱網優化之若干編碼器相關優化

屏幕共享是視頻會議中使用頻率最高的功能之一，但在實際場景中用戶所處網絡環境複雜，常遇到丟包或者擁塞的狀況，因此如何優化弱網環境下的用戶體驗也成爲了音視頻通訊中重要的一環。本文主要分享阿里雲 RTC QoS 如何經過若干編碼器相關優化提高弱網環境下的屏幕共享體驗。

做者：長程/田偉峯
審校：泰一

內容說明：

本文介紹如下四個方面的優化：

• Screen Content Coding Tools
• Long Term Reference (LTR)
• Fast QP Rate Control
• Content Adaptive Frame Rate

對本文中效果測試的說明：

1. 爲保證視頻質量，屏幕共享的 Codec 設置了最大 QP (Quantization Parameter)，在本文後面的測試中，這個最大 QP 對全部配置都是同樣的。
2. 爲了更好的比較，效果測試中展現了流暢性和清晰度兩個維度的效果。
3. 對於流暢性的比較，因爲視頻分辨率太大，因此對其畫面進行了縮放，使得原始版本和改進版本能夠放在同一個視野中播放，以很好的看到卡頓和延遲的改進。畫面模糊是因爲上述緣由降分辨率所致，在清晰度的對比中能夠看到原始分辨率的畫面。

Screen Content Coding Tools

Codec 中增長並改進了對於屏幕內容（其內容多爲如 Word、Excel、PPT 等計算機生成的圖形，文字等，具備重複紋理多，色彩分佈較離散，無噪聲等特色）特別適合的 Coding Tools 如 Intra Block Copy (Current Picture Reference)，Transform Skip 等，顯著提高了屏幕內容的壓縮效率，能夠作到相對於原 Codec，對於屏幕內容視頻相同質量下平都可以節省帶寬 20%+，編碼時間只增長 10%，對某些典型序列場景帶寬能夠節省 40%+，因爲是非標準的 Coding Tools，實際使用中會根據 SDP 協商，當全部與會方都支持該特性時纔會開啓。

SCC Tools 效果

流暢性效果

測試 SCC Tools 在弱網下的改進效果。

上圖中，上半部分是增長了 Screen Content Coding Tools 編碼出來的碼流，下半部分是原始 Codec 編出的碼流，能夠看出使用 Screen Content Coding Tools 以後卡頓和延遲明顯下降了。

清晰度效果

上面的動圖能夠看到卡頓狀況的改進，下圖展現的是清晰度的對比，左邊是原始版本，右邊是增長了 SCC Tools 版本，能夠看到 SCC Tools 版本和原始版本相比清晰度並無降低。

Long Term Reference (LTR)

長期參考幀技術是一種網絡模塊和編碼器共同配合完成的參考幀選擇技術。在 RTC 場景下通常的編碼參考策略是向前一幀參考（在不考慮 SVC 的狀況下），由於參考的距離越近壓縮效果越好，出於實時的考慮編碼只有 I 幀和 P 幀，沒有 B 幀。而長期參考幀是一種可跨幀的參考幀選擇策略，這種策略打破了傳統的向前一幀的限制，能夠更加靈活地選擇參考幀。

長期參考幀策略的目的是在有 P 幀丟失的場景下，接收端不須要從新請求 I 幀也能繼續正確的解碼和播放，其相對於 I 幀能夠明顯提高編碼效率，節省帶寬。該技術能夠繞過丟失的幀，利用丟失幀以前的一個已經接收的長期參考幀做爲參考進行編碼 / 解碼顯示，從而提高弱網場景下的視頻流暢性。

根據長期參考幀的特色和目的，實現長期參考幀技術的應用須要有接收端側反饋信息，編碼器根據接收端反饋的幀信息選擇參考幀編碼，在有 P 幀丟失的場景下，接收端經過請求長期參考幀恢復將很快恢復畫面。因爲存在接收反饋，高 RTT 時反饋延時較大將會致使參考距離變大，因此長期參考幀比較適合低 RTT 場景。在多人會議場景中，下行人數太多也會制約長期參考幀的應用。

綜合來看，長期參考幀更適合 1V1 的通訊場景，適合低 RTT 伴隨丟包或者擁塞的弱網場景，這樣的場景下長期參考幀比傳統的向前一幀參考有更好的實時性和流暢性。

LTR 效果

測試 LTR 以及 SCC Tools 在屏幕共享弱網下的效果。

流暢性效果

上圖中左上部分是沒有 LTR 的效果，幾乎徹底卡死，左下部分是使用了 LTR 的效果，能夠看到屏幕有所滾動，比左上的更流暢。同時該場景咱們還進一步測試了增長 Screen Content Coding Tools，右邊的是同時使用了 LTR 和 SCC 的效果，能夠看到明顯是三者中最流暢的。

清晰度效果

下圖中左邊是原始 Codec 效果，中間是增長了 LTR 的效果，右邊是同時增長了 LTR 和 SCC 的效果，能夠看到三者的清晰度並無明顯差異。因爲該例子咱們共享的是實時的滾屏 Log，因此三者的內容不是徹底同樣的，可是整體差異不大。

Fast QP Rate Control

屏幕共享常常會有這樣的場景：演講者的桌面靜止很長時間，而後翻頁。對於編碼器來講，畫面靜止一段時間會致使 QP 逐漸下降至最小 QP，而後翻頁畫面突變，編碼器爲了控制住碼率，會增長 QP。常規的編碼器碼率控制爲了使每幀的視頻質量平穩變化，會限制每幀的 QP 調整幅度，相鄰兩幀的 QP 變化不能太大，以獲得平穩的視頻觀看質量體驗，這樣翻頁時就會有一個碼率的忽然增長，至碼率收斂到目標碼率會有一個過程，在網絡好的時候沒有關係，能夠容忍碼率的波動，可是在弱網時，該碼率突增就會形成卡頓，影響觀看體驗。

所以，咱們增長了另外一種編碼器碼率控制模式，即碼率快速收斂模式 Fast QP，主要原理是其能夠擺脫相鄰幀 QP 不能變化太大的限制，使得實際碼率能夠快速收斂到目標碼率，而後配合網絡層的帶寬估計技術，在檢測到弱網的時候啓用這種編碼器碼率控制模式，使得視頻碼率很是平穩，觀看體驗更加流暢，雖然這樣可能犧牲了一些相鄰幀質量變化的感覺，可是此時卡頓率的體驗更加明顯和重要，這種平衡和取捨是值得的。

Fast QP 效果

下面展現弱網下的 Fast QP 效果。

流暢性效果

上圖中一開始的那個畫面（有 Twitch 單詞紫色背景）是幾乎靜止的，只有很小範圍的變化，持續了近 10 秒鐘，編碼器 QP 逐漸降低至很低，而後翻頁到一個較複雜紋理的頁面（各類分辨率卡條），此時能夠看到右下的使用 Fast QP 的畫面基本上能夠跟得上上方本地預覽畫面的變化，而左下的沒有開 Fast QP 的畫面就卡住了，而後又翻了兩頁，Fast QP 版本均能跟得上變化，而沒有開 Fast QP 版本直到最後一頁才恢復。

清晰度效果

這裏咱們只展現了翻頁前的清晰度，對於翻頁的清晰度，因爲原始版本卡住了，因此就沒有展現。左邊是原始的，右邊是加了 Fast QP 的清晰度，因爲二者都是 QP 值降到了很低，因此清晰度都很高，沒有什麼差別。

Content Adaptive Frame Rate

屏幕共享的時候若是是共享桌面文檔，PPT 等內容進行演講，通常翻頁速度是相對較慢的，幀率不用很高 5-10 幀每秒即足夠；而有時屏幕共享也會播放電影，動畫等視頻，這樣要求的幀率就比較高了，最好能到 20-30 幀每秒纔看起來比較舒服。以下面兩圖，一個是編輯 PPT 的視頻，明顯幀率能夠比較低，另外一個是廣告視頻，明顯幀率應該高一些。

若是咱們把幀率定死，如 FPS=5，則碰到播放電影的場景就顯得卡頓了；而若是咱們把幀率直接定成 FPS=30，那在通常共享文檔，PPT 的場景又會形成碼率的浪費。

視頻編碼器裏的運動矢量 MV 信息能夠很好的反應畫面的運動情況，若是是共享的文檔，PPT 等不怎麼動的畫面，則大多數 MV 都等於 0 的，而若是是播放電影，動畫等運動較多的場景，則 MV 會有必定的數值，因此利用編碼器的 MV 信息能夠很好的判斷當前共享視頻的運動情況，選擇合適的幀率。

因爲編碼器是原本就在那裏的，因此不會增長額外的運動檢測模塊開銷。本改進就是針對這種需求，根據屏幕共享的內容，利用編碼器輸出的 MV 信息，自適應的調整幀率。對於共享文檔等不怎麼動的畫面，則放低幀率，對於共享電影動畫等，則調高幀率，以達到既不浪費帶寬，也能夠有流暢的視頻觀看體驗的目的。

「視頻雲技術」你最值得關注的音視頻技術公衆號，每週推送來自阿里雲一線的實踐技術文章，在這裏與音視頻領域一流工程師交流切磋。