DXA: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
m (add a company; wikify some words)
(added format description)
Line 3: Line 3:
* Samples: http://www.mplayerhq.hu/MPlayer/samples/game-formats/dxa/
* Samples: http://www.mplayerhq.hu/MPlayer/samples/game-formats/dxa/


The DXA format is used for videos in the Amiga and Macintosh versions of the [http://www.mobygames.com/game/feeble-files Feeble Files]. It is basically zlib compressed video frames, using [[WAV]] format for audio. The Macintosh version uses [[Microsoft ADPCM]] format for the audio.
The DXA format is used for videos in the Amiga and Macintosh versions of the [http://www.mobygames.com/game/feeble-files Feeble Files]. It is basically [[zlib]] compressed video frames, using [[WAV]] format for audio. The Macintosh version uses [[Microsoft ADPCM]] format for the audio.


The source code of a player for the DXA format can be found at: http://membres.lycos.fr/cyxdown/scummvm/feeble/
The source code of a player for the DXA format can be found at: http://membres.lycos.fr/cyxdown/scummvm/feeble/
== Data Format ==
All multi-byte numbers are stored in big endian format. A DXA file begins with a video header with is laid out as follows:
  bytes 0-3    file signature: 'DEXA'
  byte 4      unknown
  bytes 5-6    frame count
  bytes 7-10  frame per second, saturated to an upper limit of 100
  bytes 11-12  frame width
  bytes 13-14  frame height
If the file contains an audio chunk, a [[Microsoft Wave]] file will be appear in its entirety after the video header.
Following any sound data there will be a sequence of CMAP, FRAM, and NULL chunks. The format of a CMAP chunk is as follows:
  bytes 0-3    chunk [[FourCC]]: 'CMAP'
  bytes 4-771  256 3-byte RGB palette triplets
Each palette component has a full 8-bit range of 0..255. The FRAM chunk is formatted as follows:
  bytes 0-3    chunk FourCC: 'FRAM'
  byte 4      compression type
  bytes 5-8    chunk size (not including this 9-byte preamble)
  bytes 9..    chunk payload
A NULL frame simply consists of the FourCC 'NULL'. There is no other data associated with it. A NULL frame instructs the decoder not to update the video buffer during this frame.
== Video Coding ==
Compression method 2 is the standard zlib algorithm. The entire payload data buffer is fed into zlib's inflate() method and the output is the decompressed video frame. That video frame is presented to the user.
Compression method 3 is the same as method 2. However, the video data is decoded into a temporary buffer. Then, the entire frame is XOR'd against the previous frame and the result is presented to the user.
Compression methods 4 and 6 are unknown. Compression methods 5 and 7 are the same as methods 4 and 6, respectively, but the decoded data is XOR'd against the previously decoded frame, as is done with method 3.


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

Revision as of 17:32, 17 April 2006

The DXA format is used for videos in the Amiga and Macintosh versions of the Feeble Files. It is basically zlib compressed video frames, using WAV format for audio. The Macintosh version uses Microsoft ADPCM format for the audio.

The source code of a player for the DXA format can be found at: http://membres.lycos.fr/cyxdown/scummvm/feeble/

Data Format

All multi-byte numbers are stored in big endian format. A DXA file begins with a video header with is laid out as follows:

 bytes 0-3    file signature: 'DEXA'
 byte 4       unknown
 bytes 5-6    frame count
 bytes 7-10   frame per second, saturated to an upper limit of 100
 bytes 11-12  frame width
 bytes 13-14  frame height

If the file contains an audio chunk, a Microsoft Wave file will be appear in its entirety after the video header.

Following any sound data there will be a sequence of CMAP, FRAM, and NULL chunks. The format of a CMAP chunk is as follows:

 bytes 0-3    chunk FourCC: 'CMAP'
 bytes 4-771  256 3-byte RGB palette triplets

Each palette component has a full 8-bit range of 0..255. The FRAM chunk is formatted as follows:

 bytes 0-3    chunk FourCC: 'FRAM'
 byte 4       compression type
 bytes 5-8    chunk size (not including this 9-byte preamble)
 bytes 9..    chunk payload

A NULL frame simply consists of the FourCC 'NULL'. There is no other data associated with it. A NULL frame instructs the decoder not to update the video buffer during this frame.

Video Coding

Compression method 2 is the standard zlib algorithm. The entire payload data buffer is fed into zlib's inflate() method and the output is the decompressed video frame. That video frame is presented to the user.

Compression method 3 is the same as method 2. However, the video data is decoded into a temporary buffer. Then, the entire frame is XOR'd against the previous frame and the result is presented to the user.

Compression methods 4 and 6 are unknown. Compression methods 5 and 7 are the same as methods 4 and 6, respectively, but the decoded data is XOR'd against the previously decoded frame, as is done with method 3.