INTRODUCTION

When I was younger, I wondered why Baskin Robbins had 36 flavors of ice cream. After all, chocolate met all my needs and cravings. Why, I questioned, were there all these other flavors, and who on earth would eat them?

Most CD-ROM title developers feel the same way about codecs. After all, Indeo or Cinepak are both wonderful technologies, and unlike the ice cream of yester year, both royalty and calorie free. Why then, do codec developers like Horizons Technologies (TrueMotionS), Iterated Systems (Fractal Codec), RAD Software (Smacker) and Sirius Publishing (Moving Pixels) try to convince us to actually pay for their technologies, and who in the world is using them?

Well, the CD-ROM publishing world is not quite as monolithic as my taste buds. Target platforms for CD-ROM titles can range from 486/33 computers with 8-bit graphics to the latest full color Pentium 150s. Video source material can be full screen animation or postage stamp-sized talking heads, and maybe a video sprite or two. You may plan to co-publish on the Internet and CD-ROM, a trend destined to mushroom as 128 Kbit/second ISDN lines become ubiquitous.

Clearly, if you're digitizing talking head video for double speed CD-ROM drives, a general purpose codec does just fine. However, in a diverse publishing milieu, codec needs transition from general purpose to boutique. When searching for ultimate quality for specific video source material or target platforms, it may pay to consider these alternative codecs.

OUR TEST PLAN

We compressed four video types - talking head, action, small animation and large animation, to extremely low and extremely high data rates, and then measured playback quality and display rate. Our goal was to identify the codec or codecs that produced higher quality output than Indeo 3.2 and Cinepak in these roles.

We did not consider Intel's Indeo Video Interactive (IVI), released as we finished this article, because of time considerations (see Sidebar - "The New Codec Paradigm"). That said, it appears that the new codec is targeted above the bulk of the installed base of computers. Traffic on Intel's Compuserve support site indicates that a Pentium 90 is a low end to mid level machine for this new wavelet-based codec. Ditto for software-only MPEG playback, which requires a Pentium 133 or above to achieve respectable display rates.

By the end of 1996, Indeo Video Interactive and MPEG will be the standards by which all other codecs are judged. However, both overpower the '486 computers and low end Pentiums that comprise the bulk of today's installed base. As we'll see, one primary focus of two of our alternative codecs is to extend the life of computers in this class, allowing title developers to sell into a larger target market than either IVI or software MPEG.

Two codecs, Horizon's TrueMotion and RAD's Smacker, were shipping at press time, enabling a complete evaluation. Iterated Systems, targeting an early 96 release of their Fractal Codec, provided compressed samples from an earlier versions. Sirius Publishing provided a beta copy of their Moving Pixels codec. For this reason, our analysis of the TrueMotionS and Smacker will be much more comprehensive than the other two.

COMPARATIVE FACTORS

We compressed all files on our ancient but still functioning Gateway Pentium 60 computer with 16 MB of RAM, Matrox Millennium graphics card, SoundBlaster AWE 32 sound card, Yamaha's YST-MSW10 speaker system and a Mitsumi 2X CD-ROM drive. While we experimented with some 30 frame per second (fps) files, we mainly compressed at 15 fps, 320x240 resolution at three target data rates, 150, 200 and 290 KB/second, attempting to find each codec's "sweet spot," or configuration combination best suited for the codec.

Video quality was our number one criteria, which we compared with captured screen shots from the various codecs. We compared files in both 8-bit and 24-bit mode, to measure both native 24-bit and dithered video quality (see Palette Management, below).

We tested display rate with a 30 fps file compressed to approximately 450 KB/s. We measured display rate with Doceo Publishing's Video Compression Sampler, testing in 8, 16 and 24-bit modes. RAD's Smacker is not a Video for Windows codec, so we tested display rate by playing back the file with frame dropping disabled and measuring playback time.

Here are the other factors we considered, some addressed in the features table, and some covered in the product review.

Interactivity - Measures how quickly a codec can jump to a particular video frame, which again affects perceived performance. We tested interactivity by timing how long it took the codec to page forward and backwards through a file in ten percent increments.

Compression Time - Compression time is the time to compress a standard three second video sequence to approximately 200 KB/Second.

Table 1 summarizes our findings regarding these performance measures.

Economics - costs of compression hardware and software and runtime licenses.

