From: ivanski@world.std.com (Ivan M CaveroBelaunde)
Subject: Re: semi-technical QuickTime info required...
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 8 Nov 1992 23:45:29 GMT

maynard@leah.msc.cornell.edu (Maynard J. Handley) writes:
>Based on the way Apple and others claim the Apple animation compressor
>should be used, I would guess that it performs RLE encoding. Does it just
>do the standard PICT RLE encoding? Is this simply along the x direction, or
>is it done along both x and y directions?

I believe that in lossless mode it is basically the standard PICT RLE
coding (x-direction only). In lossy mode (which only works on direct color
modes, 16/24/32 bpp) it uses some sort of color difference computation
(probably RGB, not really sure) to append pixels to the "runs."

>"None"-encoding. Is this truly none, or does it do the basic PICT
>compression?

No, it's truly none.

>Apple graphics---what gives here? The only thing I know about this is that
>I have yet to find anything for which it works nicely. Does it insist on
>the system pallette? Does it needs globs of the same color?

I have had generally good results with it. It's optimized for 8-bit
error-diffused images - should work with any palette.

>Apple video. Looks like it does the JPEG scheme of blocking, but what else.
>I
>guess it's not simply JPEG diddled a bit, cause of the speed.

It's block-based, but I think it has nothing to do with JPEG. The
algorithm is licensable from Apple, I believe.

>The new Apple compact video. What's this based on? Wavelets? It produced
>artifacts unlike anything I've seen elsewhere.

It's a VQ (Vector Quantization) scheme, which is similar to finding an
optimum CLUT for an image. You basically have a color map (called a
codebook) and you map each pixel to the closest color in the codebook.
The codebook then is updated as the color usage statistics change.

>2) Is ANY form of inter-frame compression performed when making movies? I
>thought that when you gave a key-frame rate, that meant that each key-frame
>was stand-alone, but other frames were based on inter-frame encoding.

It depends on the compressor (JPEG does not support interframe coding)
for example.  With photorealistic-type compressors such as Apple Video
you will not get much from interframe coding unless you lower the
spatial compression quality setting. There is also a parameter called
"temporal quality" that controls the sensitivity for interframe coding.
In Apple's compression dialog, it's generally available by holding
down the option key and using the same quality slider.

But you are right as far as what key-frame rate means. If you set
it really high (3200 frames), then you will only have one full frame and
then nothing but differences. Random access performance will suck badly,
but it should play pretty well linearly.

If you are writing your own code to call the QuickTime routines,
there are a couple of flags that must be passed to the sequence
compression calls for them to work properly (UsePrevFrame + UsePrevFrameComp
or some such).

>I've tried varying the key-frame rate from zero to every frame and in
>between, and the file size seems to change each time by about 2K, which
>seems to imply not much is happening. The various key-frame rates also
>seemed to have no effect on quality of playback, either forwards OR
>backwards. Is this just a bogus field that will be used in later versions
>of QuickTime?

They work fine for me; experiment a bit.

>3) What is the major bottleneck in playback speed? It seemed to me that
>this would be decompression. However on my SE/30 a (grey-scale 150x200)
>movie made at
>15fps plays back rather more smoothly when compressed with either Apple
>Animation or Apple Compact Video than with no compression, and compact
>video gave better playback than animation. (At ten fps all three schemes
>were equal so I guess the machine wasn't yet maxed out.) Is this because in
>fact most of the time is data transfer time, and the compressed movie have
>to pull less data off disk? Or is it some effect of grey-scale? I haven't
>yet got around to experimenting seriously with color movies so I don't know
>what would happen there. 

The main bottleneck will vary. Basically the data has to come in from the
disk, be massaged by the decompressor, and blitted up onto the screen.
If the time it takes to decompress the image is less than the additional
time it would take to read the extra uncompressed data from the disk,
then the disk is the bottleneck. In general, the bottleneck will be the
disk with a fast CPU, and the decompression on a slow CPU. The
speed of your graphics display (say, internal VRAM vs Nubus card) may also
be critical.  The only answer is "it depends."

-Ivan
---
Ivan Cavero Belaunde
DiVA Corporation
Newsgroups: comp.sys.mac.misc