PACo

• Company: The Company of Science and Art

This is a format used in animations at least in Iron Helix game. It should not be confused with Cydonia Paco.

Container format

The format comes from Macintosh so all values are big-endian.

Container header:

 2 bytes - 0x0001
 2 bytes - 0x0026
 2 bytes - width
 2 bytes - height
 2 bytes - framerate (negative means there's no audio stream)
 2 bytes - flags?
 4 bytes - maximum chunk size
 4 bytes - always zero?
 4 bytes - something audio-related
 2 bytes - number of chunks
 2 bytes - number of chunks repeated
 2 bytes - always 8?
 2 bytes - always 0x600?
 4 bytes - some flags
 2 bytes - always 0?

The header is followed by 32-bit chunk sizes. After that actual chunks data is present.

Each chunk consists of several records with 4-byte header (1 byte - record type, 3 bytes - record size including the header). Known record types are:

• 0 - nop
• 1 - old initialisation data?
• 2 - new initialisation data (usually 0x30 0x00 0x00 ... meaning 8-bit with default QuickTime palette)
• 3 - delay information
• 4 - audio data (8-bit unsigned PCM)
• 5 - should not be present
• 6 - should not be present
• 7 - unknown
• 8 - video frame
• 9 - unknown
• 10 - dummy?
• 11 - end of chunk marker

Video compression

Video compression is an enhanced RLE scheme.

Frame data starts with the following header:

 2 bytes - x offset of the updated area
 2 bytes - y offset of the updated area
 2 bytes - updated area width
 2 bytes - updated area height
 1 byte  - compression method and flags
 1 byte  - padding

Compression method should be 1 or 2, known flags are 0x20 - frame uses compact RLE and 0x40 - delta frame.

Compression methods 1 and 2 are the same except that the latter codes picture in interlaced manner (i.e. first it decodes all even lines of the updated area and then all odd lines). RLE compresses each line separately so no run/copy/skip should go past the line end.

Compression format uses the following opcodes:

• 0x00 - long operation
• 0x01-0x7F - copy the same amount of pixels
• 0x80-0xFD - repeat the following value 256 - op times
• 0xFE - next byte is either the number of pixels to skip (if non-zero) or a signal of compact RLE mode
• 0xFF - pair or quad run. Read the next byte and if it is below 128 then read and repeat a pair of pixels len times, otherwise read and repeat four pixels (but 256 - len times)

Long operation (opcode 0x00) has 16-bit word specifying the actual operation (top nibble) and operation length (bottom 12 bits). Known operations are:

• 0 - raw copy pixels
• 1 - RLE
• 2 - pair RLE (read a pair of pixels and repeat it the specified number of times)
• 3 - quad RLE (read four pixels and repeat it the specified number of times)
• 4 - skip
• 5 - end current line and skip additional len lines
• 15 - not real opcode but 00 F0 00 00 is often seen at the end of frame and can serve as an end marker

Compact RLE mode works until the current line end but using nibbles to code lengths and operations and maintaining a set of 16 colours that should be used and transmitting their indices instead. Right after FE 00 there is 16-bit mask telling which colours in the set should be updated (least significant bit - first colour, top significant bit - last colour). After the mask and optional update colours actual compact opcodes follow.

Compact mode opcodes:

• 0x - low nibble is the actual operation, the following byte is operation length. Operations are: 0 - copy, 1 - run (colour index is in low nibble), 2 - pair run, 3 - quad run, 4 - skip, 5 - end of line (plus skipping additional lines);
• 1x-7x - copy 1-7 colours with the corresponding nibble indexes from the stream, low nibble of opcode byte is the first index. If the number of colours is even it is padded to the byte with zero nibble.
• 8x-Dx - repeat colour with low nibble index 16 - (op >> 4) times
• Ex - skip the number of pixels in low nibble
• Fx - pair or quad run (if low nibble is less than eight then it's a pair run, otherwise it's a quad run for 16 - (op & 0xF) times).