MultimediaWiki - User contributions [en]

Lego Pirates of the Caribbean FMV

2026-07-24T16:27:14Z

Kostya: fill description

* Game: [https://www.mobygames.com/game/77264/lego-pirates-of-the-caribbean-the-video-game/ LEGO Pirates of the Caribbean]
* Decoder: [https://github.com/Gericom/EveryFileExplorer/blob/master/LegoPirates/FMV.cs Every File Explorer REd decoder]

This seems to be a JPEG-based cutscene format with optional audio.

Header:
4 bytes - "FMV!"
2 bytes - version
2 bytes - header length
2 bytes - width
2 bytes - height
4 bytes - total number of macroblocks?
4 bytes - unknown
2 bytes - framerate
4 bytes - flags (4 - audio present)
4 bytes - unknown

Audio header (if flag bit 2 is set):
2 bytes - unknown
4 bytes - sample rate
1 byte - unknown
1 byte - unknown
1 byte - unknown
1 byte - unknown

The rest of the file seems to be composed of chunks with the following signatures and 32-bit payload sizes:
* "FMVk" - key frame
* "FMVd" - delta frame
* "FMVn" - no frame (repeat last decoded frame)
* "FMA\0" - audio data

Key frame data:
4 bytes - "FMVk"
4 bytes - data size
2 bytes - metadata size
N bytes - RLE-compressed metadata
1 byte - quality
(first frame only) Huffman data
encoded macroblocks

Delta frame data:
4 bytes - "FMVd"
4 bytes - data size
2 bytes - metadata size
N bytes - RLE-compressed metadata
1 byte - quality
encoded macroblocks

Frame metadata is macroblock coding types using RLE scheme using a twice repeated value as a trigger for run mode. Next byte in this case tells what to do (0-2: repeat last byte 1-3 times, 128-255 means this byte contains top 7 bits of run length and next byte is low 8 bits of it, otherwise it is run length and the next byte should be repeated N+1 times).

Quality value is used to generate luma and chroma quantisation matrices in the same way as <code>libjpeg</code> does.

Huffman data is stored as 16 symbol counts (for each possible bit length) followed by the symbols.

Macroblock coding types:
* 0 - skip
* 1 - motion block with 5-bit motion vector components
* 2 - fill block with three bytes, one for each plane
* 255 - DCT-coded macroblock

[[Category:Game Formats]]
[[Category:Video Codecs]]

Pelrock cutscene

2026-06-15T16:23:58Z

Kostya: fill known information

* Game: [https://www.mobygames.com/game/14161/alfred-pelrock/| Alfred Pelrock]
* File: <code>ESCENAX.SSN</code>
* Decoder: <code>github.com/scummvm/scummvm/blob/master/engines/pelrock/video.cpp</code>

This is a cutscene format used in one Spanish game. Data is organised into chunks with size being multiple of 20480 bytes (ten sectors), video data only (audio and subtitles being stored in other files), with optional RLE compression and frames being transmitted as a XOR difference from the previous frame (initial frame is assumed to be zero).

Video has fixed dimensions of 640x400.

Chunk starts with 9-byte header: 32-bit little-endian number of 20480-byte blocks in the chunk, 32-bit size, and 1-byte chunk type:
* 1 -- RLE-compressed frame
* 2 -- raw frame updates
* 3 -- end of video
* 4 -- palette
* 6 -- delay (wait 20ms)

=== RLE compression ===

RLE data starts with 32-bit data length and is coded in the same way as PCX (if top two bits are set, low six bits are the run length of the next byte value, otherwise the current byte is a literal pixel value).

=== Raw updates ===

In this case frame data is stored in packets that start immediately after 32-bit data length. Packet header: 32-bit destination offset plus one-byte copy length (zero means end of updates). E.g. first packets of full frame will look like "copy to offset 0 input 255 bytes, (255 bytes); copy to offset 255 input 255 bytes, (255 bytes); ...".

[[Category:Game Formats]]

ACG Movie

2026-05-23T09:54:22Z

Kostya: document it

* Extensions: .m24, .wdf

This is a family of auxiliary animation formats i.e. formats that are used as an animated overlay for some background and do not code whole area themselves (8-bit version does not contain image palette either). The formats employ [[Microsoft RLE]] for compression.

== 8-bit ACG movie ==

File starts with "ACG_MOVIE" string and does not seem to contain anything useful until the offset 0x24C. From there there's frame data prefixed by two 16-bit values and RLE data. The frame ends where RLE data signals end of data.

== 8-bit ACG difference movie ==

Nothing is known about it beside the fact that it starts with "ACG_DIFF8".

== 24-bit ACG movie v1 ==

Nothing is known about it beside the fact that it starts with "ACG MOVIE TRUE24-BIT".

== 24-bit ACG difference movie ==

Nothing is known about it beside the fact that it starts with "ACG_DIFF24".

== 24-bit ACG movie v2 ==

File starts with "ACG MOVIE TRUE24- V2" string followed by 16-bit number of the frames, bounding rectangle (32-bit x, y, width and height values) and 16-bit value which looks like height aligned to multiple of 4. Frames start with similar bounding rectangle, 32-bit size (repeated twice) and two 16-bit values. Frame data consists of 24-bit image data compressed with the same 8-bit RLE per plane (i.e. first it's blue component of the whole image, then green and finally red) stored one after another (decoder has to rely on the RLE signalled end-of-data to determine where next component data starts).

[[Category:Container Formats]]

Rainbow Technology F16

2026-05-23T09:34:51Z

Kostya: document it

* Company: Rainbow Technology Group of America
* Extension: .f16

This was a 16-bit (15-bit really) competitor to [[Flic Video]] as the 16-bit extensions to Flic format were not (widely) known at that time.

The format can be described as simplified FLI with just two frame types (raw and RLE-compressed) adapted for 16-bit video.

Header format:
* 6 bytes -- unknown
* 2 bytes -- number of frames?
* 2 bytes -- video width
* 2 bytes -- video height
* 2 bytes -- bits per pixel (15)
* 20 bytes -- unknown

The rest of the data is chunks with the following header:
* 2 bytes -- chunk tag (0xFF16)
* 2 bytes -- compression type (0x7B - uncompressed, 0x7C - RLE)
* 4 bytes -- total chunk size (including this header)

RLE compression is a lot like <code>DELTA_FLI</code>: it starts with two 16-bit numbers for the height of coded block and its first start line followed by line data. Line data starts with 16-bit number of lines to skip before starting decoding (except for the very first line), followed by the 16-bit number of operations on the line. Each operation consists of 16-bit skip count and 15-bit run/copy count (top bit being used to tell whether it's copy or run). Both values code data sizes in bytes.

[[Category:Container Formats]]
[[Category:Video Codecs]]

MAGIX Video

2026-05-23T09:19:59Z

Kostya: document it

* Extension: .mxv

MAGIX Video is a RIFF-inspired container for intermediate video (motion JPEG) extended to 64-bit support with both chunk types and sizes being 64-bit. Chunk names have a form of "<code>MXxxxx64</code>". Unlike RIFF there is no padding chunk sizes to 16-bit.

File starts with <code>MXRIFF64</code> <code>MXJVID64</code> list followed by stream header either in <code>MXJVHD64</code> or <code>MXJVH264</code> chunk, some other chunks and <code>MXRIFF64</code> <code>MXJVID64</code> list with frame chunks (<code>MXJVVF64</code>). At the end there may be <code>MXJVFT64</code> index chunk (just 64-bit offsets to frames).

[[Category:Container Formats]]

MVS

2026-05-23T09:07:38Z

Kostya: inter-frame DCT tile description

MVS is an extension (new coding methods) of VNC protocol. It operates on 8x8 blocks (or tiles) and employs DCT in YUV colourspace. There is no sub-sampling, so 8x8 tile codes three 8x8 block for each components (though chroma components usually have the reduced number of coded coefficients).

Packet data begins with a byte signalling its type, the rest depends on type:
* 0 - intra frame
* 1 - inter frame
* 2 - DCT quantisation tables

In general, first decoder should receive quantisation tables, then intra frame and then some inter frames (which update data transmitted in previous frames).

Bitstream is stored MSB first in big-endian format.

== Intra frame ==

Packet payload begins with its ID (0) and two bytes with DCT quantiser selectors. Then there is 24-bit big-endian size of tile metadata followed by tile metadata and the rest is tile data. Data should end with 8-bit code for 'm' (not necessarily at the byte boundary though).

Tiles can either be simple fill operations, copy already decoded tile operation, DCT block or re-using some previously decoded DCT block again.

=== Intra tile metadata ===

Tile metadata is stored in run form: there is 3-bit tile type code followed by variable-length code for the number of tiles with that type.

Tile type run codes are:
* <code>0000-1110</code> --- 1-15 tiles
* <code>11110 + 8-bit code</code> --- 16-271 tiles
* <code>111110 + 15-bit code</code> --- 16-32783 tiles
* <code>111111 + 22-bit code</code> --- 16-4194319 tiles

Tile types are:
* 0 --- fully white block
* 1 --- paint previous block again (one to the left from the current one or last one in the previous row for the first block of the row)
* 2 --- paint block from above the current position
* 3 --- black and white block: bit mask from tile data codes which pixels of the block are black (0) or white (1)
* 4 --- fill or two-colour pattern block (see below)
* 5 --- DCT block (see below)
* 6 --- cached DCT tile: get 16-bit index, draw DCT tile from the cache
* 7 --- paint last used DCT tile (either from previously decoded DCT block or last used cached one, whichever is more recent) again

=== Fill/two-colour block ===

This mode either fills tile with single colour or paints a pattern using two colours. First bit in tile data tells which mode is that, then there are 1-2 colours in 8-6-6 YUV format (8 bits per luma, top 6 bits per chroma component, see conversion formulae below) and for 2-colour mode there is fill pattern as well.

=== DCT tile ===

DCT tile comprises data for three blocks, one for each component. For encoding, RGB data is converted to YUV, FDCT is performed on each component, then DC prediction is applied, and finally all block data is coded in a special way using general codes (usually Rice codes) dependent on the coefficient position (i.e. DCs are coded in one way, coefficients 1-6 in zigzag order are coded in a different way and the rest of coefficients are coded in yet another way).

Block format:
chroma_dc_coded = get_bit();
quant_sel = get_bit() ? header_byte2 : header_byte1;
if chroma_dc_coded {
cr_blk[0] = (last_cr_dc / 2 - get_dc()) * 2;
cb_blk[0] = (last_cb_dc / 2 - get_dc()) * 2;
last_cr_dc = cr_blk[0];
last_cb_dc = cb_blk[0];
} else {
cr_blk[0] = last_cr_dc;
cb_blk[0] = last_cb_dc;
}
y_blk[0] = last_y_dc - get_dc();
last_y_dc = y_blk[0];

idx = 1;
while (idx < 6) {
add_q = quant_sel > 14 ? 2 : (quant_sel <= idx ? 16 : 8);
if (get_bit()) {
coef[idx++] = get_ac1_5_nozero() * add_q;
} else {
// decode skip/level value
if (is_skip) {
idx += value;
} else {
coef[idx++] = value * add_q;
}
}
}
while (idx < 64) {
add_q = quant_sel > 14 ? (quant_sel > idx ? 2 : 8) : (quant_sel <= idx ? 16 : 8);
if (get_bit()) {
coef[idx++] = get_ac6_63_nozero() * add_q;
} else {
// decode skip/level value
if (is_skip) {
idx += value;
} else {
coef[idx++] = value * add_q;
}
}
}

For DC prediction initial DC predictors are set to zero.

DC codes: get prefix as unary code of ones (e.g. <code>0</code> = 0, <code>1110</code> = 3), get sign bit, get mantissa bits depending on prefix, negate value if sign bit is set and return it.

Code structure:
* <code>0 s x</code> -- codes ±1
* <code>10 s x</code> -- codes ±2-3
* <code>110 s xx</code> -- codes ±4-7
* <code>11..10 s xxx</code> -- ±((prefix - 2) * 8 + <code>xxx</code>)

Coefficient 1-4 no-zero codes: get prefix as unary code of ones, get sign bit, for prefixes 0-3 code is ±<code>(prefix * 4) + get_bits(2) + 2</code>, for other prefixes it is ±<code>(prefix - 4) * 8 + get_bits(3) + 18</code>.

Coefficient 6-63 no-zero codes are similar to DC codes: get prefix as unary code of ones (e.g. <code>0</code> = 0, <code>1110</code> = 3), get sign bit, get mantissa bits depending on prefix, negate value if sign bit is set and return it.

Code structure:
* <code>0 s x</code> -- codes ±2-3
* <code>10 s xx</code> -- codes ±4-7
* <code>1..10 s xxx</code> -- ±((prefix - 1) * 8 + <code>xxx</code>)

Other coefficient codes use special scheme signalled by 2-bit code type:
* 0 -- new level value is 1
* 1 -- new skip value (see below)
* 2 -- re-use previous non-zero coefficient value
* 3 -- re-use negated previous non-zero coefficient value

Skip value codes:
* <code>1</code> -- end of block
* <code>0 00</code> -- 3
* <code>0 01</code> -- 4
* <code>0 10</code> -- 5
* <code>0 11 xxx yyy ...</code> -- 6+n (read 3-bit values and add them to the initial value of 6, stop when 3-bit value is not equal to 7)

=== Cached DCT tile ===

Decoder maintains a circular buffer of 65000 (not 65536!) DCT tiles. Every time a DCT block is decoded, it is put into this buffer and may be re-used later.

== Inter frame ==

In this mode tile may reference previously decoded tile data e.g. re-use copy operation or update previously decoded DCT coefficients.

Like intra frame, packet data starts with ID and two bytes of header, telling the maximum number of Cr and Cb coefficients that may be coded in DCT blocks. Data should end with <code>"mvs\0"</code> sequence (not necessarily at the byte boundary though).

Unlike intra frame, this mode stores tile types and data interleaved, without any run coding and there are only four types (requiring two bits):
* 0 -- skip (leave current block unchanged)
* 1 -- DCT update tile
* 2 -- repeat copy operation (i.e. if intra frame tile at the current position copied last/top block, copy it again as well)
* 3 -- re-use cached DCT tile

=== DCT update tile ===

This DCT tile uses DCT coefficients data (luma block and DCs from chroma blocks) as its base (without updating the reference).

=== Cached DCT tile ===

Unlike intra mode, there is a flag telling whether decoder should read full 16-bit tile index or use the next tile in cache.

For example, if first e.g. tile 24 is selected from the cache, next operation may simply tell to use the next one (tile 25) instead of sending its index explicitly.

DCT data starts with 6-bit index of last non-zero luma coefficient (in zigzag order).

Coding mode for luma block depends on reference block quantiser selector.

If that selector value is less than 15 then coefficients are coded as:
* when reference coefficient is non-zero and only DC is coded -- as a signed 4-bit difference (with sign inverted if base coefficient is negative);
* when reference coefficient is non-zero -- as a signed 3-bit difference (with sign inverted if base coefficient is negative);
* when reference coefficient is zero -- the same way as DC difference in intra DCT tiles.

Otherwise there's also a different mode for small coefficients: -1/0/1 for zero base coefficients (<code>11</code>, <code>0</code> and <code>10</code> correspondingly) and 0/&mnplus;1 for non-zero ones. The rest is coded as DC differences.

Chroma DCT blocks use the same small coefficients mode to code DCs (as that's the only coefficient with the reference available) and JPEG-style AC coding (zero-run plus number of bits in coefficient plus coefficient mantissa bits).

== DCT quantisation tables ==

The packet should be 129 bytes long: packet ID and two 64-byte quantisation tables (for luma and for chroma).

== YUV colourspace ==

The colourspace seems to use these coefficients:
Y = 0.314520 * R + 0.572543 * G + 0.112937 * B
Cr = 0.527292 * R - 0.440418 * G - 0.086874 * B
Cb = -0.177695 * R - 0.323471 * G + 0.501166 * B

Or, for the reverse operation
R = Y + 1.3 * Cr
G = Y - 0.71414 * Cr - 0.34914 * Cb
B = Y + 1.77 * Cb

[[Category:Networking Protocols]]

MVS

2026-05-22T17:02:35Z

Kostya: start filling known information

MVS is an extension (new coding methods) of VNC protocol. It operates on 8x8 blocks (or tiles) and employs DCT in YUV colourspace. There is no sub-sampling, so 8x8 tile codes three 8x8 block for each components (though chroma components usually have the reduced number of coded coefficients).

Packet data begins with a byte signalling its type, the rest depends on type:
* 0 - intra frame
* 1 - inter frame
* 2 - DCT quantisation tables

In general, first decoder should receive quantisation tables, then intra frame and then some inter frames (which update data transmitted in previous frames).

Bitstream is stored MSB first in big-endian format.

== Intra frame ==

Packet payload begins with its ID (0) and two bytes with DCT quantiser selectors. Then there is 24-bit big-endian size of tile metadata followed by tile metadata and the rest is tile data. Data should end with 8-bit code for 'm' (not necessarily at the byte boundary though).

Tiles can either be simple fill operations, copy already decoded tile operation, DCT block or re-using some previously decoded DCT block again.

=== Intra tile metadata ===

Tile metadata is stored in run form: there is 3-bit tile type code followed by variable-length code for the number of tiles with that type.

Tile type run codes are:
* <code>0000-1110</code> --- 1-15 tiles
* <code>11110 + 8-bit code</code> --- 16-271 tiles
* <code>111110 + 15-bit code</code> --- 16-32783 tiles
* <code>111111 + 22-bit code</code> --- 16-4194319 tiles

Tile types are:
* 0 --- fully white block
* 1 --- paint previous block again (one to the left from the current one or last one in the previous row for the first block of the row)
* 2 --- paint block from above the current position
* 3 --- black and white block: bit mask from tile data codes which pixels of the block are black (0) or white (1)
* 4 --- fill or two-colour pattern block (see below)
* 5 --- DCT block (see below)
* 6 --- cached DCT tile: get 16-bit index, draw DCT tile from the cache
* 7 --- paint last used DCT tile (either from previously decoded DCT block or last used cached one, whichever is more recent) again

=== Fill/two-colour block ===

This mode either fills tile with single colour or paints a pattern using two colours. First bit in tile data tells which mode is that, then there are 1-2 colours in 8-6-6 YUV format (8 bits per luma, top 6 bits per chroma component, see conversion formulae below) and for 2-colour mode there is fill pattern as well.

=== DCT tile ===

DCT tile comprises data for three blocks, one for each component. For encoding, RGB data is converted to YUV, FDCT is performed on each component, then DC prediction is applied, and finally all block data is coded in a special way using general codes (usually Rice codes) dependent on the coefficient position (i.e. DCs are coded in one way, coefficients 1-6 in zigzag order are coded in a different way and the rest of coefficients are coded in yet another way).

Block format:
chroma_dc_coded = get_bit();
quant_sel = get_bit() ? header_byte2 : header_byte1;
if chroma_dc_coded {
cr_blk[0] = (last_cr_dc / 2 - get_dc()) * 2;
cb_blk[0] = (last_cb_dc / 2 - get_dc()) * 2;
last_cr_dc = cr_blk[0];
last_cb_dc = cb_blk[0];
} else {
cr_blk[0] = last_cr_dc;
cb_blk[0] = last_cb_dc;
}
y_blk[0] = last_y_dc - get_dc();
last_y_dc = y_blk[0];

idx = 1;
while (idx < 6) {
add_q = quant_sel > 14 ? 2 : (quant_sel <= idx ? 16 : 8);
if (get_bit()) {
coef[idx++] = get_ac1_5_nozero() * add_q;
} else {
// decode skip/level value
if (is_skip) {
idx += value;
} else {
coef[idx++] = value * add_q;
}
}
}
while (idx < 64) {
add_q = quant_sel > 14 ? (quant_sel < idx ? 2 : 8) : (quant_sel <= idx ? 16 : 8);
if (get_bit()) {
coef[idx++] = get_ac6_63_nozero() * add_q;
} else {
// decode skip/level value
if (is_skip) {
idx += value;
} else {
coef[idx++] = value * add_q;
}
}
}

For DC prediction initial DC predictors are set to zero.

DC codes: get prefix as unary code of ones (e.g. <code>0</code> = 0, <code>1110</code> = 3), get sign bit, get mantissa bits depending on prefix, negate value if sign bit is set and return it.

Code structure:
* <code>0 s x</code> -- codes ±1
* <code>10 s x</code> -- codes ±2-3
* <code>110 s xx</code> -- codes ±4-7
* <code>11..10 s xxx</code> -- ±((prefix - 2) * 8 + <code>xxx</code>)

Coefficient 1-4 no-zero codes: get prefix as unary code of ones, get sign bit, for prefixes 0-3 code is ±<code>(prefix * 4) + get_bits(2) + 2</code>, for other prefixes it is ±<code>(prefix - 4) * 8 + get_bits(3) + 18</code>.

Coefficient 6-63 no-zero codes are similar to DC codes: get prefix as unary code of ones (e.g. <code>0</code> = 0, <code>1110</code> = 3), get sign bit, get mantissa bits depending on prefix, negate value if sign bit is set and return it.

Code structure:
* <code>0 s x</code> -- codes ±2-3
* <code>10 s xx</code> -- codes ±4-7
* <code>1..10 s xxx</code> -- ±((prefix - 1) * 8 + <code>xxx</code>)

Other coefficient codes use special scheme signalled by 2-bit code type:
* 0 -- new level value is 1
* 1 -- new skip value (see below)
* 2 -- re-use previous non-zero coefficient value
* 3 -- re-use negated previous non-zero coefficient value

Skip value codes:
* <code>1</code> -- 1
* <code>0 00</code> -- 3
* <code>0 01</code> -- 4
* <code>0 10</code> -- 5
* <code>0 11 xxx yyy ...</code> -- 6+n (read 3-bit values and add them to the initial value of 6, stop when 3-bit value is not equal to 7)

=== Cached DCT tile ===

Decoder maintains a circular buffer of 65000 (not 65536!) DCT tiles. Every time a DCT block is decoded, it is put into this buffer and may be re-used later.

== Inter frame ==

In this mode tile may reference previously decoded tile data e.g. re-use copy operation or update previously decoded DCT coefficients.

Like intra frame, packet data starts with ID and two bytes of header, telling the maximum number of Cr and Cb coefficients that may be coded in DCT blocks. Data should end with <code>"mvs\0"</code> sequence (not necessarily at the byte boundary though).

Unlike intra frame, this mode stores tile types and data interleaved, without any run coding and there are only four types (requiring two bits):
* 0 -- skip (leave current block unchanged)
* 1 -- DCT update block
* 2 -- repeat copy operation (i.e. if intra frame tile at the current position copied last/top block, copy it again as well)
* 3 -- re-use cached DCT tile

=== DCT update block ===

**TODO**

=== Cached DCT tile ===

Unlike intra mode, there is a flag telling whether decoder should read full 16-bit tile index or use the next tile in cache.

For example, if first e.g. tile 24 is selected from the cache, next operation may simply tell to use the next one (tile 25) instead of sending its index explicitly.

== DCT quantisation tables ==

The packet should be 129 bytes long: packet ID and two 64-byte quantisation tables (for luma and for chroma)

== YUV colourspace ==

The colourspace seems to use these coefficients:
Y = 0.314520 * R + 0.572543 * G + 0.112937 * B
Cr = 0.527292 * R - 0.440418 * G - 0.086874 * B
Cb = -0.177695 * R - 0.323471 * G + 0.501166 * B

Or, for the reverse operation
R = Y + 1.3 * Cr
G = Y - 0.71414 * Cr - 0.34914 * Cb
B = Y + 1.77 * Cb

[[Category:Networking Protocols]]

Factor 5 VID1

2026-04-23T16:29:02Z

Kostya: keep updating

* Company: Factor 5
* Extension: vid
* Game: [https://www.mobygames.com/game/9211/enter-the-matrix/ Enter the Matrix (Gamecube version)]
* demuxer code: [https://github.com/librempeg/librempeg/blob/master/libavformat/vid1.c librempeg]

This is a format used in at least one Gamecube game. VID1 format is not merely a container format but a proprietary video codec used in that container as well.

== Container format ==

This a typical chunked format starting with "VID1" header chunk, "HEAD" chunk containing stream headers, and "FRAM" chunks containing both video ("VIDD") and audio ("AUDD") data.

Audio codecs include PCM, variations of IMA ADPCM, or Vorbis.

== Video codec ==

VID1 video codec is a modification of MPEG-4 ASP.

Picture header:
* 16 bits -- ignored (sync marker?)
* 2 bits -- frame type (0 - I, 1 - P, 2 - B, 3 - S)
* 1 bit -- extended information present
* (extended information if present)
* 1 bit -- rounding control
* 3 bits -- DC quantiser threshold index (<code>intra_dc_vlc_thr</code>)
* 5 bits -- quantiser
* (non-I frames) 3 bits -- <code>vop_fcode_forward</code>
* (B-frame only) 3 bits -- <code>vop_fcode_backward</code>
* 32 bits -- timecode
* (S-frame only) GMC/sprite information
* alignment to byte boundary

Extended information:
* 1 bit -- sprite information is present
* (if sprite information is present) 2 bits -- number of sprites?
* (if sprite information is present) 2 bits -- sprite MV resolution?
* 1 bit -- extended quantisation
* (if extended quantisation) 1 bit -- luma qmat present
* (if extended quantisation and luma qmat present) 8x8 bits -- luma qmat
* (if extended quantisation) 1 bit -- chroma qmat present
* (if extended quantisation and chroma qmat present) 8x8 bits -- chroma qmat
* 1 bit -- ignored
* 1 bit -- ignored

I-frames consists of macroblocks with the following layout:
* standard I MCBPC
* 1 bit -- AC prediction enabled
* I CBPY
* (if dquant is signalled) 2 bits -- dquant
* block data (likely just like ISO 14496-2 defines it)

P-frame macroblock layout:
* 1 bit -- skip flag (if set, no further information is transmitted for the MB)
* standard P MCBPC
* (for I-type MBs decoding is the same as in I-frames)
* 1 bit -- mcsel?
* P CBPY
* (for MB type 1 only) 2 bits -- dquant
* 1 or 4 motion vectors (with residual, just like ISO 14496-2)
* block data

B-frame macroblock layout:
* 1 bit -- skip flag (if set, no further information is transmitted for the MB)
* 1 bit -- coded MB
* 1-4 bits -- macroblock type (as in table B-4 of ISO 14496-2)
* (if MB is coded) 6 bits -- CBP
* (if not direct MB and CBP is non-zero) 1-2 bits -- dbquant
* (if applicable) forward/backward MV
* block data

Motion compensation is normal halfpel.

[[Category:Video Codecs]]
[[Category:Container Formats]]
[[Category:Game Formats]]

Factor 5 VID1

2026-04-22T17:12:10Z

Kostya: start to fill some information

* Company: Factor 5
* Extension: vid
* Game: [https://www.mobygames.com/game/9211/enter-the-matrix/ Enter the Matrix (Gamecube version)]
* demuxer code: [https://github.com/librempeg/librempeg/blob/master/libavformat/vid1.c librempeg]

This is a format used in at least one Gamecube game. VID1 format is not merely a container format but a proprietary video codec used in that container as well.

== Container format ==

This a typical chunked format starting with "VID1" header chunk, "HEAD" chunk containing stream headers, and "FRAM" chunks containing both video ("VIDD") and audio ("AUDD") data.

Audio codecs include PCM, variations of IMA ADPCM, or Vorbis.

== Video codec ==

VID1 video codec is a modification of MPEG-4 ASP.

Picture header:
* 16 bits -- ignored (sync marker?)
* 2 bits -- frame type (0 - I, 1 - P, 2 - B, 3 - S)
* 1 bit -- extended information present
* (extended information if present)
* 1 bit -- ?
* 3 bits -- DC quantiser threshold index (<code>intra_dc_vlc_thr</code>)
* 5 bits -- quantiser
* (non-I frames) 3 bits -- something that seems to be used only in B-frames
* (B-frame only) 3 bits -- ?
* 32 bits -- timecode?
* (frame type 3 only) GMC/sprite information
* alignment to byte boundary

Extended information:
* 1 bit -- another extended bit
* (if another extended bit is set) 2 bits -- ?, used in sprite information
* (if another extended bit is set) 2 bits -- ?
* 1 bit -- extended quantisation
* (if extended quantisation) 1 bit -- luma qmat present
* (if extended quantisation and luma qmat present) 8x8 bits -- luma qmat
* (if extended quantisation) 1 bit -- chroma qmat present
* (if extended quantisation and chroma qmat present) 8x8 bits -- chroma qmat
* 1 bit -- ignored
* 1 bit -- ignored

I-frames consists of macroblocks with the following layout:
* standard I MCBPC
* 1 bit -- AC prediction enabled
* I CBPY
* (if dquant is signalled) 2 bits -- dquant
* block data (likely just like ISO 14496-2 defines it)

P-frame macroblock layout:
* 1 bit -- skip flag (if set, no further information is transmitted for the MB)
* standard P MCBPC
* (for I-type MBs decoding is the same as in I-frames)
* 1 bit -- mcsel?
* P CBPY
* (for MB type 1 only) 2 bits -- dquant
* 1 or 4 motion vectors (with residual, just like ISO 14496-2)
* block data

Motion compensation is normal halfpel.

[[Category:Video Codecs]]
[[Category:Container Formats]]
[[Category:Game Formats]]

Adorage effects codec

2026-04-17T16:10:12Z

Kostya: yet another simple codec

* Company: proDAD
* FOURCC: pDAD

This is a codec used to store effects for proDAD Adorage video editor.

Each frame actually consists of two images, actual picture and its alpha mask. Usually it is JPEG image with PNG alpha mask but JPEG image with JPEG mask samples are also known and other combinations are theoretically possible.

Frame format:
* 4 bytes -- header size (12 bytes)
* 2 bytes -- image part type (<code>JP</code> for JPEG, <code>PG</code> for PNG)
* 2 bytes -- alpha mask type (in the same format)
* 4 bytes -- unknown, usually zero
* 4 bytes -- image part size
* 4 bytes -- alpha part size
* N bytes -- image picture
* M bytes -- alpha picture

[[Category:Video Codecs]]

MoviePak

2026-04-17T15:59:54Z

Kostya: add description

* Company: RasterOps

This is a simple [[JPEG]]-based video codec for Classic Mac QuickTime.

Frame format:
* 2 bytes -- frame width
* 2 bytes -- frame height
* 4 bytes -- first field size (or whole frame for non-interlaced files)
* 4 bytes -- second field size (0 for non-interlaced files)
* 64 bytes -- luma quantisation matrix
* 64 bytes -- chroma quantisation matrix
* N bytes -- first field data
* M bytes -- second field data (if present)

Field data is raw (non-escaped) JPEG data for 4:2:2 subsampling.

[[Category:Video Codecs]]

PDQ2

2026-04-17T15:54:31Z

Kostya: add description

* FOURCC: PDQ2
* Game: [https://www.mobygames.com/game/6145/the-incredible-hulk-the-pantheon-saga/ The Incredible Hulk: The Pantheon Saga]

This is a codec used in DOS and Saturn versions of one game and there's not much known about it (not even the proper name). From compression point of view the codec operates on 4x4 tiles that can be either coded raw or copied from some other place in the frame. DOS version allows additional LZ compression of frame data. Also while Saturn version encodes 16-bit pixels, DOS version works on 8-bit paletted format.

Frame structure (all multi-byte values endianness is native to the platform i.e. LE for DOS and BE for Saturn):
* 1 byte -- frame type (0 - DOS normal frame, 1 - DOS packed frame, 0x80 - Saturn frame)
* 2 bytes -- if zero frame should be cleared
* 2 bytes -- size of opcodes part
* 2 bytes -- size of motion vectors part
* 2 bytes -- unknown data part
* N bytes -- opcodes
* X bytes -- unknown data
* M bytes -- MV data
* P bytes -- colour data

Decoding goes as following: while not all tiles are processed read opcode, depending on it read motion vector or colour data, paint/copy tile (or several, if the opcode signals it).

Known opcodes:
* <code>0x85</code> -- motion tile, motion vector is coded as two signed 16-bit ints
* <code>0x86</code> -- invalid opcode
* <code>0x87</code> -- modifier; read next opcode, its top bit tells if it's a tile run or a tile skip minus one
* <code>0x88</code> -- motion tile, motion vector is coded as two bytes, unsigned for X component and signed for Y component
* <code>0x89</code> -- raw tile, read 16 pixel values from colour data for it
* <code>0x8A</code> -- motion tile, motion vector is coded as two bytes, X is in -256..-1 range, Y is in -128..127 range
* all other opcodes are for motion tiles, coding MV as signed nibbles e.g. <code>0xC4</code> corresponds to <code>(4,-4)</code>

[[Category:Game Formats]]
[[Category:Video Codecs]]
[[Category:Video FourCCs]]

DMV

2026-01-24T10:45:33Z

Kostya: fill information

* Company: Brainstorm Technology
* Extensions: dmv, mov

This is a video format that is remarkable for coding data for two video frames at one. It has no specific header and frames are always stored in blocks of size 0xAB15 bytes even if data may not make full use of it.

Block starts with 16-bit size of pixel data, 16-bit size of packed tile indices, 253-colour VGA palette (first three colours are unused), pixel data, and LZ77-compressed tile indices. Audio part always starts at offset 0x9D4D.

Frames are coded by splitting a pair of frames into 2x2x2 blocks and painting them with 1-8 colours (from pixel data) using one of 154 pre-defined patterns.

LZ77 compression scheme opcodes (in binary):
* <code>000xxxxx</code> -- copy <code>xxxxx</code>+1 bytes from input
* <code>001xxxxx yyyyyyyy</code> -- copy <code>yyyyyyyyxxxxx</code>+1 bytes from input
* <code>010xxxxx yyyyyyyy</code> -- copy <code>xxxxx</code>+1 bytes from already decoded output using offset <code>yyyyyyyy</code>+4
* <code>011xxxxx yyyyyyyy zzzzzzzzz</code> -- copy <code>yyyyyyyyxxxxx</code>+1 bytes from already decoded output using offset <code>yyyyyyyy</code>+4
* <code>100xxxxx yyyyyyyy zzzzzzzzz</code> -- copy <code>xxxxx</code>+1 bytes from already decoded output using offset <code>zzzzzzzzyyyyyyyy</code>+4
* <code>101xxxxx wwwwwwww yyyyyyyy zzzzzzzzz</code> -- copy <code>wwwwwwwwxxxxx</code>+1 bytes from already decoded output using offset <code>zzzzzzzzyyyyyyyy</code>+4

== Games using DMV ==
* [https://www.mobygames.com/game/15510/f1-manager/ F1 Manager (1996)]
* [https://archive.org/details/msdos_Mystery_of_Plastic_City_Part_II_The_1996 Mystery of Plastic City Part II]
* some other games by [https://www.mobygames.com/company/565/software-2000/ Software 2000]
* various trailers and even interactive movie CDs

[[Category: Game Formats]]

Sesame Street STR

2026-01-24T10:10:22Z

Kostya: fill information

This is a simple video format used in some Sesame Street related games.

File header:
4 bytes - "STHD"
4 bytes - version (should be 0x100)
4 bytes - unknown
4 bytes - unknown, usually zero
4 bytes - audio sample rate
2 bytes - bits per audio sample
2 bytes - padding?

Data is organised into chunks, <code>"GRPH"</code> for images and palettes, <code>"SND "</code> for audio. Each chunk beside 32-bit usually has one nested subchunk telling what kind of data it is: for video it is either <code>"PAL "</code> for palette or <code>"PIXX"</code> for image; for audio it is <code>"SSMP"</code>.

Image (sub)chunk has dimensions in its header and stores raw data in permuted form: by VGA bank (i.e. every fourth column) where data is also 4-way interleaved.

[[Category: Game Formats]]

Celestial Impact DXV

2026-01-24T10:00:18Z

Kostya: Created page with "This is a simple RLE-based format used in Celestial Impact intro file. First 32-bit value in the file is the number of frames, then frames follow (each prefixed with 32-bit size). Frame data is 141172 bytes of data compressed with RLE; this data includes 400x300 image, 768 bytes of palette, and seemingly unused data. RLE compression is simple: top bit of the opcode tells whether it is a run or copy, bottom 7 bits tell run/copy length. Category: Game Formats"

This is a simple RLE-based format used in Celestial Impact intro file.

First 32-bit value in the file is the number of frames, then frames follow (each prefixed with 32-bit size). Frame data is 141172 bytes of data compressed with RLE; this data includes 400x300 image, 768 bytes of palette, and seemingly unused data. RLE compression is simple: top bit of the opcode tells whether it is a run or copy, bottom 7 bits tell run/copy length.

[[Category: Game Formats]]

NAF

2026-01-24T09:55:27Z

Kostya: fill information

* Company: Ninell
* Extension: naf, ngf (for images)

This is a simple raw container format that is usually compressed with <code>GZip</code> first. It seems to be employed on some companion disks to certain Central European game magazines like Secret Service or Score.

File header:
3 bytes - "NAF" (animation) or "NGF" (image)
1 bytes - major version? (always 1)
1 bytes - minor version? (always 0)
2 bytes - width
2 bytes - height
768 bytes - VGA palette for videos or full-range palette for images

Picture or animation frames are just raw data without any additional compression or reordering.

[[Category:Container Formats]]

MGIF

2026-01-24T09:44:36Z

Kostya: fill information

* Company: Napoleon Games s.r.o.
* Extension: mgf
* Game: [https://www.mobygames.com/game/55639/gates-of-skeldal/ Gates of Skeldal]

This is a video format employing LZW compression (hence the name). Beside that it does not seem to have anything common with GIF.

Video is organised into frame blocks that may contain several chunks with e.g. video or audio data with video data employing LZW compression. One remarkable thing about LZW compression scheme employed here is that it uses delta compression: actual bytes are coded as a difference to the previously decoded value (or 0 after each LZW restart). Images are always 320x180.

File header:
6 bytes - "MGIF97"
3 bytes - unknown
4 bytes - number of blocks
582 bytes - unknown/ignored (data starts at offset 0x253)

Each block starts with a byte telling number of chunks in it and 24-bit size. Each chunk also starts with 8-bit type and 24-bit size. Known chunk types are:
* 1 -- intra frame (LZW-compressed image)
* 2 -- inter frame (LZW-compressed delta data)
* 3 -- RGB555 palette
* 4 -- audio

Inter frames data is organised (after LZW) into two parts (opcodes and pixel data) with 32-bit value in the very beginning being the pixel data offset. Decoding is rather simple: if top two bits of the opcode are set, end this line and skip following number of lines as defined in low 6 bits of the opcode; otherwise opcode is a number of pixel pairs to copy.

[[Category: Game Formats]]

Dark Moon UM

2026-01-24T09:29:17Z

Kostya: fill information

* Company: Crossroads
* Extension: um
* Game: [https://www.mobygames.com/game/25567/dark-moon/ Dark Moon]

This is a raw video stream without any header. Frames are 256x128 pixels large stored in VGA banks order (i.e. every fourth pixels on a line) followed by VGA palette.

[[Category: Game Formats]]

GRN

2026-01-23T10:26:44Z

Kostya: fill information

* Company: Microids
* Extensions: grn, anm
* Game: [https://www.mobygames.com/game/11809/ultimate-domain/ Ultimate Domain (aka Genesia)]

This is a video format that has chunked video stream interleaved with audio data if present. If file header indicates audio, then it gets padded to 2kB, followed by the signalled number of 2kB sectors of initial audio data and then it is 8kB of video stream followed by 2kB of audio followed by 8kB of video stream... Without audio there is no header padding or audio sectors present. Video data may employ RLE and/or LZSS for compression.

Header format:
4 bytes - "ANIM"
4 bytes - data offset
2 bytes - width
2 bytes - height
2 bytes - depth (8 bits per pixel)
2 bytes - number of video chunks minus one
4 bytes - delay in milliseconds between frames
4 bytes - unknown
2 bytes - unknown
2 bytes - unknown
4 bytes - number of 2kB initial audio sectors
N*2 bytes - video chunk sizes

Known chunks are:
* "PAL\x00" -- palette data
* "IMAGE" -- uncompressed image
* "LZIM" -- LZSS-compressed image
* "FRM2" -- RLE-compressed image
* "LZF2" -- LZSS compressed data for RLE-compressed image

RLE compression resembles FLI but it operates on pairs of pixels. First two 16-bit values define from which line to start decoding and how many lines to process. For each line there's a byte telling how many skip/paint operations are there (1 - skip, 2 - skip, paint, 3 - skip, paint, skip etc), skip operation is one byte telling how many pairs of pixels to skip, paint operation is a signed byte value, non-negative values telling how many bytes to copy from input, negative values telling how many times to repeat the pixel pair from input.

[[Category: Game Formats]]

AMF

2026-01-23T10:10:41Z

Kostya: update information for CITY 2000 flavour

* Extension: amf
* Samples: [http://samples.mplayerhq.hu/game-formats/amf/ http://samples.mplayerhq.hu/game-formats/amf/]

''Not to be confused with [[Asylum Music Format]]''

AMF is a very simple video file format used in the game [http://www.mobygames.com/game/dos/manic-karts Manic Karts] and [https://www.mobygames.com/game/21988/city-2000/ C.I.T.Y. 2000].
Contains [[RLE]]-encoded palettized video and optionally audio (in C.I.T.Y. 2000).

== File Format ==

All numbers are little-endian. File begins with an 8-byte header:

u16 numframes -- number of frames
u16 width -- frame width
u16 height -- frame height
u16 unknown -- unknown/unused, always 2

and is followed by at least numframes + 1 frame chunks. Each frame chunk begins with a short header:

u8 type -- chunk type
u16 size -- chunk payload size (w/o this header)

and then followed by a chunk payload.

Observed chunk types:
* 0x3D - audio data (6-byte header followed by 11kHz 8-bit mono PCM)
* 0x3E - palette chunk (always first chunk in file) Payload format:
u8 firstcolor -- first color of palette to update (always 64)
RGB palette[256-firstcolor] -- new palette entries (always 256-64 = 192 triplets), 6-bits [[DAC]] values
* 0x3F - video frame chunk (a video file has total numframes chunks of this type) Contains compressed video data
* all other chunk types are ignored/skipped.

Note: palette can not be changed during playback. Playback rate is about 10 fps.

== Video Decompression ==

while input buffer is not exhausted
tag = next byte of input
tag is:
< 0x20 : skip (tag) pixels
== 0x20 : skip (DecodeLength) pixels
< 0x3F : fill (tag - 0x21 + 2) pixels with the next byte of input
== 0x3F : fill (DecodeLength) pixels with the next byte of input
>= 0x40 : draw (tag)

DecodeLength loads variable-sized length value:

length = 32
repeat
delta = next byte of input
length += delta
until delta != 0xFF

== Trivia ==

The MANIC.AMF file has several [[BMP]] files attached at the end.

[[Category:Game Formats]]
[[Category:Formats missing in FFmpeg]]

Arc Developments HUF

2026-01-23T10:06:56Z

Kostya: fill information

* Company: Arc Developments Limited
* Extension: huf
* Game: [https://www.mobygames.com/game/31064/johnny-bazookatone/ Johnny Bazookatone]

This is a video format employing RLE and static Huffman compression (symbol weights for which are transmitted in the header). Audio format is 8-bit mono 22kHz PCM.

File header:
8 bytes - "[AVF-95]"
2 bytes - width
2 bytes - height
4 bytes - number of frames
9 bytes - unknown
256 bytes - weights
132300 bytes - initial audio data

Frames start with 32-bit size and 8-bit type (0 - intra, 1 - inter) followed by VGA palette for 128 colours and Huffman-compressed data. Last 1470 bytes of the frame are audio data.

After decompressing video data, intra or inter RLE should be applied. Intra RLE is trivial (top bit of the opcode is run flag, bottom 7 bits are pixel value; when run flag is set, next byte tells how many times to repeat the pixel instead of just once with zero value coding end of frame). Inter RLE uses the following opcodes (the number of those opcodes is the first 16 bits of video data): <code>0x00</code> -- read 16-bit value and skip that amount of pixels, <code>0x01..0x7F</code> -- read byte value and skip that many pixels, then read 1..127 pixels, <code>0x80..0xFF</code> -- read byte value and skip that many pixels, then read colour value and repeat it 128..1 times.

[[Category: Game Formats]]

Interactive Pictures VID

2026-01-23T09:53:26Z

Kostya: fill information

* Company: [https://www.mobygames.com/company/14057/interactive-pictures/ Interactive Pictures]
* Extensions: evd, fvd, gvd

This is a format used in at least DOS version of a poker game by the company.

File header:
4 bytes - "VID\x01"
4 bytes - number of frames
4 bytes - unknown
1 byte - unknown, tile size?
2 bytes - width
2 bytes - height
1 byte - unknown
1 byte - frames per second
2 bytes - number of colours
4 bytes - sample rate
231 bytes - padding to 256 bytes
C*3 bytes - VGA palette

Frame data starts with 16-bit sizes for audio, palette update and video parts. Palette updates are put at the end of palette (i.e. usually low 128 colours are transmitted in the header and top 128 colours are transmitted and updated by the frame data).

Video is coded in 8x8 tiles using following opcodes:
* <code>0x00</code> -- raw tile
* <code>0x01..0x10</code> -- 2D RLE: read 64 bits telling where new colour value should be used and fill tile using one of 16 pre-defined scan orders
* <code>0x80</code> -- read 64-bit mask and colour value, update tile with this new value in the positions where mask is set
* <code>0x81</code> -- read 64-bit mask and colour pair, paint tile using mask to select one of those colours
* <code>0xFB</code> -- read 4 colours and 64x2-bit index array, paint tile using appropriate colours
* <code>0xFD</code> -- read 16 colours and 64x4-bit index array, paint tile using appropriate colours
* <code>0xFF</code> -- read colour value, fill tile with it

[[Category: Game Formats]]

Archimedean Dynasty MVI

2026-01-23T09:36:49Z

Kostya: fill information

* Extension: mvi
* Company Massive Development GmbH

This is a video format used in [https://www.mobygames.com/game/2881/archimedean-dynasty/ Schleichfahrt] game that employs LZW compression.

File header:
4 bytes - 1 (version?)
4 bytes - unknown
4 bytes - width
4 bytes - height
4 bytes - number of frames
4 bytes - unknown
4 bytes - unknown (always 61?)
4 bytes - frames per second
4 bytes - audio present
4 bytes - number of channels
4 bytes - sample rate
4 bytes - bits per audio sample
N bytes - frame table

Frame table consists of the following records:
4 bytes - frame type
4 bytes - unknown
4 bytes - frame size
4 bytes - offset

Frame types are:
* 1 -- intra frame
* 2 -- inter frame
* 3 -- monaural audio
* 4 -- stereo audio
* 5 -- palette (sometimes followed by some table)

Intra frames start with 32-bit packed and unpacked sizes for the frame pixels followed by LZW-compressed data if packed size is smaller (and theoretically raw data otherwise). LZW compression is remarkable for mapping 0 to explicit dictionary size bumping, 1 to dictionary reset, 2 to data end and 3..258 to actual symbols.

Inter frames consist of two parts, pixel data and mask data telling where to put those pixels at. Packed and unpacked sizes for both parts are transmitted before actual data. If packed and unpacked sizes are the same, data is unpacked; otherwise LZW compression is used.

[[Category: Game Formats]]

FLK

2026-01-21T04:56:45Z

Kostya: fill information

This is an LZW-based format used in some Italian adult game called Selen.

Video consists of one or more blocks of frames with the same palette.

Block header:
4 bytes - number of frames
4 bytes - video size
4 bytes - width
4 bytes - height
4 bytes - frame table size (should be 64*nframes)
12 bytes - unknown
4 bytes - suggested unpacked data buffer size
16 bytes - unknown
N bytes - frame table
512 bytes - RGB555 palette

Frame table record:
8 bytes - unknown
4 bytes - offset to opcodes
4 bytes - opcodes size
8 bytes - unknown
4 bytes - offset to pixel data
4 bytes - pixel data size
4 bytes - offset to audio data
4 bytes - audio data size
4 bytes - frame data end?
4x2 bytes - bounding rectangle for changed area
12 bytes - unknown

Frame data consists of opcodes and LZW-compressed pixel data. If opcodes are not present, pixel data constitutes raw frame.

Opcodes (in binary):
* <code>000nnnnn</code> -- output 0..31 pixels
* <code>001nnnnn nnnnnnnn</code> -- output 0..8191 pixels
* <code>010nnnnn</code> -- run of 0..31 pixels
* <code>011nnnnn nnnnnnnn</code> -- run of 0..8191 pixels
* <code>100nnnnn</code> -- restore 0..31 pixels of the initial background
* <code>101nnnnn nnnnnnnn</code> -- restore 0..8191 pixels of the initial background
* <code>11000000 00000000</code> -- end of current line
* <code>11000000 11111111</code> -- end of frame
* <code>11000000 nnnnnnnn</code> -- skip 1..255 lines
* <code>110nnnnn</code> -- skip 0..31 pixels
* <code>111nnnnn nnnnnnnn</code> -- skip 0..8191 pixels

[[Category:Game Formats]]

Ikarion MVI

2026-01-21T04:31:22Z

Kostya: fill information

* Company: Ikarion Software GmbH
* Extension: mvi
* Game: [https://www.mobygames.com/game/5821/battle-race/ Battle Race] (both MVI versions are used in it)

There are two distinct MVI formats (even if they are used in the same game): MVI1 employs LZ77 compression on paletted images, MVI2 uses vector quantisation over YUV tiles.

=== MVI1 ===

File starts with "VR6MVI" tag and 16-bit version (either 0x302 or 0x310) followed by blocks of audio and video data.

Version 0x302 blocks contain interleaved audio and video data, version 0x310 blocks start with pre-buffered audio data and have individual audio frames grouped so there may be several video frames between two audio frame groups.

Block header format:
2 bytes - number of frames
2 bytes - number of 400-byte buffers per audio frame
1 byte (version 0x310 only) - number of audio frames in group
1 byte (version 0x310 only) - number of audio frames to pre-buffer
2 bytes - frame sizes size
N bytes - packed frame sizes

Frame sizes are stored as variable-length integers in radix-7 form: each byte has top bit signalling whether the next byte is also a part of this integer and low 7 bits containing part of the integer (LSB first). E.g. <code>0x2A</code> is coded as <code>0x2A</code> while <code>0x100</code> is coded as <code>0x80 0x02</code>.

Each frame starts with 8-bit flags:
* bit 0 - audio present
* bit 1 - special tile-based motion compensation scheme with RLE compression (not present in known samples)
* bit 2 - frame data is LZ77-compressed
* bit 3 - LZ77-compressed palette data is present

LZ77 compression opcodes:
* <code>0x00</code> -- leave next 16-bit amount of output unchanged
* <code>0x01..0x7F</code> -- leave next 1..127 bytes of output unchanged
* <code>0x80..0x9F</code> -- copy next 1..32 bytes
* <code>0xA0..0xBF</code> -- repeat next value 2..33 times
* <code>0xC0..0xFF</code> -- read 1-2 byte offset (in the same way as frame size above), copy 2..65 bytes using that offset (relative to the current position e.g. offset 1 means repeating last byte)

=== MVI2 ===

File header:
4 bytes - "MVI2"
2 bytes - version (should be 0x101)
2 bytes - number of frames
2 bytes - delay in milliseconds between frames
1 byte - width in tiles
1 byte - height in tiles
1 byte - Y depth (should be 5)
1 byte - U depth (should be 5)
1 byte - V depth (should be 5)
1 byte - index entry bits (should be 12)
1 byte - tile width exponent (should be 2, for 4x4 tiles)
1 byte - tile height exponent (should be 2, for 4x4 tiles)
4*N bytes - frame sizes

Frame starts with 8-bit flags, IMA ADPCM compressed audio data, tile data update (prefixed by 16-bit number of tiles to update) and tile indices.

Tile data is stored as 5-bit values packed LSB first into 10 bytes for 4x4 tile. Tiles are stored in the circular buffer of 4096 tiles, so e.g. if you have first updated 4000 tiles and then 100 tiles then the second update will overwrite 4 first tiles and next update will touch fifth tile and so on.

Frame is split into 64x64 macro tiles that consist of 16x16 Y tiles of size 4x4, 8x8 U tiles and 8x8 V tiles. All tiles are coded as 12-bit indices in the common tile buffer. So e.g. for 128x64 frame first you read 256 Y tile indices for the first macro tile, then 64 U and 64 V indices for the same, and then repeat it for the second macro tile.

[[Category:Game Formats]]

GTE Vantage animation

2026-01-21T03:39:31Z

Kostya: fill information

* Company: GTE Vantage Inc.
* Extension: gav
* Game: [https://www.mobygames.com/game/4796/ncaa-championship-basketball/ NCAA Championship Basketball] (at least game demo)

This is a simple format with independently RLE-compressed frames (animations are even accompanied by auxiliary index files with frame positions to enable easy seeking).

Header:
4 bytes - "GAV "
4 bytes - number of frames
2 bytes - frames per second
2 bytes - width
2 bytes - height
1 byte - local palette is in use
1 byte - padding
768 bytes - VGA palette

Frames start with 32-bit size, 768-byte VGA palette (unless the header signals global palette use only) and RLE data.

RLE scheme is simple: opcode <code>00</code> means end of stream, <code>01..7F</code> means copying next 1..127 bytes, <code>80..FF</code> means repeat the following byte 0-127 times.

[[Category:Game Formats]]

MP Entertainment animation

2026-01-21T03:28:54Z

Kostya: fill information

* Company: MP Entertainment
* Extensions: anm, seq
* Game: [https://www.mobygames.com/game/3994/hopkins-fbi/ Hopkins FBI]

This is a simple chunk-based format employing RLE compression.

File starts with "MPANIM" tag followed by 768-byte palette. First chunk should be "NORM" which contains 32-bit size, 14 bytes of data, and uncompressed frame (640x480).
Other chunks start with "IMAGE=" tag, 32-bit size, 32-bit unknown value, and the rest is RLE data.

RLE opcodes:
* <code>D3</code> (ANM only) -- long run (1 byte run length and 1 byte run value)
* <code>D4..DD</code> (ANM only) -- repeat next byte 1..10 times
* <code>DE..FA</code> (ANM only) -- skip 1..27 pixels
* <code>FB</code> -- not encountered
* <code>FC</code> -- end of stream
* <code>FD</code> -- next byte tells how many pixels to skip
* <code>FE</code> -- next 16-bit value tells how many pixels to skip
* <code>FF</code> -- next 32-bit value tells how many pixels to skip
* all other opcodes are treated as pixel values

As you can see, the difference between ANM and SEQ is that the latter has only skip codes and <code>D3..FA</code> values are treated as normal pixels.

[[Category:Game Formats]]

TMM-Frac

2025-11-10T14:08:18Z

Kostya: fill information

* Company: Total Multimedia

This is a format that employs licensed [[Iterated Systems Fractal Codec]] and was used for some interactive video discs in DOS era.

Multimedia data is stored in blocks of 0xF800 bytes long that comprise several frames with audio and video data.

Block header format:
32 bits -- 0x007C0EBF
16 bits -- 0x007C (normal block) or 0x0000 (last block)
16 bits -- number of frames in block

Frames start with a header:
16 bits -- video frame flags (or some unused value for audio)
16 bits -- frame type (0x000C - video, 0x0700 - audio)
16 bits -- audio frame size (or some unused value for video)
16 bits -- video frame size

Audio is stored as 8-bit 22kHz mono PCM, for video the part starting with motion offsets count is transmitted.

First block starts with a header, at offset <code>0x24</code> there's an absolute offset to the palette data and frame data usually starts at offset <code>0xb3</code>.

[[Category:Game Formats]]

FVF

2025-11-10T13:44:57Z

Kostya:

FVF is a format used for cutscenes in [https://www.mobygames.com/game/957/star-trek-the-next-generation-a-final-unity/ Star Trek: The Next Generation - "A Final Unity"] game.

== File structure ==
All data is little-endian. Data is grouped into frames that are grouped into blocks aligned to at least 2048 bytes. Audio is stored as unpacked PCM, video is compressed with the licensed [[Iterated Systems Fractal Codec]].

Header:
4 bytes - "FVF "
4 bytes - unknown
4 bytes - unknown
4 bytes - unknown
4 bytes - first block offset
4 bytes - last block offset
4 bytes - image header (should be 0x60)
4 bytes - audio header (usually 0xB5)
64 bytes - unknown

Image header:
2 bytes - header size? (usually 40)
2 bytes - always 1?
2 bytes - always 16?
2 bytes - width
2 bytes - height
4 bytes - delay in milliseconds
4 bytes - unknown
4 bytes - number of frames
4 bytes - unknown
2 bytes - unknown
1 byte - palette something
1 byte - number of palette entries (usually 15)
4 bytes - palette offset (usually 0x88)
6 bytes - unknown

Audio header:
2 bytes - compression? (usually it's 1 and raw PCM)
2 bytes - number of channels?
2 bytes - bits per sample (usually 8)
2 bytes - sampling rate
8 bytes - unknown

Block header:
2 bytes - header size (should be 16)
2 bytes - flags
4 bytes - previous block size
4 bytes - current block size
4 bytes - next block size

Frame header:
2 bytes - header size (should be 24)
4 bytes - full size
4 bytes - always 24?
4 bytes - video part size
4 bytes - audio part size
6 bytes - unknown

Video frame data is in the same format as VfW variant of the codec, audio part starts with 32-bit size followed by PCM data.

[[Category:Game Formats]]

FVF

2025-11-10T13:43:55Z

Kostya: Update information about the video codec

FVF is a format used for cutscenes in [https://www.mobygames.com/game/957/star-trek-the-next-generation-a-final-unity/ Star Trek: The Next Generation - "A Final Unity"] game.

== File structure ==
All data is little-endian. Data is grouped into frames that are grouped into blocks aligned to at least 2048 bytes. Audio is stored as unpacked PCM, video is compressed with the licensed [[Iterated System Fractal Codec]].

Header:
4 bytes - "FVF "
4 bytes - unknown
4 bytes - unknown
4 bytes - unknown
4 bytes - first block offset
4 bytes - last block offset
4 bytes - image header (should be 0x60)
4 bytes - audio header (usually 0xB5)
64 bytes - unknown

Image header:
2 bytes - header size? (usually 40)
2 bytes - always 1?
2 bytes - always 16?
2 bytes - width
2 bytes - height
4 bytes - delay in milliseconds
4 bytes - unknown
4 bytes - number of frames
4 bytes - unknown
2 bytes - unknown
1 byte - palette something
1 byte - number of palette entries (usually 15)
4 bytes - palette offset (usually 0x88)
6 bytes - unknown

Audio header:
2 bytes - compression? (usually it's 1 and raw PCM)
2 bytes - number of channels?
2 bytes - bits per sample (usually 8)
2 bytes - sampling rate
8 bytes - unknown

Block header:
2 bytes - header size (should be 16)
2 bytes - flags
4 bytes - previous block size
4 bytes - current block size
4 bytes - next block size

Frame header:
2 bytes - header size (should be 24)
4 bytes - full size
4 bytes - always 24?
4 bytes - video part size
4 bytes - audio part size
6 bytes - unknown

Video frame data is in the same format as VfW variant of the codec, audio part starts with 32-bit size followed by PCM data.

[[Category:Game Formats]]

Iterated Systems

2025-11-09T16:08:45Z

Kostya:

* Website: http://www.iterated.com/ (now defunct)

Iterated Systems developed the [[Iterated Systems Fractal Codec|Fractal]] and [[ClearVideo]] codec. They are apparently no longer in business.

[[Category:Multimedia-related Companies]]

Iterated Systems Fractal Codec

2025-11-09T15:57:25Z

Kostya: fill information

* Company: [[Iterated Systems]]
* FourCCs: FVC1, FVF1

This is the only known true fractal codec. It has been licensed to different companies and forms the base of [[FVF]] and [[TMM-Frac]]. Beside slight header variations, all of them have the same bitstream format.

Video internally is coded as 8-bit greyscale or RGB24 but the output is delivered in either paletted or RGB16 format. Frame is split into 320x200 green plane and one plane with 160x100 red and blue planes. Each plane is split into 8x8 blocks that are further split into 4x4 blocks (in zig-zag order) and either individual 4x4 blocks or 8x8 blocks are coded.

Most of the block coding modes are affine transform, which means taking twice as large block from the reference buffer, throw out odd columns and lines, scale pixel values by three fourths, add brightness value (seven-bit value minus 64) and optionally apply an affine transform.
There are eight possible affine transforms done as a combination of three base transform (if bit 0 is set then mirror block, if bit 1 is set then flip block, if bit 2 is set then transpose block).

== Bitstream organisation ==
Frame data consists of three parts: 16-bit frame flags, motion offsets (16-bit count followed by 16-bit signed offsets) and block opcodes. Each opcode consists of 1-4 bytes treated as a series of bit fields (LSB first). VfW codec data starts with 32-bit offset to the palette data, other formats are documented at their own pages.

Frame flags:
* 1 -- fractal frame, data should be decoded 16 times
* 2 -- palette data present after the frame data
* 4 -- swap buffers (reference and current output; for fractal frames that's done on each iteration of the decoding) and output new reference buffer
* 8 -- skip frame (no data is coded)

Opcodes are:
* 0-3 -- affine transform for 4x4 block. Next 7 bits code brightness adjustment, 14 bits after that code source block index.
* 4 -- skip block run. Next 5 bits are run length minus one.
* 5 -- motion block(s). Next bit tells if there's more than one motion block; then 4-bit index of motion offset value from the frame header follows; then (if signalled) an additional number of motion blocks (all with the same motion offset) minus one in eight-bit field.
* 6 -- raw block. After the first byte sixteen bytes with new block data follow.
* 7 -- extended opcode is in the next four bits.

Extended opcodes:
* 0-7 -- affine transform for 8x8 block. Last bit in the first byte is unused, then there's 7-bit brightness, refinement block presence flag, 14-bit source block index flag, and finally 2-bit refined subblock index. In case when refined subblock is present, it is coded as normal block except opcode 7 is not allowed and skip/motion blocks modes apply to that one block only.
* 12 -- long skip run. Top bit tells whether it's a long run (8-bit value plus 33) or a very long run (16-bit value plus 289).
* 15 -- small raw block. After the first byte there's 16-bit absolute offset and 4 bytes of block data. This mode does not seem to be used.

[[Category:Video Codecs]]

Pixar codecs

2025-08-24T16:20:09Z

Kostya: fill known information

* Company: Pixar
* FOURCCS: pix0, pix1, pix2, pix3, pix4, pix5, pix6, pix7, pixA

These codecs are employed to compress paletted data in [[QuickTime_container|MOV]].

== Pixar codecs 0 and 4 ==
These codecs store uncompressed image split into 4x4 tiles.

== Pixar codecs 1 and 2 ==
Not much is known, but they seem to be similar to codec 3.

== Pixar codec 3 ==

This codec employs vector quantisation, so instead of transmitting each frame tile, only the codebook (or its update) plus tile indices are transmitted.

Frame format:
* 16-bit big-endian number of tiles in codebook (update)
* codebook update (the number of entries is specified above):
** 16-bit codebook entry ID
** 16 bytes of tile data
* compressed frame description

Frame description consists of 16-bit opcodes specifying the operation:
* 0-159 - leave that number of tiles unchanged from the previous frame
* 160-319 - restore (opcode-159) tiles from the initial background frame (note: the frame is not coded in the file but rather provided by the game engine from elsewhere)
* 320-65535 - paint tile (opcode-320) from the codebook

== Pixar codec 5 ==

This is an extension of codec 3. Now frame data starts with 16-bit big-endian frame number and probably the total number of tiles. If that value is not zero or 0xFFFF, two additional 16-bit values should be read. The rest is the same as in codec 3.

== Pixar codec 6 ==
Probably similar to codec 5.

== Pixar codec 7 ==
Unknown, but it seems to employ Huffman compression.

== Pixar codec A ==
Unknown, but it seems to be not tile-based on the first glance.

== Games using these codecs ==

[https://www.mobygames.com/game/119619/disneys-toy-story-activity-center/ Toy Story Activity Center]

[[Category:Video Codecs]]
[[Category:Game Formats]]
[[Category:Incomplete Video Codecs]]

Motion Pixels

2025-08-16T09:43:09Z

Kostya: /* Common things and differences */ add forgotten pixel 0 mention

* FOURCCs: MVI1, MVI2
* Company: [[Sirius Publishing]]
* Samples:
** MVI1: [http://samples.mplayerhq.hu/game-formats/mvi1-avi/ http://samples.mplayerhq.hu/game-formats/mvi1-avi/]
** MVI2: [http://samples.mplayerhq.hu/V-codecs/MVI2/ http://samples.mplayerhq.hu/V-codecs/MVI2/]
** Movie CD: [http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/ http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/]
** Movie CD Win32 Codecs: [http://samples.mplayerhq.hu/drivers32/motionpixels/ http://samples.mplayerhq.hu/drivers32/motionpixels/]

== Introduction ==

Motion Pixels is a family of codecs that started with its custom [[MVI Container]] format (with MVI extension as well) and later developed into VfW codecs MVI1 and MVI2.

Motion Pixels version 1 (MVI1) was used in a few video games while version 2 (MVI2) was used in a number of Movie CDs. All of these items were published by Sirius Publishing and the Motion Pixels codec is believed to still be owned by the company's CEO, Richard Gnant.

MVI belongs to the "old-school" family of video codecs and relies on interframe differences and adaptive delta-coding for horizontal lines of the picture. Delta coefficients are additionally [[Huffman|Huffman-packed]]. For better compression at the cost of picture quality additional colorspace downsampling may be used. MVI2 adds smoother delta-coding and the ability to dynamically change downsampling for each frame.

== MVI Codec ==

=== Common things and differences ===

Essentially there are four (or even five) flavours of the codec:
* DOS version in [[MVI Container]]. Format is set in the header flags. Frames are treated either as intra or inter (depending on the flag set).
* MVI1 codec. Format is set in the flags. The only known flags include flipped frames, single-field coding, and golden frame.
* MVI2.0 codec. Format is set in the flags. In addition to MVI1 flags it also supports low-resolution mode and frame cropping.
* MVI2.1 codec. This one is signalled by a certain flag, actual coding format is set in intra frame header. Compared to MVI2.0 it also enables smooth delta coding mode.
* MVI2.2 codec. This one is signalled by a different flag but the behaviour seems to be identical to MVI2.1

All variations of MVI use the same coding principle: first special rectangular areas are marked on the frame that require special handling; they are processed and the rest of pixels are decoded using Huffman-compressed deltas. For better compression data in most cases is represented in YUV colourspace with some subsampling. See Appendix A for the code to convert between 15-bit RGB and YUV.

Supported colourspace formats are:
* 0 - RGB
* 1 - YUV with one chroma pair per 2x1 block
* 2 - YUV with one chroma pair per 2x2 block
* 3 - YUV with one chroma pair per 4x2 block
* 4 - YUV with one chroma pair per 4x4 block

Overall bitstream format looks like this:
* intra frame flag (not present in DOS version)
* coding parameters like colourspace, lowres mode and smooth delta coding (only in intra frames and only in MVI2.1/MVI2.2)
* skip map (not for intra frames)
* golden frame map (only when the feature is enabled)
* fill map
* low-resolution areas map (only when the feature is enabled)
* Huffman codes description for deltas
* top left pixel RGB value (in there are delta codes and top left pixel is marked for normal delta decoding)
* number of delta codes for vertical prediction and first field (if there are delta codes)
* number of delta codes for the second field (ditto)
* Huffman-coded deltas

Bit reading is done MSB first using 32-bit little-endian words (e.g. <code>00 00 10 80</code> is represented as <code>0x80100000</code> and first read bit will be 1).

=== Compression Flags ===

When video is packaged inside [[AVI]] files, all vital codec's parameters carried in [[BITMAPINFOHEADER]]'s '''biCompression''' field of the video stream. Actual codec type should be retrieved from <code>fccHandler</code> of AVI stream header. First two bytes of '''biCompression''' for 16-bit little-endian flags value, last two bytes should be "i1" for MVI1 and "i2" for MVI2 correspondingly.

Flag bits meaning:

* 0..3 (0x000F) - colourspace Format (see below)
* 4 (0x0010) - seems to be recognised but not used by the decoder (MVI2.2 only)
* 5 (0x0020) - alternative output mode (MVI2.2 only)
* 6 (0x0040) - seems to be intra-only mode where only intra frames are decoded and inter frames merely repeat them (MVI2.2 only)
* 7 (0x0080) - MVI2.2 mode
* 8 (0x0100) - still-frame (or golden frame) mode for MVI2.2
* 9 (0x0200) - MVI2.1 mode
* 10 (0x0400) - frame cropping enabled (MVI2 only)
* 11 (0x0800) - low-resolution mode (MVI2 only)
* 12 (0x1000) - still-frame (or golden frame) mode
* 13 (0x2000) - frames are coded upside-down (instead of bottoms-up by default)
* 14 (0x4000) - video was encoded using trial version of the codec (this flag tells original decoder to put watermark to the frame)
* 15 (0x8000) - image is single-field, only odd lines are carried

=== Golden frame mode ===

When videos with small amount of changes encoded (ex, 'talking heads' or some static scenery) special trick may be performed. Very first frame contains all the scenery, while all successive frames take this first frame as a base and add necessary changes to it. The tricky part is, that first frame contains such a 'change-frame' as well, so you have two logical frames in one physical. Offset to the base frame is located at ('''biSizeImage''' - 4) in the encoded data buffer. Change-frame located at it's start.

Please note that both of the parts in the first frame still contain the golden frame map.

=== Delta decoding modes ===

Deltas are coded as values in the range -7..7. Since sometimes larger values are needed, there are two ways to deal with it. Motion Pixels before 2.1 used a rule that if delta value is -7 or 7 then next delta value should be doubled before use (and if its original value is -7 or 7 then the next delta value as well etc etc). Smooth delta mode operates differently: if delta value is -7 or 7 then add doubled next delta value to the result (and keep doing it while additional delta values are -7 or 7).

=== Low-resolution mode ===

In this mode half of the pixels are coded using interpolation i.e. when only luma changes are coded then first (interpolated pixel) uses half of that delta value added to the previous pixel and second pixel uses full delta. If exactly one pixel is left between low-res and skip areas, it is interpolated in the same way (luma delta is calculated and half of it is added to the predictor value). If exactly one pixel is left between low-res and and normal area, it uses half of the first delta from the first pixel of that area.

Depending on coding mode and line number full and pixel position may be swapped (e.g. for even lines it may be "interpolated full interpolated full" while for odd lines it is "full interpolated full interpolated"). Additionally in smooth deltas mode luma deltas use limited range unless the very first pixel is full one.

Please note that during vertical prediction stage low-resolution mode pixels are treated as skip pixels.

=== Decompression ===

==== Frame Flags ====
Each frame begins with sequence of local flag bits. These bits are:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! # of bits !! Present if !! Name !! Description
|-
| 1 || always || KeyframeFlag || non-zero if this frame is a key frame
|-
| 3 || flags bit 9 || ColorSpace || colorspace Format for this group of frames
|-
| 1 || flags bit 9 || LowRes || low-resolution coding is enabled
|-
| 1 || flags bit 9 || SmoothDeltas || use smooth delta-coding
|-
| 1 || flags bit 9 || HaveSerial || (see next field)
|-
| 20 || flags bit 9 + HaveSerial || SerialNumber || Encoder's serial number
|-
| 1 || flags bit 9 || Cropping || frame cropping is enabled
|-
| 8 || flags bit 10 or Cropping || CropX || x offset of the frame start
|-
| 8 || flags bit 10 or Cropping || CropY || y offset of the frame start
|}

==== Maps ====
Map blocks contain rectangles which should be marked as special on the frame. All versions prior to MVI2.1 use the same format:
* 12 bits number of large rectangles
* 12 bits number of small rectangles
* large rectangles
* small rectangles

Rectangles are stored as <code><offset, width-1, height-1></code> with offset taking <code>ceil(log2(frame width * frame height))</code> bits and width and height using 8 or 4 bits depending on rectangle size. Rectangles for fill map additionally contain RGB555 fill value.

MVI2.1/MVI2.2 use a different format, they split image into chunks of 8192 bytes and for each of them use 8-bit number of large/small rectangles as well as 13-bit offsets relative to the start of that piece.

==== Deltas Bundle ====

Deltas start with 4-bit code telling how many unique delta values are being coded. Zero means no deltas are present at all, one value means next four bit contain delta value plus seven and all deltas in the frame are the same. Otherwise there's 4-bit value telling the suggested number of bits to look up during Huffman decoding followed by symbol values (delta value plus seven) and bit-coded Huffman tree shape (0 - this is a leaf; 1 - node has children, read description for it).

Then there are two numbers of deltas per field, using 18 or 19 bits (depending on whether image is larger than 320*240 or not) and the actual delta values (when there are two or more unique delta values).

==== Assembling the Frame ====
* leave areas marked as "skip" (but not "lowres") unchanged
* copy image data from the golden frame to the areas marked as such (there is no motion displacement)
* fill areas marked as "fill" with the provided colour
* perform vertical prediction for the first column (skip if there are no deltas)
* perform prediction for odd lines using the rest of deltas from the first part (skip if there are no deltas)
* perform prediction for even lines using deltas from the second part (skip if there are no deltas)

Please note that while old DOS format used sequential line numbers so field 0 consisted of lines 0,2,4,... newer formats decode lines in permuted order. So for most formats field 0 is lines 1,3,5,... and for 4x4 mode lines for field 0 are decoded in this order: 3,1,7,5,11,9,...

Delta prediction is simple: for the line (or column) skip not predicted pixels, taking last of them as a new predictor, convert it from RGB to YUV, add delta for Y and optionally U and V components, put pixel converted to RGB on frame. Pixels in the same block use the same chroma values. The rules for which pixel is supposed to have U and V deltas depend on pixel position, subsampling mode, low-res mode being employed or not, and codec version.

== Games Using Motion Pixels ==
* [https://www.mobygames.com/game/windows/treasure-quest Treasure Quest]
* [https://www.mobygames.com/game/25426/apollo-18-the-moon-missions/ Apollo 18: The Moon Missions]

== Appendix A ==

Code for generating RGB to YUV table (it is done with YUV to RGB conversion, which is used during decoding as well):

for (y = 0; y <= 31; y++) {
for (v = -31; v <= 31; v++) {
for (u = -31; u <= 31; u++) {
r = (y * 1000 + v * 701) / 1000;
g = (y * 1000 - 357 * v - 172 * u) / 1000;
b = (y * 1000 + 886 * u) / 1000;
if (r >= 0 && r < 32 && g >= 0 && g < 32 && b >= 0 && b < 32) {
pix = (r << 10) | (g << 5) | b;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = y;
rgb2yuv[pix][1] = u;
rgb2yuv[pix][2] = v;
}
}
}
}
}
for (i = 0; i < 32768; i+= 32) {
for (j = 0; j < 31; j++) {
for (k = 31; k > j; k--) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix - 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix - 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix - 1][2];
}
}
for (k = 0; k < 31 - j; k++) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix + 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix + 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix + 1][2];
}
}
}
}

[[Category:Video Codecs]]
[[Category:Game Formats]]
[[Category:Formats missing in MPlayer]]

Motion Pixels

2025-08-15T13:12:10Z

Kostya: clarify some flags and be done with it

* FOURCCs: MVI1, MVI2
* Company: [[Sirius Publishing]]
* Samples:
** MVI1: [http://samples.mplayerhq.hu/game-formats/mvi1-avi/ http://samples.mplayerhq.hu/game-formats/mvi1-avi/]
** MVI2: [http://samples.mplayerhq.hu/V-codecs/MVI2/ http://samples.mplayerhq.hu/V-codecs/MVI2/]
** Movie CD: [http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/ http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/]
** Movie CD Win32 Codecs: [http://samples.mplayerhq.hu/drivers32/motionpixels/ http://samples.mplayerhq.hu/drivers32/motionpixels/]

== Introduction ==

Motion Pixels is a family of codecs that started with its custom [[MVI Container]] format (with MVI extension as well) and later developed into VfW codecs MVI1 and MVI2.

Motion Pixels version 1 (MVI1) was used in a few video games while version 2 (MVI2) was used in a number of Movie CDs. All of these items were published by Sirius Publishing and the Motion Pixels codec is believed to still be owned by the company's CEO, Richard Gnant.

MVI belongs to the "old-school" family of video codecs and relies on interframe differences and adaptive delta-coding for horizontal lines of the picture. Delta coefficients are additionally [[Huffman|Huffman-packed]]. For better compression at the cost of picture quality additional colorspace downsampling may be used. MVI2 adds smoother delta-coding and the ability to dynamically change downsampling for each frame.

== MVI Codec ==

=== Common things and differences ===

Essentially there are four (or even five) flavours of the codec:
* DOS version in [[MVI Container]]. Format is set in the header flags. Frames are treated either as intra or inter (depending on the flag set).
* MVI1 codec. Format is set in the flags. The only known flags include flipped frames, single-field coding, and golden frame.
* MVI2.0 codec. Format is set in the flags. In addition to MVI1 flags it also supports low-resolution mode and frame cropping.
* MVI2.1 codec. This one is signalled by a certain flag, actual coding format is set in intra frame header. Compared to MVI2.0 it also enables smooth delta coding mode.
* MVI2.2 codec. This one is signalled by a different flag but the behaviour seems to be identical to MVI2.1

All variations of MVI use the same coding principle: first special rectangular areas are marked on the frame that require special handling; they are processed and the rest of pixels are decoded using Huffman-compressed deltas. For better compression data in most cases is represented in YUV colourspace with some subsampling. See Appendix A for the code to convert between 15-bit RGB and YUV.

Supported colourspace formats are:
* 0 - RGB
* 1 - YUV with one chroma pair per 2x1 block
* 2 - YUV with one chroma pair per 2x2 block
* 3 - YUV with one chroma pair per 4x2 block
* 4 - YUV with one chroma pair per 4x4 block

Overall bitstream format looks like this:
* intra frame flag (not present in DOS version)
* coding parameters like colourspace, lowres mode and smooth delta coding (only in intra frames and only in MVI2.1/MVI2.2)
* skip map (not for intra frames)
* golden frame map (only when the feature is enabled)
* fill map
* low-resolution areas map (only when the feature is enabled)
* Huffman codes description for deltas
* number of delta codes for vertical prediction and first field (if there are delta codes)
* number of delta codes for the second field (ditto)
* Huffman-coded deltas

Bit reading is done MSB first using 32-bit little-endian words (e.g. <code>00 00 10 80</code> is represented as <code>0x80100000</code> and first read bit will be 1).

=== Compression Flags ===

When video is packaged inside [[AVI]] files, all vital codec's parameters carried in [[BITMAPINFOHEADER]]'s '''biCompression''' field of the video stream. Actual codec type should be retrieved from <code>fccHandler</code> of AVI stream header. First two bytes of '''biCompression''' for 16-bit little-endian flags value, last two bytes should be "i1" for MVI1 and "i2" for MVI2 correspondingly.

Flag bits meaning:

* 0..3 (0x000F) - colourspace Format (see below)
* 4 (0x0010) - seems to be recognised but not used by the decoder (MVI2.2 only)
* 5 (0x0020) - alternative output mode (MVI2.2 only)
* 6 (0x0040) - seems to be intra-only mode where only intra frames are decoded and inter frames merely repeat them (MVI2.2 only)
* 7 (0x0080) - MVI2.2 mode
* 8 (0x0100) - still-frame (or golden frame) mode for MVI2.2
* 9 (0x0200) - MVI2.1 mode
* 10 (0x0400) - frame cropping enabled (MVI2 only)
* 11 (0x0800) - low-resolution mode (MVI2 only)
* 12 (0x1000) - still-frame (or golden frame) mode
* 13 (0x2000) - frames are coded upside-down (instead of bottoms-up by default)
* 14 (0x4000) - video was encoded using trial version of the codec (this flag tells original decoder to put watermark to the frame)
* 15 (0x8000) - image is single-field, only odd lines are carried

=== Golden frame mode ===

When videos with small amount of changes encoded (ex, 'talking heads' or some static scenery) special trick may be performed. Very first frame contains all the scenery, while all successive frames take this first frame as a base and add necessary changes to it. The tricky part is, that first frame contains such a 'change-frame' as well, so you have two logical frames in one physical. Offset to the base frame is located at ('''biSizeImage''' - 4) in the encoded data buffer. Change-frame located at it's start.

Please note that both of the parts in the first frame still contain the golden frame map.

=== Delta decoding modes ===

Deltas are coded as values in the range -7..7. Since sometimes larger values are needed, there are two ways to deal with it. Motion Pixels before 2.1 used a rule that if delta value is -7 or 7 then next delta value should be doubled before use (and if its original value is -7 or 7 then the next delta value as well etc etc). Smooth delta mode operates differently: if delta value is -7 or 7 then add doubled next delta value to the result (and keep doing it while additional delta values are -7 or 7).

=== Low-resolution mode ===

In this mode half of the pixels are coded using interpolation i.e. when only luma changes are coded then first (interpolated pixel) uses half of that delta value added to the previous pixel and second pixel uses full delta. If exactly one pixel is left between low-res and skip areas, it is interpolated in the same way (luma delta is calculated and half of it is added to the predictor value). If exactly one pixel is left between low-res and and normal area, it uses half of the first delta from the first pixel of that area.

Depending on coding mode and line number full and pixel position may be swapped (e.g. for even lines it may be "interpolated full interpolated full" while for odd lines it is "full interpolated full interpolated"). Additionally in smooth deltas mode luma deltas use limited range unless the very first pixel is full one.

Please note that during vertical prediction stage low-resolution mode pixels are treated as skip pixels.

=== Decompression ===

==== Frame Flags ====
Each frame begins with sequence of local flag bits. These bits are:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! # of bits !! Present if !! Name !! Description
|-
| 1 || always || KeyframeFlag || non-zero if this frame is a key frame
|-
| 3 || flags bit 9 || ColorSpace || colorspace Format for this group of frames
|-
| 1 || flags bit 9 || LowRes || low-resolution coding is enabled
|-
| 1 || flags bit 9 || SmoothDeltas || use smooth delta-coding
|-
| 1 || flags bit 9 || HaveSerial || (see next field)
|-
| 20 || flags bit 9 + HaveSerial || SerialNumber || Encoder's serial number
|-
| 1 || flags bit 9 || Cropping || frame cropping is enabled
|-
| 8 || flags bit 10 or Cropping || CropX || x offset of the frame start
|-
| 8 || flags bit 10 or Cropping || CropY || y offset of the frame start
|}

==== Maps ====
Map blocks contain rectangles which should be marked as special on the frame. All versions prior to MVI2.1 use the same format:
* 12 bits number of large rectangles
* 12 bits number of small rectangles
* large rectangles
* small rectangles

Rectangles are stored as <code><offset, width-1, height-1></code> with offset taking <code>ceil(log2(frame width * frame height))</code> bits and width and height using 8 or 4 bits depending on rectangle size. Rectangles for fill map additionally contain RGB555 fill value.

MVI2.1/MVI2.2 use a different format, they split image into chunks of 8192 bytes and for each of them use 8-bit number of large/small rectangles as well as 13-bit offsets relative to the start of that piece.

==== Deltas Bundle ====

Deltas start with 4-bit code telling how many unique delta values are being coded. Zero means no deltas are present at all, one value means next four bit contain delta value plus seven and all deltas in the frame are the same. Otherwise there's 4-bit value telling the suggested number of bits to look up during Huffman decoding followed by symbol values (delta value plus seven) and bit-coded Huffman tree shape (0 - this is a leaf; 1 - node has children, read description for it).

Then there are two numbers of deltas per field, using 18 or 19 bits (depending on whether image is larger than 320*240 or not) and the actual delta values (when there are two or more unique delta values).

==== Assembling the Frame ====
* leave areas marked as "skip" (but not "lowres") unchanged
* copy image data from the golden frame to the areas marked as such (there is no motion displacement)
* fill areas marked as "fill" with the provided colour
* perform vertical prediction for the first column (skip if there are no deltas)
* perform prediction for odd lines using the rest of deltas from the first part (skip if there are no deltas)
* perform prediction for even lines using deltas from the second part (skip if there are no deltas)

Please note that while old DOS format used sequential line numbers so field 0 consisted of lines 0,2,4,... newer formats decode lines in permuted order. So for most formats field 0 is lines 1,3,5,... and for 4x4 mode lines for field 0 are decoded in this order: 3,1,7,5,11,9,...

Delta prediction is simple: for the line (or column) skip not predicted pixels, taking last of them as a new predictor, convert it from RGB to YUV, add delta for Y and optionally U and V components, put pixel converted to RGB on frame. Pixels in the same block use the same chroma values. The rules for which pixel is supposed to have U and V deltas depend on pixel position, subsampling mode, low-res mode being employed or not, and codec version.

== Games Using Motion Pixels ==
* [https://www.mobygames.com/game/windows/treasure-quest Treasure Quest]
* [https://www.mobygames.com/game/25426/apollo-18-the-moon-missions/ Apollo 18: The Moon Missions]

== Appendix A ==

Code for generating RGB to YUV table (it is done with YUV to RGB conversion, which is used during decoding as well):

for (y = 0; y <= 31; y++) {
for (v = -31; v <= 31; v++) {
for (u = -31; u <= 31; u++) {
r = (y * 1000 + v * 701) / 1000;
g = (y * 1000 - 357 * v - 172 * u) / 1000;
b = (y * 1000 + 886 * u) / 1000;
if (r >= 0 && r < 32 && g >= 0 && g < 32 && b >= 0 && b < 32) {
pix = (r << 10) | (g << 5) | b;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = y;
rgb2yuv[pix][1] = u;
rgb2yuv[pix][2] = v;
}
}
}
}
}
for (i = 0; i < 32768; i+= 32) {
for (j = 0; j < 31; j++) {
for (k = 31; k > j; k--) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix - 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix - 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix - 1][2];
}
}
for (k = 0; k < 31 - j; k++) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix + 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix + 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix + 1][2];
}
}
}
}

[[Category:Video Codecs]]
[[Category:Game Formats]]
[[Category:Formats missing in MPlayer]]

Motion Pixels

2025-08-15T12:53:25Z

Kostya: more about deltas

* FOURCCs: MVI1, MVI2
* Company: [[Sirius Publishing]]
* Samples:
** MVI1: [http://samples.mplayerhq.hu/game-formats/mvi1-avi/ http://samples.mplayerhq.hu/game-formats/mvi1-avi/]
** MVI2: [http://samples.mplayerhq.hu/V-codecs/MVI2/ http://samples.mplayerhq.hu/V-codecs/MVI2/]
** Movie CD: [http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/ http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/]
** Movie CD Win32 Codecs: [http://samples.mplayerhq.hu/drivers32/motionpixels/ http://samples.mplayerhq.hu/drivers32/motionpixels/]

== Introduction ==

Motion Pixels is a family of codecs that started with its custom [[MVI Container]] format (with MVI extension as well) and later developed into VfW codecs MVI1 and MVI2.

Motion Pixels version 1 (MVI1) was used in a few video games while version 2 (MVI2) was used in a number of Movie CDs. All of these items were published by Sirius Publishing and the Motion Pixels codec is believed to still be owned by the company's CEO, Richard Gnant.

MVI belongs to the "old-school" family of video codecs and relies on interframe differences and adaptive delta-coding for horizontal lines of the picture. Delta coefficients are additionally [[Huffman|Huffman-packed]]. For better compression at the cost of picture quality additional colorspace downsampling may be used. MVI2 adds smoother delta-coding and the ability to dynamically change downsampling for each frame.

== MVI Codec ==

=== Common things and differences ===

Essentially there are four (or even five) flavours of the codec:
* DOS version in [[MVI Container]]. Format is set in the header flags. Frames are treated either as intra or inter (depending on the flag set).
* MVI1 codec. Format is set in the flags. The only known flags include flipped frames, single-field coding, and golden frame.
* MVI2.0 codec. Format is set in the flags. In addition to MVI1 flags it also supports low-resolution mode and frame cropping.
* MVI2.1 codec. This one is signalled by a certain flag, actual coding format is set in intra frame header. Compared to MVI2.0 it also enables smooth delta coding mode.
* MVI2.2 codec. This one is signalled by a different flag but the behaviour seems to be identical to MVI2.1

All variations of MVI use the same coding principle: first special rectangular areas are marked on the frame that require special handling; they are processed and the rest of pixels are decoded using Huffman-compressed deltas. For better compression data in most cases is represented in YUV colourspace with some subsampling. See Appendix A for the code to convert between 15-bit RGB and YUV.

Supported colourspace formats are:
* 0 - RGB
* 1 - YUV with one chroma pair per 2x1 block
* 2 - YUV with one chroma pair per 2x2 block
* 3 - YUV with one chroma pair per 4x2 block
* 4 - YUV with one chroma pair per 4x4 block

Overall bitstream format looks like this:
* intra frame flag (not present in DOS version)
* coding parameters like colourspace, lowres mode and smooth delta coding (only in intra frames and only in MVI2.1/MVI2.2)
* skip map (not for intra frames)
* golden frame map (only when the feature is enabled)
* fill map
* low-resolution areas map (only when the feature is enabled)
* Huffman codes description for deltas
* number of delta codes for vertical prediction and first field (if there are delta codes)
* number of delta codes for the second field (ditto)
* Huffman-coded deltas

Bit reading is done MSB first using 32-bit little-endian words (e.g. <code>00 00 10 80</code> is represented as <code>0x80100000</code> and first read bit will be 1).

=== Compression Flags ===

When video is packaged inside [[AVI]] files, all vital codec's parameters carried in [[BITMAPINFOHEADER]]'s '''biCompression''' field of the video stream. Actual codec type should be retrieved from <code>fccHandler</code> of AVI stream header. First two bytes of '''biCompression''' for 16-bit little-endian flags value, last two bytes should be "i1" for MVI1 and "i2" for MVI2 correspondingly.

Flag bits meaning:

* 0..3 (0x000F) - colourspace Format (see below)
* 4 (0x0010) - MVI2.2 only
* 5 (0x0020) - MVI2.2 only
* 6 (0x0040) - MVI2.2 only
* 7 (0x0080) - MVI2.2 only
* 8 (0x0100) - MVI2.2 only
* 9 (0x0200) - MVI2.1 mode
* 10 (0x0400) - frame cropping enabled (MVI2 only)
* 11 (0x0800) - low-resolution mode (MVI2 only)
* 12 (0x1000) - still-frame (or golden frame) mode
* 13 (0x2000) - frames are coded upside-down (instead of bottoms-up by default)
* 14 (0x4000) - video was encoded using trial version of the codec (this flag tells original decoder to put watermark to the frame)
* 15 (0x8000) - image is single-field, only odd lines are carried

=== Golden frame mode ===

When videos with small amount of changes encoded (ex, 'talking heads' or some static scenery) special trick may be performed. Very first frame contains all the scenery, while all successive frames take this first frame as a base and add necessary changes to it. The tricky part is, that first frame contains such a 'change-frame' as well, so you have two logical frames in one physical. Offset to the base frame is located at ('''biSizeImage''' - 4) in the encoded data buffer. Change-frame located at it's start.

Please note that both of the parts in the first frame still contain the golden frame map.

=== Delta decoding modes ===

Deltas are coded as values in the range -7..7. Since sometimes larger values are needed, there are two ways to deal with it. Motion Pixels before 2.1 used a rule that if delta value is -7 or 7 then next delta value should be doubled before use (and if its original value is -7 or 7 then the next delta value as well etc etc). Smooth delta mode operates differently: if delta value is -7 or 7 then add doubled next delta value to the result (and keep doing it while additional delta values are -7 or 7).

=== Low-resolution mode ===

In this mode half of the pixels are coded using interpolation i.e. when only luma changes are coded then first (interpolated pixel) uses half of that delta value added to the previous pixel and second pixel uses full delta. If exactly one pixel is left between low-res and skip areas, it is interpolated in the same way (luma delta is calculated and half of it is added to the predictor value). If exactly one pixel is left between low-res and and normal area, it uses half of the first delta from the first pixel of that area.

Depending on coding mode and line number full and pixel position may be swapped (e.g. for even lines it may be "interpolated full interpolated full" while for odd lines it is "full interpolated full interpolated"). Additionally in smooth deltas mode luma deltas use limited range unless the very first pixel is full one.

Please note that during vertical prediction stage low-resolution mode pixels are treated as skip pixels.

=== Decompression ===

==== Frame Flags ====
Each frame begins with sequence of local flag bits. These bits are:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! # of bits !! Present if !! Name !! Description
|-
| 1 || always || KeyframeFlag || non-zero if this frame is a key frame
|-
| 3 || flags bit 9 || ColorSpace || colorspace Format for this group of frames
|-
| 1 || flags bit 9 || LowRes || low-resolution coding is enabled
|-
| 1 || flags bit 9 || SmoothDeltas || use smooth delta-coding
|-
| 1 || flags bit 9 || HaveSerial || (see next field)
|-
| 20 || flags bit 9 + HaveSerial || SerialNumber || Encoder's serial number
|-
| 1 || flags bit 9 || Cropping || frame cropping is enabled
|-
| 8 || flags bit 10 or Cropping || CropX || x offset of the frame start
|-
| 8 || flags bit 10 or Cropping || CropY || y offset of the frame start
|}

==== Maps ====
Map blocks contain rectangles which should be marked as special on the frame. All versions prior to MVI2.1 use the same format:
* 12 bits number of large rectangles
* 12 bits number of small rectangles
* large rectangles
* small rectangles

Rectangles are stored as <code><offset, width-1, height-1></code> with offset taking <code>ceil(log2(frame width * frame height))</code> bits and width and height using 8 or 4 bits depending on rectangle size. Rectangles for fill map additionally contain RGB555 fill value.

MVI2.1/MVI2.2 use a different format, they split image into chunks of 8192 bytes and for each of them use 8-bit number of large/small rectangles as well as 13-bit offsets relative to the start of that piece.

==== Deltas Bundle ====

Deltas start with 4-bit code telling how many unique delta values are being coded. Zero means no deltas are present at all, one value means next four bit contain delta value plus seven and all deltas in the frame are the same. Otherwise there's 4-bit value telling the suggested number of bits to look up during Huffman decoding followed by symbol values (delta value plus seven) and bit-coded Huffman tree shape (0 - this is a leaf; 1 - node has children, read description for it).

Then there are two numbers of deltas per field, using 18 or 19 bits (depending on whether image is larger than 320*240 or not) and the actual delta values (when there are two or more unique delta values).

==== Assembling the Frame ====
* leave areas marked as "skip" (but not "lowres") unchanged
* copy image data from the golden frame to the areas marked as such (there is no motion displacement)
* fill areas marked as "fill" with the provided colour
* perform vertical prediction for the first column (skip if there are no deltas)
* perform prediction for odd lines using the rest of deltas from the first part (skip if there are no deltas)
* perform prediction for even lines using deltas from the second part (skip if there are no deltas)

Please note that while old DOS format used sequential line numbers so field 0 consisted of lines 0,2,4,... newer formats decode lines in permuted order. So for most formats field 0 is lines 1,3,5,... and for 4x4 mode lines for field 0 are decoded in this order: 3,1,7,5,11,9,...

Delta prediction is simple: for the line (or column) skip not predicted pixels, taking last of them as a new predictor, convert it from RGB to YUV, add delta for Y and optionally U and V components, put pixel converted to RGB on frame. Pixels in the same block use the same chroma values. The rules for which pixel is supposed to have U and V deltas depend on pixel position, subsampling mode, low-res mode being employed or not, and codec version.

== Games Using Motion Pixels ==
* [https://www.mobygames.com/game/windows/treasure-quest Treasure Quest]
* [https://www.mobygames.com/game/25426/apollo-18-the-moon-missions/ Apollo 18: The Moon Missions]

== Appendix A ==

Code for generating RGB to YUV table (it is done with YUV to RGB conversion, which is used during decoding as well):

for (y = 0; y <= 31; y++) {
for (v = -31; v <= 31; v++) {
for (u = -31; u <= 31; u++) {
r = (y * 1000 + v * 701) / 1000;
g = (y * 1000 - 357 * v - 172 * u) / 1000;
b = (y * 1000 + 886 * u) / 1000;
if (r >= 0 && r < 32 && g >= 0 && g < 32 && b >= 0 && b < 32) {
pix = (r << 10) | (g << 5) | b;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = y;
rgb2yuv[pix][1] = u;
rgb2yuv[pix][2] = v;
}
}
}
}
}
for (i = 0; i < 32768; i+= 32) {
for (j = 0; j < 31; j++) {
for (k = 31; k > j; k--) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix - 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix - 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix - 1][2];
}
}
for (k = 0; k < 31 - j; k++) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix + 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix + 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix + 1][2];
}
}
}
}

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]
[[Category:Undiscovered Game Formats]]
[[Category:Game Formats]]
[[Category:Formats missing in MPlayer]]

Motion Pixels

2025-08-15T10:47:40Z

Kostya: fill some information

* FOURCCs: MVI1, MVI2
* Company: [[Sirius Publishing]]
* Samples:
** MVI1: [http://samples.mplayerhq.hu/game-formats/mvi1-avi/ http://samples.mplayerhq.hu/game-formats/mvi1-avi/]
** MVI2: [http://samples.mplayerhq.hu/V-codecs/MVI2/ http://samples.mplayerhq.hu/V-codecs/MVI2/]
** Movie CD: [http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/ http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/]
** Movie CD Win32 Codecs: [http://samples.mplayerhq.hu/drivers32/motionpixels/ http://samples.mplayerhq.hu/drivers32/motionpixels/]

== Introduction ==

Motion Pixels is a family of codecs that started with its custom [[MVI Container]] format (with MVI extension as well) and later developed into VfW codecs MVI1 and MVI2.

Motion Pixels version 1 (MVI1) was used in a few video games while version 2 (MVI2) was used in a number of Movie CDs. All of these items were published by Sirius Publishing and the Motion Pixels codec is believed to still be owned by the company's CEO, Richard Gnant.

MVI belongs to the "old-school" family of video codecs and relies on interframe differences and adaptive delta-coding for horizontal lines of the picture. Delta coefficients are additionally [[Huffman|Huffman-packed]]. For better compression at the cost of picture quality additional colorspace downsampling may be used. MVI2 adds smoother delta-coding and the ability to dynamically change downsampling for each frame.

== MVI Codec ==

=== Common things and differences ===

Essentially there are four (or even five) flavours of the codec:
* DOS version in [[MVI Container]]. Format is set in the header flags. Frames are treated either as intra or inter (depending on the flag set).
* MVI1 codec. Format is set in the flags. The only known flags include flipped frames, single-field coding, and golden frame.
* MVI2.0 codec. Format is set in the flags. In addition to MVI1 flags it also supports low-resolution mode and frame cropping.
* MVI2.1 codec. This one is signalled by a certain flag, actual coding format is set in intra frame header. Compared to MVI2.0 it also enables smooth delta coding mode.
* MVI2.2 codec. This one is signalled by a different flag but the behaviour seems to be identical to MVI2.1

All variations of MVI use the same coding principle: first special rectangular areas are marked on the frame that require special handling; they are processed and the rest of pixels are decoded using Huffman-compressed deltas. For better compression data in most cases is represented in YUV colourspace with some subsampling. See Appendix A for the code to convert between 15-bit RGB and YUV.

Supported colourspace formats are:
* 0 - RGB
* 1 - YUV with one chroma pair per 2x1 block
* 2 - YUV with one chroma pair per 2x2 block
* 3 - YUV with one chroma pair per 4x2 block
* 4 - YUV with one chroma pair per 4x4 block

Overall bitstream format looks like this:
* intra frame flag (not present in DOS version)
* coding parameters like colourspace, lowres mode and smooth delta coding (only in intra frames and only in MVI2.1/MVI2.2)
* skip map (not for intra frames)
* golden frame map (only when the feature is enabled)
* fill map
* low-resolution areas map (only when the feature is enabled)
* Huffman codes description for deltas
* number of delta codes for vertical prediction and first field (if there are delta codes)
* number of delta codes for the second field (ditto)
* Huffman-coded deltas

Bit reading is done MSB first using 32-bit little-endian words (e.g. <code>00 00 10 80</code> is represented as <code>0x80100000</code> and first read bit will be 1).

=== Compression Flags ===

When video is packaged inside [[AVI]] files, all vital codec's parameters carried in [[BITMAPINFOHEADER]]'s '''biCompression''' field of the video stream. Actual codec type should be retrieved from <code>fccHandler</code> of AVI stream header. First two bytes of '''biCompression''' for 16-bit little-endian flags value, last two bytes should be "i1" for MVI1 and "i2" for MVI2 correspondingly.

Flag bits meaning:

* 0..3 (0x000F) - colourspace Format (see below)
* 4 (0x0010) - MVI2.2 only
* 5 (0x0020) - MVI2.2 only
* 6 (0x0040) - MVI2.2 only
* 7 (0x0080) - MVI2.2 only
* 8 (0x0100) - MVI2.2 only
* 9 (0x0200) - MVI2.1 mode
* 10 (0x0400) - frame cropping enabled (MVI2 only)
* 11 (0x0800) - low-resolution mode (MVI2 only)
* 12 (0x1000) - still-frame (or golden frame) mode
* 13 (0x2000) - frames are coded upside-down (instead of bottoms-up by default)
* 14 (0x4000) - video was encoded using trial version of the codec (this flag tells original decoder to put watermark to the frame)
* 15 (0x8000) - image is single-field, only odd lines are carried

=== Golden frame mode ===

When videos with small amount of changes encoded (ex, 'talking heads' or some static scenery) special trick may be performed. Very first frame contains all the scenery, while all successive frames take this first frame as a base and add necessary changes to it. The tricky part is, that first frame contains such a 'change-frame' as well, so you have two logical frames in one physical. Offset to the base frame is located at ('''biSizeImage''' - 4) in the encoded data buffer. Change-frame located at it's start.

Please note that both of the parts in the first frame still contain the golden frame map.

=== Low-resolution mode ===

In this mode half of the pixels are coded using interpolation i.e. when only luma changes are coded then first (interpolated pixel) uses half of that delta value added to the previous pixel and second pixel uses full delta. If exactly one pixel is left between low-res and skip areas, it is interpolated in the same way (luma delta is calculated and half of it is added to the predictor value). If exactly one pixel is left between low-res and and normal area, it uses half of the first delta from the first pixel of that area.

Depending on coding mode and line number full and pixel position may be swapped (e.g. for even lines it may be "interpolated full interpolated full" while for odd lines it is "full interpolated full interpolated"). Additionally in smooth deltas mode luma deltas use limited range unless the very first pixel is full one.

Please note that during vertical prediction stage low-resolution mode pixels are treated as skip pixels.

=== Decompression ===

==== Frame Flags ====
Each frame begins with sequence of local flag bits. These bits are:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! # of bits !! Present if !! Name !! Description
|-
| 1 || always || KeyframeFlag || non-zero if this frame is a key frame
|-
| 3 || flags bit 9 || ColorSpace || colorspace Format for this group of frames
|-
| 1 || flags bit 9 || LowRes || low-resolution coding is enabled
|-
| 1 || flags bit 9 || SmoothDeltas || use smooth delta-coding
|-
| 1 || flags bit 9 || HaveSerial || (see next field)
|-
| 20 || flags bit 9 + HaveSerial || SerialNumber || Encoder's serial number
|-
| 1 || flags bit 9 || Cropping || frame cropping is enabled
|-
| 8 || flags bit 10 or Cropping || CropX || x offset of the frame start
|-
| 8 || flags bit 10 or Cropping || CropY || y offset of the frame start
|}

==== Maps ====
Map blocks contain rectangles which should be marked as special on the frame. All versions prior to MVI2.1 use the same format:
* 12 bits number of large rectangles
* 12 bits number of small rectangles
* large rectangles
* small rectangles

Rectangles are stored as <code><offset, width-1, height-1></code> with offset taking <code>ceil(log2(frame width * frame height))</code> bits and width and height using 8 or 4 bits depending on rectangle size. Rectangles for fill map additionally contain RGB555 fill value.

MVI2.1/MVI2.2 use a different format, they split image into chunks of 8192 bytes and for each of them use 8-bit number of large/small rectangles as well as 13-bit offsets relative to the start of that piece.

==== Deltas Bundle ====

'''TODO'''

==== Assembling the Frame ====
* leave areas marked as "skip" (but not "lowres") unchanged
* copy image data from the golden frame to the areas marked as such (there is no motion displacement)
* fill areas marked as "fill" with the provided colour
* perform vertical prediction for the first column (skip if there are no deltas)
* perform prediction for odd lines using the rest of deltas from the first part (skip if there are no deltas)
* perform prediction for even lines using deltas from the second part (skip if there are no deltas)

'''TODO'''

== Games Using Motion Pixels ==
* [https://www.mobygames.com/game/windows/treasure-quest Treasure Quest]
* [https://www.mobygames.com/game/25426/apollo-18-the-moon-missions/ Apollo 18: The Moon Missions]

== Appendix A ==

Code for generating RGB to YUV table (it is done with YUV to RGB conversion, which is used during decoding as well):

for (y = 0; y <= 31; y++) {
for (v = -31; v <= 31; v++) {
for (u = -31; u <= 31; u++) {
r = (y * 1000 + v * 701) / 1000;
g = (y * 1000 - 357 * v - 172 * u) / 1000;
b = (y * 1000 + 886 * u) / 1000;
if (r >= 0 && r < 32 && g >= 0 && g < 32 && b >= 0 && b < 32) {
pix = (r << 10) | (g << 5) | b;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = y;
rgb2yuv[pix][1] = u;
rgb2yuv[pix][2] = v;
}
}
}
}
}
for (i = 0; i < 32768; i+= 32) {
for (j = 0; j < 31; j++) {
for (k = 31; k > j; k--) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix - 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix - 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix - 1][2];
}
}
for (k = 0; k < 31 - j; k++) {
pix = i + k;
if (!rgb2yuv[pix][0] && !rgb2yuv[pix][1] && !rgb2yuv[pix][2]) {
rgb2yuv[pix][0] = rgb2yuv[pix + 1][0];
rgb2yuv[pix][1] = rgb2yuv[pix + 1][1];
rgb2yuv[pix][2] = rgb2yuv[pix + 1][2];
}
}
}
}

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]
[[Category:Undiscovered Game Formats]]
[[Category:Game Formats]]
[[Category:Formats missing in MPlayer]]

LMS

2025-06-17T10:40:09Z

Kostya: fill description

* Extension: lms
* Samples: [http://samples.mplayerhq.hu/game-formats/segacd/ecco-lms/ http://samples.mplayerhq.hu/game-formats/segacd/ecco-lms/]

LMS is a multimedia format used on the [[Sega CD]] game [http://www.mobygames.com/game/sega-cd/ecco-the-dolphin Ecco The Dolphin]. It is a raw grayscale video plus audio format. Frames are grouped into larger blocks in the following format:
2048 bytes - unused?
8820 bytes - left channel PCM
1420 bytes - padding
2048 bytes - unused?
8820 bytes - right channel PCM
1420 bytes - padding
12x8192 bytes - twelve video frames

Video frames are stored in the console format (two 4-bit palette indices in one byte, 32 bytes per one 8x8 tile) except that tiles are arranged in a special order: first frame is divided into strips 4 tiles high and strips are filled column by column. Palette indices seem to correspond to grayscale shades, palettes do not seem to be stored anywhere.

[[Category:Game Formats]]

YQS

2025-06-17T10:22:22Z

Kostya: create an alias for YQS to make it easier to find

#REDIRECT [[EGG]]

ICOM video

2025-06-17T10:12:32Z

Kostya: fill description

* Company: ICOM Simulations Inc.
* Extension: imv

This is a format used in the original version of [https://www.mobygames.com/group/10092/sherlock-holmes-consulting-detective-series/ Sherlock Holmes: Consulting Detective] series. The files consists of blocks forming logical groups with video for one scene.

Blocks start with 32-bit size, 32-bit previous block size (useful for seeking backwards), and 16-bit block type. Known block types are:
* 0x01 - global header (first 6 bytes meaning is unknown then there are 2-byte width, height and fps)
* 0x02 - logical group (scene) start, it contains total group size in multiple of CD sectors
* 0x04 - audio plus delta frame. First 4-byte value is block number, followed by 2-byte audio data size, followed by audio and video data
* 0x08 - audio plus raw frame (with the same header)
* 0x20 - audio plus raw frame plus palette update. First 4-byte value is block number, followed by 2-byte audio data size and video data size, followed by audio and video data, ending with palette update. Palette update starts with 2-byte values for start colour index and number of colours followed by partial VGA palette
* 0x40 - palette update

Delta frames are coded as a mix of update mask bytes followed by pixel values. E.g. <code>0x7A 0x01 0x02 0x03 0x04 0x05</code> means skipping one pixel, setting next four pixels to <code>0x01 0x02 0x03 0x04</code>, skipping one pixel, setting next pixel to <code>0x05</code> and skipping last pixel. Mask value <code>0x05</code> is used as an escape value: if it is followed by <code>0x02</code> then 16-bit number of 8-pixel groups to skip follows, otherwise just ignore that following byte.

[[Category:Game Formats]]

Klondike Moon FMV

2025-06-16T15:01:02Z

Kostya: fill description

* Extension: SEQ, SFX, VID
* Samples: http://samples.mplayerhq.hu/game-formats/klondike-moon-fmv/

The DOS game Klondike Moon contains a VIDEOS/ directory that has triplets of files that likely correspond to full motion video files. The SFX files apparently contain unsigned 8-bit PCM. The SEQ files likely contain header/control information to indicate how to play the files.

VID files start with VGA palette and uncompressed 320x200 image followed by non-delimited RLE-coded delta frames.

Those frames actually consist of update chunks starting with 16-bit absolute image offset followed by RLE opcodes:
* 0xFF 0xFF -- end
* 0xFF nn ll -- run of pixel <code>nn</code> <code>ll</code> times
* nn -- single pixel value

[[Category:Video Codecs]]
[[Category:Game Formats]]

Maelstrom ANM

2025-06-16T14:55:17Z

Kostya: fill description

* Extension: anm
* Samples: [http://samples.mplayerhq.hu/game-formats/anm-maeldemo/ http://samples.mplayerhq.hu/game-formats/anm-maeldemo/]
* Samples: {{DexvertSamples|video/maelstromANM}}
* Game: [https://www.mobygames.com/game/1864/maelstrom/ Maelstrom]

This is an animation format used in the strategy game from early 1990s. It employs chunked format with <code>ANIM</code> being the root chunk, <code>BPIC</code> used for the first (intra) frame and <code>DFRM</code> used for the delta frames.

Intra frame has the following header:
1 byte - unknown
1 byte - mode (0 - raw, 1 - RLE)
2 bytes - height
2 bytes - width
1 byte - depth (should be 8)
1 byte - number of palette colours
N*3 bytes - palette

RLE opcodes are trivial: 0-127 means read 1-128 pixels, 128-255 means run of 129-2 pixels.

Delta frames use RLE compression which is employed per column. For each column there's a byte telling the number of RLE opcodes followed by those opcodes and data:
* 0 - run, read byte for run length and byte for colour value
* 1-127 - skip 1-127 lines
* 128-255 - read 128-1 pixels

[[Category:Game Formats]]

EGG

2025-06-16T14:40:04Z

Kostya: fix inaccuracies from confusion with YQS

* Extension: egg ([[Sega Saturn]] port), yqs (PC port)
* Samples: [http://samples.mplayerhq.hu/game-formats/egg/ http://samples.mplayerhq.hu/game-formats/egg/]
* Game: [http://www.mobygames.com/game/saturn/independence-day Independence Day]

The format employs YUV frames coded per-plane and [[IMA ADPCM]]-encoded audio. Data is aligned to CD sector size (2048 bytes)

Egg does not have audio stream and has slightly different coding but the differences are minimal.

EGG header:
4 bytes - "EGG\0"
4 bytes - always 0x350?
4 bytes - number of frames
2036 bytes - padding

EGG frame header:
4x2x3 bytes - offsets to each plane pixel and mode data

EGG frames are always 20kB long.

YQS header:
2 bytes - number of frames
4 bytes - audio sample rate
2042 bytes - padding

YQS frame header:
4 bytes - size
4x2x3 bytes - offsets to each plane pixel and mode data
4 bytes - audio data offset
4 bytes - audio data size

Video coding employs quadtree coding and vector quantisation: before actual image data there's an array of possible 2x2 block values which may be used during luma decoding.

Luma plane is coded as 8x8 blocks with mode flags telling how to decode them (fill/skip/split). Chroma plane is coded in similar manner using 4x4 blocks.

Luma coding:
if (get_bit() == 0) {
raw block - read 64 pixels from pixel data to fill it
} else {
//split block
for (blk_no = 0; blk_no < 4; blk_no++) {
if (get_bit() == 1)
decode_luma_4x4_block();
// otherwise leave it unchanged
}
}

4x4 luma blocks are coded in the same manner, 2x2 blocks depend on the format.

EGG uses bit pattern (highest bit is the one read first) to determine coding mode:
* 00 - skip
* 01 - fill
* 10 - raw
* 11xx - VQ with possible transformation (00 - as is, 01 - flip horizontally, 10 - flip vertically, 11 - flip in both directions)

YQS simply uses 2-bit mode for that:
* 0 - fill
* 1 - raw
* 2 - VQ (followed by index in the header table of 2x2 blocks)
* 3 - VQ flipped vertically

Chroma coding:
if (get_bit() == 1) { // otherwise skip
if (get_bit() == 0) {
fill 4x4 block with single colour
} else {
for (blk_no = 0; blk_no < 4; blk_no++) {
if (get_bit() == 1) {
// decode 2x2 chroma block
if (get_bit() == 0)
fill 2x2 block
else
raw 2x2 block
}
// otherwise leave it unchanged
}
}
}

[[Category:Game Formats]]

EGG

2025-06-16T14:18:05Z

Kostya: fill description

* Extension: egg
* Samples: [http://samples.mplayerhq.hu/game-formats/egg/ http://samples.mplayerhq.hu/game-formats/egg/]
* Game: [http://www.mobygames.com/game/saturn/independence-day Independence Day] ([[Sega Saturn]] port)

The format employs YUV frames coded per-plane and [[IMA ADPCM]]-encoded audio. Data is aligned to CD sector size (2048 bytes)

Header:
2 bytes - number of frames
4 bytes - audio sample rate
2042 bytes - padding

Frame header:
4 bytes - size
4x2x3 bytes - offsets to each plane pixel and mode data
4 bytes - audio data offset
4 bytes - audio data size

Video coding employs quadtree coding and vector quantisation: before actual image data there's an array of possible 2x2 block values which may be used during decoding.

Luma plane is coded as 8x8 blocks with mode flags telling how to decode them:
if (get_bit() == 0) {
raw block - read 64 pixels from pixel data to fill it
} else {
//split block
for (blk_no = 0; blk_no < 4; blk_no++) {
if (get_bit() == 1)
decode_luma_4x4_block();
// otherwise leave it unchanged
}
}

4x4 luma blocks are coded in the same manner, 2x2 blocks though use 2-bit mode to determine fill pattern:
* 0 - fill
* 1 - raw
* 2 - VQ index for the blocks from the header
* 3 - same but flipped vertically

Chroma coding is similar:
if (get_bit() == 1) { // otherwise skip
if (get_bit() == 0) {
fill 4x4 block with single colour
} else {
for (blk_no = 0; blk_no < 4; blk_no++) {
if (get_bit() == 1) {
// decode 2x2 chroma block
if (get_bit() == 0)
fill 2x2 block
else
raw 2x2 block
}
// otherwise leave it unchanged
}
}
}

[[Category:Game Formats]]

Savage Warriors ANM

2025-06-16T14:01:28Z

Kostya: fill description

* Extension: anm
* Samples: [http://samples.mplayerhq.hu/game-formats/anm-savagewarriors/ http://samples.mplayerhq.hu/game-formats/anm-savagewarriors/]
* Game: [http://www.mobygames.com/game/dos/savage-warriors Savage Warriors]

This is a format that employs LZ77 compression from Diet (Japanese executable compressor). Additionally there are two flavours of the format, the version used in demo version of the game and lacks "CHCK" header, and the one used in the full version (with the header and 32-bit checksum inserted after every 4kB of the file data).

Beside the 4-byte header the rest are video frame chunks:

1 byte - mode (0 - Diet packed image data, 1 - RLE, 0xFF - end of file)
1 byte - palette present
2 bytes - unknown
2 bytes - width
2 bytes - height
2 bytes - X offset
2 bytes - Y offset
4 bytes - frame size
(if palette is present) 768 bytes - palette
N bytes - frame size

RLE compression codes segments in form of <code>(skip, opcode, data)</code> where <code>skip</code> is the number of pixels to skip, <code>opcode</code> tells what operations to perform (skip=opcode=0 means image end, 1-127 means copying 1-127 pixels from the stream, 128-255 means run of 128-1 pixels).

[[Category:Game Formats]]

Castles II video

2025-06-16T13:39:53Z

Kostya: fill description

* Game: [https://www.mobygames.com/game/1874/castles-ii-siege-conquest/ Castles II]
* Extension: .M

This is a simple animation format presumably created by [https://www.mobygames.com/person/7626/byon-garrabrant/ Byon Garrabrant] and used in game to show a grayscale film footage (for other animations [[Interplay MVE]] is used).

Header:
10 bytes - "BYON PIZZA"
2 bytes - height
2 bytes - width
2 bytes - unknown

Then video frames follow, each starting with 16-bit size.

Frames are split into 2x2 tiles and use the following opcodes to decode them:
* 0-63 -- this is the first pixel value, other three pixel value follow
* 64-127 -- fill tile with the value of low 6 bits of the opcode
* 128-255 -- skip 0-127 tiles

Video uses 64 greyscale shades with 0 corresponding to white and 63 corresponding to black.

[[Category:Game Formats]]

Shadowcaster cutscene

2025-06-16T13:29:52Z

Kostya: fill information

* Game: [https://www.mobygames.com/game/550/shadowcaster/ Shadowcaster]
* Extension: DAT

This cutscene format combines compressed video data with other commands like starting/stopping external music.

Header:
2 bytes -- 0x105
2 bytes -- width
2 bytes -- height
2 bytes -- fps
48 bytes -- unknown/unused

The rest of file is organised into chunks with 16-bit tag, 32-bit size and payload. Known chunk types are:
* 1 -- intra RLE frame (negative value - copy, positive value - run)
* 2 -- optionally LZSS-packed inter RLE frame (each line containing start position and the number of RLE segments to update)
* 3 -- unpacked or LZSS-packed frame
* 4 -- palette update
* 16-21 -- unknown commands
* 22 -- palette selection command (one byte is palette index)
* 23-24 -- unknown commands
* 25 -- repeat frame command (one byte tells how many times)
* 32 -- set palette to all black
* 33 -- fade in command (one byte is target palette index)
* 34 -- fade out command
* 35 -- unknown

Palette data is stored as the palette index followed by the number of palette segments and actual segments (number of colours to skip from previous segment, number of colours in the segment modulo 256, actual colour data).

[[Category:Game Formats]]

Talk:Engines/XPAT

2025-05-10T12:53:27Z

Kostya: Created page with "== FLX == This one looks like a slightly extended Flic Video with sub-chunk 21 containing audio data and sub-chunk 22 containing some kind of back-references to that audio (and they're always 10 bytes long). --~~~~"

== FLX ==

This one looks like a slightly extended [[Flic Video]] with sub-chunk 21 containing audio data and sub-chunk 22 containing some kind of back-references to that audio (and they're always 10 bytes long). --[[User:Kostya|Kostya]] ([[User talk:Kostya|talk]]) 05:53, 10 May 2025 (PDT)

Microsoft Camcorder Video

2025-04-16T11:34:40Z

Kostya: Fill the details at last.

* FourCC: CGDI
* Company: [[Microsoft]]
* Samples: http://samples.mplayerhq.hu/V-codecs/CGDI/
* References: http://support.microsoft.com/support/office/content/office97/camcorder.asp

According to Microsoft's documentation, Camcorder Video allows users of Microsoft Office 97 to record video of their desktop. This would make it a screen capture codec if not for the fact that it actually records GDI and WINUSER API calls so in order to reconstruct image one has to implement those GDI calls.

Each frame consists of records containing GDI/WINUSER commands:

bytes 0-3 size of record including this field
bytes 4-5 command code
bytes 6-9 unknown
bytes 10-... command arguments, usually 16-bit integers

The internal state keeps a list of GDI objects in an internal array and references them by ID so that the command e.g. for drawing a rectangle sends as parameters rectangle coordinates (left, top, right, bottom) as well as the brush ID that will be selected before rectangle will be drawn. In general the commands that have brush, pen IDs or such send those IDs at the end of the list but before the variable-length part (e.g. points to draw polyline).

Known opcodes are:
* <code>0x00</code> -- fill region using region and brush IDs
* <code>0x01</code> -- draw a border around region; parameters are region/brush IDs plus stroke width/height
* <code>0x02</code> -- invert region
* <code>0x03</code> -- paint region using the provided region/brush IDs
* <code>0x04</code> -- draw an arc using provided coordinates and brush ID
* <code>0x05</code> -- draw a line to the provided point using brush ID
* <code>0x06</code> -- moveto (parameters are point coordinates)
* <code>0x07</code> -- not present
* <code>0x08</code> -- polyline (first parameter is number of points, second parameter is brush ID, the rest are line points)
* <code>0x09</code> -- draw a chord (same parameters as for arc)
* <code>0x0A</code> -- draw focused rectangle (parameters are rectangle coordinates)
* <code>0x0B</code> -- draw an ellipse (parameters are bounding rectangle plus pen and brush IDs)
* <code>0x0C</code> -- draw filled rectangle (WINUSER; parameters are its coordinates and brush ID)
* <code>0x0D</code> -- draw frame rectangle (same parameters)
* <code>0x0E</code> -- invert rectangle at the provided coordinates
* <code>0x0F</code> -- draw a pie (parameters are coordinates passed to the GDI function plus brush and pen IDs)
* <code>0x10</code> -- draw a polygon (parameters are number of points, brush/pen IDs and vertices coordinates)
* <code>0x11</code> -- draw a series of polygons (essentially the same parameters)
* <code>0x12</code> -- draw a rectangle (GDI) using provided coordinates and brush/pen IDs
* <code>0x13</code> -- draw a rounded rectangle using provided coordinates, corner radius and brush/pen IDs
* <code>0x14</code> -- blit bitmap using the provided arguments to <code>BitBlt</code> and bitmap ID
* <code>0x15</code> -- blit (optionally stretched bitmap)
* <code>0x16</code> -- <code>ExtFloodFill</code> using provided coordinates, colour, mode and brush ID
* <code>0x17</code> -- <code>PatBlt</code> using provided coordinates, mode and brush ID
* <code>0x18</code> -- set pixel at the provided coordinates to the provided colour value
* <code>0x19</code> -- stretched blit using provided coordinates, mode and bitmap ID
* <code>0x1A</code> -- <code>SetDIBitsToDevice</code> using provided bitmap data
* <code>0x1B</code> -- <code>StretchDIBits</code> using provided bitmap data
* <code>0x1C</code> -- draw provided text using specified pen/brush IDs
* <code>0x1D</code> -- same but using <code>TextOut</code> instead of <code>ExtTextOut</code>
* <code>0x1E</code> -- draw text with WINUSER function
* <code>0x1F</code> -- WINUSER TabbedTextOut
* <code>0x20</code> -- draw window frame
* <code>0x21</code> -- create new palette using provided data
* <code>0x22</code> -- delete requested GDI object by ID
* <code>0x23</code> -- unused
* <code>0x24</code> -- init window parameters (origin and viewport)
* <code>0x25</code> -- something similar
* <code>0x26</code>-<code>0x32</code> -- unused
* <code>0x33</code> -- set mapping mode to the provided argument
* <code>0x34</code> -- set window and viewport extents
* <code>0x35</code> -- set viewport origin
* <code>0x36</code> -- set window origin
* <code>0x37</code> -- set background mix mode
* <code>0x38</code> -- set background colour
* <code>0x39</code> -- set foreground mix mode
* <code>0x3A</code> -- set text colour
* <code>0x3B</code> -- set text align mode
* <code>0x3C</code> -- set text justification
* <code>0x3D</code> -- set brush origin
* <code>0x3E</code> -- set polygon fill mode
* <code>0x3F</code> -- create new brush with the provided parameters as store it at the provided ID
* <code>0x40</code> -- create new font using the provided parameters and destination ID
* <code>0x41</code> -- create patterned brush
* <code>0x42</code> -- create new pen
* <code>0x43</code> -- create memory object (some kind of bitmap?) by copying data from the stream to the given ID object
* <code>0x44</code> -- init some window parameters
* <code>0x45</code> -- unused
* <code>0x46</code> -- create new bitmap using data from the stream
* <code>0x47</code> -- init some window parameters
* <code>0x48</code> -- set default parameters to the drawing system (usually the very first opcode in the first frame)
* <code>0x49</code> -- clear drawing system from used objects
* <code>0x4A</code> -- set some flag, probably for custom window clipping
* <code>0x4B</code> -- delete requested object

[[Category:Video Codecs]]
[[Category:Screen Capture Video Codecs]]
[[Category:Formats missing in MPlayer]]

PI-Video

2025-04-05T14:20:02Z

Kostya: fix some details

* FOURCC: <code>PIVC</code>
* Company: Nordic Company

This is a rather simple quadtree-based paletted video codec with its name probably coming from its developer initials.

The image is split into squares of 4nx4n pixels large for the closest match with frame dimensions (e.g. 256x256 squares for 320x240 video) that get divided into 16 parts with a flag telling if the part is fill/skip or should be further subdivided (or coded as raw for 4x4 squares). Flags and pixel data are grouped into separate data chunks inside the frame.

Frame consists of the following data: 32-bit frame flags, 32-bit frame size (not counting frame flags), tile flags data (starting with 32-bit size), and pixel data. There are two known frame flags: bit 0 signals inter frame coding and bit 1 signals that pixel data is LZW-compressed.

Simplified decoding process:

tile_size = 0x4000;
do {
tile_size >>= 2;
} while (tile_size >= max(width, height))
tile_size <<= 2;

cur_tile_size = tile_size;
for each tile in image
decode_tile(tile_pos, cur_tile_size);

decode_tile(pos, cur_tile_size) {
flags = get_16bit_le(flags_data);
for each one of 16 subparts in tile {
if part is inside the image area {
if ((flag & 1) == 0) {
pix = get_byte(pixel_data);
if (intra || pix != 0) {
fill subpart with pix value
}
} else if (cur_tile_size > 4) {
decode_tile(subpart, cur_tile_size >> 2);
} else {
fill 4x4 block with 16 values read from pixel data
}
}
flags >>= 1;
}
}

LZW differs from the conventional algorithm used e.g. in GIF. First, there is single escape code 256 which is followed by two-bit mode (0 - end of stream, 1 - restart, 2 - increase current index bits). Second, index bits increase is manual because inter-frames keep using previous LZW dictionary to decode pixel data, so while they start decoding with 9-bit indices, they may bump it a couple of time and start reading e.g. 11-bit indices.

Additionally codec uses fixed palette stored in the middle of its extradata (first 32-bit word of it seems to be the header size before actual palette starts).

[[Category:Video Codecs]]