This report is also available as an Acrobat file.
In this appendix we give details of compression methods supported by the Sunvideo card and also those used by the different software packages we used in the study. The standards described all fall into the category of lossy compression methods which means that the compression method used discards information during the compression process which cannot then be recovered on decompression. Lossy methods allow very high compression ratios (up to 200:1) but can introduce artifacts into the decompressed frames. We also describe here well-known standards (JPEG and MPEG) that are not presently suitable for
videoconferencing applications since they require too much computing resource. They are included since they may be useful for comparison purposes.
JPEG (Joint Photographic Experts Group)
This is a standard designed mainly for still image compression. Although JPEG defines a non lossy method, of main interest here is its lossy algorithm. For video sequences each frame is compressed by transforming 8x8 or 16x16 blocks of pixels via a DCT (discrete cosine transform) to produce coefficients describing the spatial complexity of the image. The method retains the larger features in the image and discards the finer details. Standard Huffman encoding is used to compress the resulting code. The algorithm is symmetrical in that roughly the same amount of time is required to decompress the frames as it takes to compress them. The compression/decompression rates are such that video sequences of JPEG frames can be stored on disk and retrieved at 25-30 frames a second. Provided a sufficiently powerful CPU is available the frames can be decompressed in real time thus giving high quality video playback. This is currently possible only on today's high-end workstations. The compression rates provided by JPEG are not high enough to allow transmission of full video over today's communications lines (T1) or to allow playback from CD-ROM drives.
MPEG (Moving Pictures Experts Group)
There is a series of MPEG standards but we will only deal with MPEG-1 here. Basic frame compression is based on very similar principles to JPEG but in order to reduce the bandwidth required for transmission MPEG also includes interframe coding where adjacent frames are compared in blocks of 16x16 pixels to determine areas that have changed between frames. This is a very computationally intensive operation. MPEG-1 in fact takes much more time to encode than to decode but decoding rates are still much slower than that required for JPEG. Thus only the most powerful of today's workstations are currently capable of decoding MPEG-1 at full video quality.
This is SUN's proprietary codec which is used by the ShowMe software. It is designed for use in videoconferencing applications where real time coding/decoding of the bit stream is required. 4x4 pixel blocks are represented by a 16-bit bitmask and two 8-bit vector quantised codebook indeces. This gives a compression ratio of 12:1. Interframe compression is also used by comparing corresponding blocks in adjacent frames and using skip codes where a block has not changed or is 'close enough' to the previous frame. Quality can be traded against compression rate by modifying the definition of 'close enough'. Video frames are typically compressed at from .4 to .8 bits per pixel which is equivalent to about 10:1 to 20:1. At these compression rates a FCIF frame (352x288 pixels at 15 frames/sec) would require bandwidth in the region of 0.5 to 1.0 Mbits/sec range which is well within the capacity of today's LANs. CELLB is such that decompression can easily be accomplished in real time by today's workstation CPUs.
As mentioned in Chapter 1, this is one of the standards included in the ITU-T standard known as H.320. H.261 is a video compression codec which is meant to be utilised on communication lines that have multiples of 64 Kbit capacity (so-called Px64 where P=1...30). H.261, like JPEG and MPEG, is based on DCT but it uses a simpler interframe algorithm than MPEG which reduces the time taken to encode and decode the video stream. The simpler algorithm, however, means that video quality is reduced. H.261 is defined for both the FCIF and QCIF standards. It is difficult to transmit full motion CIF frames with less than 384 Kbit/sec (6 x 64 Kbit/sec) communications so QCIF tends to be used on slower connections such as when Basic Rate ISDN is used. Even then, since compression is reduced when there is a lot of movement between video frames, the pictures will be of relatively poor quality.
This is Intel's proprietary codec. We have not been able to obtain details of its algorithms in time to be included in this report. If Intel's Proshare software takes hold in the market place it could well become an important de facto standard.
Further information on Indeo and Intel's products can be obtained from http://www.intel.com/IAL/indeo/indeo.html
Virtual Environments Visualisation