本文為 QoS 弱網優化系列的第二篇
作者｜安基程、田偉峰
審校｜ 泰一
視訊編碼中的變解析度問題及解決
變解析度在弱網場景的實際應用中非常常見，網路狀況不好的時候降低解析度可以降低位元速率，減少塊效應，網路好的時候增加解析度可以提升清晰度及主觀體驗。
目前主流的視訊編碼標準，比如 H.264、H.265，在編碼過程中如果要進行解析度切換，則必須要先編碼一個 I 幀，而 I 幀只能使用幀內預測，編碼效率低下。這在弱網變解析度的時候就容易造成卡頓。下圖中展示了每秒鐘切換解析度的位元速率波動效果，高低兩個解析度，每秒鐘切換一次。
上圖中橫座標表示編碼的幀數，縱座標表示每幀的大小，圖中最高的 4 個尖峰表示從低解析度切換到高解析度時編的 I 幀，在這 4 個尖峰中間的較低尖峰是從高解析度切換到低解析度編碼的 I 幀。可見編碼 I 幀帶來的位元速率波動還是非常明顯的，這在弱網下就很有可能造成如下圖所示的卡頓。
https://v.youku.com/v_show/id_XNTEzMTY3MzU5Ng==.html
視訊中左一的男士在伸手剛接到左三女士遞出的傳單之時進入弱網，切換解析度，產生了卡頓。
新一代的壓縮標準，如 VP9、AV1、VVC/H.266 等都支援在做幀間預測的時候當前幀和其參考幀使用不同的解析度，其基本思想是對參考幀做重取樣 (re-sampling) 以使得其和當前幀的解析度匹配，從而進行幀間預測，以實現解析度切換的時候不用編 I 幀的目的。
阿里雲 RTC codec 的變解析度編碼 (resolution change coding, 以下簡稱 RCC) 也使用和上述標準類似的基本思想，通過參考幀重取樣等手段使得之前已編碼的其他解析度的參考幀也能為當前幀所用，維持幀間的參考鏈不斷，充分利用幀間資訊冗餘提升壓縮效率，省去編碼效率低下的 I 幀。
Codec level 壓縮效能測試
本文對阿里雲 RTC codec 的 RCC 特性進行測試，使用 6 個視訊會議序列（背景不動，運動幅度較小），和 5 個運動程度較大的序列，高低兩個解析度，一秒鐘切換一次，只評價解析度切換幀的位元速率和視訊質量，因為對於後續的幀，使用 RCC 與否，編碼方式並沒有變化。
對於視訊會議序列，相同視訊質量下位元速率有 70% 節省，對於運動序列，相同視訊質量下位元速率有 58% 的節省，因為視訊內容越靜止不動，幀間編碼的比例越高，則 RCC 的優勢越明顯，所以視訊會議序列 RCC 的增益比運動序列要高，是合理的。
下圖展示了一個測試序列使用 RCC 後位元速率波動的變化，藍線表示的是未加 RCC 的位元速率波動，紅線表示的是加了 RCC 之後的位元速率波動，可以看到使用 RCC 後解析度切換處的編碼 I 幀位元速率尖峰明顯沒有了，位元速率更加平穩，而且視訊質量 PSNR 也有所提升。
藍線中解析度切換處的 I 幀平均位元速率為 840kbps, PSNR=33.5db, 39.7db, 40.6db for Y, U, V 三個分量；而紅線中解析度切換幀的平均位元速率為 360kbps, PSNR=36.3db, 40.9db, 42.0db for Y, U, V 三個分量。
即開了 RCC 之後，解析度切換時的 I 幀位元速率降低了近 60%，同時亮度的 PSNR 提升了近 3 個 db。
RTC level 效果
除了前述的單純 codec level 變解析度不編 I 幀帶來的一幀的壓縮效能提升之外，RCC 在和 LTR (Long Term Reference) 結合後會進一步降低弱網下頻繁請求 I 幀的可能性。
LTR 抗弱網的原理在上一篇分享《阿里雲 RTC QoS 螢幕共享弱網優化之若干編碼器相關優化》中已有所介紹，在此結合 RCC 會進一步提升其抗弱網效果，原理如下：
- 沒有 LTR 時，在弱網場景下如果丟包或卡頓無法恢復，則會請求 I 幀；
- 增加了 LTR 之後，則不會請求 I 幀，而是會請求 LTR 幀恢復，編碼效率提升很多；
- 如果是弱網下發生了解析度切換，沒有 RCC 的情況下，由於必須編碼 IDR 幀，所以 LTR 被清空，如果此 I 幀太大，導致接收端收不到，則其會再次請求 I 幀，陷入一個惡性迴圈中。
- 如果開了 RCC ，不僅解析度切換幀本幀不會編碼 I 幀，其他的參考幀管理也和之前一樣，LTR 也不會被清空，解析度切換幀本幀的大小比 I 幀減少了很多，接收端收不到的概率大大降低，即使收不到，也可以請求 LTR 恢復，而不是 I 幀恢復。
本文在 RTC level 模擬弱網場景，使其一秒鐘切換一次解析度，下面兩圖分別是未加 RCC 和 加了 RCC 之後的效果，可以看到未加 RCC 的畫面在解析度切換時會有明顯的卡頓以及編 I 幀造成的 flicker 效應，而加了 RCC 的則會很流暢，畫面也沒有 flicker 效應。
上圖是未加 RCC，一秒鐘切換一次解析度的效果，有多次明顯的小卡頓，且畫面有頻繁 I 幀造成的 flicker 效應。
上圖是加了 RCC，一秒鐘切換一次解析度的效果，整體比較流暢，感覺不到卡頓，視訊質量也比較平穩，沒有 flicker 效應。
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。