Displayer content synchronisation
Displayer: The web-based content handling environment ran inside the browser or webview of our client applications (Android, Windows)
Displayer content loop playback synchronisation (hereafter briefly sync)
Introduction
In multi-display setups the ability to keep dynamic content playback synchronised is essential. The start time of a content loop playback depends on many factors on each screen, when did you turn the screen on, was it online when the content was updated, how fast is your network, when did it restart after an update etc, making it necessary to let the displayer know of timestamps when the start of a content is appropriate in time and identical with every screen in the system. In our current implementation the displayer can only keep one page rendered in one browser window at once. Because of technical limitations swapping pages can never be an instant 0 second task and depending on your hardware and content complexity the time required to render the next page can be very different on each screen, which over a large period of time can add up into a significant difference in the progress of the displayed content, therefore synchronising only start time of the contents is insufficient and unreliable.
The principle
The base of synchronisation is setting the local time of the screens as precisely as possible, and keeping it updated over long time. Assuming an accurate clock in the calculation we can define an exact time position in the loop as the quotient of the absolute time, and the full length of the content loop. For example, if you have a 1 hour long content, with 60 pages, each set for 1 minute duration, we know that each loop ends, and the content restarts exactly at the beginning of each hour. Let’s say current time is 1:37 PM 30 seconds, then the displayer should show the 38th page, swap to the 39th page 30 seconds later and so on.
Applicable elements
Content pages can have many widgets which can also contain material which repeats, these are: video, video gallery, weather, image gallery, carousel, contents widget (embedded sequence of contents), and repeating animation on any widget. Therefore we distinguish two groups of elements, contents and widgets.
Conditions
When the mentioned two groups overlap, synced contents contain widgets which can sync on their own, then only one of them should sync, because different loop lengths can cause contents to position differently from their defined order. For example you have a page containing an image gallery widget with 5 images, each image is having 5 seconds duration. If you use that page as a master page for another content, the page will not swap to another page at all, just statically display indefinitely, therefore the gallery inside should sync on it’s own to change it’s images exactly in every 5 seconds, regardless of when the whole content was started. If you put that page in a synced content loop, giving the page the exact 25 seconds to rotate through the whole gallery inside it, then if you would also allow the gallery to sync, it might jump to any of the images, and might display that image for less than 5 seconds, depending on the absolute time. Ideally though you probably want it to play from the first image you defined, for precisely 5 seconds each. As one exception, if the length of a page inside the loop is greater than 5 minutes, the sync of the widgets will not be prevented by the above rule. In the editor menu there is an option to enable sync for contents under the Page category, and for each applicable widget listed above, under their respective properties menu, which are turned off by default. When you open a preview from the editor in your browser, there are 3 options, only the third allowing sync. The other two opens an url which has the ‘&noSync=true’ part in it, that disables sync. The given content must contain a loop, which means any sequence of pages connected in a row, where the last page is connected to any of the pages previously displayed in that row. In a sequence stopping at a given point, there is no point in skipping pages which will not be displayed at all. Currently any page change that violates the defined order of pages in the loop, also disables the page sync, which can come from datasource, user interaction, or page jump set at the end of a video widget. When a page is started by schedule in the current content, the loop swaps are paused, and the sync becomes disabled, and will be re-enabled when the scheduled page(s) end. If any of the above conditions are not met, the sync will be disabled for the given element.
Implementation
When the sync is active, the loop of pages defined in playlist editor will be interpreted as an endless series of intervals, and any given point in time will be contained by exactly one of these intervals, determining which page should be running. When first loading a content, it always starts with the Default page, and it will keep the exact order defined, so synchronization is achieved through only modifying the duration of the pages. If the first page’s interval is significantly late behind the determined one, the displayer will not try fast-forwarding to it, it will rather wait for the next closest interval when the next page can start, increasing the current page’s duration. When this increase is more than 5 seconds, an icon is displayed in the bottom right corner.
Widgets also have a similar loop defined by the order in the list of slides created in the editor, but they are not limited to only changing the duration of their slides, they can skip slides if necessary, to show their determined slide as soon as possible.
The duration of the elements is synced at each time they are swapped, this way if any unexpected delay occurs from any source, like slow network, big file load times, or lag, it naturally gets corrected at each step.
There is a minimum time defined for each element type, if the calculated run time for a given element is smaller than the minimum time while syncing, that stage of the element will be skipped, and the next stage will be displayed, for a bit longer time than what was defined, as much longer as was calculated for the previous stage. The minimum time for pages is 3 seconds, for video gallery and contents widget it’s 1.8 seconds, for carousel it’s 0.6 seconds, for image gallery and weather widget it’s 2 seconds, for video and common widget animations it’s 1 second, and if the displayer detects a constant slow display where too much skipping occurs, it can increase the minimum time.
When video and video galleries have active sync, they will not only sync the start of their stages, they will also modify the progress of their displayed video every few seconds if it’s necessary, but only if a certain minimum threshold reached, currently 1 second, to avoid small corrections breaking the continuity of the video. If the calculated timestamp is before or after the interval allocated for the video, it will pause the video on the first or last of it’s frames, and play it only when the interval starts.
Page length modifications in displayer, regardless of sync setting
The absolute minimum duration for a page that can be set in the playlist editor is 3 seconds, which is the minimum duration the page is fully visible, without animations. If you add animations to your page swaps, they will not increase the runtime of your pages, the animations will be played during the time allocated for the given page, so depending on the animation type the duration while the pages are fully visible will somewhat decrease. The playlist editor doesn’t validate for cases where the duration of the page being fully visible would decrease below the minimum threshold, so in these cases the page duration is increased to achieve the minimum fully visible page duration is met. For example if you set a page to be 3 seconds long, and also set an animation with 1 second duration, the full page length will be increased to 5 seconds, where the animation will be played for 1 second, then the page displayed for 3 seconds, then the animation will be played for 1 second in reversed direction.