Keen to see more development in a nice subtle fade transition if possible.
I second this! Would love to see something like Axel-B's fader included in the master branch. And how about some pre-fetching for the next image in the playlist? Would that be easy/possible?
I have a ~40MBits/sec wired broadband connection here but there's still a noticeable delay as each images loads for the first time and sometimes the delay is long enough that the next image gets displayed before the first has finished cashing.
pre-fetching the next asset is more or less done on my player-browser-fader branch.
It fetches the next asset while the current one is being shown, so,
the current asset must be displayed long enough (for the next one to load), or else it all may still not look nice.
That branch also does fading -- whether it is nice is not for me to say (but I am more or less happy with it).
The fading works via an overlay that 'covers' the screen during a transition (the overlay cannot be present at the same time as the video player).
This overlay is controlled from the viewer program. Between two subsequent image/webpage assets it provides a fade-out, fade-in effect. From image/webpage to video it only fades-out the image/webpage, and for the opposite, it only fades-in the image/webpage.
It should be possible to implement other effects than fading.
I did change quite some code in the viewer to get this working, though.
I now use two uzbl (web-browser) instances, such that while one displays an image or webpage, the other can already load the next page/image (this works via a class Browser that 'wraps' around uzbl).
(I no longer use the uzbl Browser to provide a black background for video, but set that background up when the viewer starts, via 'xsetroot -solid black').
Also, I added a wrapper (class Player) around omxplayer (inspired by pyomxplayer.py). The wrapper can start omxplayer in paused mode (without being visible on the screen) -- such that omxplayer can be started in advance (in paused mode), and then on command 'almost instantly' becomes visible and starts playing the movie.
To make use of this, I introduced an Asset base class. Each Asset has three methods that are used for display: prepare(), start() and wait(). There are subclasses BrowserAsset and PlayerAsset, for webpage/image resp. video, that do the right thing using a Brower resp. Player instance.
BrowserAsset.prepare() loads a webpage/image in the 'free' Browser instance;
BrowserAsset.start() makes the currently invisible Browser instance visible (via fade-in);
BrowserAsset.wait() waits until the BrowserAsset has been shown for its given duration, then fade-out to black (when next asset is video), or white (when next asset is webpage).
(my webpages have a white background, so the white fade-color matches them; the black fade-color matches the black background used for videos).
PlayerAsset.prepare() loads a video in a new Player instance, and associates it with the PlayerAsset;
PlayerAsset.start() (removes the overlay and) 'un-pauses' the Player;
PlayerAsset.wait() waits until the Player has finished display of the video (and then instantly creates a black overlay -- user doesn't see difference between black background and black overlay).
So, after using start() for the 'current' asset,
my viewer gets the next asset (this includes testing that a remote web-page asset is available), and invokes its prepare(),
and then invokes wait() on the 'current' asset.
And then it loops (where the 'next' asset becomes the 'current' asset).
Because I have one web-page that takes a looong time to load (15-20sec) I have been thinking of dedicating a separate uzbl Browser instance to it -- it could be nice to be able to configure per asset whether it needs its own viewer (Browser instance), but that would involve changes to the playlist format.
I have started adding some 'high-level' documentation about my branches at a wiki page at github (https://github.com/axel-b/screenly-ose/wiki
On my own screenly-controlled screen I'm currently running a mix of those branches: the viewer from player-browser-fader; the server from (a modified version, that includes ldap support, of) branch https-auth-with-submodule -- it may be that the viewer still needs tiny timing tweaks to make it look even nicer.