基于Windows圖形驅(qū)動的屏幕截圖技術(shù)

龐赫

【摘要】 計算機(jī)屏幕圖像的截取在屏幕錄制、計算機(jī)遠(yuǎn)程控制以及多媒體教學(xué)軟件中都是關(guān)鍵術(shù)。研究的重點(diǎn)集中在如何快速有效的截取DIB（Device-Independent Bitmap）格式的屏幕圖形數(shù)據(jù)。本文采用一種高性能屏幕截取技術(shù)，實現(xiàn)了基于Windows圖形驅(qū)動截圖的遠(yuǎn)程控制系統(tǒng)。

【關(guān)鍵詞】 屏幕錄制 遠(yuǎn)程控制 屏幕截取

一、遠(yuǎn)程控制系統(tǒng)的系統(tǒng)設(shè)計

1.1 系統(tǒng)分析

在視頻會議系統(tǒng)中，共享桌面的客戶端，獲取本地屏幕或者其中特定窗口以及固定區(qū)域的圖像變化數(shù)據(jù)，編碼壓縮，傳輸?shù)椒?wù)器端，由服務(wù)器端將該數(shù)據(jù)分發(fā)到個個接收端。接收端解碼圖像數(shù)據(jù)，即可觀看到共享桌面。圖像的數(shù)據(jù)量很大，為了達(dá)到發(fā)送獲取壓縮，接收解壓播放的高性能，該部分的編碼采用非托管實現(xiàn)。整個視頻會議系統(tǒng)是.NET平臺下，所以該部分代碼采用組件開發(fā)模型[1]，方便系統(tǒng)的調(diào)用也符合軟件開發(fā)的N層構(gòu)架的要求[2]。

1.2系統(tǒng)結(jié)構(gòu)設(shè)計

圖1 客戶端與服務(wù)器的C/S構(gòu)架模型

在C/S模式構(gòu)架的程序中，客戶端的所有交互都是通過服務(wù)器的中轉(zhuǎn)完成。共享桌面的客戶端在開啟共享之后。桌面的圖像數(shù)據(jù)經(jīng)過編碼壓縮會發(fā)送到服務(wù)器端，經(jīng)過服務(wù)器的分發(fā)，圖像數(shù)據(jù)會被分發(fā)到N-1個客戶端，這就要求服務(wù)器有足夠的上行和下行帶寬。客戶端接收到屏幕圖像數(shù)據(jù)，經(jīng)過解碼解壓播放圖像數(shù)據(jù)，根據(jù)實際的網(wǎng)絡(luò)狀況可能會有不同程度的延時。共享桌面的客戶端（一般為教師機(jī)器），可以指定一個控制端，開啟遠(yuǎn)程控制。被授權(quán)的客戶端會把包括鼠標(biāo)坐標(biāo)，鼠標(biāo)鍵的點(diǎn)擊彈起，鍵盤按鍵的點(diǎn)擊和彈起消息進(jìn)行封裝，經(jīng)服務(wù)器傳送到共享桌面的客戶端。該客戶端接收到遠(yuǎn)程控制信息，模擬本地的輸入操作，達(dá)到遠(yuǎn)程控制的效果，構(gòu)架模型如圖1所示。

圖2 共享桌面客戶端發(fā)送屏幕圖像數(shù)據(jù)

所有客戶端在程序啟動的時候，啟動MirrorDriver，MirrorDriver會把屏幕的鏡像位圖數(shù)據(jù)和屏幕變化記錄填充到緩沖區(qū)內(nèi)，如果共享桌面的客戶端開啟共享。為了程序的執(zhí)行效率，以多線程的形式啟動桌面數(shù)據(jù)壓縮線程（在主程序運(yùn)行之外的另外一個線程）。圖像編碼的過程是比較消耗CPU資源的，但是高效率的編碼可以很大程度上節(jié)省網(wǎng)絡(luò)資源，所以編碼線程在另外一個線程中執(zhí)行，可以保障主程序的流暢運(yùn)行。編碼的過程中需要兩個緩沖區(qū)，輸入緩沖和輸出緩沖區(qū)。MSScreen的DMO壓縮需要手動填充輸入緩沖區(qū)。從屏幕鏡像緩沖區(qū)中取出圖像數(shù)據(jù)，把輸入緩沖區(qū)的地址指針給DMO，編碼后的數(shù)據(jù)會被填充到輸出緩沖區(qū)內(nèi)，并返回輸出數(shù)據(jù)的字節(jié)大小，這個過程是自動完成的。編碼正確完成之后，從輸出緩沖區(qū)取出數(shù)據(jù)，遞交給網(wǎng)絡(luò)線程就可以發(fā)送了。發(fā)送的過程和主程序的其他數(shù)據(jù)發(fā)送模式一致，所以屏幕共享模塊可以很容易的集成到主項目中，而不需要單獨(dú)的發(fā)送和接收，如圖2所示。其他客戶端（一般是學(xué)生機(jī)器客戶端），接收到教室機(jī)器的共享屏幕數(shù)據(jù)之后。數(shù)據(jù)從網(wǎng)絡(luò)線程接收，同樣是多線程的處理方式。解碼的過程類似與編碼的逆過程。輸入緩沖區(qū)存放接收到的數(shù)據(jù)。輸出緩沖區(qū)存放的是圖像數(shù)據(jù)。因為視頻的壓縮需要關(guān)鍵幀，如果客戶端剛好接收到的第一幀不是關(guān)鍵幀，解壓出來的位圖為全黑色，直到接收到關(guān)鍵幀之后可以正確解碼出圖像，如圖3所示。

