MultimediaWiki - User contributions [en]

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]]

EVA

2025-04-01T15:13:51Z

Kostya: fill information

EVA is a family of formats created by T.Yamamoto. They employ [[RLE]] for video compression.

=== EVA3 header format ===
4 bytes - "EVA3"
1+ bytes - comment ending with 0x1A byte
2 bytes - number of frames
1 byte - frames per second
1 byte - unused

Frames are stored as raw 2-bit 96x92 images.

=== EVA4 header format ===
4 bytes - "EVA4"
1+ bytes - comment ending with 0x1A byte
2 bytes - number of frames
1 byte - frames per second
1 byte - unused

Frame format is hardcoded to 2-bit 96x92.

Each frame is preceded by 16-bit frame size.

=== EVA5 header format ===
4 bytes - "EVA5"
1+ bytes - comment ending with 0x1A byte
2 bytes - number of frames
2 bytes - width
2 bytes - height
1 byte - colour depth (usually 2-bit)
1 byte - frames per second
1 byte - bits per audio sample (0 - 8bps, 1 - 4bps)
2 bytes - sampling frequency
2 bytes - audio block size
1 byte - unused

Each frame is preceded by audio block bytes and 16-bit frame size.

=== Video compression ===

EVA4 and EVA5 use the following opcodes:

* <code>00sssccc</code> -- skip <code>sss</code> bytes, copy <code>ccc</code> bytes
* <code>01ssssss</code> -- skip <code>ssssss</code> bytes
* <code>10cccccc</code> -- copy <code>cccccc</code> bytes
* <code>11sssrrr</code> -- skip <code>sss</code> bytes, repeat the next byte <code>rrr</code> times

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

Perfect Clarity Audio

2025-03-29T08:36:18Z

Kostya: fill information

*Extension: pca
*Company: [[Sony]]
*TwoCC: 0x1971

