屏幕共享系統的分析與設計

鄒航宇

0 引言

桌面共享系統是一種同步交流工具，廣泛應用于網上虛擬教室系統。在WEB2.0時代，通過瀏覽器的桌面共享系統，參與的用戶可以分享自己的桌面，從而達到資源共享的目的。在虛擬教室中，常常的情況為老師需要面對多個學生，網絡情況也極為復雜，因此對系統的性能與健壯性提出了更高的要求。本文就將論述桌面共享系統的實現架構以及性能的優化。

1 系統設計

1.1 部署

屏幕共享系統組件的配置架構，如圖1所示：

圖1 共享桌面組件架構圖

客戶端采用Adobe Flash Player，目前應用范圍最廣泛的豐富互聯網應用程序(RIA)。Flash Player通過實時消息協議(RTMP)，連接到開源流媒體服務器Red5所提供的應用服務。

RTMP協議是一個基于TCP的，在Flash player與服務器之間進行音視頻流媒體傳輸的專用協議，能夠保證鏈接的持久穩定，通訊的實時順暢。RTMP可以封裝MP3或AAC格式的音頻，以及FLV格式的視頻等流媒體，也可以通過AMF進行異步的服務器端遠程程序調用。其默認端口為1935。當1935端口無法連接時，Flash Player可以通過變種RTMP Tunneled隧道協議，將RTMP網絡包封裝在Http網絡包中，再通過80端口的Http服務器Nginx進行中轉。Nginx是著名的開源輕量級網頁服務器，相比Apache具有內存占用少，穩定性高，并發能力強的特點。

Red5是對應Adobe官方Flash Media Server的一款開源流媒體服務器，能夠提供多用戶音視頻流的優秀解決方案，適合不同規模的企業級應用。Red5由Java語言開發，建立在Jetty(servlet engine), Mina(network)基礎之上，并通過Spring框架整合起來[3]。

1.2 系統架構

桌面共享系統作為網絡虛擬教室系統的一個模塊，運行在瀏覽器中的adobe flash Player中。因此，整個系統分為客戶端部分與服務器端部分。客戶端部分負責抓取屏幕，將截屏圖像封裝為視頻，再將視頻轉化為兼容 Red 5服務器和Flash Player客戶端的編碼格式，發往服務器端。雖然Red 5與Flash支持包括 F4V、FLV在內的多種音視頻流格式，但考慮到Red 5的API僅支持FLV格式的視頻流錄制[16]，為了將來功能拓展的需求，FLV無疑是視頻流的最佳選擇。如果在這兩個階段中再次從外部引入第三方的編碼組件，顯然這樣會再次帶來額外的不可控因素，也不符合完全自有實現的預定目標。

幸運的是，Adobe官方提供的FLV視頻文件規范中，提供了一種簡單可行的實現思路。屏幕視頻比特流的幀編碼格式，如圖2所示：

Screen Video BitStream Format(svc1)是一種無損的Codec，因此這種編碼方式會成為系統的瓶頸之一[4]。

服務器端收取客戶端發來的視頻幀，暫存到flv臨時文件，供各客戶端通過RTMP協議進行連接、下載和播放。

1.2.1 源客戶端設計

要從系統客戶端，也就是Flash Player上啟動屏幕攝錄功能，一個最常用的辦法就是使用 Java Applet。利用 flex與JavaScript之間的通信，調用JavaScript函數，在JS中啟動applet。在Java.awt庫中的Robot類，正好也提供了API函數可以調用，即 createScreenCapture()方法，便捷地執行屏幕截取，返回 BufferedImage。接著將整個屏幕的BufferedImage通過GetRGB()方法轉換為AGRB像素格式的Int[]。Int[]中原本從左到右、從上到下的像素遍歷順序不符合屏幕視頻比特流的規范，必須轉變為從左到右、從下到上的順序，并隨之完成分塊過程生 Queue格式的塊隊列。隊列中的每個塊需要依次從各自ARGB像素數據中抽取出符合BGR像素順序的信息，交java.util.zip庫Deflater類，完成ZLIB格式的數據壓縮。最后使用固定端口與服務器端的Share Svc建立TCP連接后，依次傳輸隊列中轉碼后的塊數據。TCP正文的頭部只需簡單加上標示字符，以篩除無效數據包。

1.2.2 服務器端的設計

