Here's a link to the downloadable tarball. Please note that there are two [Mm]akefiles, "Makefile" and "makefile" with different cases, in the same directory level. Operating systems with a case-insensitive file system such as Windows may get confused.
Here are some details about the software architecture.
Here are some details about the software architecture.
The software roughly consists of the following components.
- Program recording scheduler with GUI
- Program recording executive
- Recorded program transfer over the Internet
- Watching recorded programs on a couch
All GUIs are implemented as simple web pages. My HTML skills have stayed in the pre-CSS/Flash era forever, and HTML 3.0 level coding is the best I can do!
The majority of the recording scheduler consists of PHP scripts except a few written in Perl. The Perl wrapper program tv.cgi works as a "filtering proxy" for displaying a commercial TV program site on the right pane of the GUI. tv.cgi prepends every <A HREF="..."> tag found in the displaying TV guide content with its own URL. This makes clicking the link be redirected to tv.cgi itself. tv.cgi reads from the passed URL and checks its MIME type. If the MIME type is iEPG, it spawns a PHP script for scheduling; for all other MIME types, the contents are passed through with the aforementioned URL modification. This is how my system can use arbitrary commercial TV guide sites for getting iEPG. If a link is buried in JavaScript, it's very difficult to correctly parse and modify its URL, but so far tv.cgi appears to be doing its job very well. Below is an example of the modification of a link tag in a content read from a fake URL "http://tv.foo.com/guide/show.php?date=20110105&prog=12345678":
Original:
<href a="iepg.php?date=20110105&prog=12345678">iEPG</a>
Modified:<href a="http://dvr.mydomain.com/cgi-bin/tv.cgi?u=http:%2f%2ftv.foo.com/guide/iepg.php%3fdate=20110105%26prog=12345678">iEPG</a>
A scheduled program's information (iEPG) is stored in a simple database where each record (scheduled TV program) is saved in its own file. The scheduler PHP script spawns a process of a Perl script start-recording, the recording executive, per each scheduled program. start-recording declares its ownership of the scheduled program and sleeps until the program's start time found in the passed iEPG. The Hauppauge video device (/dev/video[01]) is run by the ivtv driver that outputs an MPEG2 stream. start-recording simply spawns a cat process to copy the stream from the device to a disk file. At the end of the program time, start-recording simply kills the cat process to terminate recording, then spawns ffmpeg to transcode the MPEG2 stream file to an AVI file with bit-rate reduction (8Mbps -> 2Mbps) for faster transfer and for compatibility with the viewing equipment (Buffalo Network Media Player). Actually, start-recording could use ffmpeg instead of cat to directly transcode the Hauppauge's output stream, but my system's CPU is unfortunately not powerful enough to transconde the input stream in real time so that the spooling step is necessary. More recent and powerful CPUs are supposed to be able to handle direct transcoding.
A cron'ed daemon process periodically looks for an orphaned scheduled program recording to cover up accidental death of its owner start-recording process. This is a protection against a system reboot and other unpredictable incidents. The daemon process is also responsible for projecting regularly (daily, weekly) scheduled programs to individual ones with validation against their real iEPG, deleting aged recordings to reserve enough free disk space for new recordings, and other clean-up jobs.
A newly recorded program's AVI file is marked "ready." The local home server in California periodically polls a URL on the recording server looking for a new "ready" program. The home server then downloads the ready AVI file and its iEPG file using rsync over ssh. rsync is very useful as it can resume a half-way download interrupted by any reason and as it can transfer files of any size, whereas Perl and PHP on a 32-bit system cannot handle files larger than 2GB. Since the number-crunching ffmpeg transcoding and rsync file transfer are very resource-hogging jobs, they employ a one-at-a-time-and-shortest-first policy to make as many recorded programs viewable as quickly as possible. A very recent change in my code has made it possible to run as many ffmpeg processes as the number of CPU cores (including hyper-threading), but my existing system has only a single-threading CPU...
A downloaded AVI file is played back by wizd on a Buffalo network media player. A set of PHP scripts on the local home server manages recorded TV program files (delete, archive, etc).
No comments:
Post a Comment