201 lines
7.3 KiB
Plaintext
Executable File
201 lines
7.3 KiB
Plaintext
Executable File
.de PP
|
|
.LP
|
|
..
|
|
.de pT
|
|
.IP \fB\\$1\fP
|
|
..
|
|
.TL
|
|
CMIF video file format
|
|
.AU
|
|
Jack Jansen
|
|
(Version of 27-Feb-92)
|
|
.SH
|
|
Introduction
|
|
.PP
|
|
The CMIF video format was invented to allow various applications
|
|
to exchange video data. The format consists of
|
|
a header containing global information (like data format)
|
|
followed by a sequence of frames, each consisting of a header
|
|
followed by the actual frame data.
|
|
All information except pixel data is
|
|
encoded in ASCII. Pixel data is \fIalways\fP encoded in Silicon Graphics
|
|
order, which means that the first pixel in the frame is the lower left
|
|
pixel on the screen.
|
|
.PP
|
|
All ASCII data except the first line of the file
|
|
is in python format. This means that
|
|
outer parentheses can be ommitted, and parentheses around a tuple with
|
|
one element can also be omitted. So, the lines
|
|
.IP
|
|
.ft C
|
|
.nf
|
|
('grey',(4))
|
|
('grey',4)
|
|
'grey',4
|
|
.LP
|
|
have the same meaning.
|
|
To ease parsing in C programs, however, it is advised that there are
|
|
no parenteses around single items, and that there are parentheses around
|
|
lists. So, the second format above is preferred.
|
|
.PP
|
|
The current version is version 3, but this document will also explain
|
|
shortly what the previous formats looked like.
|
|
.SH
|
|
Header.
|
|
.PP
|
|
The header consists of three lines. The first line identifies the file
|
|
as a CMIF video file, and gives the version number.
|
|
It looks as follows:
|
|
.IP
|
|
.ft C
|
|
CMIF video 3.0
|
|
.LP
|
|
All programs expect the layout to be exactly like this, so no
|
|
extra spaces, etc. should be added.
|
|
.PP
|
|
The second line specifies the data format. Its format is a python
|
|
tuple with two members. The first member is a string giving the format
|
|
type and the second is a tuple containing type-specific information.
|
|
The following formats are currently understood:
|
|
.pT rgb
|
|
The video data is 24 bit RGB packed into 32 bit words.
|
|
R is the least significant byte, then G and then B. The top byte is
|
|
unused.
|
|
.IP
|
|
There is no type-specific information, so the complete data format
|
|
line is
|
|
.IP
|
|
.ft C
|
|
('rgb',())
|
|
.pT grey
|
|
The video data is greyscale, at most 8 bits. Data is packed into
|
|
8 bit bytes (in the low-order bits). The extra information is the
|
|
number of significant bits, so an example data format line is
|
|
.IP
|
|
.ft C
|
|
('grey',(6))
|
|
.pT yiq
|
|
The video data is in YIQ format. This is a format that has one luminance
|
|
component, Y, and two chrominance components, I and Q. The luminance and
|
|
chrominance components are encoded in \fItwo\fP pixel arrays: first an
|
|
array of 8-bit luminance values followed by a array of 16 bit chrominance
|
|
values. See the section on chrominance coding for details.
|
|
.IP
|
|
The type specific part contains the number of bits for Y, I and Q,
|
|
the chrominance packfactor and the colormap offset. So, a sample format
|
|
information line of
|
|
.IP
|
|
.ft C
|
|
('yiq',(5,3,3,2,1024))
|
|
.IP
|
|
means that the pictures have 5 bit Y values (in the luminance array),
|
|
3 bits of I and Q each (in the chrominance array), chrominance data
|
|
is packed for 2x2 pixels, and the first colormap index used is 1024.
|
|
.pT hls
|
|
The video data is in HLS format. L is the luminance component, H and S
|
|
are the chrominance components. The data format and type specific information
|
|
are the same as for the yiq format.
|
|
.pT hsv
|
|
The video data is in HSV format. V is the luminance component, H and S
|
|
are the chrominance components. Again, data format and type specific
|
|
information are the same as for the yiq format.
|
|
.pT rgb8
|
|
The video data is in 8 bit dithered rgb format. This is the format
|
|
used internally by the Indigo. bit 0-2 are green, bit 3-4 are blue and
|
|
bit 5-7 are red. Because rgb8 is treated more-or-less like yiq format
|
|
internally the type-specific information is the same, with zeroes for
|
|
the (unused) chrominance sizes:
|
|
.IP
|
|
.ft C
|
|
('rgb8',(8,0,0,0,0))
|
|
.PP
|
|
The third header line contains width and height of the video image,
|
|
in pixels, and the pack factor of the picture. For compatability, RGB
|
|
images must have a pack factor of 0 (zero), and non-RGB images must
|
|
have a pack factor of at least 1.
|
|
The packfactor is the amount of compression done on the original video
|
|
signal to obtain pictures. In other words, if only one out of three pixels
|
|
and lines is stored (so every 9 original pixels have one pixel in the
|
|
data) the packfactor is three. Width and height are the size of the
|
|
\fIoriginal\fP picture.
|
|
Viewers are expected to enlarge the picture so it is shown in the
|
|
original size. RGB videos cannot be packed.
|
|
So, a size line like
|
|
.IP
|
|
.ft C
|
|
200,200,2
|
|
.LP
|
|
means that this was a 200x200 picture that is stored as 100x100 pixels.
|
|
.SH
|
|
Frame header
|
|
.PP
|
|
Each frame is preceded by a single header line. This line contains timing information
|
|
and optional size information. The time information is mandatory, and
|
|
contains the time this frame should be displayed, in milliseconds since
|
|
the start of the film. Frames should be stored in chronological order.
|
|
.PP
|
|
An optional second number is interpreted as the size of the luminance
|
|
data in bytes. Currently this number, if present, should always be the
|
|
same as \fCwidth*height/(packfactor*packfactor)\fP (times 4 for RGB
|
|
data), but this might change if we come up with variable-length encoding
|
|
for frame data.
|
|
.PP
|
|
An optional third number is the size of the chrominance data
|
|
in bytes. If present, the number should be equal to
|
|
.ft C
|
|
luminance_size2*/(chrompack*chrompack).
|
|
.SH
|
|
Frame data
|
|
.PP
|
|
For RGB films, the frame data is an array of 32 bit pixels containing
|
|
RGB data in the lower 24 bits. For greyscale films, the frame data
|
|
is an array of 8 bit pixels. For split luminance/chrominance films the
|
|
data consists of two parts: first an array of 8 bit luminance values
|
|
followed by an array of 16 bit chrominance values.
|
|
.PP
|
|
For all data formats, the data is stored left-to-right, bottom-to-top.
|
|
.SH
|
|
Chrominance coding
|
|
.PP
|
|
Since the human eye is apparently more sensitive to luminance changes
|
|
than to chrominance changes we support a coding where we split the luminance
|
|
and chrominance components of the video image. The main point of this
|
|
is that it allows us to transmit chrominance data in a coarser granularity
|
|
than luminance data, for instance one chrominance pixel for every
|
|
2x2 luminance pixels. According to the theory this should result in an
|
|
acceptable picture while reducing the data by a fair amount.
|
|
.PP
|
|
The coding of split chrominance/luminance data is a bit tricky, to
|
|
make maximum use of the graphics hardware on the Personal Iris. Therefore,
|
|
there are the following constraints on the number of bits used:
|
|
.IP -
|
|
No more than 8 luminance bits,
|
|
.IP -
|
|
No more than 11 bits total,
|
|
.IP -
|
|
The luminance bits are in the low-end of the data word, and are stored
|
|
as 8 bit bytes,
|
|
.IP -
|
|
The two sets of chrominance bits are stored in 16 bit words, correctly
|
|
aligned,
|
|
.IP -
|
|
The color map offset is added to the chrominance data. The offset should
|
|
be at most 4096-256-2**(total number of bits). To reduce interference with
|
|
other applications the offset should be at least 1024.
|
|
.LP
|
|
So, as an example, an HLS video with 5 bits L, 4 bits H, 2 bits S and an
|
|
offset of 1024 will look as follows in-core and in-file:
|
|
.IP
|
|
.nf
|
|
.ft C
|
|
31 15 11 10 9 8 5 4 0
|
|
+-----------------------------------+
|
|
incore + 0+ 1+ S + H + L +
|
|
+-----------------------------------+
|
|
+----------+
|
|
L-array + 0 + L +
|
|
+----------+
|
|
+-----------------------+
|
|
C-array + 0+ 1+ S + H + 0 +
|
|
+-----------------------+
|