System Design
You can build this project to be anything from simple to sophisticated. The requirements we set for our design were these:
1. Receive broadcast video
2. Provide full personal video recorder (PVR) functionality, including pause, rewind, and fast forward/reverse, and including selection of shows to record
3. Compress recorded video, and provide sufficient storage for many hours of recorded video
4. Record video on a server for playback on multiple networked clients
5. Play recorded video, MP3 audio, and DVDs
6. Provide a client user interface suitable for use on the TV screen, from across the room, via remote control
7. Create DVDs from recordings or other sources, including video editing and authoring
If you match these requirements against the key components in Figure 6, you get the requirements for those components:
Tuner — The tuner (which incorporates the demodulator function) inputs RF or composite video signals and outputs a compressed digital video stream. The tuner selects the channel you’re watching, extracts the analog video signal, and then digitizes it (or a direct composite video signal input) into a bit stream. A compressor (see Video CODEC below) reduces the size and data rate of that bit stream, which then appears at the tuner output.
Disk storage — A standard quality DVD runs at a little over 5 Mbps, or 0.625 MBps. Multiply by 3600 and you get about 2.25 GB per hour, a number you can use to start to size the disk storage you want in your server. You’ll want the large disks directly in the server so you can avoid the network traffic you’d see between a file server and the TV server if you put the disks on a remote machine. It’s better to save the network bandwidth for video distribution to clients.
Video CODEC — Including both compression and decompression, and indicated as the MPEG decoder in the figure, the video CODEC (coder/decoder) is responsible (in the server) for compressing video headed to disk storage, and (in the client) for decompressing video headed for the display. Compression is typically part of the tuner, because it’s usually done in hardware to meet the need to do compression in real time, but faster processors have improved the quality of compression possible in software. The day is not that far off when a PC can do real-time, high-quality MPEG-2 compression entirely in software, although it’s less clear why you’d want to use essentially the entire processing capacity of a PC to replace the function of a chip costing about one percent of the price of that PC.
Server processing — The TV server software imposes only a small load on the host processor. Software able to do MPEG-2 compression on the processor would let you use a wider range of TV tuner cards, but will consume even the fastest processor to handle just one stream.
A more useful way to consume processor cycles is in authoring and burning DVDs. You’ll compress raw, uncompressed AVI files, and may need to transcode (decompress and recompress) MPEG-2 files to reduce the data rate. That processing runs on the PC, and although the software we worked with wasn’t able to exploit the hyperthreading architecture of the Intel processor we used, the raw speed helps keep authoring time to a minimum.
Client processing — Each television needs client processing in an attached PC to provide the on-screen user interface and to play video stored on the server computer. Playback includes both network access and MPEG-2 decompression (see Video CODEC); MPEG-2 decompression is less demanding on the processor, and although it was a challenge to do in real time with the first Pentium and Pentium II processors, it’s easily done now in software on even the slowest processor you’re likely to have lying around. Processing on the client PC should also include the capability to play a DVD from the local drive so you don’t need a separate DVD player.
Remote control — Even though you can use a wireless keyboard and mouse to control the client software, it’s awkward to need all that hardware. More useful is to have a remote control similar to what you’dnormally use to control a television. You can use either radio or infrared signals; infrared doesn’t go through walls, so is less likely to have inter-room interference issues, but you’ll need to be careful if you’re also using infrared to control a satellite or cable TV set top box.
We decided to only require reception of off-the-air video for the version we describe here, but the components we used are capable of being adapted to drive satellite and cable TV set top boxes, feeding a composite or S-Video signal into your video capture device.
You’ll need to decide how much storage you want. If you follow the lead of the first generation TiVo PVRs, you’ll want up to 35 hours of capacity, which translates into 35 hours * 2.25 GB per hour = 78.75 GB.Translate that to disk capacities (which use factors of 1000 and not 1024) and you need 85 GB of space. (In practice, first-generation TiVos shipped with 40 GB disks, but use a range of compression rates — that’s why the specification is for up to 35 hours.) Table 3-1 uses the same approach, and includes two different compression rates. The 0.625 MBps rate assumes MPEG-2, as above; the 3.614 MBps rate assumes video compressed to an AVI format with little processing and higher quality.Total storage numbers in the table are rounded up.
Table 3-1 notwithstanding, we simply decided to cram as much storage into the box as we could conveniently fit. You’ll need Windows 2000 or later to address the very large files and partitions associated with video; depending on the software you use, you may or may not be able to segment the storage into multiple partitions. If you can’t, then you’ll need to use RAID striping to combine multiple disks together. You can do that with Windows Server, or with hardware.