在服務端，FLVGen事先將flv的辨識頭信息以及為0的前項容量信息以字節流的方式寫入一個flv臨時文件，完成了流數據傳輸的準備工作。當接收端從 TCP正文還原出屏幕更新數據后，FrameGen將依照 flv格式要求，依次將flv類型（視頻明文為0x09）、時間戳、流標示符（恒為0）、實際荷載和總數據量寫入數據流，并暫存到flv臨時文件，供各客戶端通過RTMP協議進行連接、下載和播放。

2 系統優化

2.1 瓶頸分析

屏幕攝錄已經在在上一節中給出了基礎實現，然而其實際測試效果比較一般。Applet的截屏操作基于主講人的整個屏幕，生成的所有BufferedImage數據需要完整地進行轉碼、壓縮和傳輸，客戶端的運算負載和網絡帶寬需求相當可觀。特別是考慮到在以ADSL為主的當前國內網絡環境中，數據上傳的效率受到更多限制，上傳網絡包可能出現堆積，發送端不得不進行主動丟包，以保持視頻的實時性。當然，可以通過降低截屏的幀率，從源頭上控制數據量，但和主動丟包一樣，客戶端視頻的刷新率會降低，延時會增長，進而影響用戶體驗。

根據前文的敘述，客戶端的數據的上傳使用的是Screen Video Codec 1 Format。Screen Video Codec 1 Format是無損的壓縮方式，桌面數據經過壓縮以后達 2.0M，顯然我們系統的性能問題已經非常明顯，顯然對于實時系統，每幀的到達2.0M,這是不能接受的。

因此，系統性能的優化核心在于源數據的量，經過我的分析可以從以下三個方面降低源數據的量。

2.2 優化方式

2.2.1 關鍵幀技術

由于在實際的虛擬教室共享桌面系統中，桌面大部分時候為靜止狀態。如果源端不停的截屏并往服務器端上傳數據，會導致過多的無用數據，造成帶寬的浪費。在前文敘述的SVC中，屏幕視頻比特流（Screen Video BitStream）的每一幀被劃分為類似網格的一系列塊。塊的尺寸上限為長寬各 256個像素。塊的順序從左下角按行排列直至右上角，如圖 3所示：

圖3 塊的順序圖

通過塊的尺寸與整個圖像的尺寸，解碼器可以簡單計算出屏幕邊緣塊的實際尺寸，進行準確地像素繪制。像素信息在實際編碼和傳輸時，采用了ZLIB開源格式的壓縮。

當applet程序從客戶端每一次截取屏幕，則會被程序轉變為從左到右、從下到上的順序，并隨之完成分塊過程生成Queue格式的塊隊列。塊隊列里存的就是如圖3所示屏幕比特率的分塊數據。在大部分時間里，屏幕信息并不會發生變化，即時變化，也很有可能變化的只是整個屏幕中的一部分，也就是所有塊中的一部分。因此對Queue隊列中所存儲的每個小塊圖像計算一次哈希值，暫存在內存中。除首次截屏的第一幀之外，后續幀的在完成分塊后，將使用新計算出的哈希值與原哈希值進行比對。如果值相等，可以判定該圖像塊在兩幀之間沒有發生變化，不必對其執行后續的BGR抽取與ZLIB壓縮操作，并直接從隊列中刪除此塊。如果哈希值不匹配，則需要為變化的圖像執行原算法操作。上傳時相應的需要在 TCP正文頭部添加塊的編號信息，供服務端在接收后，恢復對應的局部圖像。最終FLVGen生成flv視頻時，也使用一個隊列緩存每個圖像塊轉碼壓縮后的數據。如果 TCP正文中缺少某塊的更新數據，則FLVGen判定此圖像塊沒有更新，使用緩存的前一幀中對應塊數據填充進FLV視頻流。反之如果包含某塊的更新數據，則需要在填充FLV視頻流的同時更新緩存隊列。

在這種設計下，客戶端必須多執行一次哈希計算，換取的收益是可能減少執行轉碼、壓縮和傳輸的數據量。如果屏幕共享的內容是畫面時刻變化的電影等，那么采用新設計的收益可能會非常有限，多執行的哈希計算甚至會使得客戶端性能出現下降。不過在日常應用中，屏幕共享的內容變化速率一般比較慢，演示時更多的是屏幕關注點的部分更新。因此采用優化設計可以有效地精簡冗余的數據處理與傳輸。