二、遠(yuǎn)程控制系統(tǒng)的系統(tǒng)實現(xiàn)

2.1獲取屏幕最小變化部分

在處理屏幕發(fā)送當(dāng)中，第一次請求或在以后需要發(fā)送整屏數(shù)據(jù)（例如：監(jiān)視區(qū)域發(fā)生變化，或在一次發(fā)送周期中的變化數(shù)據(jù)總和大于整屏數(shù)據(jù)量或客戶終端主動請求發(fā)送整屏數(shù)據(jù)的情況）。為了處理上述情況，使用兩個臨時數(shù)據(jù)full_rgn、incr_rgn。如遇到上述情況，例如第一次連接時，程序在處理過程中使變量！full_rgn.IsEmpty（）返回值>0。所以發(fā)送之前只要檢查m_full_rgn既可，如果遇到需要發(fā)送全屏的情況，incr_rgn.Clear（）（在此周期中的更新數(shù)據(jù)區(qū)域清空）。驅(qū)動返回的更新記錄是即時的，沒有必要即時發(fā)送數(shù)據(jù)。因為系統(tǒng)資源的占用消耗，捕捉到更新區(qū)域既可，遠(yuǎn)程沒有必要即時發(fā)送。其次就是數(shù)據(jù)量的原因，對于遠(yuǎn)程發(fā)送，較少的數(shù)據(jù)量可以有效的節(jié)省網(wǎng)絡(luò)帶寬資源。

圖4 屏幕變化部分 圖5 屏幕變化部分

如圖4所示，兩次連續(xù)的變化（在極短時間周期內(nèi)，即在一次獲取變化數(shù)據(jù)周期內(nèi)），兩次更新的區(qū)域有重疊，而這種情況在屏幕變化時是經(jīng)常發(fā)生的。而驅(qū)動只會記錄下變化的區(qū)域而已。如果適當(dāng)?shù)牟捎脙?yōu)化算法，不僅可以有效的減小冗余數(shù)據(jù)，而且可以降低對資源的消耗。在實際應(yīng)用過程當(dāng)中是非常實用的。如果采用相應(yīng)的算法，就不會出現(xiàn)一個周期內(nèi)的變化數(shù)據(jù)總和大于整屏幕數(shù)據(jù)，如圖5所示。

對第一種的解釋是驅(qū)動的在共享數(shù)據(jù)中的標(biāo)識，標(biāo)識該區(qū)域是在屏幕內(nèi)是移動的，由上一區(qū)域和當(dāng)前區(qū)域可以計算出位移向量（例如窗口的拖動，該標(biāo)記由驅(qū)動完成，應(yīng)用程序只負(fù)責(zé)處理該情況）。為了節(jié)省數(shù)據(jù)發(fā)送量可以假定只發(fā)送更新矩形，和源矩形的左上坐標(biāo)。把該消息發(fā)送客戶端，由客戶端完成虛擬屏幕的拖動，只需要完成數(shù)據(jù)內(nèi)部的拷貝。這樣可以節(jié)省大量數(shù)據(jù)的發(fā)送，（因為變化的數(shù)據(jù)只是在已有數(shù)據(jù)中位置的變化）。但是存在一種特殊情況，位移的矩形很小的時候，程序中假定的大小是矩形的長寬都小于一個16（int），如果矩形很小，還是采用上述方法相對來講效率不會比不考慮其特殊性高，甚至效率更低。

2.2屏幕圖像多線程壓縮及解壓實現(xiàn)

如圖6所示，在程序啟動之后，進(jìn)行資源的初始化。如果允許共享，初始化桌面壓縮線程。壓縮和發(fā)送數(shù)據(jù)都是多線程的，不是在同一個線程，但是線程同步的，數(shù)據(jù)委托給網(wǎng)絡(luò)線程發(fā)送。每執(zhí)行一個周期，將事件狀態(tài)設(shè)置為非終止?fàn)顟B(tài)，導(dǎo)致線程阻止。當(dāng)定時器達(dá)到下一次周期時，將事件狀態(tài)設(shè)置為終止?fàn)顟B(tài)，允許等待線程繼續(xù)。

圖6多線程壓縮桌面圖像

三、結(jié)束語

圖像數(shù)據(jù)的傳輸，難點(diǎn)在于數(shù)據(jù)量的大小。網(wǎng)絡(luò)數(shù)據(jù)量的大小直接關(guān)系到軟件的性能和質(zhì)量，在程序設(shè)計之初，擬采用JPEG圖片靜態(tài)壓縮算法，雖然在一定程度上減低了數(shù)據(jù)量，但是并不能達(dá)到高效。因為屏幕的圖像區(qū)別與其他位圖圖像，所以采用專門的屏幕壓縮算法可以更有效減小數(shù)據(jù)量。程序在后續(xù)的改進(jìn)中，采用微軟的Screen壓縮算法，在5 frame/s 網(wǎng)絡(luò)數(shù)據(jù)量可以降低到15 k/s，并確保圖像質(zhì)量清晰，在網(wǎng)絡(luò)狀況不是很好的時候也可以保證程序的流暢運(yùn)行。高效的壓縮算法對CPU的使用也是比較高的，多線程的處理數(shù)據(jù)的壓縮，可以保證程序流暢運(yùn)行。

參 考 文 獻(xiàn)

[1] Ted Faison. Visual C#基于組件的開發(fā). 北京：清華大學(xué)出版社.2003，4

[2] Robert C.Martin，Micah Martin.敏捷軟件開發(fā)：原則、模式與實踐（C#版）. 北京：人民郵電出版社. 2008，1