桌面分享編碼技術的演變

By 技術怪咖 湯軍

導讀：桌面分享從功能上應該怎麼分？數據編碼的技術演變又是如何演變的？資深工程師湯軍結合本身多年的實操經驗給出獨到看法。

因爲最近兩份工做分別在「在線教育」和「視頻會議」領域，在這兩個領域對用戶而言最重要的功能除了語音就是桌面分享，恰巧這也是我所擅長的領域。桌面分享從功能上能夠拆分爲屏幕抓取與數據編碼兩個大的方面。其中屏幕抓取，主要獲取數據源，在當前的機器的運算能下，該功能已再也不是瓶頸，因此咱們下面主要聊聊數據編碼的技術演變。

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

桌面分享功能脫胎於遠程桌面技術。最先的遠程桌面是基於命令行界面的模擬終端。此時並不涉及到抓屏與編碼，終端與遠端機器之間通信的是shell命令，以及命令的執行結果，對機器的性能以及網絡代碼的需求很低。隨着Win95系統上市而且成功引爆圖形界面操做系統市場，受限於當時機器的性能以及網絡帶寬，在至關長一段時間中都沒有出現針對圖形操做系統的遠程桌面工具。直到Windows2000上市，微軟在其中提供了遠程桌面組件，才第一次實現了基於圖形界面的遠程桌面。

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

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

爲了能進一步減小傳輸間隔，在沒辦法減小每一幀數據大小的狀況下，咱們問本身，每一次都傳輸完整的幀數據，就是是否必須？通過分析，咱們發現桌面發生徹底變化的機率不多，絕大部分都是局部變化，如：按鈕獲取焦點，某個控件數據得到更新等。

針對「痛點」，研究解決問題

爲此咱們設計了分塊編碼的策略：首先將整個桌面數據分塊(見下圖)，而後每個分塊在編碼前先與上一幀對應的分塊進行比較，僅當數據發生了變化時，才使用JPG算法壓縮。每次只傳輸發生變化的分塊的數據，接收端老是在上次展現的幀數據上作修改。如此，在不下降第一幀數據延遲的狀況下，大大減小了其餘幀數據的延遲。

在實際使用中發現，對於純文本展現（文本文件、PPT、靜態網頁等），使用JPG方法壓縮後字體的背景不是很乾淨。放大圖片後發現文本顯示的邊緣與背景融合處使用了漸變色過渡。而JPG壓縮會丟失這部分信息的細節。對於純文本展現（文本文件、PPT、靜態網頁等）的桌面數據觀察發現，大部分爲少數顏色的文本加大面積單色的背景。對於這種類型數據恰巧可使用基於調色盤的無損壓縮。咱們又再次改進了以前的編碼策略。在已經斷定塊須要編碼的狀況下，再分析塊中使用的顏色數，依據顏色數的不一樣選擇不一樣的編碼方式。

隨着機器性能的持續提高，顯示器的分辨率愈來愈高，1080P全高清成爲主流，4K屏也不鮮見，而且愈來愈多。用戶在使用PPT等展現數據時，複雜背景、植入的圖表（視頻），翻頁的動畫效果，全都愈來愈多。網絡帶寬雖然也有提高，但徹底跟不上機器性能提高的速度。上述的編碼方案在桌面短期發生劇烈改變時，產生了大量的爆發數據。而按上述方案，後續數據的顯示又必須依賴前面數據的更新。因爲爆發數據致使的數據積壓，使得桌面分享實時性愈來愈差。分析上述場景，咱們發如今用戶切換PPT頁面的動畫播放期間，可能產生了5幀畫面，而且這5幀畫面的變化都比較大，若是一一進行編碼傳輸，會致使傳輸在短時間出現一個峯值，超出了帶寬的承載能力。可是相對於頁面切換動畫，觀看者更指望能更快的看到下一頁的PPT。爲此，咱們引入了延遲編碼的策略，當桌面兩幀數據之間的差別很大的時候，咱們暫存待編碼的幀，等待下一幀數據，同時開始計時。下一幀數據獲取後，該幀和待編碼的幀之間的差別若是很大，用該幀代替待編碼幀，繼續等待；若是該差別比較小，丟棄待編碼的幀，編碼當前幀數據併發送到觀看端。若是兩幀之間的差別一直很大，那麼當計時器（500毫秒）超時後，編碼當前等待幀，並復位定時器。在全時雲會議的開發項目中，咱們設計並實現了上面的延遲編碼策略，顯著加快了複雜PPT頁面切換時的觀看延遲。

新時代新技術對咱們來講是雙刃劍

從2007年以來，視頻流媒體技術獲得了長足的進步。從早期H26一、H263到如今的H264，以及爲了應對目前愈來愈普及的超高清（4k分辨率）視頻而出現的H265和VP九、VP10編碼。

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

視頻編碼在應對持續變化的時候，能夠經過短時間（毫秒級）下降畫面質量的辦法來控制爆發數據波峯，等到畫面變化中止的瞬間馬上將畫面質量提高上來。咱們有理由相信，視頻流媒體的編碼方式是桌面共享支持高清、超高清畫面的「銀彈」。

以上的技術探索歷程，實際上耗費了至關的時間精力，並且是個持續改進的過程，由於產品和技術的迭代自己就不是件一勞永逸的事。僅筆者所在的團隊，5我的，7年多以來一直在「發現問題-認證分析-改進-發現問題」的循環中，並且預計之後也是這樣，不在改進，就在改進的路上，可是從各類反饋看來，效果的確不錯。前幾年有一次客戶環境下測試，全時雲會議就比另外一個國外大牌效果要好不少，比另外一個產品早了幾分鐘接通對方並且會議效果很不錯，不枉咱們的努力心血，固然這也是純自主研發的技術好處，直接把國外技術拿來用，在國內這種網絡條件下，基本能夠確定要水土不服。