Multimedia data is has many properties that make it unsuitable for a traditional file server such as UNIX or WindowsÒ NT. These reasons include:

1. Continuity. Most file servers save parts of a file in several different locations that may be far apart on the disk itself. This causes many head movements (seeks) that slow down transfer rates and the servers can not continuously send a multimedia stream.
2. Most existing systems are optimized for small files such as word processor documents. Multimedia files tend to be very large in comparison and therefore require special treatment.
3. Multiple media streams. One of the strengths of UNIX is that it treats everything as a file. A video server needs to be able to distinguish video from audio from text, etc. and treat each of these different media in a special way.

Let's say you are an enterprising individual and a few years from now you would like to make a digital video store. Your store will provide 1,000 digital movies, each an average of 100 minutes in length. MPEG-2 quality videos at NTSC resolution require 0.5 MB/sec, so doing the math tells us we will need 3 Terabytes of storage capacity. This would require a disk array with 120 25 GB disks. Assuming these disks will cost around $4000 each, this will total $480,000.00 just for the disk hardware. If you would like to get 1,000 users, you will need to bill each of them $480.00 to allow them to sign up for your service in order to cover the initial cost. This isn't too bad, considering the cost of a VCR or DVD player today.

How can we store a movie on a disk? There are a few ways to do this:

• Uncontrolled (random) Placement of blocks on disk: The conventional way would be similar to random placement of blocks used by standard file servers. As we have seen above, this has several inherent problems. The only way to solve these problems is by adequate buffering - see below.
• Contiguous Placement: In contiguous placement, each successive block is placed next to the previous block on disk. In this manner, the disk head will not have to seek very often, making retrieval fast. The problem with this approach is that editing will be difficult. Imagine trying to insert a section of video in the middle of a sequence. You would have to move the rest of the sequence just to make room!
• Constrained Placement: As usual, when neither of two methods suit our needs, we will compromise. In constrained placement, blocks of the sequence are not placed immediately next to one another as in contiguous placement, but they are scattered far enough apart to ensure that the disk will be able to read them fast enough to keep the playback continuous.

If the amount of space between blocks varies widely, you can get jitter. Since this is undesirable, we need to alleviate this problem. We solve this by using a buffer. How big a buffer? Let's take the following graph as an example:

If we plot the total number of frames produced by the server minus the total number of frames consumed by the user, we will end up with a chart like this:

As you can see, this chart dips below zero at certain points. Therefore, the user is trying to display frames that haven't been received yet! Since we have seen that this violates continuity, we want to ensure that it doesn't happen. Therefore, we force the user to read ahead and buffer enough frames before it starts to playback so that it will never try to display a frame that hasn't yet been received. Logically, this would mean that we will shift our graph as follows:

In the above graph, we have drawn the staircase type of line representing data transfered from disk (as it is shown in the first figure above), and the intersection of this staircase with the above shifted graph gives the PREFETCH = READ AHEAD = INITIAL BUFFERING needed. Ycoordinate of this point is the initial buffering, x coordinate is the initial latency, and the y coordinate of the highest peak represents maximum buffering at any time.

Let's take a closer look at the idea of constrained placement.

If we imagine the disk as a linear device, the blocks would be placed something like this:

Here, l_ds is the scattering parameter, that determines how much space there will be between the blocks. How far apart should these blocks be? Well, we need to be able to say that our disk system will be able to retrieve frames faster than we want to display them so that continuity is guaranteed. More formally, our system must be able to say that the time to traverse the gap between blocks + the time to read the frames in a block is less than or equal to the time to display the frames within a block. Mathematically, this is written as follows:

In this formula, frame size, disk rate, and playback rate are fixed. The only variables we can change are the scattering parameter and the number of frames per block.

Now, if we want to edit this sequence, we can make only small reorganizations and stay within our bounds.

Let's say that we want this system to satisfy multiple users. How can our video server do this? The answer is that it will have to operate in rounds. During one round the server will transfer a chunk of data to each user. How big will our chunk be? We can compute this with the continuity requirement shown earlier. A more interesting question is, how many users will we have? We must set an admission control principle that states that the amount of time to retrieve the necessary information for all users in a round must not exceed the time that it takes the fastest user to display all its frames received in that round. Let us define two times, and where is the time for the disk to switch to user_i and receive the first block for that user and is the time for the disk to transfer all other blocks for that user. Mathematically, this is seen in the following formulas:

Our admission control principle should say that