              Requirements for an Acorn Replay Capture program

Video Data

(1) The Acorn Replay compressors take (any) Acorn Replay files as their
input data. There are these possible forms of (uncompressed) input data:

- 15 bit rgb pixels: each pixel is 5 bits of red, green and blue (red in
  bits 0-4, green in 5-9, blue in 10-14, bit 15 zero). Pixels recorded in
  successive half words. ARMovie file compression format 2, pixel depth 16.

- 15 bit YUV pixels: each pixel is 5 bits of Y (luminance), U and V
  chrominance signals (Y in bits 0-4, U in 5-9, V in 10-14, bit 15 zero).
  Pixels recorded in successive half words. ARMovie file compression format
  2, pixel depth 16 with YUV in the pixel depth field.

- 20 bit YYUV pixel pairs: two pixels recorded with two 5 bit luminance
  signals and one set of common U and V chrominance signals (Y1 in bits
  0-4, Y2 in bits 5-9, U in bits 10-14, V in bits 15-19). Pixels recorded
  in successive 20 bit values: 160 bits (5 32 bit words) represents 16
  pixels and is a basic recording unit. ARMovie file compression format 3,
  pixel depth 16 with YUV in the pixel depth field.

- 30 bit YYYYUV pixel quads: four pixels in a square recorded with
  individual luminance signals and one set of common U and V chrominance
  signals, the whole thing held as one word (Y1 in bits 0-4, Y2 in bits
  5-9, Y3 (second row) in bits 10-14, Y4 in bits 15-19, U in bits 20-24,
  V in bits 25-29, bits 30 and 31 zero). ARMovie file compression format 5,
  pixel depth 16 with YUV in the pixel depth field.

- 90 bit YYYYYYYYYYYYYYYYUV pixel sixteens: 16 pixels in a square recorded
  with individual luminance signals and one set of common U and V
  chrominance signals, the whole thing held as three words (Y1 to Y6 in
  bits 0-29 of word 0, Y7 to Y12 in bits 0-29 of word 1, Y13 to Y16 in
  bits 0-19, U in bits 20-24, V in bits 25-29 of word 2, all bits 30 and
  31 zero). ARMovie file compression format 6, pixel depth 16 with YUV in
  the pixel depth field.

- 16 bit 6Y5UV pixels: each pixel is 6 bits of Y (luminance), U and V
  chrominance signals (Y in bits 0-5, U in 6-10, V in 11-15). Pixels
  recorded in successive half words. ARMovie file compression format
  2, pixel depth 16 with 6Y5UV in the pixel depth field.

- 22 bit 6Y6Y5UV pixel pairs: two pixels recorded with two 6 bit luminance
  signals and one set of common U and V chrominance signals (Y1 in bits
  0-5, Y2 in bits 6-10, U in bits 12-16, V in bits 17-22). Pixels recorded
  in successive 22 bit values. ARMovie file compression format 23, pixel
  depth 16 with 6Y5UV in the pixel depth field.

- 34 bit 4x6Y1x5UV pixel quads: four pixels in a square recorded with
  individual luminance signals and one set of common U and V chrominance
  signals, the whole thing held as 34 bits (Y1 in bits 0-5, Y2 in bits
  6-11, Y3 (second row) in bits 12-17, Y4 in bits 18-23, U in bits 24-28,
  V in bits 29-33). ARMovie file compression format 24, pixel depth 16 with
  6Y5UV in the pixel depth field.

- 8 bit grayscale: one pixel per byte. No compressor yet exists for this
  data, but files can be played. ARMovie file compression format 4, pixel
  depth 8.

- 24 bit rgb pixels: each pixel is 8 bits of red, green and blue in
  consecutive bytes. ARMovie file compression format 8, pixel depth 16/24.

- 24 bit YUV pixels: each pixel is 8 bits of Y (luminance), U and V in
  consecutive bytes. ARMovie file compression format 8, pixel depth 16/24
  with YUV in the pixel depth field.

- 32 bit YYUV pixel pairs: two pixels recorded with two 8 bit luminance
  signals and one set of common U and V chrominance signals (Y1 in first
  byte, Y2 in second, U in third, V in fourth). ARMovie file compression
  format 9, pixel depth 16/24 with YUV in the pixel depth field.

- 32 bit YUYV pixel pairs: two pixels recorded with two 8 bit luminance
  signals and one set of common U and V chrominance signals (Y1 in first
  byte, Y2 in third, U in second, V in fourth). ARMovie file compression
  format 21, pixel depth 16/24 with 6Y5UV in the pixel depth field.

