In our world, video begins in a lightly or uncompressed format and makes a round trip through MPEG compression and decompression, popping up on a viewer's screen in what we hope is the same quality product we put into the pipe.

Some may wonder why I put the features into MPressionist that I do. The first reason is that I put the features in that reflect my needs both as an technologist and as my sideline as an end-user of my own technology. I have a special version of MPressionist that includes features that generally only I would need to have. The ones I leave in the commercial product are the ones that I think will be useful to everybody.

One such feature is the ability to evaluate your compressed MPEG movie file with several IDCT algorithms. DCT/IDCT is the mathematical heart of many compression schemes, including both MPEG-1 and MPEG-2. The DCT stands for 'Discrete Cosine Transform'. For all you musician buffs out there, the DCT algorithm is a distant, but related cousin to additive FM synthesis systems which made their debut in the 80s. In FM audio synthesis, sounds are emulated or synthesized by mixing together simple sine waves (basis functions), which through their combination, yield a complex, composite sound. While FM audio synthesis involves only amplitude and time, the DCT as we use it involves amplitude in two dimensions (x and y) over a very small window, which turns out to be an 8x8 pixel block of data.

The MPEG specifications do not describe what mathematical algorithm is to be employed for compression or decompression, and there are many to choose from. What the MPEG specification does describe the minimum mathematical accuracy that is needed to properly decode a bitstream.

So I posed myself the question: What influence does the precision of the (I)DCT mathematics have on the quality of the finished product?

Here's part of the answer; my subjective opinion based on experience.

When I take a modern, well-compressed Hollywood DVD and watch it with MPressionist on a high-fidelity Apple Cinema display using the fixed-point (less accurate) IDCT algorithm, it looks great. No question about it.

However, if I switch the algorithm to the single-precision floating point IDCT, the video looks beyond great. It looks perfect. Stunning perfection. In fact, it is hard to believe how good it can look.

And naturally, this realization feeds back into the design of MegaPEG.X; there are three levels of mathematical accuracy available in MegaPEG.X. Fixed-point (fastest), floating-point (fast) and double-precision floating point (relatively slow). Based on the constraints in your work environment, you can pick the algorithm that is right for the job.

While an MPEG decoder (ie. DVD Player) uses only the inverse DCT (IDCT), a well designed MPEG encoder uses both the DCT and an IDCT, emulating the actions of the decoder as part of the encoding process. So, in MegaPEG.X when you select the DCT, you are, in fact, selecting a matched pair of DCT/IDCT algorithms. My favorite is the single-precision floating point pair, which has been custom written for the Velocity Engine. Probably, because it is my favorite, it is available under the 'Good & Fast' selection on the Speed vs. Quality slider.

As a counter-example to what I've written above, let me describe what happens when a movie is encoded with a low-precision DCT algorithm. If you watch such a movie with MPressionist set to floating-point IDCT, the movie will look good. If you watch the movie with a matched fixed point algorithm, it will look pretty good. However, if you watch it with an arbitrary fixed-point algorithm with different mathematical characteristics than the original encoding, the video can look bad to awful. And there is a reason for this...

Generally, in DVD compression, we have a true keyframe (I, or intra-frame) about every 15 frames, and a partial keyframe (P, or predicted-frame) every 2-3 frames. The problem with DCT inaccuracy is that the errors are cumulative over the GOP (group_of_pictures - the group of frames between I-frames). Cumulative, means that the picture which might start out looking good, can look very bad near the end of the GOP.

With MPressionist you can see this trend for yourself. Simply encode a movie with any encoder set to a fast setting. It is quite normal for fast encoding to be based on fixed-point DCT algorithms. Once you have the file, bring it up into MPressionist and switch to one of the non-default fixed-point IDCT algorithms. Wait for some challenging footage to go by (fast moving or highly textured), and then stop the playback and single step through the frames from the I-frame (start of GOP) through to the next I-frame.

Given the bewildering array of video playback devices out in the world, there is no feasible way to 'see' your final movie as it will appear on all those devices. So MPressionist gives you the next best thing: the ability to alter a single playback device so that its decoding characteristics vary within the constraints allowed by the MPEG specification. I think you may find as I have, is that the solution is to compress your movies with the floating-point reference algorithm, and let the cumulative errors on playback be less evident as a result.