DXA: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
m (Update samples link)
mNo edit summary
Line 11: Line 11:


   dword Signature;
   dword Signature;
   byte  Unknown;
   byte  Version;
   word  Frames;
   word  Frames;
   dword FrameRate;
   dword FrameRate;

Revision as of 12:36, 26 September 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:

  dword Signature;
  byte  Version;
  word  Frames;
  dword FrameRate;
  word  Width;
  word  Height;
  • Signature - File signature 'DEXA'.
  • Frames - Number of logical frames.
  • FrameRate - can be determined this way:
 if (FrameRate > 0)
   fps = 1000 / FrameRate;
 else if (FrameRate < 0)
   fps = 100000 / (-FrameRate);
 else
   fps = 10;
  • Width, Height - Frame dimensions in pixels.

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.