Video Wall Video Wall

AlmereGrid has created a 4-screen linear Video Wall.

The first version of the video wall is in the Desktop Grid demo corner at the Almere Big Data Value Center. A lot of events are organised in the centre related to Big Data and distributed computing. The focus of this centre is on using the technology, hence there are many workshops meetings, etc. for SMEs. For the centre, such a demo corner adds liveliness and a sense of technology. It makes abstract topics like distributed computing and Big Data more visible.

The goal of the video wall is twofold:

  1. Continuously displaying videos with Desktop Grid information
  2. Explaining distributed computing technology

The videos provide an advertisement of crowd computing Desktop Grids. We choose videos that are visually attractive, even when the sound is turned down.

For the technology we opted for inexpensive screens powered by Raspberry Pi computers. The inexpensive screens make the video wall very affordable. They have the drawback that there are relatively big black edges between the screens. This makes it necessary to carefully check and position the video on the screens, otherwise important features like faces are invisible.

The Raspberry PI is an inexpensive credit card size computer developed by the University of Cambridge. It can run a full Linux (Debian) operating system and power a HD monitor. It is designed for educational purposes, but also very suitable for demonstration goals.

Video wall hardware

The video wall consists of 4 screens which are placed vertically. This gives an impression of a cinema widescreen. On the photograph the video of Render Farm is shown where Big Buck Bunny explains crowd computing rendering. Each screen is called a "tile" so we have a 4-tile video wall. Each screen is powered by a single Raspberry Pi. A fifth Raspberry Pi acts as the master that holds the video archive. A Raspberry Pi (slave) that powers a screen has three connections:

  1. a HDMI cable connects it to the screen
  2. a network cable connecting it to a network switch
  3. a micro-USB cable that is only used as power cable to power the Raspberry Pi.

The only role of the slave Raspberry Pi is to receive a video stream and display (part of) it on the screen through the HDMI cable. One on the Pis has an additional audio cable that takes sound to some audio speakers. When the audio is taken from a slave Pi and not from the master the synchronisation problem is considerably reduced. The Raspberry Pi (master) that holds the video archive is not connected to a screen. So it has only the network cable and micro-USB cable connected. In our case we added a USB flash drive that holds the video archive. The software automatically reads videos from the USB drive. So replacing the drive with another one with different videos allows to display a different set of videos.

In addition to the four slave Pis that power the screens and the master Pi that holds the video archive we have two other components:

  1.  a USB hub. All the Pi power cables are connected to this hub. It is only used to power the Pis. No information is transferred to it.
  2.  an 8 port Ethernet switch connecting all the Pis.

The Ethernet switch connects the slave Pis with the master Pi. It allows the master Pi to broadcast videos to the slaves. We create a separate isolated network that is not connected to the Internet. This makes configuration easier and prevents your videos from flooding a larger network. Of course we could have saved a few euros by buying a 5 port switch. But this set-up allows to connect another computer, like your laptop, for maintenance purposes (remember it is on an isolated network so some configuration on your laptop is needed.)

We used plexiglass to mount the Pis on. They are in the same order as the screens to ease explanation. The plexiglass secures and screens the Pis which are delicate while providing maximal flexibility for demonstration purposes. (We like to pull out a plug during demos to show how the data flows.)

Figure 1: The 4-tile video wall

To hold the screens we put together an aluminium frame. Aluminium material is inexpensive and can easily be handled. For our linear set-up it further has the advantage that it is rigid. This makes aligning the screens easy. One difficulty we encountered is that the screens we used had an on/off switch. So we had to take care they could even be handled if the screens are used vertically. We also covered the screen vendor's logo with black tape so it does not distract from the video content played.

Video wall software

The Raspberry Pis were loaded with the standard operating system which is a full Linux Debian distribution. As the basic video wall software we installed pwomxplayer, an adapted version of the standard Pi media player omxplayer. Pwomxplayer takes a video stream as input and displays part of it on the attached screen. By choosing the right part to display the complete video can be displayed on combined screens. Pwomxplayer also allows to define the so-called Bezel corrections: the corrections for the black edges around the screen.

The Pi Wall pwomxplayer site also gives explanations on how to use the software.