- 48 bit YYYYUV pixel quads: four pixels in a square recorded with
  individual luminance signals and one set of common U and V chrominance
  signals, the whole thing held as six bytes (Y1 in first byte, Y2 in
  second, Y3 (second row) in third, Y4 in fourth, U in bits fifth, V in
  sixth). ARMovie file compression format 16, pixel depth 16/24 with 6Y5UV in
  the pixel depth field.

- 144 bit 16Y1UV pixels: sixteen pixels in a square recorded with
  individual luminance signals and one set of common U and V chrominance
  signals, the whole thing held as six bytes (Y1 in first byte, Y2 in
  second, Y3 (second row) in third, Y4 in fourth, U in bits fifth, V in
  sixth). ARMovie file compression format 11, pixel depth 16/24 with 6Y5UV in
  the pixel depth field.

If possible, avoid the pedestals usually found on systems (in particular, the
CCIR601/656 range subsetting) - occupy the full 0-31, 0-63 or 0-255 range of
the components. If this is not possible, then there are suitable colour spaces
for displaying the movie data (CYUV, C6Y5UV and C6Y6UV) which will need to be
put in the file header and -ccir will need to be used on compression to tell
the compression library to expand the ranges.

Gamma correction is assumed to have been done (so that equal increments in the
input range are approximately equal perceptual increments). Frame size is
recorded in the ARMovie file header: although ARMovie files can have arbitary
numbers of pixels in a frame, the Acorn Replay Moving Line compressor expects
the frame to be a multiple of 8 pixels horizontally. 160x128 or 160x120 are
typical sizes: these play back at 1/4 screen VGA. The space used for the
formats is:

format  bits used  Bytes used per
        per pixel  frame at 160x128    pixel multiples x    y
  2         16         40960               x1               y1
  3         10         25600               x2               y1
  4          8         20480               x4               y1
  5          8         20480               x2               y2
  6          6         15360               x4               y4
  8         24         61440               x1               y1
  9/21      16         40960               x2               y1
 10/16      12         30720               x2               y2
 11          9         23040               x4               y4
 23         11         28160               x4               y1
 24          8.5       21760               x4               y2

Acorn can supply sample ARMovie files in all formats if required. Acorn can
also supply an !ARMovie directory containing decompressors (with source) for
types 2, 3, 4, 5, 6, 8, 9, 10, 11, 21, 23 and 24.

There are advantages to recording in 8 bit colour component systems: Acorn
recommend format 10 as a good compromise between bytes and quality. Formats
6 and 11 have an obvious limitation in colour resolution and are only
recommended for large material (to be shown -small) or images with few sharp
edges. Formats 23 and 24 can only be compressed by SuperMovingBlocks at
present, but have the advantage that the Y resolution is large enough to
require less dithering.

(2) All frames should be image processed the same way. Dithering of some
form is recommended when converting from 8 bits per sample to 5 bits per
sample, Floyd Steinberg dithering (or some other scheme having low error
propagation values) is preferred, but dithering to the right pixel is
acceptable - it results in lower compression factors, but not as bad as no
dithering - provided the input data can stand the slight smearing that
results. When 24 source data is used with 15 bit compressors via the
CompLib program, dithering is done to reduce the depth. With any of the YUV
formats, it is possible to dither only the Y signals. Sharpening is not
recommended since it results in lower comression factors. Scaling by linear
interpolation (equal area weighting or other filtering schemes) is
recommended to produce images of the required size. Point sampling is
permitted but *not* recommended. Frame sizes should be a multiple of 8
pixels horizontally.

(3) The ARMovie file is usually called "Capture". It is recommended that it
is a multiple of 50 (60) frames in length (or a multiple of 25 frames in
length if recorded at 12.5fps). If you wish to allow for immediate play back
of the captured data, it may be necessary to restrict the chunk size to less
than 1MByte (i.e. 1 second chunks instead of the more usual two seconds): the
!ARMovie Player provided by Acorn uses double buffered chunk IO and thus
loads two chunks at once: a 25 fps 160x128 capture in format 2 with 2 second
long chunks is 2 MByte per chunk and can only be played on machines with
more than 4MBytes free.

(4) For mastering a movie at both 25fps and 12.5fps (30fps and 15fps if you
happen to be a 60Hz provider), all frames must be recorded. The Acorn Replay
compression software will make a 25fps movie using all frames and a 12.5fps
movie using only the even numbered frames.

(5) For mastering a movie at only 12.5fps (15fps) it is possible to record
only the even (or odd - your choice) frames. It need only be a multiple of 25
(30) frames in length.

