At work we needed a time lapse camera of our new student center construction project. It needs to run continuously for entire length of construction project – approx 18 months. It should run mostly unattended.
It captures 1 picture every 5 minutes. Storage capacity is cheap, so after using excel to make some projections, this worked out to be a reasonable rate for our resources. After some more research, I came to the conclusion that flash video has compatibility with most visitors while being relatively bandwidth efficient, but other codecs could be used. I originally got the idea from http://mydebian.blogdns.org/?p=261 but it wasn’t quite awesome enough, so I rewrote using Perl and expanded upon it.
Requirements – This document assumes you have:
Knowledge using Linux… You’re on your own for installing and configuring
Hardware: The General Idea
- PC capable of running Linux
- Capture card that is supported by V4L ( http://en.wikipedia.org/wiki/Video4Linux )
- Video Camera
Hardware: What we’re using
- HP D350MT – P4 2.6GHz – 512MB Ram – 80 GB SATA hard drive – retired from classroom
- Cheap generic capture card using bttv chipset
- Fixed Security Camera
Software used by the scripts:
I chose Ubuntu 8.04 LTS, but distro isn’t very important.
Note: The rest of the document is assuming use of ubuntu 8.04 LTS
Added packages: installed through apt-get or synaptic
There is more software used, but it is included in Ubuntu 8.04
- ssh – not a requirement, but great for multitasking and any maintenance – connected from my windows workstation using putty ( http://en.wikipedia.org/wiki/PuTTY )
- fswebcam – http://www.firestorm.cx/fswebcam/ – downloaded .deb and installed using either dpkg or gdebi
Date::Manip (I used cpan to install, easiest method)
This entire project is pretty much glued together by cron.
- Runs every 5 minutes
- Captures video frame using a strict naming scheme – YYYYMMDDHHmm.jpg
- Runs once a day at 3 minutes past midnight
- Builds video from pictures for the day that just ended
- Builds based on picture filename, not file creation time so it will still function after restoring from backup
- Creates thumbnails by resizing picture from 10:00AM of first day in video
- Creates playlist based on thumbnail and video files
- Copies playlist, thumbnails, and videos to webserver
- Creates backup and copies to network location
Pulling it all together
I’m going to explain this backwards, from presentation, to how to get it there.
One of the most important parts of this project is how it will be displayed to visitors to our site. I let our webmaster handle most of this.
JW FLV Media Player
We decided upon JW FLV Media Player. It is very easy to use.
- Player – free for noncommercial use!
- It has a Setup Wizard
- Recommend use full path to playlist file
- Playlist file requires full path to videos and thumbnails
Alternatives – not quite as awesome as JW FLV Player
A quick search turned up a few alternatives
Content shared with the internet has to be served from somewhere. We’re already using Microsoft IIS. Since we already have a webserver exposed to the internet, might as well use it to host the time-lapse video too. Also, we know more aobut securing IIS than apache. So hosting videos from the computer that generates them is unappealing. This was an easy decision.
This caused quite a headache when we were trying to play content published to our live webserver from the test webserver… it just didn’t work. I fired up the Firefox extension Tamper Data and loaded the page. It was showing a 404 for crossdomain.xml. A quick search later brought me to http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html.
Copy files to webserver
The webserver has a windows file share and a local user account for this project. This local user account has access to nothing else. Luckily, it’s pretty easy to copy files from a linux computer to a windows file share. The command “mount.cifs” (part of smbfs) will mount a windows file share. Then all that’s left is to copy files to the mountpoint and umount to close the connection.
tar/gzip all the pictures and copy to fileshare for safe keeping. Hard drives die more often than I’d like.
This has been in place and working since December of 2008. We have had relatively few problems. The biggest of which were due to extended power failure and issues with the video feed.