MultimediaWiki - User contributions [en]

DFA

2013-04-06T15:01:59Z

VAG: /* TDLT chunk */ tdlt sample file

* Extensions: dfa
* Samples: [http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/ http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/]

DFA is a FMV format used in PC games developed by DreamForge.

== File format ==

All multi-byte numbers are little endian. These files are comprised of chunks with the following format:

bytes 0-3 chunk fourcc
bytes 4-7 chunk size, not including 12-byte preamble
bytes 8-11 chunk type, essentially numeric equivalent of fourcc
bytes 12.. chunk payload

A DFA file begins with a 128- (0x80-)byte header:

bytes 0-3 file signature: 'DFIA'
byte 4 version (= 0)
byte 5 ? (output)
bytes 6-7 number of frames
bytes 8-9 frame width
bytes 10-11 frame height
bytes 12-15 frame rate
bytes 16-19 first frame offset (= 0x80)
bytes 20-23 ? (odirectory)
bytes 24-127 unused

Chunk types include:

EOFR (type 0) end of frame, empty chunk
PAL1 (type 1) 768-byte chunk containing a 6-bit VGA palette components
COPY (type 2) raw frame data
TSW1 (type 3) video frame, intra LZ-coded
BDLT (type 4) video frame, inter RLE-coded bytes
WDLT (type 5) video frame, inter RLE-coded words
TDLT (type 6) video frame, inter chains
DSW1 (type 7) video frame, inter LZ-coded
BLCK (type 8) solid frame, fill whole frame with the first byte of payload
DDS1 (type 9) video frame, inter LZ-coded, double-scaled

=== TSW1 chunk ===

First four bytes store number of stripes to change, next four bytes - offset inside frame. The rest is stripe data.

Every stripe is coded with 16-bit LSB little-endian words in LZ77-like scheme:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2;
count = ((v >> 13) + 2) * 2;
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else {
*cur_frame_pos++ = get_byte();
*cur_frame_pos++ = get_byte();
}
mask <<= 1;
}

=== BDLT chunk ===

First two bytes code number of lines to skip in frame before decoding, next two bytes code number of lines to decode.

Every line is coded into segments, first byte of data tells how many segments are there. Every segment is coded as RLE, first byte
tells how many pixels to skip before decoding segment, second byte is treated as signed value with sign telling if it's copy or run:

while (segments--) {
cur_line_ptr += get_byte();
count = (int8_t)get_byte();
if (count >= 0)
get_buffer(cur_line_ptr, count);
else
memset(cur_line_ptr, get_byte(), -count);
cur_line_ptr += abs(count);
}

=== WDLT chunk ===

First two bytes code number of lines to decode. Overall decoding is similar to BDLT chunk but with words copy instead of byte copy and different segment handling scheme:

while (lines--) {
stripes = (int16_t)get_le16();
while (stripes & 0xC000) {
*frame_ptr += -stripes * width;
stripes = (int16_t)get_le16();
}
if (stripes < 0) {
frame_ptr[width - 1] = stripes & 0xFF;
stripes = (int16_t)get_le16();
}
line_ptr = frame_ptr;
while (stripes--) {
line_ptr += get_byte();
count = (int8_t)get_byte();
if (count > 0) {
get_buffer(line_ptr, count * 2);
line_ptr += count * 2;
} else {
val = get_le16();
for (i = 0; i < -count * 2; i++) {
put_le16(line_ptr, val);
line_ptr += 2;
}
}
}
frame_ptr += width;
}

=== TDLT chunk ===

First four bytes code number of segments, each segment contains number of words to skip before decoding, number of words to copy and bytes to copy.

segments = getdword()
while(segments--)
{
numcopy = getbyte()
numskip = getbyte()
output += numskip * 2
output <- getbytes(numcopy * 2)
}

''Can't upload a sample to mplayerhq, grab it here and reupload yourself: http://www.sendspace.com/file/a9bn4j -- [[User:VAG|VAG]] 11:01, 6 April 2013 (EDT)''

=== DSW1 chunk ===

Almost the same as TSW1 chunk with the following differences:

* first two bytes code number of stripes
* if getbit() returned zero, get and test another bit. If that bit is zero too then read literal (two bytes), else read 2-byte number and skip corresponding number of pixels. And report two bits read in any case.

=== DDS1 chunk ===

Almost the same as DSW1 chunk but it decodes in scaled mode - every skip is twice that large, literal is used to set 2x2 block and copying also fills 2x2 block with pixel value:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2 * 2;
count = ((v >> 13) + 2) * 2;
for (i = 0; i < count; i++) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = cur_frame_pos[-offset];
cur_frame_pos += 2;
}
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else if (!(bitbuf & (mask << 1)) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
} else {
cur_frame_pos += get_le16() * 2;
}
mask <<= 2;
}

== Games using DFI ==
* [http://www.mobygames.com/game/anvil-of-dawn Anvil of Dawn]
* [http://www.mobygames.com/game/dos/chronomaster Chronomaster]

[[Category:Game Formats]]

DFA

2013-04-05T23:05:31Z

VAG: typo

* Extensions: dfa
* Samples: [http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/ http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/]

DFA is a FMV format used in PC games developed by DreamForge.

== File format ==

All multi-byte numbers are little endian. These files are comprised of chunks with the following format:

bytes 0-3 chunk fourcc
bytes 4-7 chunk size, not including 12-byte preamble
bytes 8-11 chunk type, essentially numeric equivalent of fourcc
bytes 12.. chunk payload

A DFA file begins with a 128- (0x80-)byte header:

bytes 0-3 file signature: 'DFIA'
byte 4 version (= 0)
byte 5 ? (output)
bytes 6-7 number of frames
bytes 8-9 frame width
bytes 10-11 frame height
bytes 12-15 frame rate
bytes 16-19 first frame offset (= 0x80)
bytes 20-23 ? (odirectory)
bytes 24-127 unused

Chunk types include:

EOFR (type 0) end of frame, empty chunk
PAL1 (type 1) 768-byte chunk containing a 6-bit VGA palette components
COPY (type 2) raw frame data
TSW1 (type 3) video frame, intra LZ-coded
BDLT (type 4) video frame, inter RLE-coded bytes
WDLT (type 5) video frame, inter RLE-coded words
TDLT (type 6) video frame, inter chains
DSW1 (type 7) video frame, inter LZ-coded
BLCK (type 8) solid frame, fill whole frame with the first byte of payload
DDS1 (type 9) video frame, inter LZ-coded, double-scaled

=== TSW1 chunk ===

First four bytes store number of stripes to change, next four bytes - offset inside frame. The rest is stripe data.

Every stripe is coded with 16-bit LSB little-endian words in LZ77-like scheme:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2;
count = ((v >> 13) + 2) * 2;
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else {
*cur_frame_pos++ = get_byte();
*cur_frame_pos++ = get_byte();
}
mask <<= 1;
}

=== BDLT chunk ===

First two bytes code number of lines to skip in frame before decoding, next two bytes code number of lines to decode.

Every line is coded into segments, first byte of data tells how many segments are there. Every segment is coded as RLE, first byte
tells how many pixels to skip before decoding segment, second byte is treated as signed value with sign telling if it's copy or run:

while (segments--) {
cur_line_ptr += get_byte();
count = (int8_t)get_byte();
if (count >= 0)
get_buffer(cur_line_ptr, count);
else
memset(cur_line_ptr, get_byte(), -count);
cur_line_ptr += abs(count);
}

=== WDLT chunk ===

First two bytes code number of lines to decode. Overall decoding is similar to BDLT chunk but with words copy instead of byte copy and different segment handling scheme:

while (lines--) {
stripes = (int16_t)get_le16();
while (stripes & 0xC000) {
*frame_ptr += -stripes * width;
stripes = (int16_t)get_le16();
}
if (stripes < 0) {
frame_ptr[width - 1] = stripes & 0xFF;
stripes = (int16_t)get_le16();
}
line_ptr = frame_ptr;
while (stripes--) {
line_ptr += get_byte();
count = (int8_t)get_byte();
if (count > 0) {
get_buffer(line_ptr, count * 2);
line_ptr += count * 2;
} else {
val = get_le16();
for (i = 0; i < -count * 2; i++) {
put_le16(line_ptr, val);
line_ptr += 2;
}
}
}
frame_ptr += width;
}

=== TDLT chunk ===

First four bytes code number of segments, each segment contains number of words to skip before decoding, number of words to copy and bytes to copy.

segments = getdword()
while(segments--)
{
numcopy = getbyte()
numskip = getbyte()
output += numskip * 2
output <- getbytes(numcopy * 2)
}

=== DSW1 chunk ===

Almost the same as TSW1 chunk with the following differences:

* first two bytes code number of stripes
* if getbit() returned zero, get and test another bit. If that bit is zero too then read literal (two bytes), else read 2-byte number and skip corresponding number of pixels. And report two bits read in any case.

=== DDS1 chunk ===

Almost the same as DSW1 chunk but it decodes in scaled mode - every skip is twice that large, literal is used to set 2x2 block and copying also fills 2x2 block with pixel value:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2 * 2;
count = ((v >> 13) + 2) * 2;
for (i = 0; i < count; i++) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = cur_frame_pos[-offset];
cur_frame_pos += 2;
}
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else if (!(bitbuf & (mask << 1)) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
} else {
cur_frame_pos += get_le16() * 2;
}
mask <<= 2;
}

== Games using DFI ==
* [http://www.mobygames.com/game/anvil-of-dawn Anvil of Dawn]
* [http://www.mobygames.com/game/dos/chronomaster Chronomaster]

[[Category:Game Formats]]

DFA

2013-04-05T23:04:38Z

VAG: /* File format */

* Extensions: dfa
* Samples: [http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/ http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/]

DFA is a FMV format used in PC games develped by DreamForge.

== File format ==

All multi-byte numbers are little endian. These files are comprised of chunks with the following format:

bytes 0-3 chunk fourcc
bytes 4-7 chunk size, not including 12-byte preamble
bytes 8-11 chunk type, essentially numeric equivalent of fourcc
bytes 12.. chunk payload

A DFA file begins with a 128- (0x80-)byte header:

bytes 0-3 file signature: 'DFIA'
byte 4 version (= 0)
byte 5 ? (output)
bytes 6-7 number of frames
bytes 8-9 frame width
bytes 10-11 frame height
bytes 12-15 frame rate
bytes 16-19 first frame offset (= 0x80)
bytes 20-23 ? (odirectory)
bytes 24-127 unused

Chunk types include:

EOFR (type 0) end of frame, empty chunk
PAL1 (type 1) 768-byte chunk containing a 6-bit VGA palette components
COPY (type 2) raw frame data
TSW1 (type 3) video frame, intra LZ-coded
BDLT (type 4) video frame, inter RLE-coded bytes
WDLT (type 5) video frame, inter RLE-coded words
TDLT (type 6) video frame, inter chains
DSW1 (type 7) video frame, inter LZ-coded
BLCK (type 8) solid frame, fill whole frame with the first byte of payload
DDS1 (type 9) video frame, inter LZ-coded, double-scaled

=== TSW1 chunk ===

First four bytes store number of stripes to change, next four bytes - offset inside frame. The rest is stripe data.

Every stripe is coded with 16-bit LSB little-endian words in LZ77-like scheme:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2;
count = ((v >> 13) + 2) * 2;
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else {
*cur_frame_pos++ = get_byte();
*cur_frame_pos++ = get_byte();
}
mask <<= 1;
}

=== BDLT chunk ===

First two bytes code number of lines to skip in frame before decoding, next two bytes code number of lines to decode.

Every line is coded into segments, first byte of data tells how many segments are there. Every segment is coded as RLE, first byte
tells how many pixels to skip before decoding segment, second byte is treated as signed value with sign telling if it's copy or run:

while (segments--) {
cur_line_ptr += get_byte();
count = (int8_t)get_byte();
if (count >= 0)
get_buffer(cur_line_ptr, count);
else
memset(cur_line_ptr, get_byte(), -count);
cur_line_ptr += abs(count);
}

=== WDLT chunk ===

First two bytes code number of lines to decode. Overall decoding is similar to BDLT chunk but with words copy instead of byte copy and different segment handling scheme:

while (lines--) {
stripes = (int16_t)get_le16();
while (stripes & 0xC000) {
*frame_ptr += -stripes * width;
stripes = (int16_t)get_le16();
}
if (stripes < 0) {
frame_ptr[width - 1] = stripes & 0xFF;
stripes = (int16_t)get_le16();
}
line_ptr = frame_ptr;
while (stripes--) {
line_ptr += get_byte();
count = (int8_t)get_byte();
if (count > 0) {
get_buffer(line_ptr, count * 2);
line_ptr += count * 2;
} else {
val = get_le16();
for (i = 0; i < -count * 2; i++) {
put_le16(line_ptr, val);
line_ptr += 2;
}
}
}
frame_ptr += width;
}

=== TDLT chunk ===

First four bytes code number of segments, each segment contains number of words to skip before decoding, number of words to copy and bytes to copy.

segments = getdword()
while(segments--)
{
numcopy = getbyte()
numskip = getbyte()
output += numskip * 2
output <- getbytes(numcopy * 2)
}

=== DSW1 chunk ===

Almost the same as TSW1 chunk with the following differences:

* first two bytes code number of stripes
* if getbit() returned zero, get and test another bit. If that bit is zero too then read literal (two bytes), else read 2-byte number and skip corresponding number of pixels. And report two bits read in any case.

=== DDS1 chunk ===

Almost the same as DSW1 chunk but it decodes in scaled mode - every skip is twice that large, literal is used to set 2x2 block and copying also fills 2x2 block with pixel value:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2 * 2;
count = ((v >> 13) + 2) * 2;
for (i = 0; i < count; i++) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = cur_frame_pos[-offset];
cur_frame_pos += 2;
}
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else if (!(bitbuf & (mask << 1)) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
} else {
cur_frame_pos += get_le16() * 2;
}
mask <<= 2;
}

