Screen Transfer [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I need to develop a program that transfers a users screen and sound to another user over internet. The scenario can be visualized like this:

There is a teacher in front of his computer and writes some code on his computer (ex:visual studio). He has a microphone. There is two students watching teacher's screen and listening his voice from their own computers.

There are a few alternatives to get screen capture of a user and transfer it like ffmpeg, aforge or self coded screen capture program by c# (over udp). Tried all alternatives.

However, the problem is all of them are so slow, or creates bad resolution of video. There should be an alternative way, because some programs reaches a high quality. For example teamviewer, windows remote desktop, logmein can send the screen with a high quality. More over, teamviewer can send sound also.

Where should I begin to overcome this mission? Which platform, language, protocol is useful?

Answer 1

I know it sounds simple enough, but screen/desktop sharing is actually a very complex collection of topics. Not for the faint of heart :P

Of course there are already many applications built specifically for doing this kind of thing, including BigBlueButton which was designed with academic organizations in mind.

Are you sure you want to reinvent the wheel?

If so...

There are two basic methods used to do screen sharing, one simple and slow the other complex and much more difficult to implement.

Frame Buffer Copy

Capture images of the screen and send them to the client(s). This can be very bandwidth intensive as you have already discovered, not to mention the fact that the output can be quite jumpy.

This is the method used by VNC and various other applications. A lot of work has been done on VNC to speed up the process by identifying changes in the image and only sending those areas that have changed, with various compression methods used by different incarnations of VNC to compress the delta images.

There is a C# implementation of VNC that you could use for the video portion of your app.

One limitation of VNC and it's RFB (Remote Frame Buffer) protocol is that it is graphics only. RFB is extensible however, and at least one application (QEMU) has added audio streams to the protocol. I'd suggest using your own audio extension rather than trying to implement the QEMU one though... it doesn't do compression, for instance, so the audio stream will take a significant amount of bandwidth to transport.

Advantages: Easy to implement.

Disadvantages: High latency, high bandwidth.

High-Level Command Streams

Rather than simply transferring screen images (although they usually do that too), some of the more advanced protocols send streams of drawing commands to the client, which does the rendering locally.

This is where RDP, X11 and some of the other protocols really shine. Instead of reacting to changes in the image being displayed, the commands that produce those changes are forwarded to the client.

This one is much harder to do and requires a deep understanding of the way that Windows handles drawing to the screen. Sadly I know of no shortcuts for this method. It'd be nice if there was some way to get an RDP stream for the current desktop and send that, but so far this is not possible.

Advantages: Low-medium latency, reduced bandwidth.

Disadvantages: Hard to implement, requires extensive knowledge of internal workings of operating system.

---

Unless you can locate code for using the built-in RDP stack to achieve your goal, your best option is probably to work on a VNC-style system with a custom extension to the RFB protocol to add an audio channel.