Video Server

YSTV had requested a video server for 2-3 years before it was finally passed in the summer of 2003. Begun by Kevin Bowman, and completed in autumn 2003 by Dave Baker, this remains at the heart of YSTV's broadcast programming. Controlled first by the BBC Schedula and now Spider and SchedSeven, vidserv plays out and records YSTV's live and recorded output.

It's fair to say it has revolutionised YSTV and the perception of it amongst students. It has changed the station from primarily one that rebroadcasts other networks' programming with occasional live student TV inserts to one that shows wall-to-wall original productions.

The Machine

The hardware for the video server takes massive advantage of the affordability of good performance computing hardware from the mid-2000's onwards. The heart of the system is a fairly standard Athlon XP 1800 XP CPU with 512MB of DDR RAM on a high-end nForce 2 motherboard. This has an on-board Nvidia GeForce4 MX graphics chip, which provides the TV-out as a composite video signal, as well as USB, Firewire and IDE controllers (Nvidia) and SATA ports (separate Promise chip). Playback sound comes from the on-board nForce2 AC97 Audio.

Even on this speed machine capturing video would be pretty hairy if the compression and recording was being done on the system CPU, so a hardware MPEG-2 encoder card using the iTVC 15 chip. This means that all the encoding of audio and video is done in hardware, and a ready made MPEG-2 stream comes out of the card and just has to be written to the disk by the operating system.

To hold the data, the machine has a 180GB IDE hard drive given over to video, and an 80GB SATA disk which hosts the operating system (Gentoo Linux) and provides temporary space for uploaded and recorded files. The latter is a newer addition from Easter 2006, having previously been the system disk for Rowan de Pomerai's Mac. Prior to this everything lived on the same HDD, which was sometime a problem if large files were being processed whilst the machine was also playing out to the network.

The Software

Whilst the hardware was in place at the end of the summer, getting the software stack sorted and ready to use took a little longer. It was initially set up by Kevin Bowman with a dual boot of Windows and FreeBSD, but this never made it to production and Dave Baker replaced it with Slackware Linux because it was what Computer Science was running at the time. This rapidly came into use for both playing out video to the network and capturing live shows for repeats.

This install remained in use continuously from then until Easter 2006, when the 5GB partition was rapidly getting too small, and Slackware was being problematic to maintain as the rest of the station had migrated to Gentoo Linux in the mean time. This lead Richard Ash to completely empty the (decidedly fragmented) video disk, reformat the entire disk for video using Reiserfs rather than EXT-2, and install Gentoo Linux on the new 80GB HDD. This allowed all of the necessary software to be installed using distribution packages (rather than hand-building most of the multi-media packages for slackware), and came back on-line after Easter 2006 and has been in use ever since.

An operating system is only half the problem however - we need the right application software on top to do do what we need. On the recording side this is made very simple by the hardware encoder card - the MPEG-2 stream is made available via /dev/video, so simply running $ cat /dev/video > file.mpg will create a recording in file.mpg. To stop recording, hit CTRL + C. This is in practise wrapped by a shell script, but makes for a very reliable recording system. Whilst problems have occurred with the wrong video and audio going in, and with the hard drive filling up during recording, only once has a live show failed to be captured correctly due to sending and unstable video stream in, which upset the hardware codec.

Playback is rather more complex, as the video has to be sent to a normal X11 server to be shown by the graphics card. It also has to cope with variable size videos and multiple different video and audio codecs. In order to play Idents before and after programs, a mechanism was also needed to enable videos to be chained together without a glitch at each file change. This latter point is not as simple as it seems, and defeated a number of prospective playback engines.

Finally Dave Baker settled on xine-lib because of it's continuous video output capability, and wrote a custom daemon based on it to handle video playback. It provides a telnet interface which first the BBC Schedula and now Spider and SchedSeven can use to request videos be played. Whilst this has had it's problems, mainly with bugs in xine-lib that only show up when a single instance is kept running for weeks or months at a time, it does provide a very slick playback facility. Since the bugs have been fixed upstream (notably a per-file memory leak that slowly crashed the daemon), it has provided a very solid video playback facility for the station, enabling much more broadcasting of YSTV's own output. Currently it has been running for 6 weeks without a restart of the application.

The final component of the software set-up is a battery of scripts for automating video encoding and conversion tasks, so that files are encoded to uniform file formats with uniform bit rates and so on. This not only allows us to archive material to XviD for playback and long-term storage, but create content for Watch On Demand streaming from the YSTV website and decode compressed files for easier editing.

Upgrade

At some point between 2007 and 2010 the machine was upgraded/replaced with a Pentium E2200 (2.2GHz) and 700 odd MB of memory and a markedly better graphics card, still running as the main playout and live recording server, however the duty of video encoding and conversion was handed to Encode. Eventually, with the advent of XineNet Desktop, it also became the main live playout machine for a time until the VT Server took over this role.

Drive Failure and playout system changes

Sometime in the Spring of 2011 it was noted that the machine was no longer writing to its log files (at this point the last recorded entry was 6 days ago) and had become unstable. Barely a day later the main OS drive had conclusively failed, and was rebuilt with a fresh Gentoo installation. After completing the rebuild and attempting to run the xine-net playout software, it turned out that newer versions of the X11 server were woefully incompatible with the software. Due to various degrees getting in the way, this problem was then shelved until the summer, when the decision was taken to migrate to Windows and CasparCG to enable live flash-based overlays, a project which is still in progress.