== Games using DFI ==
* [http://www.mobygames.com/game/anvil-of-dawn Anvil of Dawn]
* [http://www.mobygames.com/game/dos/chronomaster Chronomaster]

[[Category:Game Formats]]

DFA

2013-04-05T23:01:26Z

VAG: name chunk #6, fix algo, add game

* Extensions: dfa
* Samples: [http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/ http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/]

DFA is a FMV format used in PC games develped by DreamForge.

== File format ==

All multi-byte numbers are little endian. These files are comprised of chunks with the following format:

bytes 0-3 chunk fourcc
bytes 4-7 chunk size, not including 12-byte preamble
bytes 8-11 chunk type, essentially numeric equivalent of fourcc
bytes 12.. chunk payload

A DFA file begins with a 128- (0x80-)byte header:

bytes 0-3 file signature: 'DFIA'
byte 4 version (= 0)
byte 5 ? (output)
bytes 6-7 number of frames
bytes 8-9 frame width
bytes 10-11 frame height
bytes 12-15 frame rate
bytes 16-19 first frame offset (= 0x80)
bytes 20-23 ? (odirectory)
bytes 24-127 unused

Chunk types include:

EOFR (type 0) end of frame, empty chunk
PAL1 (type 1) 768-byte chunk containing a 6-bit VGA palette components
COPY (type 2) raw frame data
TSW1 (type 3) video frame, intra LZ-coded
BDLT (type 4) video frame, inter RLE-coded bytes
WDLT (type 5) video frame, inter RLE-coded words
TDLT (type 6) not occured in known samples
DSW1 (type 7) video frame, inter LZ-coded
BLCK (type 8) solid frame, fill whole frame with the first byte of payload
DDS1 (type 9) video frame, inter LZ-coded, double-scaled

=== TSW1 chunk ===

First four bytes store number of stripes to change, next four bytes - offset inside frame. The rest is stripe data.

Every stripe is coded with 16-bit LSB little-endian words in LZ77-like scheme:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2;
count = ((v >> 13) + 2) * 2;
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else {
*cur_frame_pos++ = get_byte();
*cur_frame_pos++ = get_byte();
}
mask <<= 1;
}

=== BDLT chunk ===

First two bytes code number of lines to skip in frame before decoding, next two bytes code number of lines to decode.

Every line is coded into segments, first byte of data tells how many segments are there. Every segment is coded as RLE, first byte
tells how many pixels to skip before decoding segment, second byte is treated as signed value with sign telling if it's copy or run:

while (segments--) {
cur_line_ptr += get_byte();
count = (int8_t)get_byte();
if (count >= 0)
get_buffer(cur_line_ptr, count);
else
memset(cur_line_ptr, get_byte(), -count);
cur_line_ptr += abs(count);
}

=== WDLT chunk ===

First two bytes code number of lines to decode. Overall decoding is similar to BDLT chunk but with words copy instead of byte copy and different segment handling scheme:

while (lines--) {
stripes = (int16_t)get_le16();
while (stripes & 0xC000) {
*frame_ptr += -stripes * width;
stripes = (int16_t)get_le16();
}
if (stripes < 0) {
frame_ptr[width - 1] = stripes & 0xFF;
stripes = (int16_t)get_le16();
}
line_ptr = frame_ptr;
while (stripes--) {
line_ptr += get_byte();
count = (int8_t)get_byte();
if (count > 0) {
get_buffer(line_ptr, count * 2);
line_ptr += count * 2;
} else {
val = get_le16();
for (i = 0; i < -count * 2; i++) {
put_le16(line_ptr, val);
line_ptr += 2;
}
}
}
frame_ptr += width;
}

=== TDLT chunk ===

First four bytes code number of segments, each segment contains number of words to skip before decoding, number of words to copy and bytes to copy.

segments = getdword()
while(segments--)
{
numcopy = getbyte()
numskip = getbyte()
output += numskip * 2
output <- getbytes(numcopy * 2)
}

=== DSW1 chunk ===

Almost the same as TSW1 chunk with the following differences:

* first two bytes code number of stripes
* if getbit() returned zero, get and test another bit. If that bit is zero too then read literal (two bytes), else read 2-byte number and skip corresponding number of pixels. And report two bits read in any case.

=== DDS1 chunk ===

Almost the same as DSW1 chunk but it decodes in scaled mode - every skip is twice that large, literal is used to set 2x2 block and copying also fills 2x2 block with pixel value:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2 * 2;
count = ((v >> 13) + 2) * 2;
for (i = 0; i < count; i++) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = cur_frame_pos[-offset];
cur_frame_pos += 2;
}
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else if (!(bitbuf & (mask << 1)) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
} else {
cur_frame_pos += get_le16() * 2;
}
mask <<= 2;
}

== Games using DFI ==
* [http://www.mobygames.com/game/anvil-of-dawn Anvil of Dawn]
* [http://www.mobygames.com/game/dos/chronomaster Chronomaster]

[[Category:Game Formats]]

Bink Video 2

2012-11-17T14:19:01Z

VAG: it's missing, obviously

* FourCC: KB2d (in [[Bink Container]])
* Company: [[RAD Game Tools]]
* Samples: ''ADD ME''

Bink Video 2 is a successor to [[Bink Video]].

(De)Compression details are presently unknown.

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

Bink Video 2

2012-11-17T14:15:52Z

VAG: basic info

HNM4

2012-10-13T15:00:06Z

VAG: more cats

* Extension: hnm
* Company: [[CRYO Interactive Entertainment]]
* Samples: http://samples.mplayerhq.hu/game-formats/hnm/losteden-hnm4/

HNM4 is the third generation of the Cryo HNM video format. At least two decoder-incompatible variation of this format is known. Main version, operates in 320x200x256 resolution and simplified 640x480x256 spin-off, used in ALIENS game. Both formats share same container structure.

== File Format ==
File header:
dword signature - file signature, "HNM4"
dword unknown1 - probably format version
word width - width of the frame
word height - height of the frame
dword filesize - size of the entrie hnm file
dword frames - number of frames
dword taboffset - offset of the TAB chunk
word bits - sound sample resolution
word channels - number of sound channels
dword framesize - frame allocation size (width * height)
byte unknown2[16] - seems to be unused
byte copyright[16] - "-Copyright CRYO-"

The rest of the file organized on manner similar to [[HNM (1)]] format. All single-frame related chunks combined to superchunks, where each superchunk starts with 32-bit value, lower 24 bits of it indicates superchunk size and highest 8 bits - flags (unknown). Each chunk starts with another 24+8 bits length header followed by 4 bytes of chunk ID (where only 2 bytes can be actually used), and chunk data. Near the end of file usually TAB chunk located, it doesn't have an upper-level superchunk.

=== PL Chunk ===
Palette. Stored in same format as used in [[HNM (1)]].
* ALIENS: However, non-zero bit 23 of ChunkId indicates that palette stored in complete 8-bits-per-component format, unlike regular 6-bits otherwise.

=== IZ Chunk ===
Keyframe. See video decompression below.

=== IU Chunk ===
Interframe. See video decompression below.

=== SD Chunk ===
Sound data. [[PCM#Differential_PCM|DPCM]]-encoded sound fragment.

== Decoding Video ==
=== Intraframes ===
Intraframe decompression is simialar to [[HNM (1)]] 0xFE frames. But with a few changes. Chunk data starts with small 4-bytes header:
word width - width of the frame
byte height - height of the frame (only lower byte of it)
byte mode - rendering mode (always 0xFE ?)

Then immediately followed by LZ-packed raster (without 6-byte compression header as was used before). LZ decompression algorithm remains the same, but bitreader use 32-bits queue and processing bits from highest to lowest.

* You can safely ignore width/height/mode fields of the frame header as original decoder always renders whole frame regardless specified values.

=== Interframes ===
==== HNM4 Interframe ====
Packed interframe consist of one or more compression codes. Depending on the code's count field following cases possible:

bits
0..4 : count = 0
5..7 : tag:
0: copy next two bytes of input to the output
1: skip (next byte of input) * 2 bytes of output
2: skip (next word of input) * 2 bytes of output
3: fill (next byte of input) * 2 of output with (next byte of input)
else: finish the unpacking

- or -

0..4 : count <> 0
5 : previous
6 : backline
7 : backward
8 : swap
9..23 : offset

In this case for (count) pixel pairs, copy them from the (output + offset * 2 - 32768) of the current frame to the output. Flag bits modify various parameters of this scheme (multiple flags can be used):
* previous - copy pairs from the previous frame
* backline - first pixel located 2 lines above + (swap)
* backward - advance source pixel pairs in backward order
* swap - swap pair's pixels

==== HNM4A Interframe ====
HNM4A interframe is a simplified version of the HNM4 interframe. Code format:
bits
0..5 : count = 0
6..7 : tag:
0: skip (next byte of input) bytes of output
1: draw 1x2 column of the output with next 2 bytes of input
2: advance to the next line of output (but keep current x position)
3: finish the unpacking

- or -

0..5 : count <> 0
6 : previous
7 : delta
8..23 : offset

For (count) 1x2 columns copy them from the (output + offset) to the output.
* previous - copy column from the previous frame
* delta - copy column from (output + offset - 65536)

=== Postprocessing ===
For HNM4 (but not HNM4A movies) you need to perform extra frame postprocessing by swapping pixels using following self-explaining example (assuming 4xN image):

Just unpacked frame Final frame
p0 p1 p2 p3 ==> p0 p2 p4 p6
p4 p5 p6 p7 p1 p3 p5 p7
... ...

== Decoding Audio ==
'''TODO'''

== Games Using HNM4 ==
* Lost Eden
* Hardline
* Aliens
* Dragon Lore
* Dragon Lore II
* Treasure Hunter

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

HNM6

2012-10-13T14:55:27Z

VAG: /* Normal decoding */

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative), bits meaning:
7 : stereo
6..5 : frequency in units of 11025Hz (i.e. frequency = value * 11025)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 frames2 -- upper part of frame counter, ignored by some implementations
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Audio chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller blocks. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games circa 1997.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets are little-endian and relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0,1,8,16,9,...) and quantization tables (16,11,10,16, 24,...; 17,18,24,47,99,...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's complement value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's complement value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, the first coefficient is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of a plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock.
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC:
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not its subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame.
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements:
** For keyframe motion is the same as for WARP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame.

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right:
abc -> cba
==== 2 - Vertical flip ====
Swap up and down:
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right:
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around / :
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise:
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise:
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \ :
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-10-13T14:53:25Z

VAG: /* Format modifications */

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative), bits meaning:
7 : stereo
6..5 : frequency in units of 11025Hz (i.e. frequency = value * 11025)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 frames2 -- upper part of frame counter, ignored by some implementations
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Audio chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller blocks. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games circa 1997.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets are little-endian and relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0,1,8,16,9,...) and quantization tables (16,11,10,16, 24,...; 17,18,24,47,99,...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's complement value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's complement value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, the first coefficient is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of a plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock.
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC:
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not its subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame.
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements:
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame.

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right:
abc -> cba
==== 2 - Vertical flip ====
Swap up and down:
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right:
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around / :
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise:
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise:
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \ :
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-10-13T14:52:22Z

VAG: /* File Format */

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative), bits meaning:
7 : stereo
6..5 : frequency in units of 11025Hz (i.e. frequency = value * 11025)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 frames2 -- upper part of frame counter, ignored by some implementations
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller blocks. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games circa 1997.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets are little-endian and relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0,1,8,16,9,...) and quantization tables (16,11,10,16, 24,...; 17,18,24,47,99,...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's complement value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's complement value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, the first coefficient is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of a plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock.
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC:
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not its subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame.
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements:
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame.

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right:
abc -> cba
==== 2 - Vertical flip ====
Swap up and down:
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right:
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around / :
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise:
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise:
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \ :
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-10-13T14:52:00Z

VAG: /* File Format */

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative), bits meaning:
7 : stereo
6..5 : frequency in units of 11025 (i.e. frequency = value * 11025)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 frames2 -- upper part of frame counter, ignored by some implementations
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller blocks. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games circa 1997.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets are little-endian and relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0,1,8,16,9,...) and quantization tables (16,11,10,16, 24,...; 17,18,24,47,99,...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's complement value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's complement value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, the first coefficient is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of a plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock.
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC:
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not its subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame.
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements:
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame.

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right:
abc -> cba
==== 2 - Vertical flip ====
Swap up and down:
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right:
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around / :
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise:
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise:
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \ :
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-10-13T14:51:08Z

VAG: /* File Format */ explain several fields

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative), bits meaning:
8 : stereo
7..6 : frequency in units of 11025 (i.e. frequency = value * 11025)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 frames2 -- upper part of frame counter, ignored by some implementations
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller blocks. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games circa 1997.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets are little-endian and relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0,1,8,16,9,...) and quantization tables (16,11,10,16, 24,...; 17,18,24,47,99,...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's complement value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's complement value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, the first coefficient is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of a plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock.
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC:
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not its subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame.
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements:
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame.

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right:
abc -> cba
==== 2 - Vertical flip ====
Swap up and down:
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right:
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around / :
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise:
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise:
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \ :
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-09-08T19:15:56Z

VAG: /* Video Format */ typos

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 reserved2
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller blocks. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games circa 1997.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets are little-endian and relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0,1,8,16,9,...) and quantization tables (16,11,10,16, 24,...; 17,18,24,47,99,...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's complement value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's complement value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, the first coefficient is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of a plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock.
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC:
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not its subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame.
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements:
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame.

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right:
abc -> cba
==== 2 - Vertical flip ====
Swap up and down:
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right:
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around / :
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise:
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise:
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \ :
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-09-08T18:53:24Z

VAG: /* Block transformation */

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 reserved2
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller block. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets a relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0, 1, 8, 16, 9, ...) and quantization tables (16, 11, 10, 16, 24, ... ; 17, 18, 24, 47, 99, ...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's compliment value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's compliment value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, first entry is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit.)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not it's subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame

=== Block transformation ===
During block copying, it can be additionally transformed. Transformation modes:
==== 0 - Normal copy ====
Copy block as is.
==== 1 - Horizontal flip ====
Swap left and right
abc -> cba
==== 2 - Vertical flip ====
Swap up and down
a c
b -> b
c a
==== 3 - Cross flip ====
Swap both up-down and left-right
ab fe
cd -> dc
ef ba
==== 4 - Forward flip ====
Swap block around /
ab -> db
cd ca
==== 5 - Forward rotate ====
Rotate block 90 degrees clockwise
ab eca fe
cd -> fdb -> dc
ef ba
==== 6 - Backward rotate ====
Rotate block 90 degrees counterclockwise
ab bdf fe
cd -> ace -> dc
ef ba
==== 7 - Backward flip ====
Swap block around \
ab -> ac
cd bd

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-09-08T18:32:29Z

VAG: realing

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 reserved2
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller block. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets a relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

=== Key-blocks decoding ===
Key-blocks are JPEG-encoded blocks in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0, 1, 8, 16, 9, ...) and quantization tables (16, 11, 10, 16, 24, ... ; 17, 18, 24, 47, 99, ...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's compliment value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's compliment value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, first entry is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

=== WARP decoding ===
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit.)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not it's subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

=== Normal decoding ===
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame

=== Block transformation ===

=== Bitexact decoding ===
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

HNM6

2012-09-08T18:26:33Z

VAG: /* Normal decoding */ decoding

* Extension: hnm
* Company: CRYO Interactive Entertainment
* Samples:

HNM6 is the latest variant of [[HNM]] video format by Cryo. Unlike its previous versions, it has Hi-color video support.

== File Format ==
File consist of a main header, followed by frame chunks. Each frame chunk consist of individual audio and video chunks. All numbers are little-endian.

u8 sig[4] -- file signature, "HNM6"
u8 reserved[2] -- usually 0
u8 audioflags -- nonzero value indicates file has APC sound (not authoritative)
u8 bpp
u16 width
u16 height
u32 filesize
u16 frames -- number of frames
u16 reserved2
u32 reserved3 -- usually 0, but sometimes "V107", "V108" - version?
u16 speed -- playback speed in fps, may be zero (?assume 15 fps then?)
u16 maxbuffer -- number of frame buffers used
u32 maxchunk -- max frame chunk size
u8 note[16]
u8 copyright[16] -- "-Copyright CRYO-"

Each frame chunk begins with u32 chunk size (including this size field), then followed by frame's individual chunks:

u32 chunksize -- chunk size including this field, excluding padding
u16 chunkid -- TWOCC chunk id
u16 reserved
u8 data[]
u8 padding[] -- pads chunk to 4-byte boundary

=== AA Chunk ===
APC Audio. See [[CRYO APC]]

=== BB Chunk ===
Audio continuation.

=== IW Chunk ===
Video frame, WARP format.

=== IX Chunk ===
Video frame, normal format.

== Format modifications ==

At least one known game (Riverworld) uses slightly different HNM6 container format, most likely due to different sound encoding. This format is just a small enhancement of the original, but it's not backward compatible.

Standard HNM6 header continues with additional audio description header:

u32 freq
u32 bits
u32 channels
u32 ?
u32 ?
u8 copyright[28] -- "HNMS 1.1 by SARRET Hubert\0\0\0"
u32 ? -- some initial audio samples?
u32 ?
u32 ?
u32 ?

Each frame chunk followed by an audio chunk, however, this audio chunk size is not counted by frame's chunk size field.
Frame chunk format:

u32 sig[4] -- "SOUN"
u32 chunksize -- including this preamble
u8 data[]

== Video Format ==
The video compression relies on a concept of Key-blocks, encoded with [[JPEG]]-like algorithm and motion blocks, derived from previously drawn blocks. The frame is encoded in 8x8 or smaller block. The Key-blocks are always 8x8 and directly encoded, while motion blocks heavily rely on [[D&C]] approach and various block transformation techniques. Generally, this codec is quite similar to [[4XM]] codec and [[Mobiclip]] codecs, because it's written by the same people.

