From: rwb@kurn.VI.RI.CMU.EDU (Robert Berger)
Newsgroups: comp.sys.mac.misc
Subject: Re: semi-technical QuickTime info required...
Date: 9 Nov 92 10:07:11 GMT
Article-I.D.: cs.BxG1G0.7My.2
Organization: School of Computer Science, Carnegie Mellon

In article <BxF8nt.5zw@world.std.com> ivanski@world.std.com (Ivan M  
CaveroBelaunde) writes:
> 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