Palette Management - Many CD-ROM developers target computers with 8-bit graphics, making palette management a critical issue. Briefly, 8-bit graphics cards can display a maximum of 256 colors at one time. This collection of 256 colors is called a palette, since all screen elements must be painted with colors contained in the palette. The 256-color combination is not fixed - palettes can and do frequently change. But at any one time only 256 colors can be displayed.

When Windows boots in 8-bit mode, it assumes the palette of the icons and other graphics elements displayed. All graphic objects -- animations, videos and bit-mapped and/or vector images - have their own palette. When a new graphic object displays, Windows makes certain that the colors in its palette are available in the current desktop. If not, Windows changes the palette by momentarily blanking out and "realizing" the colors of the new palette. When realizing the new palette, the screen assumes bizarre patterns of colors that can be quite distracting.

Codecs like Indeo and Cinepak store compressed video in 24-bit mode to optimize display on higher end monitors. When displaying in 8-bit mode, both decompress to 24-bit mode and then assign each pixel a color value from their own proprietary 256-color palette for display. This process, called dithering, creates a tiny geometric pattern on the video that detracts from its appearance. In addition, because these 24-bit codecs always default to their own palette, developers must plan long and hard to avoid palette flashing, a complicated process.

In contrast, codecs like Smacker and Video 1 store information in 8-bit mode, that can display in 8-bit graphics without dithering. This also allows developers to assign a particular palette to the video and easily avoid palette flashing.

Finally, 8-bit codecs are more efficient with inherently 8-bit formats like animations. Compress an animation with Indeo and the codec's first step is to blow the compact 8-bit format up to 24-bit, tripling the amount of data. Accordingly, 24-bit codecs must be at least three times more efficient than 8-bit codecs to produce the same compressed quality with animations, and predictably they aren't.

Application Interface - All codecs but Smacker are Video for Windows (VFW) AVI codecs, compatible with the gamut of VFW capture, editing and compression tools. Smacker comes with its own development environment which we'll describe in the review.

Data Rate Management - Surprisingly in this data rate centric world, most of our alternative codecs don't let developers compress to a target bandwidth. Instead, they force you to manipulate exotic, poorly defined controls like "Interframe Edge Threshold," "Color Resolution" or "Delta" setting to achieve a target data rate. This trial and error approach can add days to your development time, (not to mention hours to writing time).

TrueMotionS - Horizons Technologies

TrueMotionS is a proprietary technology licensed from Duck Corporation in New York City. Horizons is fairly closed mouthed about the algorithm, describing it a "transformless algorithm" that works with differences between RBG values of tight groups of pixels. Horizons attributes the codec's decompression speed to the fact that decompression requires many simple addition functions, but few processor consuming multiplications. After working with the codec for several days and reading between the lines of the manual, it's clear that Duck also performs some vertical scaling and pixel averaging to achieve lower data rates.

TrueMotionS stores color information in 24-bit mode, dithering to a standard 8-bit palette during decompression. Horizons intends to deliver an updated version of the codec that will hold a palette, but this wasn't ready for our review.

Unlike all other reviewed codecs, TrueMotion is an intraframe-only technology which performs no interframe compression. This improves the ability to page directly to a random frame, but typically prevents the algorithm from achieving single spin data rates with the benchmark 15 fps, 320x240 video file.

Quality/File Size - The lowest data rate TrueMotionS achieved on a low motion talking head clip while retaining usable quality was just under 190 KB/s. The high motion test clip compressed down to a minimum of 246 KB/s.

At these and higher data rates, TrueMotionS produces high quality, distortion free video [See Figure 1.]. Talking head clips with a fixed background, however, begin to exhibit noise at under 2X data rates, primarily because TrueMotionS' intraframe approach completely redraws each frame during decompression. In contrast, interframe techniques don't update static regions between frames, which can reduce background noise, but oftentimes at the cost of image distortion.

Background noise is more apparent at lower data rates due to the tradeoffs TrueMotionS makes to achieve these lower bandwidths (see below). Overall, noise is probably the most apparent compression artifact, along with a slight breakup of lines, text and other details. We saw no compression artifacts typical of other codecs such as blockiness or image distortion. At under 2X CD-ROM rates, color tended to fade slightly, which we corrected by adjusting saturation value during compression.

