home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Directions 2000
/
ILP_Directions2000.iso
/
_french
/
_armovie
/
ae7doc
< prev
next >
Wrap
Text File
|
1992-08-11
|
7KB
|
188 lines
File format AE7: ARMovie
========================
Start of file:
String ARMovie
String Movie name
String date and copyright details
String author and other details
String video compression format identifier [1][0 -> no video]
Decimal number x size in pixels
Decimal number y size in pixels
Decimal number z pixel depth in bits [16]
Decimal number number of frames per second to project at
String sound compression format identifier [0 -> no sound]
Decimal number sound replay rate in Hz (or fractions of)
Decimal number number of sound channels recorded ("reversed" if l<->r)
Decimal number sound precision ("linear" if linear, "unsigned" if unsigned)
Decimal number number of frames in a chunk
Decimal number number of chunks NC (chunks start at 0!!!!)
Decimal number "even" chunk size in bytes
Decimal number "odd" chunk size in bytes
Decimal number offset to chunk catalogue CC
Decimal number offset to "helpful" sprite
Decimal number size in bytes of the "helpful" sprite info
Decimal number offset to key frames [0/null -> no keys]
other gunge as required
(all fields are ASCII text terminated by NewLine; spaces
ignored, arbitary comment text after numeric field permitted)
byte CC: start of catalogue of chunks
this has NC+1 entries of the form:
file offset of chunk (maybe multiple of 1024)
size of video data
size of sound data (immediately after video data)
arranged FO,BS;OS<newline> (spaces permitted except in numbers)
The 'key frame offset' points to a set of NC (not NC+1) blocks of data
containing x*y*z bits. These allow the decompressor to start at a particular
chunk. Starting at the first chunk doesn't need a reference to the key frame
offsets.
Example:
ARMovie
The Concert
(c) Notts University 1991
Created by Notts University, digitised by Acorn Computers
1
160 pixels
128 pixels
16 bits per pixel
25 frames per second
1
12000 Hz samples
1 channel
8 bits per sample (exponential)
50 frames per chunk
57 chunks
204080
192992
10580256 catalogue offset
512 sprite offset
20480 sprite size
105602 key frames offset
Multiple Sound Tracks
---------------------
The single video track can have an arbitary number of sound tracks associated
with it. Extra sound track data for each sound parameter follows the sound
track marker "|" plus the sound track number. Different sound tracks can have
completely different parameters - compression format, sample rate, number of
channels, number of bits per sample. The first sound track is played by default
and does not follow a |1 marker - thus the first additional sound track has
parameters following a |2 marker.
Example:
ARMovie
The Concert
(c) Notts University 1991
Created by Notts University, digitised by Acorn Computers
1
160 pixels
128 pixels
16 bits per pixel
25 frames per second
1 |2 1
12000 Hz samples |2 16000
1 channel |2 2 channels
8 bits per sample (exponential) |2 16 bits per sample
50 frames per chunk
57 chunks
236080
228992
10580256 catalogue offset
512 sprite offset
20480 sprite size
105602 key frames offset
The catalogue entries are similarly marked:
file offset of chunk (maybe multiple of 1024)
size of video data
size of sound data 1 (immediately after video data)
|2
size of sound data 2 (immediatley after sound data 1)
arranged FO,BS;OS|2 OS<newline> (spaces permitted except in numbers)
Playing sound tracks later than the first one uses more memory (the decompressor
reads the chunk up to and including the sound data it needs).
16 bit sound data is aligned to the next word.
Although it is possible to have multiple sound tracks in a file with no video,
it is probably better to have multiple ARMovie files instead.
A note about the ARMovie's file name
------------------------------------
The movie replay program adds the ARMovie$Suffix to any path name given to it:
it tries to open this file, then tries again with the original path name. (just
like the window manager with !Sprites, !Sprites22 etc). This allows a degree of
personalisation of replay invisible to all programs.
Therefore we recommend the follow standard suffix characters:
"2" a movie made at half the frame rate of its base movie
this movie can be expected to be playable on less powerful machines
(generaliseable if required!)
"S" a movie made with much smaller chunks than its base movie
this movie can be expected to be playable on small memory machines (an "S"
suffix movie may not work from a CD-ROM drive). For example if the base
movie has 2 second chunks, then an "S" suffix might only have 1 second
chunks.
"L" a movie made with much larger chunks than its base movie
this movie will not work on CD-ROM, but can be copied from CD-ROM to
a faster filing system (winchester, magneto-optic) and played. Such movies
will usually require an ARM3 (or better) to replay them.
If two suffixes are available, then the 2 should come first.
Calling programs should use the shortest name possible.
A note about compression numbers
--------------------------------
The compression values allow for new video compressors to be written in the
future. The Player program inspects the video value and, if it cannot process
the format, calls <ARMovie$Dir>.DeComp<X>.!RunImage where <X> is the decimal
string of the value of the compression type. Thus new compression types can
be added transparently.
Compression types are allocated as follows:
0-99: Acorn
video audio
0: no video 0: no audio
1: 'Moving Lines' compression 1: uncompressed audio
100-199: EIDOS
200-299: Irlam instruments
300-399: Wild Vision
Different compression types may have different sound compression (indeed, the
entire meaning of the sound compression field is defined by the video
compression type). However, if the sound compression is the same as one of the
other sound compression methods, then the same number should be used - and,
conversely, if a different sound compression method is being used, then a
different number should be used. (Whew, what a nasty sentence). Thus companies
should either use recognised sound compression numbers (and code...) or they
should restrict their sound compression numbers to the same range as their
video compression numbers.
A note about Stereo sound
-------------------------
For a stereo sample, the left channel is the first sample, the right the
second, etc. If this is not the case, include the word "reversed" in the
number of channels field: "2 channels reversed".
WARNING: for type 0, audio type 1, Stereo 16 bits linear assumes that the
start of each sound chunk is word aligned.