There are two variants of HNM6 video codec.
* WARP codec. Prototype codec, simplified version. Used in a very little number of games.
* Normal (yes, that's how it's called internally) codec. Fully-featured version, widely used.

Both version has identical bitstream layout. Frame data begins this the following header:

s32 quality -- JPEG quality index, negative value indicates that the frame is a keyframe
u32 bitbuffer -- offset of bitbuffer
u32 motionbuffer -- offset of motion vector buffer
u32 shortmotionbuffer -- offset of short motion vector buffer
u32 jpegbuffer -- offset of jpeg data buffer
u32 jpegend -- offset of jpeg data buffer end

All offsets a relative to this header.

* quality is a standard [[JPEG]] quality value (0..100%). Negative value is used to specify a keyframe (for Normal codec only.)
* bitbuffer points to frame's VLC-encoded macroblocks. This kind of data is accessed by a bit-reader with 32-bit internal queue, MSB bit comes out first.
* motion buffer points to array of u16 motion vectors, used to copy blocks from various areas of the frame
* short motion buffer is used for accessing blocks near the current macroblock. Each entry of buffer is 12 bits long, accessed in LSB order.
* jpeg buffer points to array of encoded [[JPEG]] macroblocks

== JPEG Blocks decoding ==
JPEG blocks are encoded in YUV 4:4:4 format. The requantization, [[IDCT]] and colorspace conversion steps are identical to standard [[JPEG]]. Standard zigzag (0, 1, 8, 16, 9, ...) and quantization tables (16, 11, 10, 16, 24, ... ; 17, 18, 24, 47, 99, ...) used as well.

The only custom feature used is the coefficients encoding. Instead of Huffman coding they are stored using RLE scheme.

Macroblock's jpeg data is accessed by 4-bit nibbles, lower nibble of each byte first. Also, the following primitives are used:
* half - half of a nibble, upper part first, then lower (i.e. read a nibble, process upper part of it upon first use, lower part upon second)
* s2 - signed two-bit 2's compliment value of a half, no zero point (i.e. 0b00 -> 1, 0b01 -> 2, 0b10 -> -2, 0b11 -> -1)
* s4 - signed four-bit 2's compliment value of a nibble, no zero point
* s44 - signed eight-bit value of two nibbles, with zero point (this is basically (signextend(nibble1) << 4) | nibble2)

For each plane of 8x8 coefficients, first entry is s44, then read nibbles and fill the rest of coefficients as follows until the whole plane is complete. Repeat for each Y, U and V plane.

0 - fill remainder of plane with zeros
1 - 0, 0, 0, 0
2 - 0, 1
3 - 0, -1
4 - 0, 0, 1
5 - 0, 0, -1
6 - 0, 0, 0, 1
7 - 0, 0, 0, -1
8 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+2) coefficients with s2
9 - zeros = half, tail = half
fill (zeros+1) coefficients with 0
fill (tail+1) coefficients with s4
10 - s2, s2
11 - s4
12 - s4, s4
13 - s4, s4, s4
14 - 0
15 - s44

== WARP decoding ==
Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x4
|-
| Keyblock || 11 || n/a
|-
| Motion || 10 || 0
|-
| CrossCut || 0 || 1
|}

* Keyblock is a JPEG-encoded macroblock
* CrossCut means that the current block should be cut on to 4 smaller subblocks and each one processed independently, using the same scheme recursively.
* Motion means that the block is motion-coded and should be copied from some other part of the frame. To do so, read the next entry of the motion buffer and process it as follows:
** transformation mode = next 2 bits from bitbuffer (upper part) combined with bit 15 of motion (lower bit.)
** xmotion = 128 - (bits 7..14 of motion)
** ymotion = (if block is not 8x8, then 4) - (bits 0..6 of motion)
* 2x2 blocks are always short motion coded, using no extra VLC
** transformation mode = bits 1..3 of short motion
** motion index = bit 0 || bits 4..7 || bits 8..11 (total 9 bits)
** decode the index as follows:
if index < 12 * 8
xmotion = -2 - index % 12
ymotion = 6 - index / 12
else
index -= 12 * 8
xmotion = 19 - index % 32
ymotion = -2 - index / 32
if ymotion <= -8
ymotion = ymotion - 1

Block's source coordinates are the sum of current 8x8 macroblock's coordinates (not it's subblock's!) and the xmotion and ymotion respectively. If x-coordinate happens to go out of frame, it should be wrapped around the line. Copy block at the following coordinates to the current, applying the transformation as specified.

== Normal decoding ==
Normal compression introduces interframes, more split modes and different short motion encoding.

Macroblocks are encoded using the following VLC codes:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Block type !! 8x8 !! 4x8 !! 8x4 !! 4x4 !! 2x4 !! 4x2 !! 2x2
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Keyframe
|-
| Keyblock || 110 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 00 || 0 || n/a || 01 || 1 || n/a || n/a
|-
| VerticalCut || 01 || n/a || 0 || 10 || n/a || 1 || n/a
|-
| CrossCut || 10 || n/a || n/a || 11 || n/a || n/a || n/a
|-
| Motion || 111 || 1 || 1 || 00 || 0 || 0 || n/a
|-
| colspan="8" style="text-align: center;" bgcolor="#f0f0f0" | Interframe
|-
| Keyblock || 011 || n/a || n/a || n/a || n/a || n/a || n/a
|-
| HorizontalCut || 100 || 10 || n/a || 101 || 111 || n/a || n/a
|-
| VerticalCut || 101 || n/a || 10 || 110 || n/a || 111 || n/a
|-
| CrossCut || 1110 || n/a || n/a || 111 || n/a || n/a || n/a
|-
| Skip || 110 || 11 || 11 || 100 || 110 || 110 || 11
|-
| ShortMotion || 00 || 00 || 00 || 00 || 0 || 0 || 0
|-
| Motion || 010 || 01 || 01 || 01 || 10 || 10 || 10
|}

* HorizontalCut splits the block horizontally, producing two subblocks of smaller height. Each one then processed recursively.
* VerticalCut is identical to HorizontalCut, but splits the block vertically.
* Skip simply copies the block from the previous frame
* ShortMotion copies block from previous frame, using the spiral-encoded motion. Unlike regular motion, short motion is relative to subblock's coordinates, not the whole macroblock. Read ShortMotion index, then obtain block's relative coordinates as per illustration:
[[Image:HNM6Spiral.png]]
* Motion blocks are similar to WARP motion block, with minor enhancements
** For keyframe motion is the same as for WRAP, with the exception for blocks smaller than 4x4. For such blocks:
*** transformation mode = bits 12.14 of motion
*** xmotion = 63 - (bits 0..6 of motion)
*** ymotion = 6 - (bits 7..11 of motion)
** Keyframe's 2x2 blocks are always motion-coded as above.

** For interframe motion is different. For blocks 4x4 and larger:
*** transformation mode = next 3 bits from bitbuffer
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** xmotion = 128 - (bits 7..14 of motion)
*** ymotion = (if from previous frame then 64, otherwise if block is not 8x8, then 4) - (bits 0..6 of motion)
** For blocks smaller than 4x4:
*** if bit 15 of motion is zero then source is the previous frame, current frame otherwise
*** if from current frame - same as for keyframe, see above. for previous frame:
*** transformation mode = next 3 bits from bitbuffer
*** xmotion = 31 - (bits 0..5 of motion)
*** ymotion = 31 - (bits 6..11 of motion)
** Don't forget to wrap x motion around the line if it goes out of frame

== Bitexact decoding ==
While you can use stock [[JPEG]] routines to decode Key-blocks, if you want to produce bitexact output you need to use very specific code to do so.

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

File:HNM6Spiral.png

2012-09-08T17:57:34Z

VAG: HNM6 Short Motion vector illustration

HNM6 Short Motion vector illustration

HNM6

2012-09-08T15:48:43Z

VAG: /* WARP decoding */ decoding

HNM6

2012-09-08T14:58:13Z

VAG: /* Video Format */

HNM6

2012-09-08T14:52:04Z

VAG: /* JPEG Blocks decoding */ initial coefficient

HNM6

2012-09-08T14:46:42Z

VAG: /* JPEG Blocks decoding */

HNM6

2012-09-08T14:45:04Z

VAG: /* JPEG Blocks decoding */ better this way

HNM6

2012-09-08T14:41:06Z

VAG: /* JPEG Blocks decoding */ decoding

HNM6

2012-09-08T13:51:53Z

VAG: /* Video Format */ basic video outline

HNM6

2012-09-08T13:06:21Z

VAG: /* IX Chunk */ warp chunk

HNM6

2012-09-08T13:01:19Z

VAG: /* File Format */ revisit file header

HNM6

2012-09-08T12:24:57Z

VAG: categorize

UBB

2012-04-15T17:21:10Z

VAG:

* Extension: ubb , sometimes hnm
* Company: [[CRYO Interactive Entertainment]]
* Samples: '''ADD ME'''

UBB2 is another generation of FMV format developed by Cryo. It is an improved version of [[HNM4]] format. While general container format remains the same, video encoding is slightly improved.

== File Format ==
Remains the same as was used in [[HNM4]]. Following parts has changed:
* File signature is "UBB2" now.
* Video chunk has "IV" TwoCC.

== Video Compression ==
The video frame is encoded in a series of horizontal colums of variable width and height. However, columns height (and some of their coding properties) may only change at the beginning of new line.

 Encoded stream consist of column copy mode bytes:
bits:
7 - swap rows/columns
6 - vertical reverse
5 - horizontal reverse
4..0 - column width index (table lookup, see below)

Each of such code generally means ''"copy a width-by-height column from some other place to the current, using flags provided."''
 Flags behavior can be illustrated as follows (assuming 2x3 block and the source points to 'M' pixel):
Source Normal Horizontal Vertical Swap

ABCDE MN ML MN MR
FGHIJ RS RQ HI NS
KLMNO -> WX WV CD OT
PQRST
UVWXY

Multiple flags can be used together.

Encoded column width depends on column's height:
2: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,18,20,22,24,26,28,30,32,34,36,38,40,44,48,52,56
3: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,22,24,26,28,30,32,34,36,38,40,42,44
4: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,28,30,32,34,36,38

Source column offset may be an "absolute" offset - byte distance from the current column, or relative X:Y offset.
* For absolute offset read next 2-byte value (unsigned, little-endian) and add base oofset.
* For relative offset read next byte, extract X and Y deltas from it and add base deltas.

Certain combination used for special purposes. Those are:
* 0x20 - skip: read next byte (width) and copy width+1 column from previous frame
* 0x60 - solo: draw 1-pixel wide column using next bytes of input
* 0xA0 - draw: read next byte (width) and draw width+2 column using next bytes of input (top-down, left-right)
* 0xE0 - mode: examine next byte.
** if byte is zero, then read two bytes (width, color) and fill width+1 column with color.
** if byte is non-zero, change the decoding properties as follows:
+------+--------+--------+--------+----------+---------+--------+
| byte | height | source | offset | Y.X bits | X-base | Y-base |
+------+--------+--------+--------+----------+---------+--------+
| 1 | end of decoding |
+------+--------+--------+--------+----------+---------+--------+
| 2 | 2 | prev | -32768 | N/A | N/A | N/A |
| 3 | 3 | prev | -32768 | N/A | N/A | N/A |
| 4 | 4 | prev | -32768 | N/A | N/A | N/A |
| 5 | 2 | prev | N/A | 4.4 | -8 | -8 |
| 6 | 3 | prev | N/A | 4.4 | -8 | -8 |
| 7 | 4 | prev | N/A | 4.4 | -8 | -8 |
+------+--------+--------+--------+----------+---------+--------+
| 8 | 2 | prev | N/A | 4.4 | -2 | -8 |
| 9 | 2 | prev | N/A | 4.4 | -14 | -8 |
| 10 | 2 | prev | N/A | 4.4 | -8 | -2 |
| 11 | 2 | prev | N/A | 4.4 | -8 | -14 |
| 12 | 2 | prev | N/A | 4.4 | -2 | -2 |
| 13 | 2 | prev | N/A | 4.4 | -14 | -2 |
| 14 | 2 | prev | N/A | 4.4 | -2 | -14 |
| 15 | 2 | prev | N/A | 4.4 | -14 | -14 |
+------+--------+--------+--------+----------+---------+--------+
| 16 | 3 | prev | N/A | 4.4 | -2 | -8 |
| 17 | 3 | prev | N/A | 4.4 | -14 | -8 |
| 18 | 3 | prev | N/A | 4.4 | -8 | -2 |
| 19 | 3 | prev | N/A | 4.4 | -8 | -14 |
| 20 | 3 | prev | N/A | 4.4 | -2 | -2 |
| 21 | 3 | prev | N/A | 4.4 | -14 | -2 |
| 22 | 3 | prev | N/A | 4.4 | -2 | -14 |
| 23 | 3 | prev | N/A | 4.4 | -14 | -14 |
+------+--------+--------+--------+----------+---------+--------+
| 24 | 4 | prev | N/A | 4.4 | -2 | -8 |
| 25 | 4 | prev | N/A | 4.4 | -14 | -8 |
| 26 | 4 | prev | N/A | 4.4 | -8 | -2 |
| 27 | 4 | prev | N/A | 4.4 | -8 | -14 |
| 28 | 4 | prev | N/A | 4.4 | -2 | -2 |
| 29 | 4 | prev | N/A | 4.4 | -14 | -2 |
| 30 | 4 | prev | N/A | 4.4 | -2 | -14 |
| 31 | 4 | prev | N/A | 4.4 | -14 | -14 |
+------+--------+--------+--------+----------+---------+--------+
| 32 | 2 | curr | -65536 | N/A | N/A | N/A |
| 33 | 2 | curr | N/A | 3.5 | -16 | -8 |
| 34 | 2 | curr | N/A | 4.4 | -8 | -16 |
| 35 | 2 | curr | N/A | 4.4 | -24 | -16 |
| 36 | 2 | curr | N/A | 4.4 | +8 | -16 |
| 37 | 2 | curr | N/A | 5.3 | -4 | -32 |
| 38 | 2 | curr | N/A | 5.3 | -12 | -32 |
| 39 | 2 | curr | N/A | 5.3 | +4 | -32 |
+------+--------+--------+--------+----------+---------+--------+
| 40 | 3 | curr | -65536 | N/A | N/A | N/A |
| 41 | 3 | curr | N/A | 3.5 | -16 | -8 |
| 42 | 3 | curr | N/A | 4.4 | -8 | -16 |
| 43 | 3 | curr | N/A | 4.4 | -24 | -16 |
| 44 | 3 | curr | N/A | 4.4 | +8 | -16 |
| 45 | 3 | curr | N/A | 5.3 | -4 | -32 |
| 46 | 3 | curr | N/A | 5.3 | -12 | -32 |
| 47 | 3 | curr | N/A | 5.3 | +4 | -32 |
+------+--------+--------+--------+----------+---------+--------+
* prev means source is the previous frame, curr - current
* Y.X means "Y" value in upper Y bits of byte, "X" in lower X bits.

== Trivia ==
Apparently this format has another less-used name - HNM5.

[[Category:Game Formats]]
== Games Using UBB ==

