This wiki topic details the Xibo projects intended approach to developing a cross platform (windows/ubuntu) Xibo player for release in the 1.9 series of Xibo.
Overview
The Windows Player, discontinued Ubuntu Player and various previous attempts at a cross platform player all suffer with various problems arising from the technology stack used to implement them. The new player development will aim to work around these issues by separating concerns so that the CMS communication and rendering of content is separated. This will allow for more flexibility rendering content on specific platforms and not rely so heavily on one technology stack.
The player will be developed for release with 1.9 series, but be backwards compatible in a legacy mode with 1.8 and 1.7. This means support for XMDS versions 4 and 5.
The player should also include new features for automatically updating to the latest version (provided by the CMS) and for synchronised display playback (will require CMS changes).
Background reading on community suggestions.
Direction
The player will consist of 4 components:
- Conductor
- Player Host
- Player
- Privileged Background Service
The conductor will be responsible for communicating with the CMS to download configuration, schedule and resources, and saving those to the local player library. It will be responsible for starting a player host which will run the player and will be responsible for providing the player with a queue of instructions representing the content to render. Depending on configuration, the conductor may be sending instructions to multiple players.
The suggestion is that the Player will be hosted in a windowless browser opened by the conductor (“the player host”) and interpreting a queue of instructions for rendering. The same player can also be hosted in the CMS layout preview, receiving instructions from the CMS rather than the Conductor.
The privileged background service will be responsible for executing commands provided by the CMS and updating the Conductor.
Goals
- Cross Platform (Windows, Ubuntu)
- Replacement of Current Windows Player
- Full support for 1.8 functionality (including push messaging - XMR)
- Full support for 1.8 modules
- Support for Windows only modules (PPT files, embed Silverlight)
- Screensaver support on Windows
- Auto-update
- Playback synchronisation across displays
- Provide better rendering in the CMS Preview
Known limitations
There are several known limitations to the approach related to media rendering.
- Video Codec Support: The
<video>element which will be used by the player has limited codec support at present. H264/webm and the time of writing. Browser plugins may be able to extend this support but only when the Player Host is Internet Explorer as plugins are not avaialble in Chrome and will be discontinued end of 2016 in firefox. Browser extensions may be able to plug this limitation. Conductor side transcoding may also offer a solution. - Multicast video streams are not supported by any browser
- Native Opening of webpages will no longer be possible as the entire player canvas will be browser based. Pages will be opened in
<iframe>'s, however some sites prevent framing. These sites would have worked previously and now will not.
These limitations may be mitigated by browser advancements or by providing a different player component - but critically they will not require the entire stack to be rewritten.
Technical Details
The technology stack is not 100% finalised and may change as development challenges are encountered.
Conductor
The conductor can be considered the core component as it is responsible for marshalling the other components. It will be written in nodejs and run in a headless state. It will communicate with XMDS over SOAP, it will have a ZMQ subscription to XMR and a message queue interface to communicate with players. The default implementation for the Player message queue will be Socket.IO, but this should be designed as a configurable drop in interface script such that an alternative queue can be provided.
It will also be responsible for starting the player host and ensuring it remains stable.
The conductor will also communicate with the back-end service for privileged command execution and application auto-updates.
The conductor will run an embedded web server to provide content from the local library to the Player.
Player Host
A default implementation of the player host will be a platform/configuration specific headless browser window which has the sole responsibility of hosting the Player component. It will be started and managed by the Conductor.
It should be possible to design an alternative player host so that a dedicated application can be written to run a Player.
Player
The player application will be a HTML5 application which is served into the Browser Host by the Conductor. It will bind to the Conductor using Socket.IO as instructed by the Conductor and render content onto its canvas according to the instructions it receives.
The application logic will be embedded into the Conductor which will serve a base html file and resources that make up the Player.
The Conductor which serves the Player may be different from the Conductor which provides the instructions, depending on synchronised playback configuration.
Privileged background service
The background service is a headless nodejs application which runs as a service. It is responsible for making sure the conductor is running correctly, running shell commands and running auto-update.
Architecture overview
The following diagram shows the relationship between the components.
The ZMQ part of this diagram should be interpreted as “Player Message Queue” and current intentions are to use Socket.IO.
Player Message Queue
The player message queue will be JSON formatted and contain all necessary information for the Player to render the media.
The queue should be bi-directional so that the Player can inform the conductor of various events.
Each message will follow the same base format of json data with an event name and data key.
{
"event": "name",
"data": {
"key": "value"
}
}
The data key will have key/value entries specific to the type of event.
Conductor to Player
- reconfigure
- add
- remove
- clearCanvas
- preLoad
- setWidgetData
- executeJavaScript
Player to Conductor
- log
- signalFinished
Roadmap
The new player development will begin once 1.8.0 has been released. A release timeline is not yet provided.