This format, originally known as [http://en.wikipedia.org/wiki/Sound_Forge Sound Forge] lossless audio, is a simple lossless codec for 16- or 24-bit audio. Despite the extension, <code>pca</code> files are normal [[WAV]] files with variable-length frames.

Flags stored in extradata may signal the following features being enabled:
* 1 -- use M/S decorrelation
* 2 -- LPC is enabled
* 4 -- CRC present?

Frame format (all values are little-endian, 'C' means number of channels):
(intra frame only) 4 bytes -- 0xFFFFFFFF
(intra frame only) 4x4xC bytes -- history samples for each channel
2 bytes -- number of samples? (negative value is used to signal something)
2 bytes -- frame size
C bytes -- Rice code parameter(s)
C bytes -- filter order/value
(if LPC is enabled) 4xC bytes -- LPC filter coefficient (signed bytes)
(if something is enabled) 4 bytes -- CRC?

If filter order is 5, block is not coded, otherwise frame data consists of coefficients coded as Rice codes, data is stored per channel.
Values are read MSB first, codes are re-interpreted as signed with the sign in low bit (e.g. 0 -> 0, 1 -> -1, 2 -> 1 ...).

If LPC is enabled it's applied before fixed predictor in the form of <code>coef[i] -= (coef[i-1]*filt[0] + ... + coef[i-4]*filt[3]) >> 5</code>.

Fixed prediction seems to be borrowed from [[Shorten]]:
* 0 -- no prediction
* 1 -- <code>coef[i] += coef[i-1]</code>
* 2 -- <code>coef[i] += coef[i-1] * 2 - coef[i-2]</code>
* 3 -- <code>coef[i] += coef[i-1] * 3 - coef[i-2] * 3 + coef[i-3]</code>
* 4 -- <code>coef[i] += coef[i-1] * 4 - coef[i-2] * 6 + coef[i-3] * 4 - coef[i-4]</code>

When channel decorrelation is present, <code>L = (M * 2 + S) / 2, R = (M * 2 - S) / 2</code> with different rounding mode depending on signedness and low bit of the values before division.

16-bit audio is output as low bits of the decoded values, 24-bit audio is clipped to the range first.

[[Category:Lossless Audio Codecs]]
[[Category:Container Formats]]
[[Category:Formats missing in FFmpeg]]

DVC

2025-03-29T08:10:33Z

Kostya: fill information

* Company: [[Q-Team]]
* Extension: dvc

This is an animation format based on RLE. Quite likely it was the ancestor of [[QPEG]] codec.

=== Container format ===
Header (all values are little-endian):
6 bytes - "IDVCd\x00"
2 bytes - height
2 bytes - width
2 bytes - unknown
4 bytes - unknown, maybe frame delay in milliseconds
4 bytes - unknown
4 bytes - unknown, looks somewhat like the number of frames but not exactly it
4 bytes - data size
68 bytes - unknown
708 bytes - palette (starting from colour 20)

Frames start with 16-bit value equal to one (zero means end of file) followed by 32-bit frame size and actual payload.

=== Video compression ===
Frame data starts with 128-byte remap table (used in literal mode) followed by the opcode stream.

Opcodes:
* <code>0x00</code> -- skip pixel
* <code>0x01-0x7F</code> -- literal, output pixel value from the remap table using opcode as an index
* <code>0x80</code> -- skip <code>next_byte + 64</code> pixels
* <code>0x81</code> -- skip <code>next_byte + 320</code> pixels
* <code>0x82-0xBF</code> -- skip 2-63 pixels
* <code>0xC0-0xDF</code> -- copy 1-32 pixels from the stream
* <code>0xE0</code> -- end of stream marker
* <code>0xE1-0xFF</code> -- repeat next byte from the stream 2-32 times

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

DRL

2025-03-15T15:59:58Z

Kostya: fill information

* Company: Mass Media Inc, Philips P.O.V. Entertainment Group
* Extension: drl
* Game: [https://www.mobygames.com/game/8082/thunder-in-paradise-interactive/ Thunder in Paradise] (PC port)

This is RLE-based format used in the FMV game.

Header:
2 bytes - version
2 bytes - number of frames
2 bytes - unknown
4 bytes - unknown
2 bytes - data size in 2kB sectors
2 bytes - unknown
2 bytes - number of audio chunks to preload
2 bytes - number of colours used
2 bytes - palette changes are present
2 bytes - audio frame length
38 bytes - unknown
2 bytes - audio mode
// initial palette
1 byte - unknown
1 byte - unknown
2 bytes - start colour
2 bytes - end colour
N*3 bytes - partial VGA palette
// tables
M*4 bytes - frame offsets (relative to data start)
M*2 bytes - bottom 16 bits of total audio length at the end of the frame
X bytes - alignment to the next 2kB sector

Then if there are audio preload frames, data for that number of frame follows. Then data is aligned to the multiple of sector size again.

Frames start with the following header:
2 bytes - total frame size
2 bytes - audio data size
2 bytes - update area X offset
2 bytes - update area Y offset
2 bytes - update area width
2 bytes - update area height
1 byte - coding mode

If palette changes are allowed, then palette change data follows (1 byte - start colour index, 1 byte - number of colours, then partial VGA palette).

Then RLE-encoded video data for the update rectangle follows. Opcodes are the following:
* 0x00..0xDF -- output pixel value
* 0xE0..0xEF -- skip 2-17 pixels
* 0xF0..0xFE -- read colour value, repeat it 3-17 times
* 0xFF -- long skip (next byte value plus 18 pixels)

Finally there's audio data.

[[Category:Game Formats]]

System Shock video

2025-03-15T15:04:04Z

Kostya: fill information

This is a cutscene and audio log format employed by Looking Glass Studios in its game [https://www.mobygames.com/game/681/system-shock/ System Shock]. They are stored inside resource archive and thus have no extension or name, only numerical ID.

Header format:
4 bytes - "MOVI"
4 bytes - number of chunks
4 bytes - TOC size
4 bytes - data size
4 bytes - duration
4 bytes - frames per second in fixed-point 16-bit format (i.e. FPS * 65536)
2 bytes - width
2 bytes - height
2 bytes - bits per pixel (should be 0 or 8)
2 bytes - some palette flag
2 bytes - number of audio channels
2 bytes - bits per audio sample
4 bytes - sample rate in fixed-point format
216 bytes - padding
768 bytes - initial palette

TOC entry format:
3 bytes - timestamp
1 byte - flags (bits 3-6) and type (bits 0-2)
4 bytes - offset

Chunk types are:
* 0 - EOF
* 1 - video frame
* 2 - audio
* 3 - subtitle
* 4 - palette
* 5 - tables

=== Video frame ===
There are two possible frame coding modes.

When chunk flags are not equal to 0xF, frame uses RLE and has update rectangle position and dimensions stored as 16-bit integers before RLE data. Otherwise frame is coded with 4x4 tiles employing Huffman compression and vector quantisation (this mode is used for SVGA videos).

RLE opcodes:
* 0x00 -- run mode (with count byte and colour value following)
* 0x01..0x7F -- copy 1-127 pixels
* 0x80 -- long mode, read 16-bit opcode:
** 0x0000 -- end of decoding
** 0x0001..0x7FFF -- skip 1-32767 pixels
** 0x8000..0xBFFF -- copy 0-16383 pixels
** 0xC000..0xFFFF -- read colour value, output it 0-16383 times
* 0x81..0xFF -- skip 1-127 pixels

Tile mode works on frame split into 4x4 tiles with tile operations packed into Huffman-compressed tokens.
Known operations are:
* fill tile with a pair of colours (those values are part of the token)
* fill tile with a pair of colours (those values are part of the token) using mask
* fill tile with four/eight/sixteen colours using mask, token contains offset in the colour table for the colours to be used
* leave some tiles unchanged
* leave the rest of the current tile row unchanged
* repeat previous operation N times

It is worth noting that if the first colour value is zero, then tile is coded in update mode with zero value meaning "leave pixel unchanged".

=== Palette chunk ===
If chunk flags are 0, chunk contains new palette. If chunk flags are 1, current palette should be zeroed out.

=== Table chunk ===
Chunk flags determine table type. 0 means the colours used in tiled decoding, 1 means Huffman LUT definition (also for tiled decoding).

Huffman LUT is stored run-encoded (3 bytes - token value, 1 byte - repeat count) with initial 32-bit value telling the length of unpacked table.

[[Category:Game Formats]]

MXV

2025-03-15T13:59:19Z

Kostya: fill information

* Company: Caiman
* Extension: MXV

This is a format used for music and video in (Argentinian?) kid-oriented games by Caiman. There are two versions of the format, the older one stores LZ-compressed video and PCM audio, newer version has slightly different format and employs Vorbis audio.

== Old format ==

Header:
13 bytes - 'Archivo MXV.\x1A"
4 bytes - number of video frames (0 for audio-only files)
2 bytes - width
2 bytes - height
1 byte - bits per pixel (8-24)
2 bytes - frames per second
4 bytes - number of audio frames
2 bytes - sampling rate
1 byte - bits per audio sample
1 byte - number of audio channels
1 byte - unknown

If video frames are present, it is followed by the table with the following structure of records:
4 bytes - data offset
4 bytes - compressed data size
4 bytes - unpacked data size
4 bytes - timestamp
1 byte - flags

If audio frames are present, there are 32-bit offsets to audio data present right after the header and video frame data (if present). Audio chunks always contain 1 second of PCM audio so storing size is unnecessary.

Video frames are stored as optional palette (signalled by bit 0 of the flags) followed by image data which may be optionally compressed (bit 1 of the flag signals deflate being used on the data, bit 2 of the flags tells that it's custom LZW compression scheme).

== New format ==
Here "Archivo MXV.\x1A" is followed by chunks with various kinds of data:
* <code>FHDR</code> -- actual header (video and audio parameters, the format is similar to the old version)
* <code>VTBL</code> -- video frame table (32-bit offset, compressed size, timestamp and flags)
* <code>ATBL</code> -- audio table (now with 32-bit offset and size for each frame)
* <code>AHDR</code> -- Vorbis headers
* <code>DATA</code> -- actual video and audio data (with offsets being relative to its start)

Video data compression seems to still employ deflate on raw images and some additional method for interframes.

[[Category:Game Formats]]

Jazz Jackrabbit 2 J2V

2025-03-14T17:07:17Z

Kostya: fill information

This is an animation format used in [https://www.mobygames.com/game/1348/jazz-jackrabbit-2/ Jazz Jackrabbit 2] game.

Header format:
8 bytes - "CineFeeed"
4 bytes - file size
4 bytes - CRC
4 bytes - width
4 bytes - height
2 bytes - depth (should be 8)
2 bytes - delay between frames in milliseconds
4 bytes - number of frames
20 bytes - some sizes

Frame data is split into four streams with different kinds of data (a la [[Smacker]] or [[Bink]]), each compressed with <code>deflate</code> independently and with chunks containing data for one or more frames being output time from time. Decoder needs to prefetch and unpack that data.

For that reason the rest of the file consists of variable-size repeat of data chunks for each stream prefixed with 32-bit size. Chunks may be empty.

Data streams are:
* stream 0 - opcodes
* stream 1 - X offsets
* stream 2 - Y offsets
* stream 3 - colour data

Frame decoding works in the following way:
pal_present = read_stream(OPCODES, 1);
if (pal_present) {
pal = read_stream(CLR, 1024); // in RGBA format
}
for each line {
pos = 0;
while (pos < width) {
op = read_stream(OPCODES, 1);
switch (op) {
case 0: // long copy
len = (uint16_t)read_stream(OPCODES, 2);
copy len pixels to the current line position from CLR stream
pos += len;
break;
case 0x01..0x7F: // short copy
len = op;
copy len pixels to the current line position from CLR stream
pos += len;
break;
case 0x80: // end of line
pos = width;
break;
case 0x81: // long copy of previous segment
len = (uint16_t)read_stream(OPCODES, 2);
xoff = (uint16_t)read_stream(XOFF, 2);
yoff = read_stream(YOFF, 1) - 127;
copy len pixels from (x, y + yoff) position in the previous frame
pos += len;
break;
default: // short copy of previous segment
len = op;
xoff = (uint16_t)read_stream(XOFF, 2);
yoff = read_stream(YOFF, 1) - 127;
copy len pixels from (x, y + yoff) position in the previous frame
pos += len;
}
}
}

[[Category:Game Formats]]

Ascorn SKS

2025-03-14T16:07:54Z

Kostya: fill information

This is a simple cutscene format used by Ascorn in their game [https://www.mobygames.com/game/3817/patrician-ii-quest-for-power/ Patrician II]. It is essentially [[Motion JPEG]] with frame index.

File header:
4 bytes - "SK10"
4 bytes - width
4 bytes - height
4 bytes - framerate
4 bytes - number of frames
12 bytes - unused?
(4 bytes, 4 bytes) x N - frame index (first value - frame offset, second value - frame size)
4 bytes - total size
4 bytes - padding

Each frame is the standard JFIF data.

[[Category:Game Formats]]

Ascorn animation

2025-03-14T16:00:50Z

Kostya: fill information

This is an animation format used by Ascorn (later Ascaron) in some of its games like [https://www.mobygames.com/game/3816/gloriana/ Elisabeth I (aka Gloriana)] or [https://www.mobygames.com/game/40963/das-hexagon-kartell/ Das Hexagon Kartell]. Unlike many other formats it decodes YUV picture with 5 or 6 bits per component.

File is organised into a series of chunks, each with 4-byte type and size. First chunk should be <code>AN15</code>, last one should be <code>ENDE</code>

=== Header chunk ===
4 bytes - "AN15"
4 bytes - size (usually 64)
4 bytes - zero
4 bytes - header size again
4 bytes - "V0.9"
4 bytes - number of video frames
4 bytes - number of audio frames
4 bytes - unknown, usually zero
4 bytes - offset to video frame index
4 bytes - offset to audio frame index
12 bytes - always zero?
3 bytes - unknown
4 bytes - unknown
1 byte - unknown
4 bytes - frames per one hundredth of second (e.g. 1250 for 12.5 fps)
4 bytes - unknown

=== Audio chunk ===
4 bytes - "SAMP"
4 bytes - size
4 bytes - CRC
4 bytes - header size (usually 15, starting from CRC field)
3 bytes - sample rate
1 byte - number of channels
1 byte - bits per sample
2 bytes - usually zero

Audio data is unpacked PCM

=== Palette chunk ===
4 bytes - "PALT"
4 bytes - size
4 bytes - usually zero
4 bytes - unknown
768 bytes - VGA palette
rest - LUT

This chunk provides look-up table for mapping YUV data into indexed colours.

=== Picture chunk ===
4 bytes - "BILD"
4 bytes - size
4 bytes - usually zero
4 bytes - header size
2 bytes - width
2 bytes - height
2 bytes - compression mode
4 bytes - luma size
4 bytes - first chroma component size
4 bytes - second chroma component size
8 bytes - unknown
if header size > 34 {
11 bytes - unknown
1 byte - bits per luma sample (0 or 5 - 5 bits, 6 - 6 bits)
}

There are several compression methods known:
* 2 - raw YUV data packed in bits (5 or 6 bits for luma, signed 8 bits for chroma), luma plane first, chroma planes afterwards
* 3 - differences to the previous YUV frame
* 4 - same as method 3 but data is motion compensated with MV data sent before the change data (each 8x8 luma block having MV source consisting of 9-bit vertical offset and 10-bit horizontal offset)
* 16 - RGB compression

Method 3 codes data almost in the same way as method 2 except that zero component value means skip with the next 8- or 16-bit value (top bit set means 16-bit value, 8 bits otherwise) being the number of values to leave unchanged.

Method 16 is LZ77-like compression performed on RGB24 data. Flags are grouped in bytes and sent before the rest of the data. Flag 1 means raw RGB triplet, flag 0 means reading 16-bit offset plus 8-bit length (plus three) and copying that number of pixels from that offsets.

Image data is stored in wrapped 128000-pixel buffer which fits two images, so the previous image may be referenced while decoding the current one.

=== Index chunks ===
4 bytes - "SPTR" (audio) / "BPTR" (video)
4 bytes - usually 4
4 bytes - usually 12
4 bytes - number of entries
N*4 bytes - offsets to the audio/video frame chunks

[[Category:Game Formats]]

Ravenloft ANM

2025-03-14T15:05:59Z

Kostya: fill information

* Company: DreamForge
* Extension: ANM
* Game: [https://www.mobygames.com/game/3315/ravenloft-strahds-possession/ Ravenloft]

This is a simple RLE-based cutscene format. The header contains 16-bit number of frames and version. Then frames consisting of one or more chunks follow.

Frame starts with 16-bit number of chunks followed by chunks, each with 16-bit type and 32-bit size.

Chunk types are:
* 0 - VGA palette
* 1 - clear palette command
* 2 - intra RLE
* 3 - inter RLE
* 4 - repeat decoding previous chunk 16-bit times at 32-bit offset
* 5-7 - some game engine commands
* 8 - raw image interleaved by factor four (i.e. each line stores pixels in order 0 40 80 120 1 41 81 ...)

Intra RLE is trivial: read one-byte opcode, non-negative values mean copy length minus one, negative values mean run length minus one.

Inter RLE operates on updating columns of video: first 16-bit number is how many areas to update there are, each one starts with 16-bit left offsets and 16-bit number of segments to update. Each segment is coded as 16-bit number of pixels to skip (vertically) plus how many pixels to update (also vertically), followed by pixel values.

[[Category:Game Formats]]

Black Diamond STR

2025-03-09T17:46:35Z

Kostya: fill information

* Extension: STR

At least one computer/video [[FMV]] game (Psychic Detective) developed by Colossal Pictures and published by [[Electronic Arts]] uses a custom video codec stored in several huge files with extension .str

Video frames are encoded with a method strongly resembling [[Cinepak]], while audio is encoded using the stock [[IMA ADPCM]] algorithm.

The identifier "Black Diamond" comes from a string found in the game's executable: '''MS-DOS Black Diamond Player V0.10.1 BETA.'''

Data is organised into chunks with 32-bit tag and size. 0xF7F7F8F8 is used for audio, "MRFI" is used for images.

Video frame header:
1 byte - unknown
1 byte - method (should be 5 or 6)
2 bytes - number of tiles for 4x4 blocks, first part
2 bytes - number of tiles for 4x4 blocks, second part
2 bytes - number of tiles for 2x2 sub-blocks
2 bytes - palette size
2 bytes - switch line (before it tiles from the first part are used, afterwards - from the second part)
2 bytes - always zero?
N bytes - palette
K*4 bytes - paletted vectors for first 4x4 part
L*4 bytes - paletted vectors for second 4x4 part
M*4 bytes - paletted vectors for 2x2 sub-blocks
K*6 bytes - YUV vectors for first 4x4 part
L*6 bytes - YUV vectors for second 4x4 part
M*6 bytes - YUV vectors for 2x2 part

Then there is a mask telling whether block is coded using one or four vector, followed by vector indices. Decoding is the same as in Cinepak, only data ordering differs.

== References ==

* Mobygames link: http://www.mobygames.com/game/psychic-detective

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

ReadySoft scenes

2025-03-09T17:37:29Z

Kostya: fill some information

The company has created several PC ports of classic FMV games such as [https://www.mobygames.com/game/4495/dragons-lair-escape-from-singes-castle/ Dragon's Lair], [https://www.mobygames.com/game/54843/space-ace/ Space Ace] or [https://www.mobygames.com/game/2083/brain-dead-13/ Brain Dead 13].

While the formats for each game differ, there is a lot of common between them. For instance, they all employ RLE compression, splitting image into background and sprite and moving them separately.

== Dragon's Lair scenes ==
Files start with 128-byte header, followed by chunks with the following header:
2 bytes - some count
4 bytes - chunk size
4 bytes - unknown
4 bytes - chunk type

Chunk type is a four-character code telling what kinds of data it has inside. First letter being 'A' means RLE-encoded inter frame while 'B' chunks contain raw background image and audio. Images are stored in VGA banked mode (i.e. every fourth column).

== Space Ace scenes ==

Data is organised into chunks (32-bit next chunk offset plus 16-bit chunk ID) with the following meaning:
* 0 - background
* 1 - sprite
* 2 - audio
* 5 - frame output command?
* 6 - VGA palette update (starts with 16-bit number of colours, 32-bit offset to palette data)

Background data starts with several 16-bit values: image translation vector (i.e. how to shift it up/left), update area X offset and width, update area Y offset and with. Then there are 32-bit image data size and offset (usually image starts immediately after the header).
Image is coded with RLE: one-byte opcode, 0x80 means end of decoding, negative values mean run, 0x00 is no-op, positive values mean copy.

Sprite data starts with 16-bit coordinates, 32-bit mask offset and 32-bit data offset. Mask tells which 8x8 sprite blocks should be decoded and displayed over background.

Audio data starts with 32-bit size and offset.

Additionally images are coded for VGA banked mode (i.e. interlaced by every fourth column), in transposed form and background image has size 328x208.

== Brain Dead 13 scenes ==

Data is organised into chunks (32-bit next chunk offset plus 16-bit chunk ID) with the following meaning:
* 0 - background
* 1 - sprite
* 2 - audio
* 5 - frame output command?
* 6 - VGA palette update (starts with 16-bit number of colours, 32-bit offset to palette data)
* 10 - some header chunk
* 11 - audio header

Background data starts with three pairs of 16-bit values: image translation vector (i.e. how to shift it up/left), update area coordinates, update area dimensions. Then there are 32-bit image data size and offset (usually image starts immediately after the header).
Image is coded with RLE: one-byte opcode, 0x80 means end of decoding, negative values mean run, positive values mean copy.

Sprite data starts with 16-bit coordinates, 16-bit update flag, 32-bit sprite data size and offset. Image data is coded in the same manner but with two enhancements: opcode 0x00 means long RLE with actual 16-bit operation length, and there are two special pixel values (0x00 mean leave pixel unchanged and 0xFF mean copying data from the background frame).

Audio data starts with 32-bit size and offset.

[[Category:Game Formats]]