Vidcap Multimedia Experimentation Platform:

System Goals

Mark R. Lindsey
Last modified Saturday, 10-Nov-2001 15:37:16 EST

System goals

To make it as easy as possible to do really cool multimedia stuff.

The vidcap system goals is to rapidly provide a platform for multimedia-project experimentation and development using existing equipment. That platform should be secure enough so as not to compromise the existing trust domain established in the existing network facilities (e.g., the IP filtering rules used in the colab), and should make it easy to distribute software across all of the machines (e.g., develop on one machine, push it out to several others).

Existing Equipment

The project has four Dell Dimension 4100 machines, each with a video capture board. Each machine has a Pentium III 1GHz cpu and 256MB real memory (physical RAM), and a 20GB Maxtor 5T020H2.

General Design

Generally speaking, each system will be as similar to all of the other systems as is practically possible.

Each machine will be connected to a single video camera (vidcap1 .. vidcapN, where N is the number of cameras). One machine will be a file server (this machine may or may not have a camera), and all of the camera machines will have access to the shared filesystem.

Initially, we will designate one of the camera machines as a file server, because we don't have another machine to function as the file server. The file service is completely decoupled from the camera connections, so we can just choose a machine arbitrarily to perform this service.

We're concerned about the space on the other three systems which won't be available; by only using one of the systems as a file server, we're not using roughly 75% of our total storage capacity.

One approach to this problem would be to have each machine mount space from each of the other three machines, and export its space to the other three machines. Thusly, the total available capacity would be accessible to all systems. However, each NFS mount creates a dependency; if the other NFS exports must be available at boot time (i.e., so that the space is available for system functions), then there is no boot sequence which would allow any one of the four machines to start up properly.

Even if we work around this problem by staging the boot to allow all of the NFS servers to become available before the NFS clients attempt to mount, each of the systems is still dependent on all of the other systems -- unnecessarily so. And if the storage from the other systems isn't even necessary for system functioning (i.e., so that background, soft mounts could be used), then it must not be needed. Thus, we've resolved to initially use a single file server, potentially wasting the space for the moment.