* [http://www.mobygames.com/game/megarace-2 Megarace II]
* lots of others

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

Psygnosis SMV

2012-03-31T09:20:52Z

VAG:

* Extension: smv
* Company: [[Psygnosis]]
* Samples: http://cd.textfiles.com/cdaction/cdaction04/FILM/

SMV is a short-lived FMV format used in the PC game [http://www.mobygames.com/game/dos/wipeout Wipeout] by Psygnosis. It employs LZ-like compression to encode 8-bit palettized video and audio.

== File Format ==
An SMV file consist of a number of chunks with unique [[TwoCC]]. All numbers are little-endian.

u16 chunkid
u16 chunklen
u8 payload[chunklen]

=== ST chunk ===
File header. Encodes basic movie properties.

u16 width -- movie width
u16 height -- and height
u16 mbwidth -- macroblock width
u16 mbheight -- and height
u16 frames -- number of video frames
u16 colors -- number of used colors
u16 nibbles -- offset of frame's nibble data
-- if chunk size is >= 15
u8 codec -- video codec format

* Codec field may be absent, in such case assume codec 0.
* mbwidth is always 16, mbheight may be either 16 or 8.
* Movie playback rate is 12 FPS.

=== GP chunk ===
New palette. Contains a number of 6-bit [[RGB]] entries, as specified in ST chunk.

=== MU chunk ===
Sound chunk. Contains audio fragment in 15862Hz, 8-bit, unsigned, mono format. If the payload size is equal to the amount of audio data for a frame (i.e. the size is freq / fps, which is equal to 1321) then the audio data is stored in raw [[PCM]] format. Otherwise, it's additionally LZ-word-packed.

=== FR chunk ===
Frame chunk. Contains encoded video frame.

=== FE chunk ===
End of the movie. No payload.

== Video Compression ==

=== Video Codec 0 ===

LZUnpack(payload, temp, words)
DrawBlocks(temp)

=== Video Codec 1 ===

LZUnpack(payload, temp, bytes)
DrawBlocks(temp)

=== Video Codec 2 ===

LZUnpack(payload, temp, bytes)
UnpackPartitions(temp, temp2)
DrawBlocks(temp2)

UnpackPartitions decodes Macroblock's nibbles.

Source frame is broken on to several equal partitions, 2 across by 4 down. Encoded partitions format:

u8 pixels[16 * num_mblocks] -- passed as is to DrawBlocks()
for each partition
u8 codebook[256][2] -- nibbles codebook for each partition
for each partition
for each macroblock
u8 index[mb_width*mb_height/4] -- index of codebook entry

Each entry of codebook encodes 4 nibbles. First byte encodes two nibbles of upper macroblock's line, second - next line, and so on.

=== Video Codec 3 ===
This codec is never used, but the code is still in place.

if GetByte()
LZUnpack(payload, temp, bytes)
UnpackSpecial(temp, temp2)
DrawBlocks(temp2)
else
same as codec 1

UnpackSpecial performs advanced decompression. '''TODO''' ''this may be some common algorithm''

=== Macroblocks drawing ===
Macroblocks are stored in the following format:

u8 pixels[16 * num_mblocks]
u4 nibbles[num_mblocks]

Size of pixels[] is equal to ST chunk's ''nibbles''.
For each macroblock draw it by indexing its pixels by nibbles. First nibble stored in top 4 bits of byte.

== Common Algorithms ==
=== LZ decompression ===
This is a more-or-less common LZ77-like algorithm. It can operate in two modes: byte mode and words mode. Mode affects backchain offset encoding.
* "next bit" means next bit from the internal 8-bit bitreader queue. Queue refilled with the input stream bytes, bits are consumed starting from the highest.
* "next byte" means raw octet from the input stream

repeat

if next bit == 0
output next byte
else
if next bit == 0
offset = next byte
else
if byte mode
offset = next 3 bits || next byte + 1
if words mode
offset = next 2 bits || next byte + 1 *2

if next bit == 0 length = 2
else if next bit == 0 length = 3 + next bit
else if next bit == 0 length = 5 + next bit
else if next bit == 0 length = 7
else if next byte != 0 length = 7 + this byte
else finish unpacking

copy length bytes from output - offset to output
note that, bytes may overlap to repeat itself

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

Noctropolis VID

2012-02-20T21:47:42Z

VAG: add another game

: ''See also [[VID]]''

* Extensions: vid
* Company: Flashpoint Productions, Inc.
* Year: 1994
* Samples: '''TODO'''

VID is an FMV format first appeared in the computer game [http://www.mobygames.com/game/dos/noctropolis Noctropolis]. Uses basic [[RLE]] compression.

A file consists of a header and a number of frame chunks. All numbers are little endian.

== File header ==

+ 0 s8 Signature[4] -- "VID"
+ 4 s8 Version -- usually 2
+ 5 s16 Frames -- number of video frames (not chunks!)
+ 7 s16 Width -- frame width and height
+ 9 s16 Height
+ B s16 Unknown -- related to playback speed?
+ D s16 Rate -- playback rate (?)

== Frame chunks ==
Each chunk begins with a byte chunk type then followed by payload of variable length.

=== 0x00 - Intraframe ===

u16 sync value, followed by Width * Height frame raster

=== 0x01 - Interframe ===

u16 sync value, followed by RLE-compressed raster. Version 2 movies has extra zero byte after it (if not ended permaturely by a stop-code.) Decompression algorithm:

while frame is not complete
len = next byte of input
if len is 0 finish
if high bit of len is set
leave (len & 0x7F) pixels unchanged
else
draw next (len) pixels

=== 0x02 - Palette ===

256 6-bit [[RGB]] [[DAC]] triplets.

=== 0x03 - RLE Intraframe ===

Same as 0x01, but no stop-codes and instead of skipping pixels, fill them with the next byte of input.

=== 0x04 - Partial Interframe ===

Same as 0x01, but has an extra u16 value after the sync field denotes how many horizontal lines to skip before start of decoding.

=== 0x7C - Audio Start ===

u16 sync, followed by u8 sampling frequency in SoundBlaster [[VOC]] format, then followed by u16 size of data and corresponding amount of actual [[PCM]] data in Mono, 8-bit Unsigned format.

=== 0x7D - Audio Continue ===

Same as 0x7C, but no sync/frequency fields.

== Games Using VID ==

* [http://www.mobygames.com/game/dos/noctropolis Noctropolis]
* [http://www.mobygames.com/game/synnergist Synnergist]

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

Origin Flic Codec

2012-02-20T21:37:07Z

VAG: categorize

* FourCC: JYV1, JYA1, RRV1, RRV2
* Company: Origin Systems
* Samples: ask Mike

''Please rename this codec name to something more original''

Origin Flic Codec is a relatively simple palettized video codec used in PC version of Crusader: No Remorse game. Data is packaged inside standard [[AVI]] container and employs relatively simple [[RLE]] compression. Audio stored in uncompressed [[PCM]] form. It is rumored that codec's FourCCs are actually based on game developer's names (not confirmed.)

== Video Codec ==
A video movie uses fixed palette, stored in corresponding AVI Stream Format chunk.

Video frame is encoded in a series of slices, where each slice encodes a number of horizontal lines of picture. Number of slices depends on FourCC and is:
* JYV1, RRV1 - 5 slices
* RRV2 - 15 slices
Therefore, each slice contains VideoHeight/slices raster lines.

Frame chunk consist of the following parts:

u32 slicetable[num_slices]
-- for each slice --
u32 codes_size;
u8 codes[codes_size]
u8 raster[]
--------------------
where each entry of slicetable points to corresponding codes/raster block (offsets are relative to beginning of the chunk.)

Video decompression is performed as follows (for each slice):

flipflop = flip
while slice is not complete
idx = GetBits(4);
blocksize = BaseLength[idx];
if idx != 0 and idx != 8
blocksize += GetBits(FineLengthBits[idx]);
if flipflop == flip
leave blocksize pixels unchanged
else
draw blocksize pixels from raster[]
flip flop

BaseLength[] = {0, 1<<7, 1<<3, 0, 1<<1, 0, 1<<5, 0,
1, 1<<8, 1<<4, 0, 1<<2, 0, 1<<6, 0};
FineLengthBits[] = {0, 7, 3, 0, 1, 16, 5, 0,
1, 8, 4, 0, 2, 24, 6, 0};

GetBits() reads variable number of bits from codes[], highest bits of lowest byte first.
For RRV* FourCCs 'leave' and 'draw' command skips/doubles each pixel when decoding a keyframe (i.e. a keyframe should be upscaled horizontally.)

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

Noctropolis VID

2012-02-20T21:36:02Z

VAG: typos

: ''See also [[VID]]''

* Extensions: vid
* Company: Flashpoint Productions, Inc.
* Year: 1994
* Samples: '''TODO'''

VID is an FMV format used in the computer game [http://www.mobygames.com/game/dos/noctropolis Noctropolis]. Uses basic [[RLE]] compression.

A file consists of a header and a number of frame chunks. All numbers are little endian.

== File header ==

+ 0 s8 Signature[4] -- "VID"
+ 4 s8 Version -- usually 2
+ 5 s16 Frames -- number of video frames (not chunks!)
+ 7 s16 Width -- frame width and height
+ 9 s16 Height
+ B s16 Unknown -- related to playback speed?
+ D s16 Rate -- playback rate (?)

== Frame chunks ==
Each chunk begins with a byte chunk type then followed by payload of variable length.

=== 0x00 - Intraframe ===

u16 sync value, followed by Width * Height frame raster

=== 0x01 - Interframe ===

u16 sync value, followed by RLE-compressed raster. Version 2 movies has extra zero byte after it (if not ended permaturely by a stop-code.) Decompression algorithm:

while frame is not complete
len = next byte of input
if len is 0 finish
if high bit of len is set
leave (len & 0x7F) pixels unchanged
else
draw next (len) pixels

=== 0x02 - Palette ===

256 6-bit [[RGB]] [[DAC]] triplets.

=== 0x03 - RLE Intraframe ===

Same as 0x01, but no stop-codes and instead of skipping pixels, fill them with the next byte of input.

=== 0x04 - Partial Interframe ===

Same as 0x01, but has an extra u16 value after the sync field denotes how many horizontal lines to skip before start of decoding.

=== 0x7C - Audio Start ===

u16 sync, followed by u8 sampling frequency in SoundBlaster [[VOC]] format, then followed by u16 size of data and corresponding amount of actual [[PCM]] data in Mono, 8-bit Unsigned format.

=== 0x7D - Audio Continue ===

Same as 0x7C, but no sync/frequency fields.

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

Origin Flic Codec

2012-02-17T00:44:18Z

VAG: doh!

Origin Flic Codec

2012-02-17T00:42:50Z

VAG: ok, you asked for it

* FourCC: JYV1, JYA1, RRV1, RRV2
* Company: Origin Systems
* Samples: ask Mike

''Please rename this codec name to something more original''

Origin Flic Codec is a relatively simple palettized video codec used in PC version of Crusader: No Remorse game. Data is packaged inside standard [[AVI]] container and employs relatively simple [[RLE]] compression. Audio stored in uncompressed [[PCM]] form. It is rumored that codec's FourCCs are actually based on game developer's names (not confirmed.)

== Video Codec ==
A video movie uses fixed palette, stored in corresponding AVI Stream Format chunk.

Video frame is encoded in a series of slices, where each slice encodes a number of horizontal lines of picture. Number of slices depends on FourCC and is:
* JYV1, RRV1 - 5 slices
* RRV2 - 15 slices
Therefore, each slice contains VideoWidth/slices raster lines.

Frame chunk consist of the following parts:

u32 slicetable[num_slices]
-- for each slice --
u32 codes_size;
u8 codes[codes_size]
u8 raster[]
--------------------
where each entry of slicetable points to corresponding codes/raster block (offsets are relative to beginning of the chunk.)

Video decompression is performed as follows (for each slice):

flipflop = flip
while slice is not complete
idx = GetBits(4);
blocksize = BaseLength[idx];
if idx != 0 and idx != 8
blocksize += GetBits(FineLengthBits[idx]);
if flipflop == flip
leave blocksize pixels unchanged
else
draw blocksize pixels from raster[]
flip flop

BaseLength[] = {0, 1<<7, 1<<3, 0, 1<<1, 0, 1<<5, 0,
1, 1<<8, 1<<4, 0, 1<<2, 0, 1<<6, 0};
FineLengthBits[] = {0, 7, 3, 0, 1, 16, 5, 0,
1, 8, 4, 0, 2, 24, 6, 0};

GetBits() reads variable number of bits from codes[], highest bits of lowest byte first.
For RRV* FourCCs 'leave' and 'draw' command skips/doubles each pixel when decoding a keyframe (i.e. a keyframe should be upscaled horizontally.)

HNM6

2012-02-05T17:30:54Z

VAG:

Noctropolis VID

2011-08-06T13:08:36Z

VAG:

: ''See also [[VID]]''

* Extensions: vid
* Company: Flashpoint Productions, Inc.
* Year: 1994
* Samples: '''TODO'''

VID is an FMV format used in the computer game [http://www.mobygames.com/game/dos/noctropolis Noctropolis]. Uses basic [[RLE]] compression.

A file consists of a header and a number of frame chunks. All numbers are little endian.

== File header ==

+ 0 s8 Signature[4] -- "VID"
+ 4 s8 Version -- usually 2
+ 5 s16 Frames -- number of video frames (not chunks!)
+ 7 s16 Width -- frame width and height
+ 9 s16 Height
+ B s16 Unknown -- releated to playback speed?
+ D s16 Rate -- playback rate (?)

== Frame chunks ==
Each chunk begins with a byte chunk type then followed by payload of variable length.

=== 0x00 - Intraframe ===

u16 sync value, followed by Width * Height frame raster

=== 0x01 - Interframe ===

u16 sync value, followed by RLE-compressed raster. Version 2 movies has extra zero byte after this (if not ended permaturely by a stop-code.) Decompression algorithm:

while frame is not complete
len = next byte of input
if len is 0 finish
if high bit of len is set
leave (len & 0x7F) pixels unchanged
else
draw next (len) pixels

=== 0x02 - Palette ===

256 6-bit [[RGB]] [[DAC]] triplets.

=== 0x03 - RLE Intraframe ===

Same as 0x01, but no stop-codes and instead of skipping pixels, fill them with the next byte of input.

=== 0x04 - Partial Interframe ===

Same as 0x01, but has an extra u16 value after the sync field denotes how many horizontal lines to skip before start of decoding.

=== 0x7C - Audio Start ===

u16 sync, followed by u8 sampling frequency in SoundBlaster [[VOC]] format, then followed by u16 size of data and corresponding amount of actual [[PCM]] data in Mono, 8-bit Unsigned format.

=== 0x7D - Audio Continue ===

Same as 0x7C, but no sync/frequency fields.

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

Electronic Arts Formats

2011-07-30T22:54:16Z

VAG: /* Games Using Electronic Arts Multimedia Formats */

* Extensions: ASF, CMV, DCT, SND, TGI, TGV, TGQ, WVE, UV, UV2, VID, MAD, VP6
* Company: [[Electronic Arts]]

Electronic Arts, the video game publishing empire, and the various constituent development houses under its umbrella, have deployed a number of multimedia formats in its games.

EA multimedia formats are comprised of a series of blocks with the following format:

bytes 0-3 block type [[FourCC]]
bytes 4-7 block size (including this 8-byte preamble)
bytes 8.. block payload

It is important to note that there is no consistent byte order for multi-byte numbers. However, order is optimized for target platform, i.e. little-endian for PC/PS/XBOX and big-endian for Mac/Saturn/GameCube.

== Chunk Types ==

* Audio
** [[Electronic Arts SEAD]]: SEAD, SNDC, SEND
** [[Electronic Arts 1SNx]]: 1SNh, 1SNd, 1SNl, 1SNe
** [[Electronic Arts SCxl]]: SCHl, SCCl, SCDl, SCLl, SCEl, and SHEN, SCEN, SDEN, SEEN
* Video
** [[Electronic Arts CMV]]: MVIh, MVIf, MVIe
** [[Electronic Arts TGV]]: kVGT, fVGT
** [[Electronic Arts DCT]]: mTCD
** [[Electronic Arts TGQ]]: pQTG, TGQs (rumored MUVf?)
** [[Electronic Arts TQI]]: pIQT, (rumored UV2f?)
** [[Electronic Arts MAD]]: MADk, MADm, MADe
** [[Electronic Arts VP6]]: MVhd, MV0K, MV0F
** [[Electronic Arts MPC]]: MPCh

== Games Using Electronic Arts Multimedia Formats ==

{| border="1" cellpadding="2"
! Name !! File Ext !! Video Codec !! Audio Codec || Byte Order
|-
| [http://www.mobygames.com/game/dos/nhl-95 NHL 95]
| cmv || CMV || none || le
|-
| [http://www.mobygames.com/game/dos/nhl-96 NHL 96]
| tgv || ? || ? || ?
|-
| [http://www.mobygames.com/game/dos/cybermage-darklight-awakening CyberMage: Darklight Awakening]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-96 FIFA '96]
| tgv || TGV || 1SNx/EACS/pcm_s16 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-97 FIFA '97]
| tgv || TGV || SCHl/PATl/TMpl/adpcm_ima_? || le
|-
| [http://www.mobygames.com/game/fifa-soccer-98 FIFA '98]
| dct || DCT || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/fifa-soccer-99 FIFA '99]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed Need for Speed]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/privateer-2-the-darkening Privateer 2: The Darkening]
| tgv || TGV || SEAD/adpcm_ima_ea_sead || le
|-
| [http://www.mobygames.com/game/dos/nba-live-96 NBA Live 96]
| tgv || TGV || 1SNh/EACS/adpcm_ima_ea_eacs || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2]
| dct || DCT || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2 (Demo)]
| uv || TGQ || SCHl/PT/adpcm_ea || le
|-
|rowspan="2"|[http://www.mobygames.com/game/beasts-bumpkins Beasts and Bumpkins]
| vid || TQI || SCHl/PT/adpcm_ea || le
|-
| m10 || none || PT/microtalk10:1? || le
|-
| [http://www.mobygames.com/game/dungeon-keeper-2 Dungeon Keeper 2]
| tgq || TQI (no typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/saturn/warcraft-ii-the-dark-saga Warcraft II: The Dark Saga (Sega Saturn)]
| tgq || TGQ || ? || be
|-
| [http://www.mobygames.com/game/superbike-2001 Superbike 2001]
| tgq || TQI (yes) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/saturn/crusader-no-remorse Crusader: No Remorse (Sega Saturn)]
| tgq || TGQ || 1SNh/EACS/mulaw || be
|-
| [http://www.mobygames.com/game/harry-potter-quidditch-world-cup Harry Potter: Quidditch World Cup]
| tgq || TQI (not a typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/wing-commander-prophecy Wing Commander: Prophecy]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/the-sims The Sims]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/nba-live-99 NBA Live 99]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-iii-hot-pursuit Need for Speed 3: Hot Pursuit]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-high-stakes Need for Speed 4: High Stakes]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-porsche-unleashed Need for Speed 5: Porsche]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| [http://www.mobygames.com/game/need-for-speed-hot-pursuit-2 Need for Speed 6: Hot Pursuit 2]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| rowspan="2"| [http://www.mobygames.com/game/nba-live-2003 NBA Live 2003]
| mad || MAD || pcm_s16le_planar || le
|-
| asf || none || SCHl/PT/mp3 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2004]
| mad || ? || ? || ?
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2005]
| mad || MAD || SCHl/PT/adpcm_ea_r1, SCHl/PT/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/simcity-4-rush-hour Sim City 4: Rush Hour]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/sims-2 The Sims 2]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/ps2/need-for-speed-underground Need for Speed: Underground (PlayStation 2)]
| mpc || MPC || SCHl/PT/adpcm_ea_r2 || le
|-
| [http://www.mobygames.com/game/ps2/fifa-soccer-07 FIFA 2007 (PlayStation 2)]
| mpc || MPC || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-underground-2 Need for Speed: Underground 2]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-most-wanted Need for Speed: Most Wanted]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-carbon Need for Speed: Carbon]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth The Lord of the Rings: The Battle for Middle Earth]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/lord-of-the-rings-the-battle-for-middle-earth-ii The Lord of the Rings: The Battle for Middle Earth II]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth-ii-the-rise-of-the The Lord of the Rings: The Battle for Middle Earth II - The Rise of the Witch-King]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/command-conquer-3-tiberium-wars Command & Conquer: Tiberium Wars]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/command-conquer-3-kanes-wrath Command & Conquer: Tiberium Wars: Kane's Wrath]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-prostreet Need for Speed: Pro Street]
| vp6 || VP6 || SHEN/GSTR/ealayer3 || le
|-
| [http://www.mobygames.com/game/command-conquer-red-alert-3 Red Alert 3]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| Red Alert 3: Uprising
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/burnout-paradise-the-ultimate-box Burnout Paradise: The Ultimate Box]
| vp6/sns || VP6 || ealayer3 w/o header || le
|}

