NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/mac/misc/18955

Internet Message Format | 1992-11-09 | 5.3 KB

Path: sparky!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!news
From: [e-mail] (Robert Berger)
Newsgroups: comp.sys.mac.misc
Subject: Re: semi-technical QuickTime info required...
Message-ID: <[e-mail]>
Date: 9 Nov 92 10:07:11 GMT
Article-I.D.: cs.BxG1G0.7My.2
References: <[e-mail]>
Sender: [e-mail] (Usenet News System)
Organization: School of Computer Science, Carnegie Mellon
Lines: 114
Nntp-Posting-Host: kurn.vi.ri.cmu.edu

In article <[e-mail]> [e-mail] (Ivan M
CaveroBelaunde) writes:
> [e-mail] (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