On the master we installed avconv as media player/broadcaster. (On other computers also other media players like ffmpeg or VLC could be used). With the avconv media broadcaster on the master Pi and the pwomxplayer media player installed on the slave Pis we need to configure the network. The network interface on each Pi is changed using standard Linux tools. Each Pi gets its own fixed IP number (Internet Protocol address). And they are told to belong to a specific network. If you want to connect your laptop to the same network you also have to add/change the network connection there. Notice we use fixed IP addresses. Most of the networks you connect to dynamically provide an IP address to your computer. So this is different. Please note we do not use WiFi but a cabled network. With a WiFi network we would have to add a WiFi USB connector to each Pi, and a WiFi router. This would have added to the costs. But more important wireless connections would add delay to the videos that could be different for each Pi making the screens to run out of sync with each other. Having our own private network allows for low level video broadcasting that automatically synchronises the screens. The network is only used for transmitting the video file and nothing else. The slave Pis are only displaying the video on the screen and do not do anything else. (So we should not have a BOINC client or other crowd computing programme running on the Pis when using the video wall. This would also need some additional complex network configuration.)

The video is broadcasted by avconv over the network by a technique called UDP Broadcast. It is a broadcast so each slave can listen to the broadcast and pick up the complete video. This can be compared to a standard tv broadcast, where each tv-set also gets the complete tv broadcast. It is a very efficient technique for getting large amounts of (video) data across. On the slave pwomxplayer listens to the broadcast and displays a part of the video.

At this point we could start the pwomxplayer on each of the four screen Pis. So starting the four tiles of the video wall. Then we could start avconv on the master to start sending the video which will then be displayed on the four tiles. After that we could start another video.

However we also automated this process in such a way that, when a USB stick with videos is installed on the master and the video wall is powered up, automatically the videos on the USB stick are being played.

To this end we installed and adapted some additional Linux scripts on the video wall tile slave Pis computers: 1. a script to start the pwomxplayer and automatically rotate the video to portrait orientation 2. a daemon script that starts the pwomxplayer automatically 3. update the s-called init.d so that the daemon script starts when the computer starts

On the master Pi we installed an init script that automatically loops over the videos in the USB stick.

Future additions

We intend to add some further additions to the video wall software. Some ideas include:

  1. Software shutdown and reboot. Probably by adding a button on the GPIO interface of the Master Pi.
  2. Possibility to send different streams to each Pi. (to show what is happening on different systems in the Grid)
  3. Rewrite scripts to Python programmes so they can be better maintained. 4. Create automatic installers.

References

Raspberry Pi main site: http://www.raspberrypi.org/

Piwall Video Wall software: http://piwall.co.uk/

Scripts Scripts

Scripts

First have a look at the installation instructions at http://piwall.co.uk/information/installation We need to install several scripts as root, because we want to start them as daemon.

/root/.piwall (on each tile)

# wall definition for 4x1 screens with bezel compensation
[4bez_wall]
width=1224
height=480
x=0
y=0

# corresponding tile definitions
[4bez_1]
wall=4bez_wall
width=270
height=480
x=0
y=0

[4bez_2]
wall=4bez_wall
width=270
height=480
x=315
y=0

[4bez_3]
wall=4bez_wall
width=270
height=480
x=630
y=0


[4bez_4]
wall=4bez_wall
width=270
height=480
x=945
y=0


# config
[4bez]
pi1=4bez_1
pi2=4bez_2
pi3=4bez_3
pi4=4bez_4

/root/.pitile (different for each tile)


[tile]

id=pi3


/home/pi/VideoWall/starttile.sh (on each tile)



#!/bin/sh
#voor linear
#pwomxplayer -O  left   --config=4bez  udp://239.0.1.23:1234?buffer_size=1200000B



/etc/init.d/videolooptile (on each tile.)
Take care it is automatically started at booth:
sudo update-rc.d videolooptile defaults
#!/bin/sh

### BEGIN INIT INFO
# Provides:          videolooptile
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Simple script to start a program at boot
# Description:       A simple script from www.stuffaboutcode.com which will start / stop a program a boot / shutdown.
### END INIT INFO

#DISPLAY=:0

# Change the next 3 lines to suit where you install your script and what you want to call it
DIR=/home/pi/VideoWall
DAEMON=$DIR/starttile.sh
DAEMON_NAME=videolooptile

