From: RWilson@acorn.co.uk
Newsgroups: comp.sys.acorn
Subject: Misc. Replay Answers
Date: 13 Nov 92 10:27:31 GMT

The Harrier file hasn't got any 'key frames" and so doesn't start well from
arbitary positions!

The Replay compressor generates a 'forwards stream' of information - if the
decompressor leaps into the middle of it it doesn't have frame (N-1) and so
can't decompress frame N correctly (though it can decompress it without
crashing!). With a long enough sequence (or with some sequence cuts) frames
greater than (N-1) will eventually be decompressed correctly.

Obviously this is a disaster for random access to an arbitary movie, so the
decompressor periodically (actually once per chunk) writes out the state of
a frame WITHOUT any other frame dependency. To start at any frame, the
decompressor starts at the beginning of a chunk, loads the key frame and
quickly (the replay decompressor is QUICK) decompresses from the 'forward
stream' to the right frame. There is no 'palette' in a Replay file (as Gary
Palmer theorised): all pixel values refer to 15bpp RGB or YUV.

For compactness the key frame information can be omitted except for that in
the first chunk - and then you get a movie like Harrier2 which can't be
started anywhere except the beginning. The key frame information is not read
during normal play, so the bandwidth of data transfer doesn't need to take
it into account: its around 20KBytes extra per second of the movie.

Playing the movie at -speed 2 (or even -speed 2.4 if you want to try 30fps)
isn't an accurate test of Replay: objects in the 12.5fps world are moving
'unexpectedly far' compared to those in the 25fps or 30fps world: this
causes less efficient coding at 12.5fps compared with the same scene at
25fps: as a consequence the decompressor ends up doing more work to
reconstruct a frame. So I usually tell the compressor to go for a higher
quality (spend more bytes per frame) at 12.5fps compared with 25fps, since
the supporting media has an easy job to provide it. 5800 bytes per frame at
12.5fps (average) is much easier than 5000 bytes per frame at 25fps! This
greater number of bytes is hard to transfer at the higher speed...

Playing Replay movies from a RAM disc is not particularly advantageous: the
decompressor might have been able to use the extra memory in a better way
(such as greater buffering of decompressed frames allowing the decompressor
to decompress more frames 'at once'). An IDE or SCSI hard disc provides
>300KBytes per second data transfer at not much more CPU overhead (which is
what's important) than the RAM disc: Replay is designed to cope with the
additional latency of a real drive (it can cope with the 0.4 second latency
of CD-ROM, after all!) and does sequential access to the file so there's
little actuator overhead.

As for the ARM3 (or better) comment: I wrote that expecting the
documentation (which, after all, gets burned into various CD-ROMs) to be
eventually over taken by newer chips - we didn't want people with ARM800
unearthing these old CD-ROMs, reading the blurb ("works on ARM2 or ARM3")
and ringing up Customer Services to ask if that meant "works on ARM800".
Obviously ARM600 is not a rumour. Presently ARM700 and ARM800 are the
material for rumours ("which I cannot confirm or deny").

--Roger