螢幕共享是視訊會議中使用頻率最高的功能之一，但在實際場景中使用者所處網路環境複雜，常遇到丟包或者擁塞的情況，所以如何優化弱網環境下的使用者體驗也成為了音視訊通訊中重要的一環。本文主要分享阿里雲 RTC QoS 如何通過若干編碼器相關優化提升弱網環境下的螢幕共享體驗。 作者：長程/田偉峰 審校：泰一 ## 內容說明： **本文介紹以下四個方面的優化：** * Screen Content Coding Tools * Long Term Reference (LTR) * Fast QP Rate Control * Content Adaptive Frame Rate **對本文中效果測試的說明：** 1. 為保證視訊質量，螢幕共享的 Codec 設定了最大 QP (Quantization Parameter)，在本文後面的測試中，這個最大 QP 對所有配置都是一樣的。 1. 為了更好的比較，效果測試中展示了流暢性和清晰度兩個維度的效果。 1. 對於流暢性的比較，由於視訊解析度太大，所以對其畫面進行了縮放，使得原始版本和改進版本可以放在同一個視野中播放，以很好的看到卡頓和延遲的改進。畫面模糊是由於上述原因降解析度所致，在清晰度的對比中可以看到原始解析度的畫面。 ## 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 資訊，自適應的調整幀率。對於共享文件等不怎麼動的畫面，則放低幀率，對於共享電影動畫等，則調高幀率，以達到既不浪費頻寬，也可以有流暢的視訊觀看體驗的目的。 > 「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流