Last updated 12-28-2023
Video walls of a grid of displays involve the same technologies and design issues as Multi-seat. Instead of multiple workstations connected over the network to a server, video walls have a single administrator at the server but multiple virtual displays only being viewed and listened to remotely. Typically the playlist will repeat as various members of an audience are continually arriving and departing asynchronously.
.
The Raspberry Pi 4B is the only SBC that has two HDMI outputs. This makes it especially economical for digital signage. The board itself only costs $35 plus shipping in the 2GB memory size. Heatsinks or an aluminum case that acts as a heatsink will be needed as well as a power supply, micro HDMI to full size HDMI cables, and a microSD card for its OS. It is capable of simultaneously playing two independent commercial DVD movies on its separate two displays at 1920×1080 each. It also has separate HDMI audio and analog audio devices which can be assigned separately to two video streams.
Alternately, program content can be displayed at 3840 x 1080 spread across each two displays per Pi 4B. Content can also be rotated for 1080 x 3840, 2160 x 1920, or 1920 x 2160 per Pi 4B, or independently for each of its two displays. Pi 4Bs can be aggregated for video wall grids of more than 2 displays.
In addition to playing movies, it is possible to play a URL including Youtube, play a slideshow on one or more displays, or run apps for weather or web cams.
The Raspberry Pi 4B clients have graphic hardware support for H.264 video. By playing on the client instead of a server, network traffic is reduced to close to zero if the content is on the Pi 4B(s), and still greatly reduced if the content is on a cloud compared to playing on a server and forwarding pixels to each of the clients. For telling the clients what to play, another Pi 4B or even a smart phone would be sufficient.
The RaspiPlayer consists of an identical OS on a microSD card for each Pi 4B and of server software to remotely configure the Pi 4B clients for unique hostnames so that program content can be configured to target each specified display connected to specific Raspberry Pi4Bs. The configuration/control server communicates with the clients with a unix socket over ssh. MicroSD cards can be eliminated on player devices by using piserver to PXE boot them. Pisever in the distribution OS has not yet been updated to see the Pi 4B model, but its source has been updated and can be built for multiple architectures. https://raspiplayer.com/piserver/
If your business only needs one signage display, then you can use the other display for controlling the signage as well. For instance a food cart with one signage display to show menu and prices could use the rest of the same Pi 4B as a desktop computer that printed receipts and kept track of sales.
In the screenshot above, an x96max is being used to remotely control a Raspberry Pi 4B playing the two movies you see reporting their current AV: position. Although I did not have a 1920×1080 monitor for HDMI digital audio, if I did, one of the movies could have been configured to play its audio through HDMI cable making it independent of the other movie playing audio through its analog audio output. Both movies are being played using hardware H.264 decompression.
The bottom 70% of this screen is showing resource usage on the Raspberry Pi 4B client (not on the x96max that is the controlling what the clients are playing). All software required above is opensource and free, so the CLI version requires no license fees.
The tmux unix socket can be written to by tmux inside of php using shell_exec. Therefore, a php web server could provide a GUI like application to control the display of content on all screens.
Now screenshots of the two client displays playing these different movies
The video quality is indistinguishable from playing the same DVD films in a Blu-ray Disc Player. Clearly, video should be played on the client, not the media server. The Phistek ZE7000 network attached zero client requires at least a Intel i3 media server for one client 1920 x 1080 display. The x2go client approach is a little choppy even with an Intel i3 media server. Playing the content on the client eliminates the step of compressing changed pixels in the server video frame buffer and then decompressing them again at the client end. Network bandwidth is conserved because the original video content is compressed at a much higher ratio than is possible in real time for forwarding changes in a video frame buffer. There is hardware support for the best of the content compression schemes.
While in the examples above, the content was first read from two USB DVD drives on the server, to make two ISO files on a microSD card in a USB media reader for the x96max, you can use handbrake to create a more compressed MP4 file for just the main title and serve it from a web server on the x96 max to the raspberry pi 4B client and view it in a browser instead of in VLC.
If the video is played at the display, then its videos can be launched from a cell phone accessing a simple web page on the display controller. In this cell phone screenshot, touching one of the thumbnails launches the movie on the remote display. Additional buttons could be added to pause, resume, seek forward or back, and stop the currently playing movie. A central server is not needed to forward pixels to the remote display, so the network traffic is minimal and a cell phone suffices to control a wall of multiple displays.
If the gird of displays represents a single picture spread across the grid, then the content will need to have a mechanism to keep each display in synch if this is a video and not a still photo.
I will update this page when I have data on Pi 4B clients PXE booting (no microSD card) from a server running piserver, and providing a web server as well as eMMC storage under piserver for content to be controlled and displayed on the clients at the displays and connected only by network cable to the media server.