MultimediaWiki - User contributions [en]

LEAD Screen Capture

2009-02-02T06:21:05Z

Eli.friedman: Add category

* FourCC: LSCR
* Company: LEAD Technologies
* Website: http://www.leadtools.com/help/leadtools/v15/mapping/Features/Codecs.htm
* Samples: (TO ADD; see http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/060393.html)

[[Category:Video Codecs]]

LSCR

2009-02-02T06:19:46Z

Eli.friedman: FourCC

#redirect [[LEAD Screen Capture]]

[[Category:Video FourCCs]]

LEAD Screen Capture

2009-02-02T06:18:04Z

Eli.friedman: Stub

DV video

2009-02-02T06:09:21Z

Eli.friedman: Link to samples

* FOURCCs: CDVC, CUV5, CDVH
* Samples: http://samples.mplayerhq.hu/V-codecs/CDVC/

[[Category:Video Codecs]]

MVXM

2009-02-02T06:05:34Z

Eli.friedman: Add a FourCC

#redirect [[ISO MPEG-4]]

[[Category:Video FourCCs]]

ISO MPEG-4

2009-02-02T06:05:03Z

Eli.friedman: Add a FourCC

* FourCCs: 3IV2, 3iv2, BLZ0, DIGI, DIV1, div1, DIVX, divx, DX50, dx50, DXGM, EM4A, EPHV, FMP4, fmp4, FVFW, HDX4, hdx4, M4S2, m4s2, MP4S, mp4s, MP4V, mp4v, MVXM, RMP4, SEDG, SMP4, UMP4, WV1F, XVID, XviD, xvid, XVIX
* Matroska CodecIDs: V_MPEG4/ISO/SP (Simple Profile), V_MPEG4/ISO/ASP (Advanced Simple Profile)
* Samples:
** 3IV2: http://samples.mplayerhq.hu/V-codecs/3iv2/
** BLZ0: http://samples.mplayerhq.hu/V-codecs/BLZ0/
** DCOD: http://samples.mplayerhq.hu/V-codecs/DCOD/
** DIGI: http://samples.mplayerhq.hu/V-codecs/DIGI/
** DX50: http://samples.mplayerhq.hu/V-codecs/DX50-DivX5/
** DXGM: http://samples.mplayerhq.hu/V-codecs/DXGM/
** EM4A: http://samples.mplayerhq.hu/V-codecs/EM4A/
** FVFW: http://samples.mplayerhq.hu/V-codecs/FVFW/
** M4S2: http://samples.mplayerhq.hu/V-codecs/M4S2/
** MP4S: http://samples.mplayerhq.hu/V-codecs/MP4S/
** RMP4: http://samples.mplayerhq.hu/V-codecs/RMP4/
** SEDG: http://samples.mplayerhq.hu/V-codecs/SEDG/
** SMP4: http://samples.mplayerhq.hu/V-codecs/SMP4/
** UMP4: http://samples.mplayerhq.hu/V-codecs/UMP4/
** WV1F: http://samples.mplayerhq.hu/V-codecs/WV1F/
** XVID: http://samples.mplayerhq.hu/V-codecs/XVID/

'''MPEG-4 part 2''' video. Different encoders use different FourCCs to identify MPEG-4 content in AVI files, with DIVX, XVID, DX50, and FMP4 being most common. Strictly speaking, some of these FourCCs should refer only to simple profile rather than advanced simple profile, but this can not be relied upon.

This does not include [[H.264]] video ([[MPEG-4 part 10]]).

In particular, specifically for FMP4 fourcc, accordingly with MPlayer FAQ :

Q:
Why do third-party players fail to play MPEG-4 movies encoded by MEncoder versions later than 1.0pre7?

A:
libavcodec, the native MPEG-4 encoding library usually shipped with MEncoder, used to set the FourCC to 'DIVX' when encoding MPEG-4 videos (the FourCC is an AVI tag to identify the software used to encode and the intended software to use for decoding the video). This led many people to think that libavcodec was a DivX encoding library, when in fact it is a completely different MPEG-4 encoding library which implements the MPEG-4 standard much better than DivX does. Therefore, the new default FourCC used by libavcodec is 'FMP4', but you may override this behavior using MEncoder's -ffourcc option. You may also change the FourCC of existing files in the same way:

mencoder input.avi -o output.avi -ovc copy -oac copy -ffourcc XVID

Note that this will set the FourCC to XVID rather than DIVX. This is recommended as DIVX FourCC means DivX4, which is a very basic MPEG-4 codec, whereas DX50 and XVID both mean full MPEG-4 (ASP). Therefore, if you change the FourCC to DIVX, some bad software or hardware players may choke on some advanced features that libavcodec supports, but DivX doesn't; on the other hand XviD is closer to libavcodec in terms of functionality, and is supported by all decent players.

Because of this annoying detail, third-party software may fail to decode video that has been encoded with software based on a recent libavcodec, such as VLC.
Modifying the fourcc with 'DX50' or 'XVID', for example, should resolve the problem.

== See also ==
* [[H.263]]

[[Category:Video Codecs]]

IJPG

2009-02-02T06:01:21Z

Eli.friedman: Add FourCC

#redirect: [[Motion JPEG]]

[[Category:Video FourCCs]]

Motion JPEG

2009-02-02T06:00:46Z

Eli.friedman: Add FourCC to list

* FourCCs: AVDJ, AVID, AVRn, dmb1, IJPG, MJPG, mjpa, mjpb
* Company: [[Independent JPEG Group]], [[Pegasus Imaging]]

Motion JPEG is a sub-category of motion video codecs where successive frames are encoded using the standard [[JPEG]] algorithm. No interframe compression is performed and the resulting encoded data generally does not achieve the same level of compression as a codec using interframe techniques. However, decompression is usually faster and any frame can be referenced independently since there are no dependencies on other frames. Plus, there are fewer legal caveats when using the open JPEG standard.

[[Category:Incomplete Video Codecs]]
[[Category:Video Codecs]]

Sunplus JPEG

2009-02-02T05:37:55Z

Eli.friedman: A bit more info about FourCCs

* FourCC: SP54 (and per MPlayer docs, also SP53, SP55, SP56, SP57, SP58)
* Samples: http://samples.mplayerhq.hu/V-codecs/SP5x/

An [[MJPEG]] variant with data rearranged in a slightly unusual manner; per MPlayer documentation, this codec is used by the software for Aiptek MegaCam.

[[Category:Video Codecs]]

SP54

2009-02-02T05:36:43Z

Eli.friedman: FourCC

#REDIRECT [[Sunplus JPEG]]

[[Category:Video FourCCs]]

SP53

2009-02-02T05:35:34Z

Eli.friedman: FourCC

#REDIRECT [[Sunplus JPEG]]

[[Category:Video FourCCs]]

MOHD

2009-02-02T05:33:46Z

Eli.friedman: Fix FourCC redirect

#REDIRECT [[Mobiclip Video Codec]]

[[Category:Video FourCCs]]

Sunplus JPEG

2009-02-02T05:29:25Z

Eli.friedman: Fix wikilink

* FourCC: SP53, SP54, SP55, SP56, SP57, SP58
* Samples: http://samples.mplayerhq.hu/V-codecs/SP5x/

An [[MJPEG]] variant with data rearranged in a slightly unusual manner; per MPlayer documentation, this codec is used by the software for Aiptek MegaCam.

[[Category:Video Codecs]]

Sunplus JPEG

2009-02-02T05:29:02Z

Eli.friedman: Stub

* FourCC: SP53, SP54, SP55, SP56, SP57, SP58
* Samples: http://samples.mplayerhq.hu/V-codecs/SP5x/

An [MJPEG] variant with data rearranged in a slightly unusual manner; per MPlayer documentation, this codec is used by the software for Aiptek MegaCam.

[[Category:Video Codecs]]

MOHD

2009-01-28T16:15:03Z

Eli.friedman: Redirect for MOHD FourCC

#REDIRECT [[Mobiclip Video Codec]]

Escape 130

2008-06-22T18:16:21Z

Eli.friedman:

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt (The referenced document was used as a reference for a lot of the description here, but note that the Pb/Pr adjustment table described there has errors! The tables on this page are correct.)

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

The following is a spec for the Escape 130 codec; this is accurate as far as I know, but it is possible there are errors.

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the base sample, which provides more resolution.

XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; possibly to reduce blockiness? That said, I think this adjustment is too small to be visible.

XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in bit 17 of the header that allows selecting an alternate colorspace, but I don't know of any samples.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value.

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-06-22T17:53:51Z

Eli.friedman: /* Colorspace and Organization */

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.

XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in bit 17 of the header that allows selecting an alternate colorspace, but I don't know of any samples.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value.

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-06-22T17:44:54Z

Eli.friedman: /* Encoding */

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.

XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in but 17 of the header that allows selecting an alternate colorspace.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value.

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-06-22T17:43:39Z

Eli.friedman: /* Colorspace and Organization */

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.

XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in but 17 of the header that allows selecting an alternate colorspace.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. (XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-04-03T06:05:47Z

Eli.friedman:

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, the default pattern is a pattern which affects the Cb and Cr channels; this doesn't really make much sense to me, though.

XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there might be.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. (XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-04-03T05:53:14Z

Eli.friedman: /* Colorspace and Organization */ Wording change, plus explain FIXME a bit

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, the default pattern is a pattern which affects the Cb and Cr channels; this doesn't really make much sense to me, though.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. (XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-04-03T05:25:40Z

Eli.friedman: Fix up intensity pattern information

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. (XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====

The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.

======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======

This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.

{| border="1"
|-
! Code
! Top left
! Top right
! Bottom left
! Bottom right
|-
| 000000
| 0
| 0
| 0
| 0
|-
| 000001
| -1
| 1
| 0
| 0
|-
| 000010
| 1
| -1
| 0
| 0
|-
| 000011
| -1
| 0
| 1
| 0
|-
| 000100
| -1
| 1
| 1
| 0
|-
| 000101
| 0
| -1
| 1
| 0
|-
| 000110
| 1
| -1
| 1
| 0
|-
| 000111
| -1
| -1
| 1
| 0
|-
| 001000
| 1
| 0
| -1
| 0
|-
| 001001
| 0
| 1
| -1
| 0
|-
| 001010
| 1
| 1
| -1
| 0
|-
| 001011
| -1
| 1
| -1
| 0
|-
| 001100
| 1
| -1
| -1
| 0
|-
| 001101
| -1
| 0
| 0
| 1
|-
| 001110
| -1
| 1
| 0
| 1
|-
| 001111
| 0
| -1
| 0
| 1
|-
| 010000
| 0
| 0
| 0
| 0
|-
| 010001
| 1
| -1
| 0
| 1
|-
| 010010
| -1
| -1
| 0
| 1
|-
| 010011
| -1
| 0
| 1
| 1
|-
| 010100
| -1
| 1
| 1
| 1
|-
| 010101
| 0
| -1
| 1
| 1
|-
| 010110
| 1
| -1
| 1
| 1
|-
| 010111
| -1
| -1
| 1
| 1
|-
| 011000
| 0
| 0
| -1
| 1
|-
| 011001
| 1
| 0
| -1
| 1
|-
| 011010
| -1
| 0
| -1
| 1
|-
| 011011
| 0
| 1
| -1
| 1
|-
| 011100
| 1
| 1
| -1
| 1
|-
| 011101
| -1
| 1
| -1
| 1
|-
| 011110
| 0
| -1
| -1
| 1
|-
| 011111
| 1
| -1
| -1
| 1
|-
| 100000
| 0
| 0
| 0
| 0
|-
| 100001
| -1
| -1
| -1
| 1
|-
| 100010
| 1
| 0
| 0
| -1
|-
| 100011
| 0
| 1
| 0
| -1
|-
| 100100
| 1
| 1
| 0
| -1
|-
| 100101
| -1
| 1
| 0
| -1
|-
| 100110
| 1
| -1
| 0
| -1
|-
| 100111
| 0
| 0
| 1
| -1
|-
| 101000
| 1
| 0
| 1
| -1
|-
| 101001
| -1
| 0
| 1
| -1
|-
| 101010
| 0
| 1
| 1
| -1
|-
| 101011
| 1
| 1
| 1
| -1
|-
| 101100
| -1
| 1
| 1
| -1
|-
| 101101
| 0
| -1
| 1
| -1
|-
| 101110
| 1
| -1
| 1
| -1
|-
| 101111
| -1
| -1
| 1
| -1
|-
| 110000
| 0
| 0
| 0
| 0
|-
| 110001
| 1
| 0
| -1
| -1
|-
| 110010
| 0
| 1
| -1
| -1
|-
| 110011
| 1
| 1
| -1
| -1
|-
| 110100
| -1
| 1
| -1
| -1
|-
| 110101
| 1
| -1
| -1
| -1
|-
| 110110
| 0
| 0
| 0
| 0
|-
| 110111
| 0
| 0
| 0
| 0
|-
| 111000
| 0
| 0
| 0
| 0
|-
| 111001
| 0
| 0
| 0
| 0
|-
| 111010
| 0
| 0
| 0
| 0
|-
| 111011
| 0
| 0
| 0
| 0
|-
| 111100
| 0
| 0
| 0
| 0
|-
| 111101
| 0
| 0
| 0
| 0
|-
| 111110
| 0
| 0
| 0
| 0
|-
| 111111
| 0
| 0
| 0
| 0
|}

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

Escape 130

2008-04-03T02:47:25Z

Eli.friedman: Some small, but important, corrections/clarifications

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. (XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)

There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for intensity-pattern encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
(XXX Table is a mess/unwikified; view the source to see it. I'm not going to bother reformatting it until I have some confidence that it's accurate.)


(TODO: Finish decoder and check that everything I've said is actually accurate)

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

Escape 130

2008-04-02T01:48:51Z

Eli.friedman: /* Table for Cb/Cr adjustment codes */ Finally figured out the right Cr codes

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus a difference pattern for the individual pixels, one just encodes a base value (XXX with a flat pattern?), one encodes a difference from the previous values, and one is just an indicator to use the values from the previous block.

There are three formats for the Cb and Cr values: one encodes the values for the block, and one encodes an adjustment for the previous block, and one is just an indicator to use the values from the previous block.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 1
|-
| 100
| -1
| 0
|-
| 101
| -1
| -1
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for 4-color encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
(XXX Table is a mess/unwikified; view the source to see it. I'm not going to bother reformatting it until I have some confidence that it's accurate.)


(TODO: Finish decoder and check that everything I've said is actually accurate)

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

Escape 130

2008-04-02T00:58:08Z

Eli.friedman: Comment out pattern codes

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus a difference pattern for the individual pixels, one just encodes a base value (XXX with a flat pattern?), one encodes a difference from the previous values, and one is just an indicator to use the values from the previous block.

There are three formats for the Cb and Cr values: one encodes the values for the block, and one encodes an adjustment for the previous block, and one is just an indicator to use the values from the previous block.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
(XXX I'm almost certain the Cr column is wrong!)
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 0
|-
| 100
| -1
| -1
|-
| 101
| -1
| -2
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for 4-color encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
(XXX Table is a mess/unwikified; view the source to see it. I'm not going to bother reformatting it until I have some confidence that it's accurate.)


(TODO: Finish decoder and check that everything I've said is actually accurate)

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

Escape 130

2008-04-02T00:55:11Z

Eli.friedman: Wikifying + warning

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

'''The following is a work-in-progress spec for the Escape 130 codec; it is likely to be inaccurate!'''

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus a difference pattern for the individual pixels, one just encodes a base value (XXX with a flat pattern?), one encodes a difference from the previous values, and one is just an indicator to use the values from the previous block.

There are three formats for the Cb and Cr values: one encodes the values for the block, and one encodes an adjustment for the previous block, and one is just an indicator to use the values from the previous block.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
(XXX I'm almost certain the Cr column is wrong!)
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 0
|-
| 100
| -1
| -1
|-
| 101
| -1
| -2
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for 4-color encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
{| border="1"
|-
! Code
! Strength
|-
| 00
| 2
|-
| 01
| 4
|-
| 10
| 10
|-
| 11
| 20
|}

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
{ {0, 0, 0, 0},
{-1, 1, 0, 0},
{1, -1, 0, 0},
{-1, 0, 1, 0},
{-1, 1, 1, 0},
{0, -1, 1, 0},
{1, -1, 1, 0},
{-1, -1, 1, 0},
{1, 0, -1, 0},
{0, 1, -1, 0},
{1, 1, -1, 0},
{-1, 1, -1, 0},
{1, -1, -1, 0},
{-1, 0, 0, 1},
{-1, 1, 0, 1},
{0, -1, 0, 1},

{0, 0, 0, 0},
{1, -1, 0, 1},
{-1, -1, 0, 1},
{-1, 0, 1, 1},
{-1, 1, 1, 1},
{0, -1, 1, 1},
{1, -1, 1, 1},
{-1, -1, 1, 1},
{0, 0, -1, 1},
{1, 0, -1, 1},
{-1, 0, -1, 1},
{0, 1, -1, 1},
{1, 1, -1, 1},
{-1, 1, -1, 1},
{0, -1, -1, 1},
{1, -1, -1, 1},

{0, 0, 0, 0},
{-1, -1, -1, 1},
{1, 0, 0, -1},
{0, 1, 0, -1},
{1, 1, 0, -1},
{-1, 1, 0, -1},
{1, -1, 0, -1},
{0, 0, 1, -1},
{1, 0, 1, -1},
{-1, 0, 1, -1},
{0, 1, 1, -1},
{1, 1, 1, -1},
{-1, 1, 1, -1},
{0, -1, 1, -1},
{1, -1, 1, -1},
{-1, -1, 1, -1},

{0, 0, 0, 0},
{1, 0, -1, -1},
{0, 1, -1, -1},
{1, 1, -1, -1},
{-1, 1, -1, -1},
{1, -1, -1, -1} };

(TODO: Finish decoder and check that everything I've said is actually accurate)
(TODO: Wikify)

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

ARMovie

2008-04-01T23:25:58Z

Eli.friedman:

* Extensions: rpl
* Technical Description: [http://multimedia.cx/AE7doc.txt http://multimedia.cx/AE7doc.txt]
* Samples: [http://samples.mplayerhq.hu/game-formats/rpl/ http://samples.mplayerhq.hu/game-formats/rpl/]

ARMovie is ostensibly a multimedia container format used on Acorn RISC computer systems. Perhaps the most curious aspect of the format's design is its use of variable-length strings in the file header.

While apparently designed as a general container format, its most most notable use is in various [[Eidos Interactive]] computer games (using the extension rpl for Replay) including the Tomb Raider series. These [[FMV]] files contain video encoded with the [[ESCAPE]] video codec, and the audio is either uncompressed PCM or a custom [[IMA ADPCM]] variant.

== PC Games That Use RPL Files ==

* [http://www.mobygames.com/game/big-red-racing Big Red Racing] ([[Escape 122]])
* [http://www.mobygames.com/game/windows/fighting-force Fighting Force] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/ian-livingstones-deathtrap-dungeon Ian Livingstone's Deathtrap Dungeon] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/joint-strike-fighter-jsf Joint Strike Fighter] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/legacy-of-kain-soul-reaver Legacy of Kain: Soul Reaver] ([[Escape 130]])
* [http://www.mobygames.com/game/dos/tomb-raider Tomb Raider] ([[Escape 124]])
* [http://www.mobygames.com/game/windows/tomb-raider-ii-the-dagger-of-xian Tomb Raider II] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/tomb-raider-iii-adventures-of-lara-croft Tomb Raider III] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/warzone-2100 Warzone 2100] ([[Escape 130]])

[[Category:Container Formats]]
[[Category:Game Formats]]

ARMovie

2008-04-01T19:22:56Z

Eli.friedman: Small cleanup: audio is definitely IMA ADPCM, patch was integrated into ffmpeg svn

* Extensions: rpl
* Technical Description: [http://multimedia.cx/AE7doc.txt http://multimedia.cx/AE7doc.txt]
* Samples: [http://samples.mplayerhq.hu/game-formats/rpl/ http://samples.mplayerhq.hu/game-formats/rpl/]

ARMovie is ostensibly a multimedia container format used on Acorn RISC computer systems. Perhaps the most curious aspect of the format's design is its use of variable-length strings in the file header.

While apparently designed as a general container format, its most most notable use is in various [[Eidos Interactive]] computer games (using the extension rpl for Replay) including the Tomb Raider series. These [[FMV]] files contain video encoded with the [[ESCAPE]] video codec, and the audio is either uncompressed PCM or a custom [[IMA ADPCM]] variant.

== PC Games That Use RPL Files ==

* [http://www.mobygames.com/game/big-red-racing Big Red Racing] ([[Escape 122]])
* [http://www.mobygames.com/game/windows/fighting-force Fighting Force] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/ian-livingstones-deathtrap-dungeon Ian Livingstone's Deathtrap Dungeon] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/joint-strike-fighter-jsf Joint Strike Fighter] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/legacy-of-kain-soul-reaver Legacy of Kain: Soul Reaver] ([[Escape 130]])
* [http://www.mobygames.com/game/dos/tomb-raider Tomb Raider] ([[Escape 124]])
* [http://www.mobygames.com/game/windows/tomb-raider-ii-the-dagger-of-xian Tomb Raider II] ([[Escape 130]])
* [http://www.mobygames.com/game/windows/tomb-raider-iii-adventures-of-lara-croft Tomb Raider III]
* [http://www.mobygames.com/game/windows/warzone-2100 Warzone 2100] ([[Escape 130]])

[[Category:Container Formats]]
[[Category:Game Formats]]

Escape 130

2008-04-01T19:18:58Z

Eli.friedman: Wikifying

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus a difference pattern for the individual pixels, one just encodes a base value (XXX with a flat pattern?), one encodes a difference from the previous values, and one is just an indicator to use the values from the previous block.

There are three formats for the Cb and Cr values: one encodes the values for the block, and one encodes an adjustment for the previous block, and one is just an indicator to use the values from the previous block.

==Encoding details==

====Skip codes====
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

====Block code, Y part====
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

====Block code, Cb/Cr part====
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

====Table for Y adjustment codes====
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

====Table for Cb/Cr adjustment codes====
(XXX I'm almost certain the Cr column is wrong!)
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 0
|-
| 100
| -1
| -1
|-
| 101
| -1
| -2
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for 4-color encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
Code Strength
00 2
01 4
10 10
11 20

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
{ {0, 0, 0, 0},
{-1, 1, 0, 0},
{1, -1, 0, 0},
{-1, 0, 1, 0},
{-1, 1, 1, 0},
{0, -1, 1, 0},
{1, -1, 1, 0},
{-1, -1, 1, 0},
{1, 0, -1, 0},
{0, 1, -1, 0},
{1, 1, -1, 0},
{-1, 1, -1, 0},
{1, -1, -1, 0},
{-1, 0, 0, 1},
{-1, 1, 0, 1},
{0, -1, 0, 1},

{0, 0, 0, 0},
{1, -1, 0, 1},
{-1, -1, 0, 1},
{-1, 0, 1, 1},
{-1, 1, 1, 1},
{0, -1, 1, 1},
{1, -1, 1, 1},
{-1, -1, 1, 1},
{0, 0, -1, 1},
{1, 0, -1, 1},
{-1, 0, -1, 1},
{0, 1, -1, 1},
{1, 1, -1, 1},
{-1, 1, -1, 1},
{0, -1, -1, 1},
{1, -1, -1, 1},

{0, 0, 0, 0},
{-1, -1, -1, 1},
{1, 0, 0, -1},
{0, 1, 0, -1},
{1, 1, 0, -1},
{-1, 1, 0, -1},
{1, -1, 0, -1},
{0, 0, 1, -1},
{1, 0, 1, -1},
{-1, 0, 1, -1},
{0, 1, 1, -1},
{1, 1, 1, -1},
{-1, 1, 1, -1},
{0, -1, 1, -1},
{1, -1, 1, -1},
{-1, -1, 1, -1},

{0, 0, 0, 0},
{1, 0, -1, -1},
{0, 1, -1, -1},
{1, 1, -1, -1},
{-1, 1, -1, -1},
{1, -1, -1, -1} };

(TODO: Finish decoder and check that everything I've said is actually accurate)
(TODO: Wikify)

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

Escape 130

2008-04-01T19:17:40Z

Eli.friedman: Wikifying

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus a difference pattern for the individual pixels, one just encodes a base value (XXX with a flat pattern?), one encodes a difference from the previous values, and one is just an indicator to use the values from the previous block.

There are three formats for the Cb and Cr values: one encodes the values for the block, and one encodes an adjustment for the previous block, and one is just an indicator to use the values from the previous block.

==Encoding details==

======Skip codes======
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

======Block code, Y part======
1SSSSSSDDBBBBB 
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.

011BBBBBB 
B is the base value

010AAA 
A is the code for the adjustment from the previous block's values

00 
Indicator to use the values from the previous block

======Block code, Cb/Cr part======
11BBBBBRRRRR 
B is the Cb value, R is the Cr value

10AAA 
A is the code for the adjustment from the previous block's values

0 
Indicator to use the values from the previous block

======Table for Y adjustment codes======
{| border="1"
|-
! Code
! Adjustment (relative to 6-bit sample)
|-
| 000
| -4
|-
| 001
| -3
|-
| 010
| -2
|-
| 011
| -1
|-
| 100
| 1
|-
| 101
| 2
|-
| 110
| 3
|-
| 111
| 4
|-
|}

======Table for Cb/Cr adjustment codes======
(XXX I'm almost certain the Cr column is wrong!)
{| border="1"
|-
! Code
! Cb Adjustment (relative to 5-bit sample)
! Cr Adjustment (relative to 5-bit sample)
|-
| 000
| 1
| 0
|-
| 001
| 1
| 1
|-
| 010
| 0
| 1
|-
| 011
| -1
| 0
|-
| 100
| -1
| -1
|-
| 101
| -1
| -2
|-
| 110
| 0
| -1
|-
| 111
| 1
| -1
|}

====Tables for 4-color encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
Code Strength
00 2
01 4
10 10
11 20

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
{ {0, 0, 0, 0},
{-1, 1, 0, 0},
{1, -1, 0, 0},
{-1, 0, 1, 0},
{-1, 1, 1, 0},
{0, -1, 1, 0},
{1, -1, 1, 0},
{-1, -1, 1, 0},
{1, 0, -1, 0},
{0, 1, -1, 0},
{1, 1, -1, 0},
{-1, 1, -1, 0},
{1, -1, -1, 0},
{-1, 0, 0, 1},
{-1, 1, 0, 1},
{0, -1, 0, 1},

{0, 0, 0, 0},
{1, -1, 0, 1},
{-1, -1, 0, 1},
{-1, 0, 1, 1},
{-1, 1, 1, 1},
{0, -1, 1, 1},
{1, -1, 1, 1},
{-1, -1, 1, 1},
{0, 0, -1, 1},
{1, 0, -1, 1},
{-1, 0, -1, 1},
{0, 1, -1, 1},
{1, 1, -1, 1},
{-1, 1, -1, 1},
{0, -1, -1, 1},
{1, -1, -1, 1},

{0, 0, 0, 0},
{-1, -1, -1, 1},
{1, 0, 0, -1},
{0, 1, 0, -1},
{1, 1, 0, -1},
{-1, 1, 0, -1},
{1, -1, 0, -1},
{0, 0, 1, -1},
{1, 0, 1, -1},
{-1, 0, 1, -1},
{0, 1, 1, -1},
{1, 1, 1, -1},
{-1, 1, 1, -1},
{0, -1, 1, -1},
{1, -1, 1, -1},
{-1, -1, 1, -1},

{0, 0, 0, 0},
{1, 0, -1, -1},
{0, 1, -1, -1},
{1, 1, -1, -1},
{-1, 1, -1, -1},
{1, -1, -1, -1} };

(TODO: Finish decoder and check that everything I've said is actually accurate)
(TODO: Wikify)

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

Escape 130

2008-04-01T18:31:10Z

Eli.friedman: Massive dump of Escape 130 details (I'll finish wikifying later)

* [[Eidos Technologies]]
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt

Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

==Container==

All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.

Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.

The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.

See the [[ARMovie]] page for a list of games using this codec.

==Bit order==

All numbers in this format are little-endian; this format is bit-oriented,
and the bitstream is parsed in little-endian order. Multi-bit quantities
are stored smallest bit first.

==Header==

The header is 16 bytes long; decoding doesn't require any information from this header.

The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.

==Colorspace and Organization==

Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a YCbCr colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There can be either one or four Y samples for any given block.

XXXFIXME: I've seen various comments involving stuff in an RGB colorspace; I don't know exactly what is going on here, and I'm not going to try and figure it out until I've got the rest of decoding working.

==Encoding==

Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.

A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).

A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)

A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

There are four formats for the Y value(s): one encodes a base value for the block plus a difference pattern for the individual pixels, one just encodes a base value (XXX with a flat pattern?), one encodes a difference from the previous values, and one is just an indicator to use the values from the previous block.

There are three formats for the Cb and Cr values: one encodes the values for the block, and one encodes an adjustment for the previous block, and one is just an indicator to use the values from the previous block.

==Encoding details==

======Skip code======
{| border="1"
|-
!Binary
!Value
|-
| 000000000000XXXXXXXXXXXXXXX (12 zero bits followed by 15 data bits)
| X + 262
|-
| 0000XXXXXXXX (4 zero bits followed by 8 data bits)
| X + 7
|-
| 0XXX (1 zero bit followed by 3 data bits)
| X
|-
| 1 (1 one bit)
| 0
|}

======Block code, Y part======
1SSSSSSDDBBBBB
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.
011BBBBBB
B is the base value
010AAA
A is the code for the adjustment from the previous block's values
00
Indicator to use the values from the previous block

======Block code, Cb/Cr part======
11BBBBBRRRRR
B is the Cb value, R is the Cr value
10AAA
A is the code for the adjustment from the previous block's values
0
Indicator to use the values from the previous block

======Table for Y adjustment codes (adjustments relative to 6-bit sample)======
Code Adjustment
000 -4
001 -3
010 -2
011 -1
100 1
101 2
110 3
111 4

======Table for Cb/Cr adjustment codes (adjustments relative to 5-bit sample)======
(XXX I'm almost certain the Cr column is wrong!)
Code Cb Adjustment Cr Adjustment
000 1 0
001 1 1
010 0 1
011 -1 0
100 -1 -1
101 -1 -2
110 0 -1
111 1 -1

====Tables for 4-color encoding====
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
(XXX Unverified)
Code Strength
00 2
01 4
10 10
11 20

======Pattern codes======
(XXX need to clean up; the codes are listed from 000000 to 110101, the pixels are
listed left to right, top to bottom; zero indicates the base value,
1 indicates a positive adjustment by thestrength value, -1 indicates a
negative adjustment by the strength value.)
(XXX May be wrong)
{ {0, 0, 0, 0},
{-1, 1, 0, 0},
{1, -1, 0, 0},
{-1, 0, 1, 0},
{-1, 1, 1, 0},
{0, -1, 1, 0},
{1, -1, 1, 0},
{-1, -1, 1, 0},
{1, 0, -1, 0},
{0, 1, -1, 0},
{1, 1, -1, 0},
{-1, 1, -1, 0},
{1, -1, -1, 0},
{-1, 0, 0, 1},
{-1, 1, 0, 1},
{0, -1, 0, 1},

{0, 0, 0, 0},
{1, -1, 0, 1},
{-1, -1, 0, 1},
{-1, 0, 1, 1},
{-1, 1, 1, 1},
{0, -1, 1, 1},
{1, -1, 1, 1},
{-1, -1, 1, 1},
{0, 0, -1, 1},
{1, 0, -1, 1},
{-1, 0, -1, 1},
{0, 1, -1, 1},
{1, 1, -1, 1},
{-1, 1, -1, 1},
{0, -1, -1, 1},
{1, -1, -1, 1},

{0, 0, 0, 0},
{-1, -1, -1, 1},
{1, 0, 0, -1},
{0, 1, 0, -1},
{1, 1, 0, -1},
{-1, 1, 0, -1},
{1, -1, 0, -1},
{0, 0, 1, -1},
{1, 0, 1, -1},
{-1, 0, 1, -1},
{0, 1, 1, -1},
{1, 1, 1, -1},
{-1, 1, 1, -1},
{0, -1, 1, -1},
{1, -1, 1, -1},
{-1, -1, 1, -1},

{0, 0, 0, 0},
{1, 0, -1, -1},
{0, 1, -1, -1},
{1, 1, -1, -1},
{-1, 1, -1, -1},
{1, -1, -1, -1} };

(TODO: Finish decoder and check that everything I've said is actually accurate)
(TODO: Wikify)

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