home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / acorn / 9561 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  3.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!spool.mu.edu!agate!doc.ic.ac.uk!uknet!acorn!rwilson
  2. From: RWilson@acorn.co.uk
  3. Newsgroups: comp.sys.acorn
  4. Subject: Misc. Replay Answers
  5. Message-ID: <20111@acorn.co.uk>
  6. Date: 13 Nov 92 10:27:31 GMT
  7. Sender: rwilson@acorn.co.uk
  8. Lines: 53
  9.  
  10. The Harrier file hasn't got any 'key frames" and so doesn't start well from
  11. arbitary positions!
  12.  
  13. The Replay compressor generates a 'forwards stream' of information - if the
  14. decompressor leaps into the middle of it it doesn't have frame (N-1) and so
  15. can't decompress frame N correctly (though it can decompress it without
  16. crashing!). With a long enough sequence (or with some sequence cuts) frames
  17. greater than (N-1) will eventually be decompressed correctly.
  18.  
  19. Obviously this is a disaster for random access to an arbitary movie, so the
  20. decompressor periodically (actually once per chunk) writes out the state of
  21. a frame WITHOUT any other frame dependency. To start at any frame, the
  22. decompressor starts at the beginning of a chunk, loads the key frame and
  23. quickly (the replay decompressor is QUICK) decompresses from the 'forward
  24. stream' to the right frame. There is no 'palette' in a Replay file (as Gary
  25. Palmer theorised): all pixel values refer to 15bpp RGB or YUV.
  26.  
  27. For compactness the key frame information can be omitted except for that in
  28. the first chunk - and then you get a movie like Harrier2 which can't be
  29. started anywhere except the beginning. The key frame information is not read
  30. during normal play, so the bandwidth of data transfer doesn't need to take
  31. it into account: its around 20KBytes extra per second of the movie.
  32.  
  33. Playing the movie at -speed 2 (or even -speed 2.4 if you want to try 30fps)
  34. isn't an accurate test of Replay: objects in the 12.5fps world are moving
  35. 'unexpectedly far' compared to those in the 25fps or 30fps world: this
  36. causes less efficient coding at 12.5fps compared with the same scene at
  37. 25fps: as a consequence the decompressor ends up doing more work to
  38. reconstruct a frame. So I usually tell the compressor to go for a higher
  39. quality (spend more bytes per frame) at 12.5fps compared with 25fps, since
  40. the supporting media has an easy job to provide it. 5800 bytes per frame at
  41. 12.5fps (average) is much easier than 5000 bytes per frame at 25fps! This
  42. greater number of bytes is hard to transfer at the higher speed...
  43.  
  44. Playing Replay movies from a RAM disc is not particularly advantageous: the
  45. decompressor might have been able to use the extra memory in a better way
  46. (such as greater buffering of decompressed frames allowing the decompressor
  47. to decompress more frames 'at once'). An IDE or SCSI hard disc provides
  48. >300KBytes per second data transfer at not much more CPU overhead (which is
  49. what's important) than the RAM disc: Replay is designed to cope with the
  50. additional latency of a real drive (it can cope with the 0.4 second latency
  51. of CD-ROM, after all!) and does sequential access to the file so there's
  52. little actuator overhead.
  53.  
  54. As for the ARM3 (or better) comment: I wrote that expecting the
  55. documentation (which, after all, gets burned into various CD-ROMs) to be
  56. eventually over taken by newer chips - we didn't want people with ARM800
  57. unearthing these old CD-ROMs, reading the blurb ("works on ARM2 or ARM3")
  58. and ringing up Customer Services to ask if that meant "works on ARM800".
  59. Obviously ARM600 is not a rumour. Presently ARM700 and ARM800 are the
  60. material for rumours ("which I cannot confirm or deny").
  61.  
  62. --Roger
  63.