(6) The !ARMovie Player program can play format 2, 3, 4, 5, 6, 8, 9 and 10
directly, providing the source media is fast enough. This gives direct
evidence of sound sync etc. If the source isn't fast enough, then use -speed
to slow the play rate down (e.g. -speed 0.5).

(7) Writing the ARMovie file. Note that the last chunk in the movie need not
have the same number of frames in it as all the other chunks: just write the
catalogue entry correctly (the sound can be cut immediately by an appropriately
short catalogue entry). The various pointers in the header of the ARMovie file
all need to be filled in properly or it doesn't work! Two fields in particular
are the number of chunks and the catalogue of chunk offsets.

(a) If you know the length (say, in seconds) in advance of making the
recording, then the number of chunks field can be written directly the
header is written (note that its the number of chunks -1: a 2 second long
movie with 2 second chunks has 0 s the number of chunks). If you are not
recording the sound, the number of bytes in a chunk will be constant and
the catalogue can also be written directly, with each catalogue entry
calculated to contain what will be written. Then write the data. If the
sound is being recorded, the number of samples per sound grab may well
vary (especially if approximating an irrational frequency like 1/72uS):
the catalogue needs to be written after the chunks have been written, so
make enough space (e.g. in the wimpslot) to keep the entire catalogue in
RAM; write all the chunks, then write the catalogue after the chunks, then
go back to the start of the file and ammend the catalogue pointer.

(b) if you don't know the length, then the strategy is similar to (a)
above: write the header, write all the chunks keeping the data which will
be used to construct the catalogue in RAM, finish recording by writing
the final chunk, write the catalogue, then go back and ammend the header
to have the correct number of chunks and correct catalogue pointer.

Sound Data

(1) It is required that the sound sampler's notion of time and the video
sequence's notion of time agree: otherwise the sound will start in sync with
the video and drift out as the clip is played. This can be achieved either
by extreme accuracy of player and sampler (both to within 1/10 second after
1000 seconds, say) or by GENLOCKing the player and sampler togther. Since
most professional video equipment has GENLOCK input capability, Acorn
recommend that the sampler's clock is divided down to produce a VSync-like
signal to which the video source is GENLOCKed.

(2) Sound capture must be started in frame sync with the video sequence. The
sound sample must be continuous and extend to the end of the video sequence
(preferably just beyond the end!). There should be no AGC or other systems
used to unnaturally alter the sound level.

(3) Sound data should be oversampled at at least twice the desired replay
rate: for example, if the replay rate is to be 10,000Hz, then the sample
should be made at at least 20,000Hz, with the data resampled to 10,000Hz.
Alternatively, you can capture at the desired replay rate using one of the
modern over-sampling-with-dsp-decimation devices which does it all for you.

(4) Sample rate (and thus replay rate) must be specified precisely - don't
say 10,000Hz when you mean 10,000.25Hz!!!! Precise numbers of uS can also be
represented: 72 means 72 uS rather than 72Hz (true up to 255 uS).

(5) The replayed data uses VIDC's exponential format for greater dynamic range.
Input data should be 16 bit linear or 8 bit exponential (bytes). 16 bit linear
data can be converted to 8 bit exponential format with a table or to a
compressed format such as ADPCM by using one of the sound compressors - see
CompSound - (of course, it may use too much CPU to do this, in which case
capture at 16 bit linear for subsequent offline compression).

(6) Although the sound data should be held in the ARMovie "Capture" file, it
may be hard to do this if sound and video are being recorded seperately. So an
8 bit sound sample can also be held as a different ARMovie file, or as one RISC
OS file "Sound" at the top level of the hierarchy of files. 16 bit files are
called "Samples". These files may also exist if sound is derived from the
captured sound before being made into the final movie.

Other Data

(1) A header containing all the textual information for the ARMovie (AE7)
file produced by the compressors must be supplied and called "1Header" or
"2Header". This file is especially important if the ARMovie "Capture" file
contains no sound, since it is the reference for it. The chunk size in these
header files should be 2 seconds.

(2) A default sprite called "Sprite" must be supplied. This should contain
an image the same size as the movie in mode 13 pixels (the sprite can be
mode 15 or mode 28 if required).

(3) Acorn have converters for old captured data. These programs are
basically modified compressors which work on old capture trees, writing out
Images which can then be Joined by old Joiners to make type 2 or type 3
format ARMovie files. Please contact Acorn if you need these, however we
don't consider them 'user friendly'!