At 3X CD-ROM data rates TrueMotionS produced better than MPEG-1 video quality, though at 15 fps. At this data rate, CD-ROMs hold only about 20 minutes of video, but those seeking short doses of ultimate video quality may find TrueMotionS quite attractive in these configurations. On the other hand, those developing for the 8-bit environment may find TrueMotionS' dithering algorithm too course for comfort, and should definitely view the video in 8-bit mode before making the codec decision [See Figure 2.].

While TrueMotionS produced excellent quality animated files, data rates were extremely high. For example, on the full screen animation, TrueMotionS' data rate was twenty four times larger than the original animation. TrueMotionS is probably not well suited for working with animations.

Display Rates - TrueMotion performed well in display rate tests, easily achieving 30 fps in 8-bit mode, and 18 fps in 16-bit mode. We could not test in 24-bit mode because of incompatibilities with the Matrox Millenium graphics card.

Response Latency - Horizons was the fastest of the alternative codecs, though slightly slower than Cinepak, Indeo and Indeo video interactive.

Interactivity - TrueMotionS' intraframe-only compression smoked through the interactivity tests, the only codec to keep up with the mouse clicks. This translates to the most responsive codec of all those test.

Operation - Horizons sells both a Macintosh and Video for Windows version of the TrueMotionS compressor. We tested the latter, using Microsoft's VidEdit utility as the compression interface.

The TrueMotionS compression interface does not offer a direct data rate control, and unlike most other codecs does not normalize data rate over the duration of a file. Instead, users regulate data rate via the controls shown in Figure 3, and the codec compresses each frame as designated with the data rate rising and falling throughout the video in relation to the complexity of the individual frame. This technique makes it extremely difficult to select and regulate data rate for clips containing different sequences.

For example, frame sizes in the action video compressed to an average data rate of 300 KB/second ranged in size 16.7 KB to 23.8 KB, which translates to per second data rates of 250 to 357 KB/second. Obviously, this video would not play smoothly from a 2X CD-ROM. In contrast, compressed frame sizes for a talking head video with very little interframe variation hovered around 18.3 KB/frame for the duration of the clip, perfect for the 274 KB/Second data rate.

By experimenting with small extracts of our main test clips, we quickly found the optimal compression settings, which we saved as a separate preset. Fortunately, TrueMotionS is an extremely fast compressor, burning through our 45 frame clip in just over one minute and 21 seconds.

Compression Controls

Horizons offers five compression presets, ranging from Least (least quality/least data rate) to Most (most quality/most data rate). Since the presets produce different data rates for different types of clips, their primary value is to illustrate how the various controls impact data rate.

The largest single data rate determinant is compression scaling, toggled on and off with the Compression - normal and high control. This control subsamples information horizontally at a ratio of 2:3, essentially reducing data rate to 2/3 of the original without significant quality degradation. However, to access this compression feature, the video's horizontal vertical resolution must be a multiple of twelve, which is why most TrueMotionS clips tend to have a resolution of 312x224.

The second largest factor in reducing quality is Vertical and Horizontal Color Resolution, which sets pixel block sizes for color averaging. At the high:high resolution, color is sampled in 2x2 pixel blocks, which are usually too small to discern during normal playback. At normal:normal resolution, the codec samples color with 4x4 pixel blocks, producing significant bandwidth savings (approx. 50 KB/s in 312x224x15 fps clip) but creating more background noise.

Overall, TrueMotionS has dramatically improved in both quality and playback performance since the early versions that surfaced in late 1994. Through its relation to Duck Corporation, Horizons also offers decompression access to the SEGA, Nintendo and 3DO platforms, one reason TrueMotionS has gained acceptance with large CD-ROM publishers. Now that Horizons has included 500 free decompression licenses with each compressor, in-house publishers seeking high quality, high data rate video may also want to take a look.

TrueMotionS Summary:

Strengths: Very high quality video (better than MPEG-1) at 3X data rates. Good display rates on DCI enabled computers. Very fast compression makes TrueMotionS ideal for test compressions, mock-ups and proofs of concept. Color, contrast and brightness controls are very handy during compression.

Weaknesses: Achieving target data rate can be a lengthy, trial and error process, and data rate will vary over clip duration. Typically can't achieve 1X CD-ROM rates with 320x240 videos. Appearance in 8-bit mode is marred by gross dither patterns. Unsuitable for animations due to high data rates.

RAD Software - Smacker