In addition to FMV, the EA audio chunk types are frequently used throughout Electronic Arts games for music tracks, audio effects and speech. Older titles use the .ASF file extension for individual music tracks, whereas newer titles store multiple audio sequentially within the one file (hence rational for the ending chunk types) and use a variety of file extensions.

[[Category:Game Formats]]

Electronic Arts SCxl

2011-07-30T22:46:33Z

VAG: /* SCHl or SHEN */ dirty PATl/TMpl info

* Company: [[Electronic Arts]]
* Samples: TBD.

SCxl is an audio stream format used in various games published by companies under the Electronic Arts umbrella.

== Chunk Types ==
See [[Electronic Arts Formats]] for file format description.

=== SCHl or SHEN ===
Header. Contains special Patch record, describes all vital audio parameters.

==== PATl patch ====
Used in very old files.

* PATl block

offset type description
0 byte Tag, "PATl"

'''TODO'''

* TMpl block

offset type description
0 byte Tag, "TMpl"
4 byte Version, 0
5 byte Sample width (bits)
6 byte Channels
7 byte ?
8 byte ?
9 byte ?
A int16 Frequency
C int32 ?
10 int32 ?
14 int32 ?
18 int32 ?

==== PT patch ====

offset type description
0 byte Tag, should be 'PT'
2 int16 Platform identifier
0x00 PC
0x03 Macintosh
0x05 Playstation 2
0x06 Game Cube
0x07 Xbox
0x09 Xenon (Xbox 360)
0x0A PSP
4 ... Patch substream

===== Default Audio Format =====

* 16 bits
* Mono
* 22050 kHz
* XA compression

==== GSTR patch ====

offset type description
0 byte Tag, should be 'GSTR'
4 int32 Unknown, presumably version or platform id
8 ... Patch substream

===== Default Audio Format =====

* 16 bits
* Mono
* 48000 kHz
* XA compression

==== Patch substream ====

Patch substream consist of a series of small chunks, tagged with unique byte identifiers. General substream format is:

Tag[, Length, Data][, ...]

* Tag is an unique identifier of the data. Several tags doesn't contain any data, thus, has no Length and Data fields.
* Length is a single byte, unless it's value is 0xFF. In this case, extra 4-bytes value of the actual length follows, stored in big-endian order.
* Data is a big-endian number of Length bytes total, meaning is specific to particular Tag.

Note, that patch substream may not include various tags/values or even be completely empty at all. In this case default audio parameters is used (listed above).

==== Known patch tags ====

* 0x00 - Unknown
* 0x05 - Unknown
* 0x0B - Unknown
* 0x13 - Unknown
* 0x1B - Unknown
* 0x80 - Compression version.
0x01 EA XA ADPCM R1
0x02 EA XA ADPCM R2
0x03 EA XA ADPCM R3
* 0x82 - Number of channels.
* 0x83 - Compression type.
0x00 PCM Signed Interleaved Data
0x07 EA XA ADPCM
0x09 Unknown
* 0x84 - Sample rate (Hertz).
* 0x85 - Total count of samples in the stream.
* 0x86 - Loop offset
* 0x87 - Loop length
* 0x88 - Data offset (relevant only to Electronic Arts Bank Format)
* 0x8A - End of the format description substream. No data.
* 0x8C - Unknown
* 0x92 - Bytes per sample
* 0x9C - Unknown
* 0x9D - Unknown
* 0xA0 - Compression type.
0x00* PCM Signed 16-bit Interleaved (LE)
0x01* PCM Signed 16-bit Interleaved (BE)
0x02* PCM Signed 8-bit Interleaved
0x04 MicroTalk 10:1
0x05* VAG ADPCM
0x07* PCM Signed 16-bit Planar (BE)
0x08 PCM Signed 16-bit Planar (LE)
0x09 PCM Signed 8-bit Planar
0x0A EA XA ADPCM
0x0B* PCM Unsigned 8-bit Interleaved
0x0C* CD XA
0x0E* MP3 Layer 1
0x0F* MP3 Layer 2
0x10 MP3 Layer 3
0x12* Game Cube ADPCM
0x13* PCM Signed 24-bit Interleaved (LE)
0x14* XBOX ADPCM
0x15* PCM Signed 24-bit Interleaved (BE)
0x16 MicroTalk 5:1
0x17 EALayer3
* Denotes codec supported by [[Electronic Arts Sound eXchange]], but has not yet been observed in a computer game.
* 0xFC, 0xFD - Begin the format description portion of substream. No data.
* 0xFE - Begin of the envelope portion of substeam. No Data.
* 0xFF - End of substream. No data.

=== SCCl or SCEN ===
Holds single 4-byte value, indicates total number of SCDl or SDEN chunks in the stream.

=== SCDl or SDEN ===
Data. Actual audio data in format, specified by SCHl or SHEN chunk.

=== SCLl ===
Loop.

=== SCEl or SEEN ===
End. Indicates end of the stream. Contains no data.

[[Category:Game Formats]]

Electronic Arts Formats

2011-07-30T22:15:08Z

VAG: /* Games Using Electronic Arts Multimedia Formats */

* Extensions: ASF, CMV, DCT, SND, TGI, TGV, TGQ, WVE, UV, UV2, VID, MAD, VP6
* Company: [[Electronic Arts]]

Electronic Arts, the video game publishing empire, and the various constituent development houses under its umbrella, have deployed a number of multimedia formats in its games.

EA multimedia formats are comprised of a series of blocks with the following format:

bytes 0-3 block type [[FourCC]]
bytes 4-7 block size (including this 8-byte preamble)
bytes 8.. block payload

It is important to note that there is no consistent byte order for multi-byte numbers. However, order is optimized for target platform, i.e. little-endian for PC/PS/XBOX and big-endian for Mac/Saturn/GameCube.

== Chunk Types ==

* Audio
** [[Electronic Arts SEAD]]: SEAD, SNDC, SEND
** [[Electronic Arts 1SNx]]: 1SNh, 1SNd, 1SNl, 1SNe
** [[Electronic Arts SCxl]]: SCHl, SCCl, SCDl, SCLl, SCEl, and SHEN, SCEN, SDEN, SEEN
* Video
** [[Electronic Arts CMV]]: MVIh, MVIf, MVIe
** [[Electronic Arts TGV]]: kVGT, fVGT
** [[Electronic Arts DCT]]: mTCD
** [[Electronic Arts TGQ]]: pQTG, TGQs (rumored MUVf?)
** [[Electronic Arts TQI]]: pIQT, (rumored UV2f?)
** [[Electronic Arts MAD]]: MADk, MADm, MADe
** [[Electronic Arts VP6]]: MVhd, MV0K, MV0F
** [[Electronic Arts MPC]]: MPCh

== Games Using Electronic Arts Multimedia Formats ==

{| border="1" cellpadding="2"
! Name !! File Ext !! Video Codec !! Audio Codec || Byte Order
|-
| [http://www.mobygames.com/game/dos/nhl-95 NHL 95]
| cmv || CMV || none || le
|-
| [http://www.mobygames.com/game/dos/nhl-96 NHL 96]
| tgv || ? || ? || ?
|-
| [http://www.mobygames.com/game/dos/cybermage-darklight-awakening CyberMage: Darklight Awakening]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-96 FIFA '96]
| tgv || TGV || 1SNx/EACS/pcm_s16 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-97 FIFA '97]
| tgv || TGV || SCHl/PATl/TMpl/adpcm_ima_? || le
|-
| [http://www.mobygames.com/game/fifa-soccer-98 FIFA '98]
| dct || DCT || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/fifa-soccer-99 FIFA '99]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed Need for Speed]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/privateer-2-the-darkening Privateer 2: The Darkening]
| tgv || TGV || SEAD/adpcm_ima_ea_sead || le
|-
| [http://www.mobygames.com/game/dos/nba-live-96 NBA Live 96]
| tgv || TGV || 1SNh/EACS/adpcm_ima_ea_eacs || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2]
| dct || DCT || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2 (Demo)]
| uv || TGQ || SCHl/PT/adpcm_ea || le
|-
|rowspan="2"|[http://www.mobygames.com/game/beasts-bumpkins Beasts and Bumpkins]
| vid || TQI || SCHl/PT/adpcm_ea || le
|-
| m10 || none || PT/microtalk10:1? || le
|-
| [http://www.mobygames.com/game/dungeon-keeper-2 Dungeon Keeper 2]
| tgq || TQI (no typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/saturn/warcraft-ii-the-dark-saga Warcraft II: The Dark Saga (Sega Saturn)]
| tgq || TGQ || ? || be
|-
| [http://www.mobygames.com/game/superbike-2001 Superbike 2001]
| tgq || ? || ? || ?
|-
| [http://www.mobygames.com/game/saturn/crusader-no-remorse Crusader: No Remorse (Sega Saturn)]
| tgq || TGQ || 1SNh/EACS/mulaw || be
|-
| [http://www.mobygames.com/game/harry-potter-quidditch-world-cup Harry Potter: Quidditch World Cup]
| tgq || TQI (not a typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/wing-commander-prophecy Wing Commander: Prophecy]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/the-sims The Sims]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/nba-live-99 NBA Live 99]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-iii-hot-pursuit Need for Speed 3: Hot Pursuit]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-high-stakes Need for Speed 4: High Stakes]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-porsche-unleashed Need for Speed 5: Porsche]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| [http://www.mobygames.com/game/need-for-speed-hot-pursuit-2 Need for Speed 6: Hot Pursuit 2]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| rowspan="2"| [http://www.mobygames.com/game/nba-live-2003 NBA Live 2003]
| mad || MAD || pcm_s16le_planar || le
|-
| asf || none || SCHl/PT/mp3 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2004]
| mad || ? || ? || ?
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2005]
| mad || MAD || SCHl/PT/adpcm_ea_r1, SCHl/PT/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/simcity-4-rush-hour Sim City 4: Rush Hour]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/sims-2 The Sims 2]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/ps2/need-for-speed-underground Need for Speed: Underground (PlayStation 2)]
| mpc || MPC || SCHl/PT/adpcm_ea_r2 || le
|-
| [http://www.mobygames.com/game/ps2/fifa-soccer-07 FIFA 2007 (PlayStation 2)]
| mpc || MPC || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-underground-2 Need for Speed: Underground 2]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-most-wanted Need for Speed: Most Wanted]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-carbon Need for Speed: Carbon]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth The Lord of the Rings: The Battle for Middle Earth]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/lord-of-the-rings-the-battle-for-middle-earth-ii The Lord of the Rings: The Battle for Middle Earth II]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth-ii-the-rise-of-the The Lord of the Rings: The Battle for Middle Earth II - The Rise of the Witch-King]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/command-conquer-3-tiberium-wars Command & Conquer: Tiberium Wars]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/command-conquer-3-kanes-wrath Command & Conquer: Tiberium Wars: Kane's Wrath]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-prostreet Need for Speed: Pro Street]
| vp6 || VP6 || SHEN/GSTR/ealayer3 || le
|-
| [http://www.mobygames.com/game/command-conquer-red-alert-3 Red Alert 3]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| Red Alert 3: Uprising
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/burnout-paradise-the-ultimate-box Burnout Paradise: The Ultimate Box]
| vp6/sns || VP6 || ealayer3 w/o header || le
|}

In addition to FMV, the EA audio chunk types are frequently used throughout Electronic Arts games for music tracks, audio effects and speech. Older titles use the .ASF file extension for individual music tracks, whereas newer titles store multiple audio sequentially within the one file (hence rational for the ending chunk types) and use a variety of file extensions.

[[Category:Game Formats]]

Duck TrueMotion 1

2011-07-30T21:53:51Z

VAG: /* Games Using Duck TrueMotion 1 */

