Menu
▾
▴
Home
pySignage
What?
A digital signage project. Digital signage primarily involves the use of large, flat-panel, monitors hung in the common areas of various institutions. Typically a video distribution network is configured to broadcast video output from a client computer, or individual client computers are connected to each monitor. In either case, layout and content is configured from a master, or server, system while the client endpoints receive the layout and the streamed content and display it on the monitor on onto the video distribution network.
Why?
The major limitation of this model is the client endpoints themselves. The endpoints must understand the content being streamed to them as well as having the horsepower and support to render the content and display it properly. This can be challenging when trying to use "thin" clients or open source components for rendering the content. For example, Microsoft PowerPoint is often used to create digital signage-type content, but open source systems have no effective way of opening or rendering this file type. In addition, may non--profits are desperate to scrape together any type of computing infrastructure available to them to power their monitors. Unfortunately, these client endpoints just don't have the power to render the amount of content being sent their way.
How?
Our answer is to allow the server to do all the layout and rendering and use the RFB protocol to stream the video to the client endpoints. The RFB protocol is very effective and providing the high-quality video needed in this digital signage application and is also very low in the amount of compute resources necessary to display the video. Leaving the content management, decoding, and rendering to the server drives down the client endpoint requirements to the bare minimum, free better resources to be used elsewhere in the environment. Furthermore, the server can be better equipped to processes all sorts of content...with little regard to the operating environments of the client endpoints. All that is necessary there is an RFB client.
However, this project is not without challenges. The RFB protocol is not natively geared to handle anything other than image/graphical content. Video and audio poses challenges that may need to be handled through extensions of the RFB protocol. Also current RFB servers rely on capturing the active display of a running server. Our project strives to do rendering to a framebuffer that may or may not actually be rendered to a screen.
Now What?
I hope this brief overview at least peaks your interest and you are interested on contributing or, at the least, seeing how things progress. We look forward to getting something out there for you to play with as quickly as possible.
