I wrote this little whitepaper a while back for Amy Zunk to document the function of the VideoKeg/VideoJukebox boxes. Documented here for posterity.

The primary goal of the video keg was to build a reliable video box that was easy to transport with enough space to store 3 days worth of Anime fan-subs.

The secondary goal of the video keg was to make a home PVR system for video playback and time-shifting, along with a video arcade and perhaps a web browser.

The tertiary goal of the video keg was to find an affordable hardware platform so that we could buy 4 of them immmediately to service the primary goal's need for 4 separate video rooms.

For a PVR, the machine neeed to be small, quiet, low-heat, and still fast enough to run the software video player and arcade games.

For portability, we decided to go with a smaller mini-ITX style cube box.

The primary goal suggests redundant drives, but due to the smaller form factor chassis and heat requirements, it was decided that recreating a harddrive should one encounter problems would be a minor task.

Looking at the primary goal, mplayer seemed to suit the need of playing media with a variety of codecs with a minimum of fuss. Easy to script, easy to extend, low overhead, with the ability to normalize audio and clean up dirty videos - mplayer was simply ideal. This lead to the requirement of a ~1Ghz or greater box. The secondary goals would be served as well, though MAME would like a bit more horsepower for some of the more complex emulators.

In the end, we settled on a Chyang Fun Cellbox CF-7989EPIA (1Ghz EPIA-MII 10000) turnkey system with 128M of RAM, a Samsung 160G harddrive, and a DVD-ROM drive.

• The cellbox is a small attractive easy to transport case.
• The EPIA-M comes with builtin audio, video, mpeg playback hardware, and a variety of other goodies for a VERY attractive price.
• The 128M stick was enough to run mplayer with an Xserver with plenty left over for PVR software.
• A 160G harddrive was the sweet spot cost wise at the time of purchase.

Once the boxes arrived, the decision at the time was which distribution to pick. If I'm managing more than one server for a given purpose, I like to use debian for package management. If this were a lone PVR box, I would have probably used Gentoo simply for the EPIA community support toward that end.

Starting off with Debian 3.1 Sarge, it was apparent a number of things needed fixing to get it to work with the embedded hardware.

Step 1, find patches and build a kernel.

Kernel patches

After roaming the net for hours, there really seems to be one good source for the latest in EPIA patches: the EPIA wiki:

http://www.epiawiki.org

The site has more of a Gentoo bent, but the patches work on a vanilla kernel just the same under debian.

CPU Optimizations

While building all packages, it seemed important to pay attention to optimizations to squeeze every last cycle out the 1Ghz processor. To that end, the generally recommended C3 Nehemiah CFLAGS are:

CFLAGS="-march=i686 -msse -mmmx -mfpmath=sse -Os -pipe -fomit-frame-pointer"

If you use gcc 3.3, there is a new arch designation for C3 Nehemiah CPUs:

-march=c3-2

Some in the commmunity think that the small 64k L1 cache on the C3 processors is causing starvation, and using -Os and not -funroll-loops actually helps performance:

CFLAGS="-march=i686 -msse -mmmx -mfpmath=sse -Os -pipe -fomit-frame-pointer"

Many others claim the following works best for them:

CFLAGS="-march=686 -O2 -pipe -fomit-frame-pointer -ffast-math -finline-functions -msse -mfpmath=sse,387"

As I was using gcc 3.3 at the time, and the middle ground seems less extreme, I went with -funroll-loops being bad, and back off to -O2:

CFLAGS="-march=c3-2 -msse -mmmx -mfpmath=sse,387 -O2 -pipe -ffast-math -finline-functions -fomit-frame-pointer"

MPlayer

Step one, after building an optimized kernel and loading the appropriate drivers, was to look at MPlayer and decide how to use it. There are video output drivers within MPlayer for the native Linux Framebuffer device, DirectFB, and X11 (XFree86/Xorg), among others.

Getting TVout to work with the viafb driver was tricky to say the least (more on that later).

Playing with mplayer for a while, it became apparent that the optimal playback CPU wise was using X11 with the Xv extension for video output.

XFree86 4.x/Xorg 6.8

Wether XFree86 or Xorg? This is really up to you. The Xorg project has some neat new things (like DRI enabled DDX) and a more "friendly" license that makes everyone happier. Newer distributions seem to be coming out with Xorg builds now, which is a problem for people who are forced to use older XFree86 binary drivers for their hardware (like ATI users).

For our purposes, the differences are moot. To that end, I decided to stick with the "debian way", and patch up the XFree86 4.3.0-dfsg package.

Video Driver

VIA uses their newer Unichrome chipset on newer motherboards, including the EPIA-M. Unforunately, VIA is horrible when it comes to OpenSourcing their efforts. You may download various binary drivers for specific versions and revisions of various distributions off of their VIA support site. There are also old video driver source snapshot releases floating about on there that simply won't work. Some have hacked at it and managed to get those old drivers working on newer handbuilt kernels, but it really isn't necessary anymore.

There is a sourceforge project now where development seems to be focused:

