Cross Platform Player Specification

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.



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.


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.


  • 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.


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.


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


The new player development will begin once 1.8.0 has been released. A release timeline is not yet provided.


Hi Dan,

I am not an expert programmer but have you had a look at I believe it might be easy to make cross platform app and keep the versions updated. It uses javascript,html5 and css.


Thanks for your comment - we may well look at electron for the “Player Host and Player” parts of the application - we’ve dug into it a little bit so far, but we’re still deciding for certain :slight_smile:

thanks for the update Dan. So we can soon expect xibo to be back in action on linux :slight_smile: .

Hi, Dan! What problem with “the current player with CEF” suggestion? IMHO, it’s best solution, it requires minimum developers time. And current code was tested by clients. Why so radical changes with another technologies?

The current technology stack we use isn’t and can’t be cross platform and doesn’t support some of the more advanced things Xibo can do (such as overlaying regions).

The CEF bindings move far too quickly for us to keep up with and therefore we are constantly fighting to keep up - they also don’t play very nicely with the stack we use and the way we need to use them.

The plans outlined above insulate us from the problem and bring cross-platform operation as part of the bargain.


Just a comment as i just read about a new framework (well maybe old but new for me !) i may use for future multimedia cross platform projects.

Haxe portable toolkit :

and the Kha framework based on it :

I already seen projects using it and meet people building interactive installations from it.
possibilities seems impressive and performances are great

Thanks for the great Xibo project by the way

Thanks to let us know what you are into !
Thanks for xibo, awesome job :wink:

hello Dan,

any update on this topic.


When we have something to announce, we will make an announcement regarding the Player applications. Work is underway however.

1 Like

I am a new user in the xibo.
Thank you for your all work. I installed XIBO CSM windows and ubuntu.
I look forward to Xibo Cross Platform Player with all eyes.

Have you considered building upon OpenSplash and if not, what are the reasons?


How many times have you been in a public place like an airport and seen a great big ol’ Windows nag screen over the digital signage?

Yea, doesn’t look good does it. Now, what if that was Xibo, I bet that has happened? I know because it sure is happening in my environment.

Now that version 1.8.1 is out and it seems to be solid so far, I am looking forward to the promised update on a Linux player. I feel this is the number one feature that would really improve the value of Xibo, IMO.

Here where I am using it, I am pestered to no end by windows updates that render Xibo not just useless; but the product makes us look silly when there are windows nags on our otherwise professional signage. I cannot control Windows, its under central IT control, so I have no ability to tame these nags. I do have more control over Linux in that I can schedule updates in a more predictable way, so this would be a solution to the windows nag. Linux might also allow us to use thinner (read cheaper) clients (maybe even Raspberry Pi?) and really help us extend our physical reach with Xibo beyond what we are doing right now.

I really don’t care about sophisticated overlays or interactivity, I really just want the basic functionality to be rock solid.

I know that Unix clients are targeted for 1.9; my hope is that this is made the highest (at least really high) priority because it provides basic functionality that is necessary for Xibo to be viable in my environment. From the sounds of it, others are having the same problems and would like to see this update soon. Maybe it can even be done before 1.9 drops, assuming it doesn’t need changes to the CMS?


For Xibo to move into the Corporate area it has to support Windows both CMS and Player.

Currently with a bit of work the CMS runs on Windows as does the player.

Linux would be a great addition but Linux as with Android comes with lack of support in the corporate world.

Many enterprises use RedHat and at a stretch CentOS. Ubuntu is great but is making limited headway in the Corporate area.

The reason for RedHat and Windows is one of Support. You can raise support calls in minutes with Microsoft and RedHat.

This is the reason you see Digital Signage in Airports etc. running on Windows. Those airports have support from Microsoft. Many corporations buy support which entitles them to not only raise support calls but also receive onsite visits to address issues.

Xibo must continue to support Windows and Linux for the reasons outlined.

The reason corporations will adopt Xibo is because the CMS can be set-up internally on supported platforms and the player is available on at least one supported platform.

It’s the reason many companies won’t use the other free digital signing offerings because they host the CMS themselves.

We do agree with you and it is a priority for the project, however writing a stable player under any operating system is a huge effort and is therefore a labour of time. There can and will be other advancements in the CMS and our current player offerings while this cross platform player development continues unaffected.

In the interests of balance it should be noted that Windows is a suitable platform for digital signage, provided it can be tweaked and controlled to be made suitable. Running Windows configured as a desktop environment (by central I.T for example) will lead to nags. A lot of that can be solved with more control over the O/S (admittedly not all of it).

We’re unlikely to ever recommend a player on RPi - based on their current hardware to date - there are numerous discussions detailing why (we did try it, we’re not just being dismissive).

While this is being developed, you could consider Android as a stop-gap, or even permanent solution. Android is likely to remain the lowest total cost of ownership even after the release of a cross platform player, which will likely require more powerful hardware. However, support for the operating system is harder to obtain, but that may not be an issue in your environment.

@smunir Thank you for your reply - I agree with your sentiments regarding support in corporate environment. Xibo is used extensively in the corporate world due to it running on on-premise, supportable hardware/software and this wont change.

Off topic, but Docker EE (enterprise edition) is available on RHEL (and Docker CE is available on CentOS). So the CMS host stack is supportable in the corporate environment. The containers themselves are “black boxes” and therefore should hopefully be permissible.