CompuServe Messages

Hi Wade, Right-on in general… a little more info here from Craig Birkmaier's article in the January "Videography". He got this from the folks at Sarnoff labs. All errors of interpretation are strictly my own. <g> Both JPEG and MPEG rely on intra-coded pictures, or "I" frames. All compression is based on the internals of this one image. It uses the discrete cosine transform to measure variance of color from one pixel to its neighbors within an 8×8 block. High compression rates here cause the "blockiness" seen in some JPEG images. Motion-JPEG algorithms also use this DCT intra-frame compression scheme. I believe, but do not know, that Motion-JPEG may use some type of differential across time as well. This would require that a fully-coded "I" keyframe be sent at regular intervals. As you point out, delta frames cannot be pulled out directly; they would need to be calculated from the previous keyframe. MPEG uses DCT algorithms too, but introduces a few optimizations. "Macroblocks" consist of four 8×8 blocks of luminance data and the two corresponding 8×8 blocks of chrominance data. Macroblocks are formed into horizontal "slices". These larger units are used for the prediction of motion of objects within it. iow, suppose there's a red ball moving across the screen. Motion-JPEG would code how each pixel changes. MPEG would code the motion of the ball across the macroblocks. This is similar to the way that a graphic program blits sprites to a screen, but works in the noisier environment of video. MPEG uses two types of frames in addition to the fully-coded "I" frame above. A "predictive-coded picture" ("P" frame) generates its image from delta'ing a past frame. This is similar to the way FLCs and PICS work. A "bidirectionally predictive coded picture" ("B" frame) works from both the prior and the following keyframes. This allows it to not only predict the motion on the interpolated frames, but also to predict how the shading on the object will change. It gives the most efficient compression ratios, but requires a buffer to store the additional keyframe, and I suspect a bit more processing muscle. This "B" frame interpolation would help in low-throughput situations, like a CD-ROM or telephone line. The way that these various frames are stored and read is not standardized yet, however. Right now on the PC, Sigma Designs has the ReelMagic MPEG board, and there's also a XingIt Board which features a different MPEG implementation. On the Mac there's a freeware MPEG reader called "Sparkle", and there will be support for MPEG in QuickTime 2.0 this summer. But it's still a bit wild'n'wooly out there on the compression frontier. Whoof! Sorry to go on for so long, and apologies in advance for any distortions I may have introduced, but hope that the above is of interest! Regards, John Dowdell Macromedia Tech Support