C# 更好地压缩远程桌面广播应用程序
我正在创建一个 TCP 远程桌面广播应用程序。 （类似于 Team Viewer 或 VNC） 服务器应用程序
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。
有人可以建议我执行此操作的算法/程序吗？
I am in the process of creating a TCP remote desktop broadcasting application. (Something like Team Viewer or VNC)
the server application will
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.
i need to make this application possible to run on a connections with a 12KBps upload and 50KBps download DSL connection (client's and server).
so.. i have to reduce the size of the data/image i send per second.
i tried to reduce by doing the following.
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.
i was unsuccessful to send a JPEG frame and then each next time send the difference of the previously sent JPEG frame.
i tried using lzma compression (7zip SDK) for the when i was transmitting the difference of the Bitmap.
But i was unsuccessful to reduce the data into 12KBps. the maximum i was able to achieve was around 50KBps.
Can someone advice me an algorithm/procedure for doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您想要做的就是执行图像压缩格式的操作，但是以自定义方式（仅发送更改，而不是一遍又一遍地发送整个图像）。这是我要做的，分两个阶段（第 1 阶段：完成，证明它有效，第 2 阶段：优化）
概念证明阶段
1) 以位图格式捕获屏幕图像
2 ) 将图像分成连续字节块。您需要尝试找出最佳的块大小是多少；它将根据上行链路/下行链路速度而变化。
3）为每个块获取一个短散列（crc32，也许是md5，也可以尝试一下）
4）压缩（不要忘记这样做！）并传输每个更改的块（如果散列更改，则该块更改并且需要待转移）。在接收端将图像拼接在一起以显示它。
5) 使用UDP数据包进行数据传输。
优化阶段
您可以采取以下措施来优化速度：
1) 收集统计数据和硬代码传输速度与帧大小和哈希方法的比较，以实现最佳传输速度
2) 为 #1 建立一个自我调整机制
3) 正如我在上面第一阶段的#2 中所解释的那样，图像在方形区域中压缩得比连续字节块中压缩得更好。改变你的算法，这样你就可以得到一个视觉上的正方形区域，而不是连续的线条块。这种平方方法就是图像和视频压缩人员的做法。
4）尝试压缩算法。这将为您提供很多可供使用的变量（CPU 负载 vs 互联网访问速度 vs 压缩算法选择 vs 屏幕更新频率）
这基本上是（粗略地）压缩视频流工作原理的总结（您可以看到与您的任务的相似之处）如果你考虑一下），所以这不是一个未经证实的概念。
HTH
编辑：您还可以尝试一件事：捕获屏幕位图后，减少其中的颜色数量。例如，如果从 32 位颜色深度变为 16 位，则可以节省一半的图像大小。
What you want to do is do what image compression formats do, but in a custom way (Send only the changes, not the whole image over and over). Here is what I would do, in two phases (phase 1: get it done, prove it works, phase 2: optimize)
Proof of concept phase
1) Capture an image of the screen in bitmap format
2) Section the image into blocks of contiguous bytes. You need to play around to find out what the optimal block size is; it will vary by uplink/downlink speed.
3) Get a short hash (crc32, maybe md5, experiment with this as well) for each block
4) Compress (don't forget to do this!) and transfer each changed block (If the hash changed, the block changed and needs to be transferred). Stitch the image together at the receiving end to display it.
5) Use UDP packets for data transfer.
Optimization phase
These are things you can do to optimize for speed:
1) Gather stats and hard code transfer speed vs frame size and hash method for optimal transfer speed
2) Make a self-adjusting mechanism for #1
3) Images compress better in square areas rather then contiguous blocks of bytes, as I explained in #2 of the first phase above. Change your algorithm so you are getting a visual square area rather than sequential blocks of lines. This square method is how the image and video compression people do it.
4) Play around with the compression algorithm. This will give you lots of variables to play with (CPU load vs internet access speed vs compression algorithm choice vs frequency of screen updates)
This is basically a summary of how (roughly) compressed video streaming works (you can see the similarities with your task if you think about it), so it's not an unproven concept.
HTH
EDIT: One more thing you can experiment with: After you capture a bitmap of the screen, reduce the number of colors in it. You can save half the image size if you go from 32 bit color depth to 16 bit, for example.