http://unichrome.sf.net

Occasionally, the unichrome project submits a release to Xorg for incorporation into their CVS repository.

There are a number of older drivers out there, along with HOWTOs on patching debian kernels with them.

The unichrome download page has a patch against the Debian XFree86 4.3.0-dfsg package.

DRI/DRM

The newer video driver also requires a newer DRM kernel module. The DRI project has split CVS off of SourceForge to freedesktop.org. You can visit the DRI wiki or the freedesktop.org site directly:

http://dri.sf.net
http://dri.freedesktop.org

Unfortunately, you can't use Debian's default xlibmesa-drm-src package.

To build the latest DRM drivers, I built a CVS snapshot.

Audio

Either OSS or ALSA would do. I'm a fan of ALSA however (newer code), and the debian alsa-driver package was a simple module addition to the kernel build.

$ module-assist auto-install alsa

The VIA EPIA-M motherboard uses the "vt8233" driver.

Writing the Video Keg

The video keg was based on a simple premise: always play video.

The first generation of the video keg was simple. Using a text file listing the filenames of video to play, loop through the list and run mplayer for each filename.

This had the unfortunate site effect of requireing a precalculated spreadsheet of the start time and length of every file in the list. As such, the posted times on the door to the video room would show a complex schedule that was suprisingly accurate.. until a video doesn't play correctly.

Watching 3 days worth of linear video watching for video that doesn't play correctly isn't for the feint of heart. This is the problem with Anime fan subs.

The second generation added scheduling element. If the filename starts with an equal sign ("="), there will be a command after it. Initially there will be one command, "waituntil". This command takes one argument, a time/date string to wait until.

When the video keg script is started up, it reads each line, waiting when appropriate. While waiting, it randomly plays commercials from a directory (sorted on number of times already played and length of playtime) and plays videos with play times shorter than the time available until the wait finishes.

As the keg knows the length of every video, it can calculate when it should be in middle of playback of something. If this is the case, the "-s" argument to mplayer is used to skip a calculated number of seconds into a video. This way, should a video keg lock up, crash, loose power, or otherwise stop, powering it back up will resume the video right where it left off.

If a video cannot play correctly, it dies or otherwise stops playing, and the next waituntil will wait with filler commercials. Brilliant.

Writing the Touch Screen

The "touch screen" box proved a new challenge.

Step 1: Find a touchscreen on EBay that will work with Linux. Step 2: ? Step 3: Profit.

The screen that arrived was an Elo Graphics touch screen with a serial interface. XFree86 already had a driver for it, so the no-brainer was to add a section for it in /etc/XF86Config-4:

Section "Inputdevice"                       
 Identifier "touchscreen1"
 Driver "elographics"               
 Option "Device" "/dev/ttyS0"     
 Option "AlwaysCore"                    
 Option "screenno" "0"                    
 Option "MinX" "0"                  
 Option "MaxX" "4000"                
 Option "MinY" "0"                   
 Option "MaxY" "4000"
 Option "UntouchDelay" "3"
 Option "ReportDelay" "1"
 Option "SendCoreEvents" "true"
EndSection

Then include that as an inputdevice to the ServerLayout section (after your existing mouse):

Section "ServerLayout" 
 ...
 InputDevice "touchscreen1"
 ...
EndSection

Viola. We have a touch screen. The input is as if it were a mouse. This makes development easy.

Deciding on what to develop in was simply enough: Perl. Just as the video keg was hacked together as an overnight perl script frontending a set of bourne scripts for playback, the touch screen would be developed overnight using the same rapid development mindset... only...

I want themes. Users want eye-candy. The default Perl::TK widgets don't take to easy theming. What I really want is a way to theme widgets like GTK...

Enter Perl::GTK2. That was easy.

Time to write the script:

Put a banner of text at the top: "Metrocon Video Touch Screen Jukebox".

Put a play button and a progress bar.

Put a tabbed listbox of all available video (each tab as a letter of the alphabet, and 0-9, for quick searching).

Spawn mplayer to play back video. Watch the output of mplayer to update the progress bar while the video is playing.

Allow the user to select other video while the video is playing, but don't let them click "Play" until the previous video is complete (grey out the button).

Ah, but there is dead air between viewings, what can we do with that dead time?

Simple enough: add commercials.

Create a commercials directory full of video to play, and another directory to record how many times each commercial has been played. Between user selections, start playing from the sorted list of commercials that have been played the least. If the user clicks play, schedule their video to play after the current commercial finishes playing.

QED.

Add standard GTK2 themes. Enjoy.

Polish & Branding

To "brand" this as a drop-dead simple device, I spent a bit of effort making the boot sequence pretty.

Finding the award bios flash tool for the motherboard and the bios modification tool for changing the graphics, I built a DOS Boot Floppy (Bart's modular boot floppy) and burned it as an el-torito bootable CD. Making space for the new graphic ("Linux evil inside") required removing the rhine PXE boot ROM from the flash image (no real loss).

Patching the kernel with bootsplash shows another graphic up until XFree86 starts up.