.de PP

.LP

..

.de pT

.IP \fB\\$1\fP

..

.TL

CMIF video file format

.AU

Jack Jansen

(Version of 27-Feb-92)

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.

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.

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).

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.

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 +

+-----------------------+