home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / mac / misc / 18944 < prev    next >
Encoding:
Text File  |  1992-11-09  |  4.9 KB  |  105 lines
  1. Newsgroups: comp.sys.mac.misc
  2. Path: sparky!uunet!world!ivanski
  3. From: ivanski@world.std.com (Ivan M CaveroBelaunde)
  4. Subject: Re: semi-technical QuickTime info required...
  5. Message-ID: <BxF8nt.5zw@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <1992Nov8.091942.8451@msc.cornell.edu>
  8. Date: Sun, 8 Nov 1992 23:45:29 GMT
  9. Lines: 94
  10.  
  11. maynard@leah.msc.cornell.edu (Maynard J. Handley) writes:
  12. >Based on the way Apple and others claim the Apple animation compressor
  13. >should be used, I would guess that it performs RLE encoding. Does it just
  14. >do the standard PICT RLE encoding? Is this simply along the x direction, or
  15. >is it done along both x and y directions?
  16.  
  17. I believe that in lossless mode it is basically the standard PICT RLE
  18. coding (x-direction only). In lossy mode (which only works on direct color
  19. modes, 16/24/32 bpp) it uses some sort of color difference computation
  20. (probably RGB, not really sure) to append pixels to the "runs."
  21.  
  22. >"None"-encoding. Is this truly none, or does it do the basic PICT
  23. >compression?
  24.  
  25. No, it's truly none.
  26.  
  27. >Apple graphics---what gives here? The only thing I know about this is that
  28. >I have yet to find anything for which it works nicely. Does it insist on
  29. >the system pallette? Does it needs globs of the same color?
  30.  
  31. I have had generally good results with it. It's optimized for 8-bit
  32. error-diffused images - should work with any palette.
  33.  
  34. >Apple video. Looks like it does the JPEG scheme of blocking, but what else.
  35. >I
  36. >guess it's not simply JPEG diddled a bit, cause of the speed.
  37.  
  38. It's block-based, but I think it has nothing to do with JPEG. The
  39. algorithm is licensable from Apple, I believe.
  40.  
  41. >The new Apple compact video. What's this based on? Wavelets? It produced
  42. >artifacts unlike anything I've seen elsewhere.
  43.  
  44. It's a VQ (Vector Quantization) scheme, which is similar to finding an
  45. optimum CLUT for an image. You basically have a color map (called a
  46. codebook) and you map each pixel to the closest color in the codebook.
  47. The codebook then is updated as the color usage statistics change.
  48.  
  49. >2) Is ANY form of inter-frame compression performed when making movies? I
  50. >thought that when you gave a key-frame rate, that meant that each key-frame
  51. >was stand-alone, but other frames were based on inter-frame encoding.
  52.  
  53. It depends on the compressor (JPEG does not support interframe coding)
  54. for example.  With photorealistic-type compressors such as Apple Video
  55. you will not get much from interframe coding unless you lower the
  56. spatial compression quality setting. There is also a parameter called
  57. "temporal quality" that controls the sensitivity for interframe coding.
  58. In Apple's compression dialog, it's generally available by holding
  59. down the option key and using the same quality slider.
  60.  
  61. But you are right as far as what key-frame rate means. If you set
  62. it really high (3200 frames), then you will only have one full frame and
  63. then nothing but differences. Random access performance will suck badly,
  64. but it should play pretty well linearly.
  65.  
  66. If you are writing your own code to call the QuickTime routines,
  67. there are a couple of flags that must be passed to the sequence
  68. compression calls for them to work properly (UsePrevFrame + UsePrevFrameComp
  69. or some such).
  70.  
  71. >I've tried varying the key-frame rate from zero to every frame and in
  72. >between, and the file size seems to change each time by about 2K, which
  73. >seems to imply not much is happening. The various key-frame rates also
  74. >seemed to have no effect on quality of playback, either forwards OR
  75. >backwards. Is this just a bogus field that will be used in later versions
  76. >of QuickTime?
  77.  
  78. They work fine for me; experiment a bit.
  79.  
  80. >3) What is the major bottleneck in playback speed? It seemed to me that
  81. >this would be decompression. However on my SE/30 a (grey-scale 150x200)
  82. >movie made at
  83. >15fps plays back rather more smoothly when compressed with either Apple
  84. >Animation or Apple Compact Video than with no compression, and compact
  85. >video gave better playback than animation. (At ten fps all three schemes
  86. >were equal so I guess the machine wasn't yet maxed out.) Is this because in
  87. >fact most of the time is data transfer time, and the compressed movie have
  88. >to pull less data off disk? Or is it some effect of grey-scale? I haven't
  89. >yet got around to experimenting seriously with color movies so I don't know
  90. >what would happen there. 
  91.  
  92. The main bottleneck will vary. Basically the data has to come in from the
  93. disk, be massaged by the decompressor, and blitted up onto the screen.
  94. If the time it takes to decompress the image is less than the additional
  95. time it would take to read the extra uncompressed data from the disk,
  96. then the disk is the bottleneck. In general, the bottleneck will be the
  97. disk with a fast CPU, and the decompression on a slow CPU. The
  98. speed of your graphics display (say, internal VRAM vs Nubus card) may also
  99. be critical.  The only answer is "it depends."
  100.  
  101. -Ivan
  102. ---
  103. Ivan Cavero Belaunde
  104. DiVA Corporation
  105.