General Description: Smacker is an 8-bit codec targeted primarily towards games developers converting Autodesk Animator FLIC files to an interleaved format capable of playing back smoothly from a CD-ROM. Smacker is not a Video for Windows codec, so files cannot be produced, edited or played back with any VFW-compatible tools. At the present time, RAD does not offer an MCI-controllable interface, though they may add this interface in the future.

Instead, developers access playback via SmackScript, RAD's proprietary scripting language, which offers a broad range of playback options not found in the VFW interface. This makes the codec extremely attractive to developers, especially those targeting the 8-bit playback environment, but somewhat inaccessible to the more casual user. This is unfortunate, since our tests revealed that Smacker could play a much broader role in the general market if decompression could be accessed by more casual developers.

Smacker is based upon a proprietary algorithm that involves color averaging and variable frequency Huffman encoding. Smacker uses both interframe and intraframe compression and achieves exceptional compression quality at below 1X CD-ROM data rates for animations and low motion videos. As an 8-bit codec, Smacker can compress to specific for Window's playback, making it a favorite of games developers targeting the 8-bit platform. Smacker also compresses audio, usually by approximately 25%.

Quality/File Size - Smacker compressed the talking head clip to under 100 KB/second with only a slight hint of dithering and virtually no noise during playback [See Figure 4.]. In fact, Smacker's low data rate talking head clips actually looked better than higher data rate clips, which typically exhibited more background noise.

Like TrueMotionS, Smacker does not offer a data rate control, and couldn't produce a high motion file at 1X CD-ROM Rates. At approximately 200 KB/s and higher, however, Smacker again produced files with very high visual quality.

Animations, however, were Smacker's strongest suit. Both quarter screen and full screen animations were virtually indistinguishable from the original at roughly 1/2 to 1/4 of original size. This reflects the quality and focus of Smackers compression algorithm and that as an 8-bit codec, Smacker starts with one third the data of TrueMotionS and other 24-bit codecs.

Display Rates - We measured display rate of our 30 fps action clip by timing playback with frame dropping disabled. Surprisingly for an 8-bit codec, Smacker played slower in higher color depths than in 8-bit mode. However, Smacker was much faster with animated files, playing back the full screen test animation at upwards of 70 frames per second in 24-bit mode.

Response Latency - While the first Smacker file loaded and played fairly slowly, subsequent files loaded very promptly, indicating that the initial latency related to loading the Smacker driver rather than inherent slowness in operation.

Interactivity - Could not test.

Operation - We worked with RAD's Windows-based compressor. Since Smacker isn't Video for Windows compatible, RAD couldn't use existing tools like Premiere or VidEdit, and had to build a complete operating environment from scratch.

While RAD did a great job with the installation program, user interface and help files, the Windows program suffers from lack of automation tools. Converting an AVI file to a Smacker .SMK file involved three separate steps, AVI to FLC, FLC to SMK and then audio interleaving. All steps are manual, and neither the complete operation nor any individual steps have batch modes. Note that there are batch conversion options available under DOS.

Compression Controls

Converting an AVI file to FLC format is the first step towards "Smacking" a file. This is a fairly simple operation with no quality related controls.

Like TrueMotionS, Smacker does not compress to a target data rate. Instead, the user toggles three controls - a Lossy Setting, Delta control and key frame interval [See Figure 5.].

The lossy setting controls the amount of loss in the file, with completely lossless compression possible at higher data rates. The Delta setting filters out minor interframe noise by setting a threshold of interframe change for the codec to ignore. This technique works extremely well in low motion videos where minor changes typically represent noise rather than real motion, allowing the codec to concentrate on real motion instead of noise.

The final setting is key frame, which sets the interval for complete frames. According to the manual, key frames are only really required when playback speed is slow, or for fast jumps to specific frames.

RAD also enables specific key frame placement and modification of compression controls over the duration of the clip. This allows the developer to locate key frames to maximize interactivity, and to use different settings to maximize quality over the varying regions of a clip.

Once again, we used extracts of our main test clips to search for the optimal compression configuration. On low motion clips, the Delta setting had the most impact on data rate, with changes of 10 Delta points dropping data rate from about 170 KB/s to about 63 KB/s without audio. Using too high a delta setting caused ghosting, or a gauzy trail behind any motion on the video.

In higher motion clips, the Lossy control had much more impact on display rate, degrading video quality as data rate decreased. As you would expect, data rates dropped for both clip types as the interval between key frames got larger.

