屏幕共享系統(tǒng)的分析與設(shè)計

鄒航宇

0 引言

桌面共享系統(tǒng)是一種同步交流工具，廣泛應(yīng)用于網(wǎng)上虛擬教室系統(tǒng)。在WEB2.0時代，通過瀏覽器的桌面共享系統(tǒng)，參與的用戶可以分享自己的桌面，從而達(dá)到資源共享的目的。在虛擬教室中，常常的情況為老師需要面對多個學(xué)生，網(wǎng)絡(luò)情況也極為復(fù)雜，因此對系統(tǒng)的性能與健壯性提出了更高的要求。本文就將論述桌面共享系統(tǒng)的實(shí)現(xiàn)架構(gòu)以及性能的優(yōu)化。

1 系統(tǒng)設(shè)計

1.1 部署

屏幕共享系統(tǒng)組件的配置架構(gòu)，如圖1所示：

圖1 共享桌面組件架構(gòu)圖

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

RTMP協(xié)議是一個基于TCP的，在Flash player與服務(wù)器之間進(jìn)行音視頻流媒體傳輸?shù)膶Ｓ脜f(xié)議，能夠保證鏈接的持久穩(wěn)定，通訊的實(shí)時順暢。RTMP可以封裝MP3或AAC格式的音頻，以及FLV格式的視頻等流媒體，也可以通過AMF進(jìn)行異步的服務(wù)器端遠(yuǎn)程程序調(diào)用。其默認(rèn)端口為1935。當(dāng)1935端口無法連接時，F(xiàn)lash Player可以通過變種RTMP Tunneled隧道協(xié)議，將RTMP網(wǎng)絡(luò)包封裝在Http網(wǎng)絡(luò)包中，再通過80端口的Http服務(wù)器Nginx進(jìn)行中轉(zhuǎn)。Nginx是著名的開源輕量級網(wǎng)頁服務(wù)器，相比Apache具有內(nèi)存占用少，穩(wěn)定性高，并發(fā)能力強(qiáng)的特點(diǎn)。

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

1.2 系統(tǒng)架構(gòu)

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

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

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

服務(wù)器端收取客戶端發(fā)來的視頻幀，暫存到flv臨時文件，供各客戶端通過RTMP協(xié)議進(jìn)行連接、下載和播放。

1.2.1 源客戶端設(shè)計

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

1.2.2 服務(wù)器端的設(shè)計

在服務(wù)端，F(xiàn)LVGen事先將flv的辨識頭信息以及為0的前項容量信息以字節(jié)流的方式寫入一個flv臨時文件，完成了流數(shù)據(jù)傳輸?shù)臏?zhǔn)備工作。當(dāng)接收端從 TCP正文還原出屏幕更新數(shù)據(jù)后，F(xiàn)rameGen將依照 flv格式要求，依次將flv類型（視頻明文為0x09）、時間戳、流標(biāo)示符（恒為0）、實(shí)際荷載和總數(shù)據(jù)量寫入數(shù)據(jù)流，并暫存到flv臨時文件，供各客戶端通過RTMP協(xié)議進(jìn)行連接、下載和播放。

2 系統(tǒng)優(yōu)化

2.1 瓶頸分析

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

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

因此，系統(tǒng)性能的優(yōu)化核心在于源數(shù)據(jù)的量，經(jīng)過我的分析可以從以下三個方面降低源數(shù)據(jù)的量。

2.2 優(yōu)化方式

2.2.1 關(guān)鍵幀技術(shù)

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

圖3 塊的順序圖

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

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

在這種設(shè)計下，客戶端必須多執(zhí)行一次哈希計算，換取的收益是可能減少執(zhí)行轉(zhuǎn)碼、壓縮和傳輸?shù)臄?shù)據(jù)量。如果屏幕共享的內(nèi)容是畫面時刻變化的電影等，那么采用新設(shè)計的收益可能會非常有限，多執(zhí)行的哈希計算甚至?xí)沟每蛻舳诵阅艹霈F(xiàn)下降。不過在日常應(yīng)用中，屏幕共享的內(nèi)容變化速率一般比較慢，演示時更多的是屏幕關(guān)注點(diǎn)的部分更新。因此采用優(yōu)化設(shè)計可以有效地精簡冗余的數(shù)據(jù)處理與傳輸。

2.2.2 壓縮方式

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

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

2.2.3 分辨率問題

分辨率問題是系統(tǒng)必須討論的?？紤]這種情況，如果教師端的屏幕為 1440*900，而學(xué)生端的屏幕為 800*600,1024*768等不同的分辨率。在源端 applet截屏后，得到的截屏BufferedImage為1440*900的分辨率，如果就這也傳輸?shù)綄W(xué)生端，在學(xué)生端1024*768的顯示器上，將不能完全顯示。也就是有一部分像素點(diǎn)浪費(fèi)，同理在800*600的顯示器也會出現(xiàn)相同的情況。因此，在客戶端顯示器分辨率不統(tǒng)一的情況下，對源端上傳的BufferedImage做一定程度的壓縮不僅能減少數(shù)據(jù)量，并且能滿足不同客戶端的需求。對1024分辨率以上的屏幕，做一個縮略，縮減為800像素。這樣大多數(shù)情況下，數(shù)據(jù)量可以變?yōu)樵瓉淼?.6左右，大大減小了數(shù)據(jù)量。

2.3 性能分析

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

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

3 結(jié)論

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

[1]陳旭玲，劉蘇. 基于 JAVA的網(wǎng)絡(luò)教學(xué)電子白板的設(shè)計與實(shí)現(xiàn)[J]. 計算機(jī)技術(shù)與發(fā)展，2006.4(16): 167-169

[2]劉璐，董小國.Red5 Flash服務(wù)器研究. [J]網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2009.6:78-79

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