9.1 Technical Approaches:

The first major decision was to choose which MPEG encoder to use as the basis of this project. Due to its significant documentation and extensive acceptance in the motion-video computing community, the Berkeley MPEG Group’s algorithm was chosen. The only alternative to this was a less popular adaptation by a group from Stanford University.

Many different hardware alternatives were available. Computers based on Intel's microprocessor are plentiful, but computers from Sun Microsystems, Digital Equipment Corporation, or Hewlett Packard would work equally well. Each offers its own features to accelerate multimedia applications such as MPEG encoding. The only important characteristic in making the decision was which one offered the most performance for the lowest price.

The choice of operating systems brought many more options. With some computers, only the manufacturer's proprietary operating system will work. Most popular flavors of Unix offer identical advantages and disadvantages from the prospective of this project. Linux, a Unix clone, is free, widely available, and well documented. Microsoft's operating systems are the most commonly used, and they are also offered at relatively low cost and include ample support. A disadvantage is that Microsoft’s Windows consumes more of the system's resources then a minimal Unix or Linux configuration.

There are different approaches for managing communications between the computers. Here, the tradeoff is between tools that are simple to use and ones that offer maximum performance. In many cases, though, the difference in performance is negligible. The easiest to use alternatives are PVM (Parallel Virtual Machine) and Linda. At the other end is MPI (Message Passing Interface) and at the lowest level, direct socket programming.

The only remaining choice was deciding on the number of computers to use in the parallelization scheme. The alternatives vary with regard to economics and performance. One possibility would be to use a few powerful, yet more expensive machines to minimize network interconnects. Alternately, a greater number of less powerful and less expensive machines could be used. The latter choice must take into consideration how easily and naturally the encoding can be divided among the computers, and the unavoidable complexity caused by the increase in network interconnects.

9.2 Technical Design

The Berkeley encoder has been ported to all popular operating systems, so nearly any type of computer could have been used. At the time, Intel based systems offer the best ratio of performance to price. Originally, using many of Intel's older 486 processor chips seemed to be the best choice. However, it turned out that a fewer number of Intel's newer chips, which offer tools for multimedia acceleration, would actually lower the total cost of the final product.

Linux was chosen as the operating system. Unlike commercial Unix distributions, versions of Linux are freely available. Microsoft's Windows is inexpensive, but Linux provides better networking tools and free documentation.

Originally, PVM was chosen as the best platform for implementing the parallel features of the encoder. It hides much of the setup and provides intuitive functions for controlling the communications between the computers. Because it is very popular, information on its use is easily found. However, as more of the original encoder was understood, it became clear that many of PVM's features already existed in the MPEG code. For instance, the encoder already provided features for sending portions of the input to different computers and for synchronizing the data as it was combined into a single output. Those portions of the software were modified so that the output could be produced in real-time.

This encoding algorithm repeatedly performs the same operation on large sets of data. Intel's new microprocessors have instructions specifically designed for this type of load (MMX assembly instructions). In order to improve performance, the most time consuming portions of the process were rewritten to use these instructions.

As indicated in figure 9.1, each group of three related frames is encoded, one on the master (which gets an I or P frame because it is less difficult and therefore less time consuming), and a B frame on each "slave" machine. The master will continue to block until the "slaves" have completed their work. Then the three encoded frames are queued, from the hard drive, and merged with the output bitstream. This allows for a more uniform use of network and I/O resources.

9.3 Testing Description

The reason that effective video compression is so important is that uncompressed video data is extremely large. That makes testing somewhat difficult. Fortunately, the part of the program that performs the compression has not been modified, so only tests of the encoder's speed were needed. The input can have a large effect on the rate at which encoding takes place, so several representative inputs were used. The original encoder had mechanisms for generating statistics. These were used to generate performance data.

9.4 Risks & Risk Management

The biggest risk the project faced was that the potential performance increases were based on estimates of the hardware's capabilities. Because computers are composed of several devices acting independently of each other, it is difficult to make an accurate prediction. The only way to minimize this risk was by observing the performance of the original encoder on several different computers in order to make the best possible prediction.

Another risk was that the structure of the original encoder might not have allowed the necessary modifications. Studying the source code before the project began lowered this risk.

A final risk was that the hardware might not be available. It was decided that the project could be completed on alternative hardware if the desired equipment was not available.