桌面分享編碼技術的演變

  桌面分享編碼技術的演變 

by 技術怪咖 湯軍

導讀：桌面分享從功能上應該怎么分？數據編碼的技術演變又是如何演變的？資深工程師湯軍結合自己多年的實操經驗，給出獨到見解

由于最近幾年的工作分別在“在線教育”和“視頻會議”領域，在這兩個領域對用戶而言最重要的功能除了語音就是桌面分享，恰巧這也是我所擅長的領域。

桌面分享從功能上可以拆分為屏幕抓取與數據編碼兩個大的方面。其中屏幕抓取，主要獲取數據源，在當前的機器的運算能下，該功能已不再是瓶頸，所以我們下面主要聊聊數據編碼的技術演變。

桌面分享功能脫胎于遠程桌面技術

最早的遠程桌面是基于命令行界面的模擬終端。此時并不涉及到抓屏與編碼，終端與遠端機器之間通訊的是shell命令，以及命令的執行結果，對機器的性能以及網絡代碼的需求很低。

隨著Win95系統上市并且成功引爆圖形界面操作系統市場，受限于當時機器的性能以及網絡帶寬，在相當長一段時間中都沒有出現針對圖形操作系統的遠程桌面工具。直到Windows2000上市，微軟在其中提供了遠程桌面組件，才第一次實現了基于圖形界面的遠程桌面。

早期的圖形界面的分辨率比較低（800*600），顏色數比較少（以16位色居多，24位真彩色很少見）。然而就算這樣，屏幕數據量（937KB）對于當時的寬帶網絡（ADSL撥號上網，上傳帶寬512kb~1Mb）也是個沉重的負擔，理論上以當時的網絡，傳遞一幀未壓縮的屏幕數據需要用時8~16秒，這顯然無法接受。為了能更快的將桌面圖形快速的通過網絡傳遞到終端，桌面數據的壓縮編碼就應運而生了。

桌面數據壓縮之初，主要被用來解決幀數據過大這個問題。所以首先被應用的就是當時很流行的圖片數據有損壓縮方法（JPG），該壓縮算法在圖片質量下降不是很明顯的情況下，壓縮后的圖片僅為原大小的10%。在使用了JPG壓縮算法后，對于觀看遠端靜態文檔暫時勉強夠用。

為了能進一步減少傳輸間隔，在沒辦法減少每一幀數據大小的情況下，我們問自己，每一次都傳輸完整的幀數據，就是是否必須？經過分析，我們發現桌面發生完全變化的概率很少，絕大部分都是局部變化，如：按鈕獲取焦點，某個控件數據獲得更新等。

（圖1）

在實際使用中發現，對于純文本展示（文本文件、PPT、靜態網頁等），使用JPG方法壓縮后字體的背景不是很干凈。放大圖片后發現文本顯示的邊緣與背景融合處使用了漸變色過渡。

而JPG壓縮會丟失這部分信息的細節。對于純文本展示（文本文件、PPT、靜態網頁等）的桌面數據觀察發現，大部分為少數顏色的文本加大面積單色的背景。對于這種類型數據恰巧可以使用基于調色盤的無損壓縮。我們又再次改進了之前的編碼策略。在已經判定塊需要編碼的情況下，再分析塊中使用的顏色數，依據顏色數的不同選擇不同的編碼方式。

隨著機器性能的持續提升，顯示器的分辨率越來越高，1080P全高清成為主流，4K屏也不鮮見，并且越來越多。用戶在使用PPT等展示數據時，復雜背景、植入的圖表（視頻），翻頁的動畫效果，全都越來越多。網絡帶寬雖然也有提升，但完全跟不上機器性能提升的速度。上述的編碼方案在桌面短時間發生劇烈改變時，產生了大量的爆發數據。

而按上述方案，后續數據的顯示又必須依賴前面數據的更新。由于爆發數據導致的數據積壓，使得桌面分享實時性越來越差。分析上述場景，我們發現在用戶切換PPT頁面的動畫播放期間，可能產生了5幀畫面，并且這5幀畫面的變化都比較大，如果一一進行編碼傳輸，會導致傳輸在短期出現一個峰值，超出了帶寬的承載能力。但是相對于頁面切換動畫，觀看者更期望能更快的看到下一頁的PPT。

為此，我們引入了延遲編碼的策略，當桌面兩幀數據之間的差異很大的時候，我們暫存待編碼的幀，等待下一幀數據，同時開始計時。下一幀數據獲取后，該幀和待編碼的幀之間的差異如果很大，用該幀代替待編碼幀，繼續等待；如果該差異比較小，丟棄待編碼的幀，編碼當前幀數據并發送到觀看端。

如果兩幀之間的差異一直很大，那么當計時器（500毫秒）超時后，編碼當前等待幀，并復位定時器。在全時云會議的開發項目中，我們設計并實現了上面的延遲編碼策略，顯著加快了復雜PPT頁面切換時的觀看延遲。

從2007年以來，視頻流媒體技術得到了長足的進步。從早期H261、H263到現在的H264，以及為了應對目前越來越普及的超高清（4k分辨率）視頻而出現的H265和VP9、VP10編碼。

而用戶對桌面共享的流暢性的期望越來越向視頻的流暢度靠攏，這使得我們不得不考慮，桌面數據的壓縮方式是否能使用視頻的壓縮方法。我們發現，桌面數據走視頻流的模式對于持續變化的桌面分享有顯著的削峰填谷效果。