Screen sharing is an important collaboration feature. As a screencast, it is used to capture and archive screen contents for educational and training purposes. Real time screen sharing is widely used for remote logging, debugging and screen sharing. Some of the popular screen sharing applications include VNC (and variants such as Apple Remote Desktop), Microsoft Remote Desktop, Google Chrome Desktop and Cisco WebEx.
Historically, real time screen sharing systems were designed to operate over constrained networks. This design choice does not lend itself to scenarios in which such bottlenecks are irrelevant. DisplayCast targets intranet scenarios in which the wired/wireless networks and computation resources are abundant. We envision a collaboration scenario in which many users share their screens with many other users in an intranet setting.
We describe two deployment scenarios to motivate the need for DisplayCast:
- Group collaboration in a corporate setting Meeting rooms are replete with projectors and large monitors. In FXPAL, we can project a 3840x1200 image using two projectors. Meetings frequently start with one presenter showing their ideas to the team. In the illustration,Emily presents her spreadsheet. Others respond by projecting contents from their own personal devices (e.g., Sam projects powerpoint slides from his laptop). Physical proximity is not always possible; some team members monitor the conversation from their own offices. For example, Dan watches some of these presentations while simultaneously performing other tasks. Others (such as Olivia) may briefly leave the meeting to take a phone call (with her bluetooth headset) while continuing to watch the presentations on her smart phone. Some presentations originate in the cloud; all these presentations may also be archived to the cloud.
- Lecture capture in academia Powerpoint slides have become an integral component of lectures. In our vision, physical proximity is not mandatory; students join in remotely (say from the dormitory) to watch the lectures. Traditionally, students sought clarification using the in-class blackboards. In the future, they will illustrate and project them from their personal devices. Archiving all these interactions would also be invaluable for lecture review.
Our primary design goal is to faithfully reproduce the screen contents.
- Users are not required to reconfigure their systems (e.g., lower screen resolution) in order to make them suitable for screen sharing.
- Users can use any application and expect good performance.
DisplayCast system currently includes three components: Streamer, Player and Archiver.
Streamer
The streamer is the source component. It can either share the entire screen or a portion (using a configuration MASK region). It interacts with users using a task-bar interface (a windowed interface can be compiled using appropriate compile time flags).Player
The player is the real time receiver. The created windows can be dragger around using the GUI. It can also be remotely controlled.Archiver
This component captures a stream into a H.264 movie.
Usage
Mac OSX
Both the Streamer and the Player use a task bar based interface (a window based interface is also available and requires a recompilation). Further information on getting a pre-build binary as well building from source are available here.
Windows 7
Both the Streamer and the Player use a task bar based interface (a window based interface is also available and requires a recompilation). More information is available here
Technical Info
Screen capture
On Mac OSX, we used the CGRegisterScreenRefreshCallback() call to receive asynchronous notifications regarding screen updates. On Windows 7, we used the DemoForge mirror driver to collect pixmap updates. This driver implements the Windows mirroring function. We poll the driver every 16 msec to collect stored updates. We then memory mapped the mirror driver's framebuffer copy to access the pixels that correspond to each pixmap update.
Bitmap transformation for better Zlib compression
Zlib does not incorporate any inter-update redundancy. We incorporate them by first transforming each update pixmap. We separated pixmaps into a similarity byte-map and pixel data. We use 0x00 and 0xFF to represent similar and dissimilar pixels in the byte-map, respectively. The pixel data is a sparse array that stores the 24 bit RGB values of dissimilar pixels.
Naming
We use Apple Bonjour for naming the various components. Each component chooses a 8 character GUID to identify itself. It also provides a user friendly (and configurable) name that is displayed to the user to identify each component. By default, we use Bonjour local name resolution (within the .local domain) using link-local multicast. DisplayCast can be recompiled to use wide-area DNS.
Location management
Like many intranet applications, DisplayCast could benefit from fine grain location information. For example, an user walking into a conference room might want to project their laptop to the projector (without explicitly choosing from the many Players available to her). Streamers currently use Bluetooth to locate nearby Players. All Players disclose their Bluetooth ID through Bonjour. The Streamers search for nearby Bluetooth devices. Once found, they match the observed Bluetooth ID with the Bonjour advertised Players to identify nearby Players. More accurate location management is an active area of research
Frequently Asked Questions
- Is DisplayCast secure?
Currently, DisplayCast does not provide any authorization mechanism; any Player/Archiver within the same intranet can watch any active Streamer. The streams are unencrypted over the wire. However, DisplayCast does not surreptitiously leak any information. We do not log or monitor any communication (nor provide means for doing do). - Does DisplayCast support sharing keyboard/mouse clicks/interactions?
The released version does not support interactions. - Should I use DisplayCast over cellular 3G networks?
DisplayCast was designed for intranet networks (at least IEEE 802.11n). However, we suspect that its performance will be better than with VNC (especially because of the bitmap compression). On the other hand, DisplayCast aggressively sends updates. RFB (the VNC distribution protocol) requires that the server can only send updates on a prior request from a client. - How easy would it be to port DisplayCast Streamer to Linux?
Even though DisplayCast is available in Mac OSX and Windows 7, the capture mechanisms in each of these operatings systems is completely different. We suspect that porting to FreeBSD and Linux would require substantial effort on the capture side. X windows (used in Linux and FreeBSD) is network based. Unlike Max OSX and Windows, X applications are likely to be optimized; they will pre-render their screen on an internal pixmap and then send the final output to the screen. Thus, the screen dynamics could be completely different from OSX and Win7. On the other hand, our compression mechanism might be directly applicable in X. - How easy would it be to port DisplayCast Streamer to Android
Should be relatively straightforward. Use one of the VNC implementations as a starting point. You'd have to root the device to access the display subsystem. - How easy would it be to port DisplayCast Streamer to iOS
Unless Apple allows the Streamer to run in the background, while you perform other useful tasks, porting Streamer to iOS is meaningless. - How easy would it be to port DisplayCast Player to Linux/Android/HTML5/...? This should be straight forward. The player needs to run Zeroconf (both to advertise itself as well as locate Streamers), use TCP to receive bitmap compressed pixmaps, uncompress using Zlib and then display the bitmap. Most modern operating systems support all this functionality. Implementing DisplayCast Player as a HTML5 player should be straightforward as well (except for the Zeroconf advertisement component)
- How easy would it be to port DisplayCast Archiver to Windows 7 Hardware assisted H.264 compression is required to achieve good performance. Intel Media SDK 2012 appears promising though you carefully choose your hardware to achieve good performance.