* FOURCCs: DUCK,PVEZ
* Company: [[On2|On2 (formerly Duck)]]
* Patents: US #6,181,822, "Data compression apparatus and method"
* Samples: http://samples.mplayerhq.hu/V-codecs/DUCK/

Duck TrueMotion 1 (TM1) is the first video codec developed by The Duck Corporation. It uses [[Differential Coding|differential pulse code modulation]] and interframe differencing. The primary application for which Duck TrueMotion 1 was developed is gaming software, typically on PC or Sega Saturn titles.

== Underlying Concepts ==

TM1 operates on bidirectional delta quantization. The mathematical premise of delta coding is simple addition. For example, take the following sequence of numbers:

82 84 81 80 86 88 85

All of the numbers are reasonably large (on a scale of 0..255 in this example). However, they are quite similar to each other. Using delta coding, only the differences between successive numbers are stored:

82 +2 -3 -1 +6 +2 -3

The first number is still large but since the remaining numbers are clustered close to each other, the deltas are relatively small. Thus, the deltas require less information to encode.

TM1 takes this concept and extends it to 2 dimensions. A particular pixel is assumed to have a pixel directly above it and a pixel directly to the left (if neither of these pixels exist in the frame, e.g., for the top-left corner pixel, 0 is used in place of the non-existant pixels). The current pixel is decoded as the sum of the up and left pixels, plus a delta from the encoded video bitstream.

encoded video bitstream: ...D5 D6 D7 D8...

decoded video frame:
A B C D
E F G H

In this example, the encoded video bitstream is sitting at delta D5 when it is time to decode pixel E. A is the pixel above E. There is no pixel to the left of E, so 0 is used as the left value. Thus:

E = A + 0 + D5

In the case of pixel F, both the up and left pixel values (called the vertical and horizontal predictors, respectively) are available:

F = B + E + D6

That is the general idea behind decoding TM1 data. The actual decoding algorithm is more involved. The TM1 bytestream actually contains a series of indices that point into tables with the delta values to be
applied to the vertical and horizontal predictor pixels. These tables only specify small deltas to be added to pixel predictors. When a larger delta is needed because the delta between 2 numbers is too large, then a special bytestream code indicates that the next delta is to be multiplied by 5 before it is applied.

TM1 operates on 4x4 macroblocks of pixels. Each block in a frame can be broken into 4 2x2 blocks, 2 halves (either 4x2 or 2x4), or encoded as a 4x4 block. The block type is encoded in the frame header.

While the TM1 algorithm operates on RGB colorspace data at the input and output level, it borrows some ideas from YUV colorspaces. For more information of RGB and YUV colorspaces, see the References section.

TM1 uses a modified colorspace that embodies luminance (Y) and chrominance (C) information encoded as RGB deltas. Since Y information is more important to the human eye than C information, the Y data must be updated more frequently than the C data (i.e., more Y predictors than C predictors are applied to the image). For a every pixel within a given block in a macroblock, a Y predictor must be applied. However, only one C predictor is applied for each block in the macroblock.

== TrueMotion v1 Frame Format and Header ==

All multi-byte numbers are stored in little endian format.

An encoded intraframe (keyframe) of TM1 data is laid out as:

header | predictor indices

An encoded interframe is laid out as:

header | block change bits | predictor indices

The difference between the 2 types of frames is that an interframe has a section of bits that specify which blocks in the frame are unchanged from the previous frame.

A TM1 header is quasi-encrypted with a logical XOR operation. This is probably done to provide some obfuscation of the header and thwart casual inspection of the data format.

An encoded TM1 frame begins with the one byte that indicates the length of the decrypted header, only with a dummy high bit and rotated left by 5. To obtain the actual length from byte B:

L = ((B >> 5) | (B << 3)) & 0x7F

Then, decrypt the header by starting with byte 1 in the encoded frame (indexing from 0) and XORing each byte with its successive byte. Assuming the header is of length L bytes as computed above, and that the encoded header starts at buffer[1] (buffer[0] had the rotated length), the decode process is:

for (i = 1; i < L; i++)
decoded_header[i - 1] = buffer[i] ^ buffer[i + 1];

The decoded header data structure is laid out as follows:

byte 0 compression method
byte 1 delta set
byte 2 vector set
bytes 3-4 frame height
bytes 5-6 frame width
bytes 7-8 checksum
byte 9 version
byte 10 header type
byte 11 flags
byte 12 control
bytes 13-14 x offset
bytes 15-16 y offset
bytes 17-18 width
bytes 19-20 height

The compression method field indicates the type of compression used to encode this frame. There are 2 general types: 16-bit and 24-bit. Further, each has 4 block sizes to select from. The valid compression types are

0, 9, 11, 13, 15: NOP frames; frame is unchanged from previous frame
1: 16-bit 4x4 (V)
2: 16-bit 4x4 (H)
3: 16-bit 4x2 (V)
4: 16-bit 4x2 (H)
5: 16-bit 2x4 (V)
6: 16-bit 2x4 (H)
7: 16-bit 2x2 (V)
8: 16-bit 2x2 (H)
10: 24-bit 4x4 (H)
12: 24-bit 4x2 (H)
14: 24-bit 2x4 (H)
16: 24-bit 2x2 (H)
>16: invalid compression type

The (H) and (V) designations come from the original Duck source code. It is unclear what they mean, except for the common horizontal and vertical designations common in video terminology.

The delta set and vector set fields are used to generate the set of predictor tables that will be used to decode this frame.

The height and width fields should be the same as those specified in the AVI file that contains the data.

The checksum field appears to contain the frame's sequence number modulo 512. The first frame is 0x0000 and the next frame is 0x0001. Frame #511 has a checksum of 0x01FF while frame #512 wraps around to 0x0000.

If the version field is less than 2, then the frame is intracoded (this may indicate that early versions of the coding method was purely intracoded). If the version field is greater than or equal to 2, then if the header type field is 2 or 3, the flags field has bit 4 set (flags & 0x10) to indicate an intraframe; else if the header type field is greater than 3, then the header is invalid; else the frame is intracoded.

The purpose of the control field is unclear.

The x & y offset, width, and height fields apparently pertain to a sprite mode that is not covered in this document.

== 16-bit Data ==

Decoding a 16-bit frame requires 2 tables. The tables can change from one frame to the next and must be rebuilt if the header specified a new table. One table contains the C predictors while the other contains the Y predictors.

Each table consists of 1024 32-bit entries. Each group of 4 entries corresponds to a byte index from 0..255. Each entry contains a double pixel predictor shifted left by one. If the very last bit (bit 0) in the 32-bit entry is 0, then there is another predictor for that index. If the last bit is 1, then this predictor is the last one for this list.

For example...

A B C D ...
E F G H ...
I J K L ...
M N O P ...

'''(UNFINISHED)'''

== 24-bit Data ==

The process of decoding a 24-bit frame is similar to that of decoding a 16-bit frame. However, the frame is decoded into 2 separate planes, a Y plane and a C plane, and recombined into a final RGB map at render time.

'''(UNFINISHED)'''

== Duck TrueMotion v1 Tables ==

[http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/truemotion1data.h?view=markup&rev=4679 http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/truemotion1data.h?view=markup&rev=4679]

== Games Using Duck TrueMotion 1 ==
These software titles are known to use the Duck TrueMotion 1 video codec to encode full motion video:

* [http://www.mobygames.com/game/saturn/blazing-dragons Blazing Dragons (Sega Saturn)]
* Congo (Sega Saturn)
* [http://www.mobygames.com/game/saturn/horde The Horde (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/nhl-all-star-hockey NHL All-Star Hockey (Sega Saturn)]
* [http://www.mobygames.com/game/phantasmagoria-a-puzzle-of-flesh Phantasmagoria: A Puzzle of Flesh (DOS & Windows)]
* [http://www.mobygames.com/game/santa-fe-mysteries-the-elk-moon-murder Santa Fe Mysteries: The Elk Moon Murder (DOS & Windows)]
* [http://www.mobygames.com/game/saturn/solar-eclipse Solar Eclipse (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/sonic-3d-blast Sonic 3D Blast (Sega Saturn)]
* [http://www.mobygames.com/game/spycraft-the-great-game Spycraft: The Great Game (DOS & Windows)]
* [http://www.mobygames.com/game/saturn/theme-park Theme Park (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-cop-2 Virtua Cop 2 (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-fighter-2 Virtua Fighter 2 (Sega Saturn)]
* [http://www.mobygames.com/game/windows/zork-grand-inquisitor Zork: Grand Inquisitor (Windows)]
* [http://www.mobygames.com/game/windows/zork-nemesis-the-forbidden-lands Zork Nemesis: The Forbidden Lands (Windows)]
* Bubble Bobble special CD release with Rainbow Island (DOS) by Acclaim

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

Reaper

2011-07-24T16:19:27Z

VAG:

* Extension: fmv

Psygnosis' 1999 title [http://www.mobygames.com/game/windows/rollcage Rollcage] included directory full of video with a .fmv extension. The first 8 bytes of the files contain a header of "!Reaper!".

Looking at the strings in the either of the games binaries (Glide or Direct3D) the string "Reaper '95 Version 1.30, (c) Paul Hughes" can also be found.

The game (its PSX version) take advantage of an [[MDEC]] chip, therefore the video encoding is an [[MPEG]] variant and audio is [[IMA ADPCM]] packaged in a custom container.

== File Format ==
All numbers are little-endian. File consist of a main header:

s8 signature[8] -- "!Reaper!" (but only first 5 characters actually checked)
s32 headersize -- size of the header and coefficients table (i.e. it's an offset of the first data chunk)
s16 width -- video width
s16 height -- video height
s16 coeffsize -- size of the decompressed coefficients table
s16 audiotype -- 0 - no sound, 1 - IMA sound
s16 audiorate -- audio frequency
s16 audiobits -- sound sample bits (always 16?)
s16 audiochnl -- 1 - mono, 2 - stereo
s16 unknown

then followed by packed coefficients table (size = headersize - sizeof(header)) and then followed by frame chunks.
Chunk format:
u32 signature -- chunk type
u32 size -- chunk size, including this header
u8 payload[] -- chunk payload

Observed chunk types:
* 0x0B85120F - video chunk
* 0x90FC0302 - audio chunk
* 0xD6BD0106 - ?

== Video Decompression ==

'''TODO'''

[[Category:Game Formats]]
[[Category:Undiscovered Game Formats]]

AMF

2011-07-23T20:45:42Z

VAG: mention another AMF format

* 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].
Contains only [[RLE]]-encoded palettized video.

== 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:
* 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]]

AMF

2011-07-23T20:20:26Z

VAG:

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

AMF is a very simple video file format used in the game [http://www.mobygames.com/game/dos/manic-karts Manic Karts].
Contains only [[RLE]]-encoded palettized video.

== 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:
* 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 num_frames 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]]

H.264 Prediction

2011-04-23T06:50:43Z

VAG: /* Plane */ ohh, Mike, Mike...

This page documents the various prediction methods used in [[H.264]] and related formats such as [[Sorenson Video 3]], [[RealVideo 4]], and [[On2 VP8]].

== 4x4 Prediction Modes ==

4x4 prediction modes vary between different codecs. While they are almost the same for [[H.264]] and [[Sorenson Video 3]], [[RealVideo 4]] has a different order for these modes and some of them significantly differ from H.264 counterparts (by using left predictors where H.264 does not and down left predictors which are not used elsewhere).

=== Vertical ===

* H.264: mode 0
* SVQ3: mode 0
* RV40: mode 1
* VP8: not used

| T0 T1 T2 T3
---------------------
| T0 T1 T2 T3
| T0 T1 T2 T3
| T0 T1 T2 T3
| T0 T1 T2 T3

=== Vertical (VP8) ===

* H.264: not used
* SVQ3: not used
* RV40: not used
* VP8: mode 2

LT | T0 T1 T2 T3 T4
------------------------
| a b c d
| a b c d
| a b c d
| a b c d

where:

a = (LT + 2*T0 + T1 + 2) >> 2
b = (T0 + 2*T1 + T2 + 2) >> 2
c = (T1 + 2*T2 + T3 + 2) >> 2
d = (T2 + 2*T3 + T4 + 2) >> 2

=== Horizontal ===

* H.264: mode 1
* SVQ3: mode 1
* RV40: mode 2
* VP8: not used

|
---------------------
L0 | L0 L0 L0 L0
L1 | L1 L1 L1 L1
L2 | L2 L2 L2 L2
L3 | L3 L3 L3 L3

=== Horizontal (VP8) ===

* H.264: not used
* SVQ3: not used
* RV40: not used
* VP8: mode 3

LT |
--------------------
L0 | a a a a
L1 | b b b b
L2 | c c c c
L3 | d d d d

where:

a = (LT + 2*L0 + L1 + 2) >> 2
b = (L0 + 2*L1 + L2 + 2) >> 2
c = (L1 + 2*L2 + L3 + 2) >> 2
d = (L2 + 2*L3 + L3 + 2) >> 2

=== DC ===

* H.264: mode 2
* SVQ3: mode 2
* RV40: mode 0
* VP8: mode 0

| T0 T1 T2 T3
---------------------
L0 | a a a a
L1 | a a a a
L2 | a a a a
L3 | a a a a

where:

if top and left predictors are available
a = (T0 + T1 + T2 + T3 + L0 + L1 + L2 + L3 + 4) / 8
else if top predictors are available
a = (T0 + T1 + T2 + T3 + 2) / 4
else if left predictors are available
a = (L0 + L1 + L2 + L3 + 2) / 4
else
a = 128

Note that the VP8 reference code does not make any provisions for either or both sets of predictors to be missing.

=== Diagonal Down/Left ===

* H.264: mode 3
* SVQ3: not used
* RV40: not used
* VP8: mode 4

| T0 T1 T2 T3 T4 T5 T6 T7
-------------------------------------
| a b c d
| b c d e
| c d e f
| d e f g

where:

a = (T0 + 2*T1 + T2 + 2) / 4
b = (T1 + 2*T2 + T3 + 2) / 4
c = (T2 + 2*T3 + T4 + 2) / 4
d = (T3 + 2*T4 + T5 + 2) / 4
e = (T4 + 2*T5 + T6 + 2) / 4
f = (T5 + 2*T6 + T7 + 2) / 4
g = (T6 + 3*T7 + 2) / 4

=== Diagonal Down/Left (SVQ3) ===

* H.264: not used
* SVQ3: mode 3
* RV40: not used
* VP8: not used

| T1 T2 T3
---------------------
| a b c c
L1 | b c c c
L2 | c c c c
L3 | c c c c

where:

a = (L1 + T1) / 2
b = (L2 + T2) / 2
c = (L3 + T3) / 2

=== Diagonal Down/Left (RV40) ===

* H.264: not used
* SVQ3: not used
* RV40: mode 4
* VP8: not used

| T0 T1 T2 T3 T4 T5 T6 T7
-------------------------------------
L0 | a b c d
L1 | b c d e
L2 | c d e f
L3 | d e f g
L4 |
L5 |
L6 |
L7 |

where:

a = (T0 + 2*T1 + T2 + L0 + 2*L1 + L2 + 4) / 8
b = (T1 + 2*T2 + T3 + L1 + 2*L2 + L3 + 4) / 8
c = (T2 + 2*T3 + T4 + L2 + 2*L3 + L4 + 4) / 8
d = (T3 + 2*T4 + T5 + L3 + 2*L4 + L5 + 4) / 8
e = (T4 + 2*T5 + T6 + L4 + 2*L5 + L6 + 4) / 8
f = (T5 + 2*T6 + T7 + L5 + 2*L6 + L7 + 4) / 8
g = (T6 + T7 + L6 + L7 + 2) / 4

=== Diagonal Down/Right ===

* H.264: mode 4
* SVQ3: mode 4
* RV40: mode 3
* VP8: mode 5

LT | T0 T1 T2 T3
---------------------
L0 | d e f g
L1 | c d e f
L2 | b c d e
L3 | a b c d

where:

a = (L3 + 2*L2 + L1 + 2) / 4
b = (L2 + 2*L1 + L0 + 2) / 4
c = (L1 + 2*L0 + LT + 2) / 4
d = (L0 + 2*LT + T0 + 2) / 4
e = (LT + 2*T0 + T1 + 2) / 4
f = (T0 + 2*T1 + T2 + 2) / 4
g = (T1 + 2*T2 + T3 + 2) / 4

=== Vertical/Right ===

* H.264: mode 5
* SVQ3: mode 5
* RV40: mode 5
* VP8: mode 6

LT | T0 T1 T2 T3
---------------------
L0 | a b c d
L1 | e f g h
L2 | i a b c
| j e f g

where:

a = (LT + T0 + 1) / 2
b = (T0 + T1 + 1) / 2
c = (T1 + T2 + 1) / 2
d = (T2 + T3 + 1) / 2
e = (L0 + 2*LT + T0 + 2) / 4
f = (LT + 2*T0 + T1 + 2) / 4
g = (T0 + 2*T1 + T2 + 2) / 4
h = (T1 + 2*T2 + T3 + 2) / 4
i = (LT + 2*L0 + L1 + 2) / 4
j = (L0 + 2*L1 + L2 + 2) / 4

=== Horizontal/Down ===

* H.264: mode 6
* SVQ3: mode 6
* RV40: mode 8
* VP8: mode 8

LT | T0 T1 T2
---------------------
L0 | a b c d
L1 | e f a b
L2 | g h e f
L3 | i j g h

where:

a = (LT + L0 + 1) / 2
b = (L0 + 2*LT + T0 + 2) / 4
c = (LT + 2*T0 + T1 + 2) / 4
d = (T0 + 2*T1 + T2 + 2) / 4
e = (L0 + L1 + 1) / 2
f = (LT + 2*L0 + L1 + 2) / 4
g = (L1 + L2 + 1) / 2
h = (L0 + 2*L1 + L2 + 2) / 4
g = (L2 + L3 + 1) / 2
j = (L1 + 2*L2 + L3 + 2) / 4

=== Vertical/Left ===

* H.264: mode 7
* SVQ3: mode 7
* RV40: mode 6
* VP8: mode 7

| T0 T1 T2 T3 T4 T5 T6
---------------------------------
| a b c d
L1 | f g h i
L2 | b c d e
L3 | g h i j
L4 |

where:

a = (T0 + T1 + 1) / 2
b = (T1 + T2 + 1) / 2
c = (T2 + T3 + 1) / 2
d = (T3 + T4 + 1) / 2
e = (T4 + T5 + 1) / 2
f = (T0 + 2*T1 + T2 + 2) / 4
g = (T1 + 2*T2 + T3 + 2) / 4
h = (T2 + 2*T3 + T4 + 2) / 4
i = (T3 + 2*T4 + T5 + 2) / 4
j = (T4 + 2*T5 + T6 + 2) / 4

For RV40 two coefficients differ:

a = (2*T0 + 2*T1 + L1 + 2*L2 + L3 + 4) / 8
f = ( T0 + 2*T1 + T2 + L2 + 2*L3 + L4 + 4) / 8

For VP8, 3 coefficients differ:

c = (T2 + T3 + T4 + 2) / 4
e = (T4 + 2*T5 + T6 + 2) / 4
j = (T5 + 2*T6 + T7 + 2) / 4

=== Horizontal/Up ===

* H.264: mode 8
* SVQ3: mode 8
* RV40: not used
* VP8: mode 9

|
---------------------
L0 | a b c d
L1 | c d e f
L2 | e f g g
L3 | g g g g

where:

a = (L0 + L1 + 1) / 2
b = (L0 + 2*L1 + L2 + 2) / 4
c = (L1 + L2 + 1) / 2
d = (L1 + 2*L2 + L3 + 2) / 4
e = (L2 + L3 + 1) / 2
f = (L2 + 3*L3 + 2) / 4
g = L3

=== Horizontal/Up (RV40)===

* H.264: not used
* SVQ3: not used
* RV40: mode 7
* VP8: not used

| T0 T1 T2 T3 T4 T5 T6 T7
-------------------------------------
L0 | a b c d
L1 | c d e f
L2 | e f g h
L3 | g h i j
L4 |
L5 |
L6 |

where:

a = (T1 + 2*T2 + T3 + 2*L0 + 2*L1 + 4) / 8
b = (T2 + 2*T3 + T4 + L0 + 2*L1 + L2 + 4) / 8
c = (T3 + 2*T4 + T5 + 2*L1 + 2*L2 + 4) / 8
d = (T4 + 2*T5 + T6 + L1 + 2*L2 + L3 + 4) / 8
e = (T5 + 2*T6 + T7 + 2*L2 + 2*L3 + 4) / 8
f = (T6 + 3*T7 + L2 + 3*L3 + 4) / 8
g = (T6 + T7 + L3 + L4 + 2) / 4
h = ( L3 + 2*L4 + L5 + 2) / 4
i = ( L4 + L5 + 1) / 2
j = ( L4 + 2*L5 + L6 + 2) / 4

=== TrueMotion (VP8) ===

* H.264: not used
* SVQ3: not used
* RV40: not used
* VP8: mode 1

LT | T0 T1 T2 T3
---------------------
L0 | a . . .
L1 | . b . .
L2 | . . c .
L3 | . . . d

where this pattern is satisfied:

a = SATURATE_U8(T0 - LT + L0)
b = SATURATE_U8(T1 - LT + L1)
c = SATURATE_U8(T2 - LT + L2)
d = SATURATE_U8(T3 - LT + L3)

I.e., for each of the 16 samples: (top predictor for column) - (left/top predictor) + (left predictor for row), then saturate in an unsigned byte range 0..255.

== 16x16 Prediction Modes ==

=== DC ===

* H.264: mode 0
* SVQ3: mode 0
* RV40: mode 0
* VP8: mode 0

Using the 16 top predictors (T0..T15) and the 16 left predictors (L0..L15), set all 256 elements to the mean, computed as:

if top and left predictors are available
mean = (sum(T0..T15) + sum(L0..L15) + 16) / 32
else if top predictors are available
mean = (sum(T0..T15) + 8) / 16
else if left predictors are available
mean = (sum(L0..L15) + 8) / 16
else
mean = 128

=== Vertical ===

* H.264: mode 1
* SVQ3: mode 1
* RV40: mode 1
* VP8: mode 1

| T0 T1 T2 T3 T4 .. T15
-------------------------- .. -----
| T0 T1 T2 T3 T4 .. T15
| T0 T1 T2 T3 T4 .. T15
| T0 T1 T2 T3 T4 .. T15
......
| T0 T1 T2 T3 T4 .. T15

=== Horizontal ===

* H.264: mode 2
* SVQ3: mode 2
* RV40: mode 2
* VP8: mode 2

|
--------------------------- .. -----
L0 | L0 L0 L0 L0 L0 .. L0
L1 | L1 L1 L1 L1 L1 .. L1
L2 | L2 L2 L2 L2 L2 .. L2
......
L15 | L15 L15 L15 L15 L15 .. L15

=== Plane ===

* H.264: mode 3
* SVQ3: mode 3
* RV40: mode 3
* VP8: not used

Notice that SVQ3 and RV40 follow a slightly different method here.

Given the top predictors (T0..T15), left predictors (L0..L15) and the left-top corner predictor (LT) arranged as follows:

LT | T0 T1 T2 .. T15
----------------------------------- .. --------
L0 | c[ 0, 0] c[ 1, 0] c[ 2, 0] .. c[15, 0]
L1 | c[ 0, 1] c[ 1, 1] c[ 2, 1] .. c[15, 1]
......
L15 | c[ 0,15] c[ 1,15] c[ 2,15] .. c[15,15]

Compute H' and V':
H' = 1* (T8 - T6) +
2* (T9 - T5) +
3*(T10 - T4) +
4*(T11 - T3) +
5*(T12 - T2) +
6*(T13 - T1) +
7*(T14 - T0) +
8*(T15 - LT)

V' = 1* (L8 - L6) +
2* (L9 - L5) +
3*(L10 - L4) +
4*(L11 - L3) +
5*(L12 - L2) +
6*(L13 - L1) +
7*(L14 - L0) +
8*(L15 - LT)

For H.264, compute H and V as:

H = (5*H' + 32) / 64
V = (5*V' + 32) / 64

For SVQ3, compute H and V as:

V = (5*(H'/4)) / 16
H = (5*(V'/4)) / 16
(notice that V and H are computed from H' and V', respectively)

For RV40, compute H and V as:

H = (5*(H' >> 2)) >> 4
V = (5*(V' >> 2)) >> 4
(like SVQ3 but without swapping and it's important to use shifts here instead of divisions)

The final process for filling in the 16x16 block is:

a = 16 * (L15 + T15 + 1) - 7*(V+H)
for (j = 0..15)
for (i = 0..15)
b = a + V * j + H * i
c[i,j] = SATURATE_U8(b / 32)

The SATURATE_U8() function indicates that the result of the operation should be bounded to an unsigned 8-bit range (0..255).

=== TrueMotion (VP8) ===

* H.264: not used
* SVQ3: not used
* RV40: not used
* VP8: mode 3

Given the top predictors (T0..T15), left predictors (L0..L15) and the left-top corner predictor (LT) arranged as follows:

LT | T0 T1 T2 .. T15
----------------------------------- .. --------
L0 | c[ 0, 0] c[ 1, 0] c[ 2, 0] .. c[15, 0]
L1 | c[ 0, 1] c[ 1, 1] c[ 2, 1] .. c[15, 1]
......
L15 | c[ 0,15] c[ 1,15] c[ 2,15] .. c[15,15]

Compute c[t,l] as:

c[t,l] = SATURATE_U8(L[l] + T[t] - LT)

I.e., for each element, sum the left and top predictors for the row and column, respectively, and subtract the left-top predictor. Then, saturate the result between 0 and 255.

[[Category:Compression Theory]]

RNC ProPack

2011-03-12T17:23:47Z

VAG:

RNC Pro-Pack is a general data compression library (like [[zlib]]), RNC is acronym for author's company name, Rob Northen Computing.

Packer DOS binary, along with assembly decoding modules (barely useable nowdays) can be freely downloaded [http://aminet.net/package/util/pack/RNC_ProPack here].

There are several known variants in the wild, version 1 was employed to compress data files in various games, like Beneath a Steel Sky or Dungeon Keeper, version 2 seems to be used in [[ETV]] codec.

== Header ==

All numbers are stored as big-endian.

3 bytes signature "RNC"
1 byte version
4 bytes unpacked data length
4 bytes packed data length
2 bytes CRC-16 of packed data
2 bytes CRC-16 of unpacked data
2 bytes overlap size (used for inplace unpacking)

== Compression ==

As an extra protection measure against curious hackers compressed data can be encrypted with secret 16-bit key (supplied to decompression routine by programmer.) In that case all byte literals decoded as follows:

byte ^= key; key = _rotr(key, 1);

=== Version 0 ===

This is uncompressed data.

=== Version 1 ===

Decoder source is in [https://github.com/scummvm/scummvm/blob/master/engines/sky/rnc_deco.cpp ScummVM repository].

Bits are packed into bytes and those are interspersed with byte values (like in [[KMVC]] for example).

Data is packed with LZ77 scheme into blocks, each block has three Huffman tables for literal and copy lengths and offsets.

Huffman tables:

5 bits - number of entries (0-16)
4x<number> bits - code lengths

for codes reconstruction and tree reading pleas refer to decoder code.

Block starts with three tables description and 16-bit number of (literal, copy) pairs.

while (!end) {
read literal length table
read offset table
read copy length table
blocks = get_bits(16);

while (blocks--) {
read_length = get_value(literal_table);
while (read_length--)
*dst++ = get_byte();
if (blocks) {
offset = get_value(offset_table);
length = get_value(copy_len_table);
memmove(dst, dst - offset, length);
dst += length;
}
}
}

=== Version 2 ===

This seems to be designed to be faster on decoding so it does not use Huffman tables (but it's still LZ77 scheme with the same bitreader).

get_bits(2); // unused
while (!end) {
if (!get_bit()) {
*dst++ = get_byte();
} else {
if (!get_bit()) {
length = 4 + get_bit();
if (get_bit()) {
length = (length - 1) * 2 + get_bit();
if (length == 9) {
length = (get_bits(4) + 3) * 4;
for (i = 0; i < length; i++)
*dst++ = get_byte();
continue;
}
}
offset = get_offset();
} else {
if (get_bit()) {
if (get_bit()) {
length = get_byte() + 8;
if (length == 8) {
get_bit();
continue; //dunno why
}
} else {
length = 3;
}
offset = get_offset();
} else {
offset = get_byte() + 1;
}
}
memmove(dst, dst - offset, length);
dst += length;
}
}

Offset is coded like that:

value = 0;
if (get_bit()) {
value = get_bit();
if (get_bit()) {
value = value * 2 + 4 + get_bit();
if (!get_bit())
value = value * 2 + get_bit();
} else if (value == 0)
value = get_bit() + 2;
}
offset = (value << 8) + get_byte() + 1;

[[Category:General Compression Methods]]

PMM

2011-03-12T16:06:56Z

VAG: rewrite

* Extensions: pmm
* Samples: [http://samples.mplayerhq.hu/game-formats/krazy-ivan-pmm/ http://samples.mplayerhq.hu/game-formats/krazy-ivan-pmm/]

The game [http://www.mobygames.com/game/windows/krazy-ivan Krazy Ivan] uses multimedia files with the extension .pmm. Carries encoded 15-bit video along with [[PCM]] or [[DPCM]] (never used) audio track.

== File Format ==

File structure follows general [[RIFF]] format, but uses custom chunk names. All numbers are little endian.

File begins with 4 * 3 bytes catalog header:

u32 fourcc -- "PIFF"
u32 filesize -- not including fourcc and filesize fields
u32 filetype -- "PXMT" /PXM Type?/

followed by chunks:

u32 fourcc -- chunk [[FOURCC]]
u32 chunksize -- not including fourcc and chunksize fields
u8 payload[chunksize] -- chunk data

=== PXMH chunk ===
/PXM Header?/
Carries general movie information.

u16 unknown0
u16 flags
u16 width -- frame width in blocks
u16 height -- frame height in blocks
u16 bwidth -- block width (always 8)
u16 bheight -- block height (always 8)
u16 framerate
u16 numframes
u32 maxframe -- size of the largest BODY chunk
u8 descrition[32]
u16 audiofreq
u8 audiotype -- audio compression format
u8 audiochnl
... -- the rest is unknown/unused

=== CPAL ===
8-bit palette. Obsolete.

=== MPAL ===
Palette? Obsolete.

=== BODY ===
Contains encoded vide frame. See below.

=== AUDO ===
Contains audio fragment. See below.

== Video Compression ==
Vide is encoded as a series of bwidth x bheight blocks (typically, 8x8), which may further be divided in to smaller blocks. Pixel format is 15-bit RGB.

Video payload format:

u16 codetable_ofs -- offset of code table bitstream (inside the chunk)
u16 pixels_ofs -- offsets of pixels data (inside the chunk)
...
u8 codetable[] -- bitstream data, read bits from the lowest of each byte
u8 pixels[] -- encoded pixel data (bytes)

Compression is based on selective pixel color components change within the block. To decode single block:

1. Initialize last_pixel to 0 
2. Read the 3-bits color_mask value. This is a bit mask, indicates which pixel components will be changed (bit 0 - Red, 1 - Green, 2 - Blue). Zero value indicates the whole block is unchanged. 
3. Read next bit. If bit is zero, decode pixel and use it to draw the whole (sub)block; otherwise 
4. If subblock size is 2, decode each pixel of subblock and draw it; otherwise 
5. Split the (sub)block on to 4 equial subblocks and process recursively from step 3 (left-right-top-bottom.)

DecodePixel operates as follows:

1. Read next 8-bits pixel_data (from pixels[]) 
2. If high bit of pixel_data is set, pixel value is the next entry of pixels[] (lower part) combined with 7 bits of pixel_data (upper part.); otherwise 
3. Color_index = value in bits 5-6 of pixel_data (0 - Blue, 1 - Green, 2 - Red, 3 - Skip), color_value = bits 0-4 of pixel_data. If color_index is Skip, assume pixel value is last_pixel. Otherwise, for each color component selected by color_mask, set it to color_value if it's the same component as specified by color_index, or if color_mask indicates no change of color_index component (this case is used to change two components at once.) Reuse all untouched components from last_pixel. 
4. Set last_pixel to newly decoded pixel value.

== Audio Compression ==

According to audiotype field, audio can be stored in the following formats:
=== Type 0 - PCM16 ===
Raw 16-bit [[PCM]] samples.
=== Type 1 - Packed PCM16 ===
Only high 8 bits of 16-bits sample stored. I.e. DecodedSample = data << 8.
=== Type 2 - DPCM ===
Decode a sample using the following [[DPCM]] table:

-32767,-30191,-27818,-25631,-23617,-21760,-20050,-18474,-17021,-15683,-14451,-13315,-12268,-11304,-10415, -9596,
-8842, -8147, -7506, -6916, -6373, -5872, -5410, -4985, -4593, -4232, -3899, -3593, -3310, -3050, -2810, -2589,
-2386, -2198, -2025, -1866, -1719, -1584, -1460, -1345, -1239, -1142, -1052, -969, -893, -823, -758, -698,
-643, -593, -546, -503, -464, -427, -393, -363, -334, -308, -283, -261, -241, -222, -204, -188,
-173, -160, -147, -135, -125, -115, -106, -97, -90, -83, -76, -70, -65, -59, -55, -50,
-46, -43, -39, -36, -33, -31, -28, -26, -24, -22, -20, -19, -17, -16, -14, -13,
-12, -11, -10, -9, -9, -8, -7, -7, -6, -6, -5, -5, -4, -4, -4, -3,
-3, -3, -2, -2, -2, -2, -2, -1, -1, -1, -1, -1, -1, -1, -1, 0,
1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3,
4, 4, 4, 5, 5, 6, 6, 7, 7, 8, 9, 9, 10, 11, 12, 13,
14, 16, 17, 19, 20, 22, 24, 26, 28, 31, 33, 36, 39, 43, 46, 50,
55, 59, 65, 70, 76, 83, 90, 97, 106, 115, 125, 135, 147, 160, 173, 188,
204, 222, 241, 261, 283, 308, 334, 363, 393, 427, 464, 503, 546, 593, 643, 698,
758, 823, 893, 969, 1052, 1142, 1239, 1345, 1460, 1584, 1719, 1866, 2025, 2198, 2386, 2589,
2810, 3050, 3310, 3593, 3899, 4232, 4593, 4985, 5410, 5872, 6373, 6916, 7506, 8147, 8842, 9596,
10415, 11304, 12268, 13315, 14451, 15683, 17021, 18474, 20050, 21760, 23617, 25631, 27818, 30191, 32767, 32767

[[Category:Game Formats]]

DFA

2011-03-09T19:14:47Z

VAG: fix BLCK, update file header

* Extensions: dfa
* Samples: [http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/ http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/]

A DOS-based game called [http://www.mobygames.com/game/dos/chronomaster Chronomaster] includes files with the extension .dfa which appear to be animation files. All multi-byte numbers are little endian. These files are comprised of chunks with the following format:

bytes 0-3 chunk fourcc
bytes 4-7 chunk size, not including 12-byte preamble
bytes 8-11 chunk type, essentially numeric equivalent of fourcc
bytes 12.. chunk payload

A DFA file begins with a 128- (0x80-)byte header:

bytes 0-3 file signature: 'DFIA'
bytes 6-7 number of frames
bytes 8-9 frame width
bytes 10-11 frame height
bytes 12-15 frame rate
bytes 16-19 ?
bytes 20-127 unused

Chunk types include:

EOFR (type 0) end of frame, empty chunk
PAL1 (type 1) 768-byte chunk containing a 6-bit VGA palette components
COPY (type 2) raw frame data
TSW1 (type 3) video frame, intra LZ-coded
BDLT (type 4) video frame, inter RLE-coded bytes
WDLT (type 5) video frame, inter RLE-coded words
type 6 not occured in known samples
DSW1 (type 7) video frame, inter LZ-coded
BLCK (type 8) solid frame, fill whole frame with the first byte of payload
DDS1 (type 9) video frame, inter LZ-coded, double-scaled

=== TSW1 chunk ===

First four bytes store number of stripes to change, next four bytes - offset inside frame. The rest is stripe data.

Every stripe is coded with 16-bit LSB little-endian words in LZ77-like scheme:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2;
count = ((v >> 13) + 2) * 2;
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else {
*cur_frame_pos++ = get_byte();
*cur_frame_pos++ = get_byte();
}
mask <<= 1;
}

=== BDLT chunk ===

First two bytes code number of lines to skip in frame before decoding, next two bytes code number of lines to decode.

Every line is coded into segments, first byte of data tells how many segments are there. Every segment is coded as RLE, first byte
tells how many pixels to skip before decoding segment, second byte is treated as signed value with sign telling if it's copy or run:

while (segments--) {
cur_line_ptr += get_byte();
count = (int8_t)get_byte();
if (count >= 0)
get_buffer(cur_line_ptr, count);
else
memset(cur_line_ptr, get_byte(), -count);
cur_line_ptr += abs(count);
}

=== WDLT chunk ===

First two bytes code number of lines to decode. Overall decoding is similar to BDLT chunk but with words copy instead of byte copy and different segment handling scheme:

while (lines--) {
stripes = (int16_t)get_le16();
while (stripes & 0xC000) {
*frame_ptr += -stripes * width;
stripes = (int16_t)get_le16();
}
if (stripes < 0) {
frame_ptr[width - 1] = stripes & 0xFF;
stripes = (int16_t)get_le16();
}
line_ptr = frame_ptr;
while (stripes--) {
line_ptr += get_byte();
count = (int8_t)get_byte();
if (count > 0) {
get_buffer(line_ptr, count * 2);
line_ptr += count * 2;
} else {
val = get_le16();
for (i = 0; i < -count * 2; i++) {
put_le16(line_ptr, val);
line_ptr += 2;
}
}
}
frame_ptr += width;
}

=== chunk type 6 ===

First four bytes code number of segments, each segment contains number of bytes to skip before decoding, number of bytes to copy and bytes to copy.

=== DSW1 chunk ===

Almost the same as TSW1 chunk with the following differences:

* first two bytes code number of stripes
* if getbit() returned zero, get and test another bit. If that bit is zero too then read literal (two bytes), else read 2-byte number and skip corresponding number of pixels.

=== DDS1 chunk ===

Almost the same as DSW1 chunk but it decodes in scaled mode - every skip is twice that large, literal is used to set 2x2 block and copying also fills 2x2 block with pixel value:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2 * 2;
count = ((v >> 13) + 2) * 2;
for (i = 0; i < count; i++) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = cur_frame_pos[-offset];
cur_frame_pos += 2;
}
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else if (!(bitbuf & (mask << 1)) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
} else {
cur_frame_pos += get_le16() * 2;
}
mask <<= 1;
}

[[Category:Game Formats]]

DFA

2011-03-09T19:07:58Z

VAG: /* BDLT chunk */ fix broken algo

* Extensions: dfa
* Samples: [http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/ http://samples.mplayerhq.hu/game-formats/chronomaster-dfa/]

A DOS-based game called [http://www.mobygames.com/game/dos/chronomaster Chronomaster] includes files with the extension .dfa which appear to be animation files. All multi-byte numbers are little endian. These files are comprised of chunks with the following format:

bytes 0-3 chunk fourcc
bytes 4-7 chunk size, not including 12-byte preamble
bytes 8-11 chunk type, essentially numeric equivalent of fourcc
bytes 12.. chunk payload

A DFA file begins with a 128- (0x80-)byte header:

bytes 0-3 file signature: 'DFIA'
bytes 4-127 unknown (mostly 0s)

Chunk types include:

EOFR (type 0) end of frame, empty chunk
PAL1 (type 1) 768-byte chunk containing a 6-bit VGA palette components
COPY (type 2) raw frame data
TSW1 (type 3) video frame, intra LZ-coded
BDLT (type 4) video frame, inter RLE-coded bytes
WDLT (type 5) video frame, inter RLE-coded words
type 6 not occured in known samples
DSW1 (type 7) video frame, inter LZ-coded
BLCK (type 8) black frame (fill all frame with zero)
DDS1 (type 9) video frame, inter LZ-coded, double-scaled

=== TSW1 chunk ===

First four bytes store number of stripes to change, next four bytes - offset inside frame. The rest is stripe data.

Every stripe is coded with 16-bit LSB little-endian words in LZ77-like scheme:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2;
count = ((v >> 13) + 2) * 2;
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else {
*cur_frame_pos++ = get_byte();
*cur_frame_pos++ = get_byte();
}
mask <<= 1;
}

=== BDLT chunk ===

First two bytes code number of lines to skip in frame before decoding, next two bytes code number of lines to decode.

Every line is coded into segments, first byte of data tells how many segments are there. Every segment is coded as RLE, first byte
tells how many pixels to skip before decoding segment, second byte is treated as signed value with sign telling if it's copy or run:

while (segments--) {
cur_line_ptr += get_byte();
count = (int8_t)get_byte();
if (count >= 0)
get_buffer(cur_line_ptr, count);
else
memset(cur_line_ptr, get_byte(), -count);
cur_line_ptr += abs(count);
}

=== WDLT chunk ===

First two bytes code number of lines to decode. Overall decoding is similar to BDLT chunk but with words copy instead of byte copy and different segment handling scheme:

while (lines--) {
stripes = (int16_t)get_le16();
while (stripes & 0xC000) {
*frame_ptr += -stripes * width;
stripes = (int16_t)get_le16();
}
if (stripes < 0) {
frame_ptr[width - 1] = stripes & 0xFF;
stripes = (int16_t)get_le16();
}
line_ptr = frame_ptr;
while (stripes--) {
line_ptr += get_byte();
count = (int8_t)get_byte();
if (count > 0) {
get_buffer(line_ptr, count * 2);
line_ptr += count * 2;
} else {
val = get_le16();
for (i = 0; i < -count * 2; i++) {
put_le16(line_ptr, val);
line_ptr += 2;
}
}
}
frame_ptr += width;
}

=== chunk type 6 ===

First four bytes code number of segments, each segment contains number of bytes to skip before decoding, number of bytes to copy and bytes to copy.

=== DSW1 chunk ===

Almost the same as TSW1 chunk with the following differences:

* first two bytes code number of stripes
* if getbit() returned zero, get and test another bit. If that bit is zero too then read literal (two bytes), else read 2-byte number and skip corresponding number of pixels.

=== DDS1 chunk ===

Almost the same as DSW1 chunk but it decodes in scaled mode - every skip is twice that large, literal is used to set 2x2 block and copying also fills 2x2 block with pixel value:

mask = 0x10000;
while (stripes--) {
if (mask == 0x10000) {
mask = 1;
bitbuf = get_le16();
}
if (bitbuf & mask) {
v = get_le16();
offset = (v & 0x1FFF) * 2 * 2;
count = ((v >> 13) + 2) * 2;
for (i = 0; i < count; i++) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = cur_frame_pos[-offset];
cur_frame_pos += 2;
}
memmove(cur_frame_pos, cur_frame_pos - offset, count);
} else if (!(bitbuf & (mask << 1)) {
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
cur_frame_pos[0] = cur_frame_pos[1] =
cur_frame_pos[width] = cur_frame_pos[width + 1] = get_byte();
cur_frame_pos += 2;
} else {
cur_frame_pos += get_le16() * 2;
}
mask <<= 1;
}

[[Category:Game Formats]]

RNC ProPack

2011-03-09T18:56:23Z

VAG: fix header, add info about encryption, fix broken algo

RNC is a general data compression library (like [[zlib]]), name probably stands for Rob Northern Compression (got it from [http://code.google.com/p/corsix-th/wiki/RNC here]).

Packer DOS binary, along with assembly decoding modules (barely useable nowdays) can be freely downloaded [http://aminet.net/package/util/pack/RNC_ProPack here].

There are several known variants in the wild, version 1 was employed to compress data files in various games, like Beneath a Steel Sky or Dungeon Keeper, version 2 seems to be used in [[ETV]] codec.

== Header ==

All numbers are stored as big-endian.

3 bytes signature "RNC"
1 byte version
4 bytes unpacked data length
4 bytes packed data length
2 bytes CRC-16 of packed data
2 bytes CRC-16 of unpacked data
2 bytes overlap size (used for inplace unpacking)

== Compression ==

As an extra protection measure against curious hackers compressed data can be encrypted with secret 16-bit key (supplied to decompression routine by programmer.) In that case all byte literals decoded as follows:

byte ^= key; key = _rotr(key, 1);

=== Version 0 ===

This is uncompressed data.

=== Version 1 ===

Decoder source is in [https://github.com/scummvm/scummvm/blob/master/engines/sky/rnc_deco.cpp ScummVM repository].

Bits are packed into bytes and those are interspersed with byte values (like in [[KMVC]] for example).

Data is packed with LZ77 scheme into blocks, each block has three Huffman tables for literal and copy lengths and offsets.

Huffman tables:

5 bits - number of entries (0-16)
4x<number> bits - code lengths

for codes reconstruction and tree reading pleas refer to decoder code.

Block starts with three tables description and 16-bit number of (literal, copy) pairs.

while (!end) {
read literal length table
read offset table
read copy length table
blocks = get_bits(16);

while (blocks--) {
read_length = get_value(literal_table);
while (read_length--)
*dst++ = get_byte();
if (blocks) {
offset = get_value(offset_table);
length = get_value(copy_len_table);
memmove(dst, dst - offset, length);
dst += length;
}
}
}

=== Version 2 ===

This seems to be designed to be faster on decoding so it does not use Huffman tables (but it's still LZ77 scheme with the same bitreader).

get_bits(2); // unused
while (!end) {
if (!get_bit()) {
*dst++ = get_byte();
} else {
if (!get_bit()) {
length = 4 + get_bit();
if (get_bit()) {
length = (length - 1) * 2 + get_bit();
if (length == 9) {
length = (get_bits(4) + 3) * 4;
for (i = 0; i < length; i++)
*dst++ = get_byte();
continue;
}
}
offset = get_offset();
} else {
if (get_bit()) {
if (get_bit()) {
length = get_byte() + 8;
if (length == 8) {
get_bit();
continue; //dunno why
}
} else {
length = 3;
}
offset = get_offset();
} else {
offset = get_byte() + 1;
}
}
memmove(dst, dst - offset, length);
dst += length;
}
}

Offset is coded like that:

value = 0;
if (get_bit()) {
value = get_bit();
if (get_bit()) {
value = value * 2 + 4 + get_bit();
if (!get_bit())
value = value * 2 + get_bit();
} else if (value == 0)
value = get_bit() + 2;
}
offset = (value << 8) + get_byte() + 1;

[[Category:General Compression Methods]]

What codec shall I reverse engineer next

2011-03-07T15:26:34Z

VAG:

With so much to choose from, sometimes we need help deciding what to do next. Here is a list. Its not a wishlist or bug-tracker. Think of this as a choose your own adventure...

* [[Discworld]] Noir
* [[MSS1]] / [[MSS2]]
* [[Smush]]
* [[VP7]]
* [[Indeo 4]]

And if you are better at writing than reversing, you can help by properly documenting / implementing the following (already reversed) codecs:

* [[Gremlin Digital Video]] - document missing features
* Krazy Ivan [[PMM]] - de-optimize
* Chronomaster [[DFA]]
* [[RNC ProPack]] - not directly related to multimedia, but still used by some codecs

Contact me if interested and I'll provide you with neccessary code and information. --[[User:VAG|VAG]] 09:57, 7 March 2011 (EST)

[[Category:FFmpeg]]