Origin Xan Codec: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(→‎Games Using Xan Video: not on No Remorse game)
Line 68: Line 68:


* [http://www.mobygames.com/game/dos/crusader-no-regret Crusader: No Regret (DOS)]
* [http://www.mobygames.com/game/dos/crusader-no-regret Crusader: No Regret (DOS)]
* [http://www.mobygames.com/game/dos/crusader-no-remorse Crusader: No Remorse (DOS)]
* [http://www.mobygames.com/game/windows/pandemonium Pandemonium!] (note: not an Origin's game!)
* [http://www.mobygames.com/game/windows/pandemonium Pandemonium!] (note: not an Origin's game!)
* [http://www.mobygames.com/game/wing-commander-iv-the-price-of-freedom Wing Commander IV]
* [http://www.mobygames.com/game/wing-commander-iv-the-price-of-freedom Wing Commander IV]

Revision as of 00:23, 14 February 2012

The Xan codec is a codec used in various multimedia-heavy titles from early in the FMV-era of PC computer games. The video was packaged in AVI files along with a custom DPCM audio codec.

While not all of the details have been reverse engineered, the Xan codec is known to use the same byte unpacking algorithm as used in the custom video codec developed for Wing Commander III. Further, it uses Huffman coding and bit packing, though using a slightly different algorithm than its predecessor codec, and it appears to have been designed to easily accommodate a number of video output and scaling modes.

Trivia: All Xan-encoded AVI files contain very interesting comment string inside. 'Xxan video stream, Blue Mu Productions.' What could possible that Blue Mu be? A subdivision of Origin or real codec authors?

Format

This codec is similar to Wing Commander III MVE Video Codec and employs the same packing algorithm. The main difference is that this codec stores information in YUV colorspace (6 bits for Y component, 5 bits for U and V components).

Frame format:

 header:
  bytes  0-3  - frame type
  bytes  4-7  - offset to chroma data
  bytes  8-11 - offset to luma refinements
  bytes 12-? - luma Huffman-coded data for frame type 0
 or
  bytes 12-15 - offset to chroma differences
  bytes 16-? - luma Huffman-coded data for frame type 1
 chroma data:
  bytes 0-1 - chroma data is YUV420 or YUV410
  bytes 2-3 - offset to Huffman-coded chroma indexes
  bytes 4-? - possible chroma values

Luma data is packed with left-to-right Huffman codes, chroma data is packed with the same wc3_unpack.

Huffman codes for luma

Huffman tree is stored in this form:

 1 byte - number of symbols (usually 32)
 1 byte - EOF symbol (usually 32)
 [symbols*2] bytes - tree description

Tree description consists of tree nodes pointing to other nodes or symbols (if node value is equal or less than EOF symbol).

Decoding is done by reading bits in MSB order and traversing the tree (root node is the last node of the tree).

Intra frame (type 0)

Luma reconstruction

Only every second pixel value is coded, the other half is interpolated as an average of their right and left neighbours. An optional enhancement for interpolated pixels can be present as a separate chunk (called luma refinement previously). Coded values are 5-bit delta coded and then expanded to 6-bit range. Top line uses deltas between current and left neighbour, the rest of lines use top neighbour for prediction.

For details please refer libavcodec/xxan.c

Chroma reconstruction

Chroma values use 16-bit symbol table prior to packed data for storing possible chroma values.

Inter frame (type 1)

Luma reconstruction

It employs the same principle of coding but previous frame luma values are used for prediction.

Games Using Xan Video