| |
 |  | |  | |  | |  | |  | |
 |
| | BitJazz Here's a chart comparing the RAM-to-RAM speed performance of all serious lossless QuickTime image codecs, measured on the Kodak Test Set, on a 667 MHz single-processor PowerBook G4 (the January 2002 Titanium model) with 256 KiB of level-2 cache and no level-3 cache, running QuickTime 5.0.2 under MacOS 9.2.2. Note that this cache is way smaller than a single SD video frame. We wrote a simple custom application to load the uncompressed movie frames into RAM, encode them with QuickTime's SCCompressSequence API (for RGB) and ImageTranscodeSequence API (for Y'CbCr), and decode them with QuickTime's DecompressSequence API, timing the encoding and decoding with the Microseconds() function of Apple's microsecond timer for precision. The reason we're comparing RAM-to-RAM speeds here is that, in contrast to the CPU-boundness of all other image codecs, SheerVideo is i/o-bound, running faster than just about any storage device or transmission channel. So if you were to try to measure SheerVideo's RAM-to-disk speed, for example, you'd just be measuring the speed of the disk. "Serious" nondestructive image codec here means attaining a compression power of at least 2.0 — the minimum level, our surveys show, that users require before they'll consider using a codec worth the effort. This excludes the both None codec (which leaves the video uncompressed, for a compression power of 1.0), and the Animation codec, whose lossless compression power for real-world data is only a feeble 1.06. It also excludes PNG, whose lossless compression power averages a mere 1.79 for real-world images, but we've included PNG in the chart anyway as a familiar reference point. The definitions of encoding speed and decoding speed are encoding speed = uncompressed size / encoding timeFor convenience, the figures given here are normalized for a single-processor 1 GHz G4. Our tests have shown that SheerVideo's speed increases linearly with processor speed for the Mac, since Apple generally takes care to speed up the bus and memory in concert with the CPU. For reference, StuffIt 6, Aladdin Systems' general-purpose compression utility, compresses the Kodak RGB images at 0.67 MiB/s (mebibytes per second) with a mean compression power of 2.09, and Aladdin's DropZip compresses them at 0.92 MiB/s by an average of 1.62. The black bar shows how fast a codec needs to be in order to process standard-definition video in real time. Standard Definition video here means around 10,368,000 p/s (pixels per second) — either NTSC standard, which is 29.97 or 30 frames per second at 720 by 480 pixels per frame; or PAL or SECAM standard, which is 25 frames per second at 720 by 576 pixels per frame. For RGB 8b and Y'CbCr 4:4:4, which have 3 bytes per pixel, this works out to about 29.7 MiB/s (though on the Macintosh, these are usually stored with 4 bytes per pixel, corresponding to about 39.6 MiB/s). For Y'CbCr 8b 4:2:2, which has only 2 b/s, SD is around 19.8 MiB/s. For viewing on an analog television monitor, 720 pixels per line is a wishfully optimistic number, but it's the standard resolution for digital video. Note that these figures assume that all these pixels are actually visible, and not part of the horizontal or vertical blanking intervals.
The RGB 8b statistics here are for the original Kodak images, repackaged as a QuickTime movie; For Y'CbCr 8bv 4:4:4, the RGB movie was encoded with the standard equations in Recommendation ITU-R BT.601-4 and stored in the 'v408', 'VUYA', and 'r408' pixel formats (which differ from each other only in byte order and Y' offset). For Y'CbCr 8bw 4:2:2, the RGB movie was encoded with Apple's Component Video codec, which uses the 'yuvu' ('yuv2') pixel format; For Y'CbCr 8bv 4:2:2, the Y'CbCr 8bw 4:2:2 movie was then transcoded with the standard equations in Recommendation ITU-R BT.601-4, and stored in the '2vuy' and 'yuvs' pixel formats (which differ from each other only in byte order). The Y'CbCr images were tested at this nonstandard video resolution to simplify comparison. As you can see from this chart, for RGB 8b footage, lossless video codec SheerVideo encodes well over 50 times faster than Microcosm, PNG, and PhotoJazz, and decodes far faster than all of them too. So who cares? Well, let's say you've shot one hour of uncompressed real-world SD RGB 8b video footage, and you want to archive a digital copy for backup. You don't want it to take up 100GB of storage space, so you decide to compact it for archival using a lossless image codec. Let's say you pick PNG, Microcosm, or PhotoJazz to compact it. So you click OK on your 1GHz Mac G4, and what do you do then? You take a coffee break, of course. How long a coffee break? Oh, a little over 15 and a half hours. You see the problem? Who in their right mind would want to tie up their computer for 15 and a half hours to archive one hour of video? God help you if you had a productive day and shot 2 hours of video that you want to archive! Now let's entertain a different scenario. Let's say you pick the Sheer ultrafast lossless video codec to compact your video. Then you click OK on your 1 GHz Mac G4, and what do you do next? You take a coffee break, of course. How long a coffee break? Oh, about 16 minutes. You see the solution? [Personally, as someone who isn't fond of coffee, I'd way rather be forced to drink coffee for 16 minutes than for 15 1/2 hours.] For the native Y'CbCr video formats ('v408', 'VUYA', 'r408', '2vuy', 'yuvs', 'yuvu), SheerVideo is not only the fastest lossless video codec, it's also the only option, because no other lossless image codec supports native video formats.
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
= encoding
= decoding
reference speed