2.2.2 壓縮方式

前文提到，系統使用的是 adobe公司官方提供的 FLV視頻文件規范中Screen Video BitStream Format(svc1)編碼，而 SVC1編碼雖然簡單，但卻屬于無損壓縮方式。對于1440*900左右的分辨率，經過 SVC1的壓縮后，桌面數據大概達到2M。對于每一幀，盡管可以改變幀與幀的更新策略，但是原始桌面數據太大，當桌面信息頻繁發生變化時，數據量會陡然變大，從而導致系統性能急劇下降。因此，改變壓縮方式，減小源端每一幀的數據量，定能大幅提高系統性能。

Adobe官方提供了另外一種 codec，即 Screen Video Codec 2 Format(SVC2)。SVC2比SVC1在壓縮效率上有了很大的提升，SVC1只支持24Bit的RGB bitmap,而SVC2支持16bit RGB555和RGB565，SVC2采用了顏色表，顏色表是一個長度是128的顏色數組，Flash decoder里面有對應默認的顏色表，相比SVC1而言，SVC2只要求傳一個byte（8個bit）的index來代表一個顏色，顯然數據量減少了一半，而這些128長度的顏色表能夠表達大多數顏色，因此命中后的顏色，數據大小將減少一半。改變codec后，原本大概2M的數據量，可以減少為500KB左右，大大減小了桌面頻繁變化時數據量的傳輸[4]。

2.2.3 分辨率問題

分辨率問題是系統必須討論的。考慮這種情況，如果教師端的屏幕為 1440*900，而學生端的屏幕為 800*600,1024*768等不同的分辨率。在源端 applet截屏后，得到的截屏BufferedImage為1440*900的分辨率，如果就這也傳輸到學生端，在學生端1024*768的顯示器上，將不能完全顯示。也就是有一部分像素點浪費，同理在800*600的顯示器也會出現相同的情況。因此，在客戶端顯示器分辨率不統一的情況下，對源端上傳的BufferedImage做一定程度的壓縮不僅能減少數據量，并且能滿足不同客戶端的需求。對1024分辨率以上的屏幕，做一個縮略，縮減為800像素。這樣大多數情況下，數據量可以變為原來的0.6左右，大大減小了數據量。

2.3 性能分析

以分辨率為為1440*900的屏幕為例分析優化前與優化后性能的改善。Applet每 200ms對屏幕進行一次截圖，那每秒會得到5個1440*900的BufferedImage，經ZLIB壓縮后每個 BufferedImage為 3MB，則需要的傳輸速度為15MB/S。顯然現有的網絡條件不可能達到這樣的速度，這是不能接受的。

首先將SVC1的編碼格式改變為SVC2的編碼格式，構造一個大小為128的顏色數組。因此在編碼后的Image每個像素的大小從SVC1時候的4byte變為現在的1byte，意味著總的數據量變為 1/4，此時需要的傳輸速度驟減為3.75MB/S。根據更新策略，假設視頻教室中，PPT的翻頁速度平均為30秒一次(老師講課時時間遠遠不止)，則30秒內的最壞情況為頁面上每一塊都進行過更新，即每30秒需要傳 2次屏幕的所有像素約為 1.5MB，則平均每秒為51KB/S。再進一步經過圖像的縮小，使所有的幀轉化為800*600幀后，只需要31.25KB/S。對于這個上傳速度，正常情況下的網絡條件都能滿足，因此經過優化的桌面共享系統具有了一定可用性。

3 結論

基于RED5的WEB桌面共享系統，是WEB2.0時代典型的 RIA應用，在網絡教學中教師與學生的信息的交流與互動上具有優勢。系統應用 RTMP網絡通信協議，實現Screen Video Codec 2 Format(SVC2),部署 Red5，Nginx，Applet等服務組件，實現了一個用戶體驗良好，性能強大，健壯的Flash/Flex RIA程序，能很好地滿足網絡教學應用的實際需求。

[1]陳旭玲，劉蘇. 基于 JAVA的網絡教學電子白板的設計與實現[J]. 計算機技術與發展，2006.4(16): 167-169

[2]劉璐，董小國.Red5 Flash服務器研究. [J]網絡安全技術與應用，2009.6:78-79

[3]Adobe Systems Incorporated. SWF File Format Specification Version 10[S]. 2008