2010-11-04 119 views
3

我正在創建一個TCP遠程桌面廣播應用程序。 (喜歡的東西團隊瀏覽器或VNC) 服務器應用程序將C#更好的壓縮遠程桌面廣播應用程序

1. run on a PC listening for multiple clients on one Thread 
2. and on another thread it will record the desktop every second 
3. and it will broadcast the desktop for each connected client. 

我需要這個應用程序可以在一個12Kbps的上傳和下載50KBps DSL連接(客戶端和服務器)的一個連接運行。

所以..我必須減少每秒發送的數據/圖像的大小。

我試圖通過下列方法減少。

I. first i send a Bitmap frame of the desktop and each other time i send only the difference of the previously sent frame. 

II. the second way i tried was, each time i send a JPEG frame. 

我不成功發送一個JPEG幀,然後每個下一次發送以前發送的JPEG幀的差異。

我嘗試使用lzma壓縮(7zip SDK)的時候,我發送的位圖的區別。

但我沒有成功將數據減少到12KBps。我能夠達到的最大值約爲50KBps。

有人可以給我一個這樣做的算法/程序嗎?

+0

請嘗試這一個http://cstheory.stackexchange.com/ – 2010-11-04 15:35:04

+0

即時通訊有點困惑什麼是這個問題在cstheory.stackexchange.com適當的標記集。 – 2010-11-04 15:49:20

+0

當天回來的時候,Laplink會以某種方式直接傳輸UI對象,如菜單和對話框,而不是發送它們的圖像。我不知道他們是如何做到這一點的,或者如果現在用這樣的圖形程序這樣做是有道理的,但對於超低帶寬,這可能是一種選擇。真的,不要重新發明輪子。 UltraVNC有很多優點可以將帶寬降低到無,包括顯示驅動程序(Vista和更高版本所必需的)和屏幕捕捉選項。 – Brad 2010-11-04 16:18:49

回答

8

你想要做的是做什麼圖像壓縮格式,但以自定義的方式(只發送更改,而不是整個圖像反覆)。這裏是我會做什麼,在兩個階段(第1階段:完成它,證明它的工作原理,第2階段:優化)

概念證明階段

1)的捕獲屏幕的圖像中位圖格式

2)將圖像分割成連續字節塊。你需要四處尋找最佳塊大小是什麼;它將根據上行/下行速度而變化。

3)獲取短哈希(CRC32,也許MD5,實驗與本以及)每個塊

4)壓縮(不要忘了這樣做!)和轉移的每個改變塊(如果散列已更改,塊已更改並需要傳輸)。在接收端拼接圖像以顯示它。

5)使用UDP數據包進行數據傳輸。

優化相

這些都是可以做,以優化速度:

1)收集的統計信息和硬編碼的傳輸速度VS幀大小和散列法以獲得最佳的傳輸速度

2)爲#1製作自我調整機制

3)正如我在第一個#2中所解釋的那樣,圖像在方形區域中壓縮得更好,而不是連續的字節塊階段以上。改變你的算法,讓你得到一個可視的方形區域,而不是連續的線條塊。這種方形方法就是人們如何進行圖像和視頻壓縮。

4)玩弄壓縮算法。這會給你很多變數(CPU負載vs網絡訪問速度vs壓縮算法選擇vs屏幕更新頻率)

這基本上是(大致)壓縮視頻流工作原理的總結(你可以看到如果你仔細想想,它與你的任務有相似之處),所以它不是一個未經證實的概念。

HTH

編輯:您捕獲屏幕的位圖後,減少它的顏色數:一個你可以嘗試更多的東西。例如,如果您從32位顏色深度到16位,則可以保存圖像大小的一半。

+0

我有幾個問題在階段 1,項目3 - 我從來沒有使用散列,你能解釋我應該如何使用它。 和在階段1,第4項 - 你說我必須使用UDP。你看到的優勢是什麼。 在階段2,第1項 - 你說使用散列法來獲得最佳傳輸速度。我該怎麼做.. – 2010-11-04 16:04:48

+0

對那些人有很多解釋......在某些時候,研究基本理論會更好;但是在這裏,散列是一個校驗和,就像一個彙總數字。它基本上允許你獲取大量數據(在這種情況下是像素和它們的顏色),並基於它生成一個數字(稱爲哈希)。如果數字發生變化,則底層數據會發生變化。因此,您可以比較少量數據(散列值),以確定大數據是否更改(數據塊)。至於UDP與TCP,這是因爲速度。閱讀以下更多信息:http://www.gutgames.com/post/TCPIP-vs-UDP.aspx – 2010-11-04 16:16:36