The final step compression step, audio interleave, is another simple operation with no quality related controls. Interleaving took less than a minute per video, and Smacker compressed the audio by approximately 25%.

One final note for CD-ROM publishers. RAD's Smack Info tool identifies the largest and smallest frames but does not check the per second bandwidth of the file to ensure smooth CD-ROM playback. Developers should compress to total data rates well under the target bandwidth to ensure smooth playback.

Overall, Smacker has gained a remarkable following in the CD-ROM development community by underpromising and overdelivering, an unusual and refreshing tack in the overhyped codec market. At $199, RAD's Smacker software compressor is worth a look by anyone who makes a living putting video or animations on CD-ROMs.

Smacker Summary:

Strengths: Outstanding performance in low motion clips even at well under 1X CD-ROM rates. Outstanding compression and playback performance in converted animations, even at full screen. As an 8-bit codec, Smacker fits easily into projects bound for the 8-bit target platform.

Other Codecs

Two other codecs not ready in final form were also reviewed at a high level. Here are our observations.

Sirius Publishing - Motion Pixels

General Description: Motion Pixels is based on a proprietary "object oriented" algorithm that uses both interframe and intraframe compression. Sirius offers two programming interfaces, Video for Windows and their own proprietary MVI format. We tested the Beta 2.1 release of the VFW codec, compressing with VidEdit.

Sirius is targeting publishers seeking to develop jointly for CD-ROM and the Internet. They claim that the final version of Motion Pixels will offer superior quality at lower data rates, and also a patented scaling algorithm for fast, high quality scaling with little or no distortion or pixelation.

Operation: Sirius' compression controls were confusing and obscure, forcing the user to conjure up the data rate impact of increasing an "Edge Threshold," "Minimum Color Distance" or changes in "Gamma Correction." We were unable to compress high motion clips to data rates under 275 KB/s.

Sirius shined, however in low motion talking head clips, compressing the video portion of a 320x240x15 fps clip to 30 KB/second while retaining excellent still image quality [See Figure 6.] though the video exhibited significant ghosting during even moderate movement. Sirius also compressed the video component of a 160x120x15 fps clip down to 12 KB/second, under the magical ISDN 128 Kbps rate.

We tested 4X playback using the six options offered by the MVI playback control [See Figure 7.], with the 160x120 file. In 24-bit mode, the clip played back at 320x240 resolution at 14 fps, approximately the same speed as a native 320x240 low motion clip (as opposed to the high motion used in the benchmark).

While few technologists doubt that CD-ROM and Web publishing will converge, many question whether video can compress to sub ISDN rates while retaining sufficient quality for business applications. While far from perfect, Motion Pixels offers a glimpse of how compression and scaling can work together to deliver this promise.

Iterated Systems - The Fractal Codec

With their unique fractal-based codec, Iterated Systems is also chasing the lure of joint CD-ROM and Internet publishing. Iterated claims both superior quality at low bandwidths and scalability, the ability to scale using the inherent fractal technology to avoid blockiness and distortion. While Iterated has long delivered still image technology that made good on these claims, the company has lived on the periphery of the video compression market, always somewhat present but never introducing and strongly marketing a video codec.

In late summer, 1995, Iterated came close to releasing a new codec, which was the basis of the compressed clips used in this comparison. However, the product was ultimately withdrawn to refocus thetechnology towards internet publishing, a market that leverages both key features of their fractal based codec. Iterated has promised to deliver a streaming video codec for the Internet by March, 1996.

Based on the clips we reviewed, the fractal technology does perform well at lower bandwidths, delivering good quality and reasonable playback rates. At 61 KB/s, Iterated's low bandwidth video retained high quality, albeit at the lower 320x200 resolution used by their codec [See Figure 8.].

With new management and a new strategic direction, perhaps fractal technology can blossom in this new target market. As with all nascent technologies, however, we await the proof of the pudding.

Conclusion

The changing digital video landscape has necessarily changed our view of the codec market. We've seen how emerging markets can create new demands on codecs, and how innovative codec developers can create features that are instantly invaluable to CD-ROM title developers. We've also seen how the market can push aside technologies, like the ill fated Captain Crunch, that once seemed like a sure thing.

It's safe to say that in this diverse market, there won't be one killer codec, but many boutique codecs, perfect in some roles, unsuited for others. While there may not be 36 flavors, like our Baskin Robbins Ice Cream shop, there will always be some extremely compelling choices.