# This next line determines what user the script runs as.
# Root generally not recommended but necessary if you are using the Raspberry Pi GPIO from Python.
DAEMON_USER=pi

# The process ID of the script when it runs is stored here:
PIDFILE=/var/run/$DAEMON_NAME.pid

. /lib/lsb/init-functions
#echo "start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile $PIDFILE --user $DAEMON_USER --exec $DAEMON"

do_start () {
    log_daemon_msg "Starting  $DAEMON_NAME daemon"
     start-stop-daemon --start  --background --pidfile $PIDFILE --make-pidfile $PIDFILE --user $DAEMON_USER  --exec $DAEMON
    log_end_msg $?
}
do_stop () {
    log_daemon_msg "Stopping  $DAEMON_NAME daemon"
    start-stop-daemon --stop --pidfile $PIDFILE --retry 10
    log_end_msg $?
#    killall starttile.sh
#    killall pwomxplayer.bin
}

case "$1" in

    start|stop)
        do_${1}
        ;;

    restart|reload|force-reload)
        do_stop
        do_start
        ;;

    status)
        status_of_proc "$DAEMON_NAME" "$DAEMON" && exit 0 || exit $?
        ;;
    *)
        echo "Usage: /etc/init.d/$DEAMON_NAME {start|stop|restart|status}"
        exit 1
        ;;

esac
exit 0

/etc/init.d/videoloopmaster (on the master) Take care it is automatically started at booth: sudo update-rc.d videoloopmaster defaults)



#!/bin/sh
# /etc/init.d/videoloopmaster

### BEGIN INIT INFO
# Provides:          videoloopmaster
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Simple script to start a program at boot
# Description:       A simple script from www.stuffaboutcode.com which will start / stop a program a boot / shutdown.
### END INIT INFO

DISPLAY=:0

# Change the next 3 lines to suit where you install your script and what you want to call it
DIR=/home/pi/VideoWall
DAEMON=$DIR/StartVideoLoop.sh
DAEMON_NAME=videoloopmaster

# This next line determines what user the script runs as.
# Root generally not recommended but necessary if you are using the Raspberry Pi GPIO from Python.
DAEMON_USER=pi

# The process ID of the script when it runs is stored here:
PIDFILE=/var/run/$DAEMON_NAME.pid

. /lib/lsb/init-functions

do_start () {
    log_daemon_msg "Starting system $DAEMON_NAME daemon"
    start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile $PIDFILE --user $DAEMON_USER --startas $DAEMON
    log_end_msg $?
}
do_stop () {
    log_daemon_msg "Stopping system $DAEMON_NAME daemon"
    start-stop-daemon --stop --pidfile $PIDFILE --retry 10
    log_end_msg $?
    killall StartVideoLoop.sh
    killall avconv.bin
}

case "$1" in

    start|stop)
        do_${1}
        ;;

    restart|reload|force-reload)
        do_stop
        do_start
        ;;

    status)
        status_of_proc "$DAEMON_NAME" "$DAEMON" && exit 0 || exit $?
        ;;
    *)
        echo "Usage: /etc/init.d/$DEAMON_NAME {start|stop|restart|status}"
        exit 1
        ;;

esac
exit 0


/home/pi/VideoWall/StartVideoLoop.sh (on the master)



/home/pi/VideoWall/StartVideoLoop.sh (on the master)
#!/bin/bash

   declare -a vids

   mount  /dev/sda1 /media/WallVideos/

    #Make a newline a delimiter instead of a space
    SAVEIFS=$IFS
    IFS=$(echo -en "\n\b")


    FILES="/media/WallVideos/"

    current=0


    while true; do

    tempindx=0
    for f in `ls $FILES | grep ".mp4$\|.avi$\|.mkv$\|.mp3$\|.mov$\|.mpg$\|.flv$\|.m4v$"`
    do
            vids[$tempindx]="$f"
            let tempindx+=1
       echo "$f"
    done
    max=$tempindx

    if pgrep omxplayer > /dev/null
    then
       echo 'running'
    else
       let current+=1
       if [ $current -ge $max ]
       then
          current=0
       fi

       /usr/bin/avconv -re -i  "$FILES${vids[$current]}"  -vcodec copy -f avi  udp://239.0.1.23:1234
    fi
    done

 #Reset the IFS
    IFS=$SAVEIFS

done