INDEO VIDEO INTERACTIVE

The New Codec Paradigm

The nice thing about an Intel product introduction is that it comes with a marketing lesson, "Product Launch, 101," give me some of that old time religion as preached by Silicon Valley strategist extraordinaire, Regis McKenna, say hallelujah. Intel doesn't really launch a product, they stage a revival.

When the product is a codec like Indeo video interactive (first word capitalized, second two lower case), this means that Intel announces with the sworn allegiance of a bevy full of tools developers (Adobe, Asymetrix), a covey of title developers (Microprose, Imagination Pilots, Comptons New Media) and a gaggle of hardware developers (BrookTree, Digital Video Arts). All with cross complimentary press releases complete with the requisite hyperbole, and a nationwide road show.

There is, however, a subtle difference this time. Intel actually solicited these companies' input throughout the development cycle, making Indeo video interactive (IVI) the first codec developed specifically for the PC games community. The first codec not designed by committee (e.g. MPEG), or by a skunk group of mathematicians and engineers without the input of their ultimate users.

While this doesn't mean IVI will immediately outperform all other codecs - only time and testing will tell - it does mean this. In one product introduction, Intel changed the codec paradigm.

From linear play to interactive. From quality at a given bandwidth to quality and features. From technology for the sake of hyperbole to technology intelligently selected and applied.

Intel's goal was not solely better quality at a lower bandwidth. It was to provide the features necessary to promote the Pentium and successors as a world class game platform. To provide the features that MPEG, stultified by its very standard status, necessarily couldn't.

Here are the key features targeted at CD-ROM developers:

Transparency support - enabling video sprites and other video overlays that can be interactively controlled during playback with a mouse or key board.

Local window decode -allowing the developer to decode regions within the compressed video rather than the entire video during runtime.

Random key frame access - enabling the developer to insert key frames randomly into the video to maximize quality and interactivity.

Saturation/contrast/brightness controls - letting the user customize video characteristics for their graphics card/monitor combination.

Password protection - protecting the intellectual property interests of the developer from editing and alteration.

None of these features are available in a PC-based codec today. Indeo's primary competitor, MPEG, offers only Random key frame access, and that only on high end systems.

OTHER FEATURES

From a technology perspective, Intel broke from the past with IVI, using a hybrid wavelet-based technology rather than the vector quantization employed by Indeo 3.2. Intel's wavelet approach divides each frame into four sections, each describing different views of the entire frame. The first section contains gross colors and details, the next additional detail, the third still more with the last section containing the final level of intricacy.

All sections are necessary to perfectly recreate the original image. But the first two or three layers are typically sufficient for acceptable quality video.

Intel calls this feature "scalability," and it lets IVI achieve two unique goals. First, when playing back on a less than optimal workstation, IVI can decompress fewer layers of each frame, rather than simply dropping frames like other codecs. This preserves the motion, albeit at some loss of detail.

Second, in low bandwidth transmission applications like video over a network, the developer can allocate bandwidth to multiple users by sending two or three streams rather than all four, making this selection on the fly. When only six users request the video, all would receive the entire stream. When 20 users log on, the administrator could satisfy all requests by sending less than the complete stream to certain users, while ensuring that the president gets all four streams.

The benefit of these features in limited bandwidth settings are immediately apparent. While there are other wavelet-based codecs, none even attempt to provide this level of scalability.

SIN QUA NON

Finally, recognizing that quality at a given bandwidth is the sin qua non of any codec, IVI's design goal was to deliver MPEG-1 quality at 24 fps at 2X CD-ROM rates on Pentium 100s and above. While MPEG-1 is a moving target, preliminary tests reveal that Intel has met the quality goal, while perhaps underestimating the horsepower necessary to display 24 fps from a CD-ROM.

This, of course, not surprising from a company who never met a problem that couldn't be solved with a faster processor. After all, one of IVI's design goals was not to preserve the installed base of '86 and low end Pentiums.

CONCLUSION

Without adequate time for testing, we can't fully measure Intel's execution on these design goals. However, we can say that from a feature's perspective, IVI sets the standard by which all future codecs will be measured. In addition, by "hitting it where MPEG ain't," Intel once again shows how proprietary, software-only codecs can often deliver functionality that committee driven, largely hardware standards usually can't.