https://wiki.multimedia.cx/api.php?action=feedcontributions&user=Cyx&feedformat=atomMultimediaWiki - User contributions [en]2024-03-29T02:34:27ZUser contributionsMediaWiki 1.39.5https://wiki.multimedia.cx/index.php?title=Delphine_CIN&diff=6113Delphine CIN2006-10-03T13:25:25Z<p>Cyx: </p>
<hr />
<div>* Extension: cin<br />
* Company: [[Delphine Software International]]<br />
<br />
Delphine CIN is an [[FMV]] format used in the DOS version of the game [http://www.mobygames.com/game/fade-to-black Fade To Black].<br />
<br />
The CIN files contains both video and audio data with custom compression methods.<br />
<br />
== Container Format ==<br />
<br />
The layout of a CIN file is :<br />
<br />
struct FileHeader<br />
foreach AnimationFrame {<br />
struct FrameHeader<br />
byte PaletteData[]<br />
byte VideoData[]<br />
byte AudioData[]<br />
}<br />
<br />
All data stored in the file and frame headers is in little endian.<br />
<br />
== File Header ==<br />
<br />
bytes 0- 3 - file signature marker (0x55AA0000)<br />
bytes 4- 7 - maximum size of a video frame<br />
bytes 8- 9 - video frame width<br />
bytes 10-11 - video frame height<br />
bytes 12-15 - audio frame frequency (always 22050)<br />
byte 16 - number of audio frame bits (always 16)<br />
byte 17 - 0 = mono, 1 = stereo (always stereo)<br />
bytes 18-19 - maximum size of a sound frame<br />
<br />
== Frame Header ==<br />
<br />
byte 0 - video frame type<br />
byte 1 - audio frame type<br />
bytes 2- 3 - number of palette colors<br />
bytes 4- 7 - video frame size<br />
bytes 8-11 - audio frame size<br />
bytes 12-15 - frame marker (0xAA55AA55)<br />
<br />
== Video Frame Types ==<br />
<br />
The video frame type field in the frame header specifies which set of decompression routines to use.<br />
<br />
type 9 - RLE decode<br />
type 34 - RLE decode, delta frame<br />
type 35 - Huffman decode, RLE decode<br />
type 36 - Huffman decode, RLE decode, delta frame<br />
type 37 - Huffman decode<br />
type 38 - LZSS decode<br />
type 39 - LZSS decode, delta frame<br />
<br />
== Video Frame Decoders ==<br />
<br />
=== RLE Decoding ===<br />
<br />
The following code is executed until end of data is reached :<br />
<br />
code = get next byte<br />
if (code & 0x80) repeat (code - 0x7f) times the following byte value<br />
else copy the following (code) bytes<br />
<br />
<br />
=== Huffman Decoding ===<br />
<br />
The first operation is to get the code_table :<br />
<br />
code_table = get first 15 bytes<br />
<br />
Then, the following code is executed until end of data is reached :<br />
<br />
code = get next byte<br />
if (code >> 4) == 15 {<br />
b = get next byte<br />
output (code << 4) | (b >> 4)<br />
code = b & 15<br />
} else {<br />
output code_table[code >> 4]<br />
code &= 15<br />
}<br />
if code == 15 {<br />
b = get next byte<br />
output b<br />
} else {<br />
output code_table[code >> 4]<br />
}<br />
<br />
<br />
=== Delta Frame Decoding ===<br />
<br />
Source bytes are just added to destination bytes.<br />
<br />
<br />
=== LZSS Decoding ===<br />
<br />
The following code is executed until end of data is reached :<br />
<br />
code = get_next_byte<br />
foreach (bit in code) {<br />
if (bit is set) {<br />
b = get next byte<br />
output b<br />
} else {<br />
cmd = get next word le<br />
offset = cmd >> 4<br />
size = (cmd & 15) + 2<br />
copy 'size' bytes from (dst - offset - 1) to dst<br />
// note: buffer overlapping is (ab)used to repeat bytes<br />
}<br />
<br />
<br />
== Audio Frame Types ==<br />
<br />
The audio frame type is always equal to 1, which represents 22 KHz, 16 bits mono [[DPCM]].<br />
<br />
The deltas are given by a geometric sequence with a multiplier equal to 32767 ^ (1 / 128).<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Game Formats]]</div>Cyxhttps://wiki.multimedia.cx/index.php?title=Humongous_CUP&diff=6112Humongous CUP2006-10-03T13:24:27Z<p>Cyx: </p>
<hr />
<div>* Extension: cup<br />
* Company: [[Humongous Entertainment]]<br />
* Samples: http://samples.mplayerhq.hu/game-formats/cup/<br />
<br />
Humongous CUP files are used as demo movies for games from Humongous Entertainment. CUP files have the file signature 'BEAN' and are played with an executable called coffee.exe. They appear to contain non-interleaved audio and video data; all of the audio data is stored in the file first and the video data second.<br />
<br />
The source code of a (rather incomplete) player for the CUP format can be found at: http://membres.lycos.fr/cyxdown/scummvm/humongous/<br />
<br />
== Data Format ==<br />
CUP file use both little and big endian numbers. Big endian numbers are used when encoding the chunk size in the chunk preamble. All other multi-byte numbers appear to be stored in little endian format.<br />
<br />
bytes 0-3 chunk type [[FourCC]]<br />
bytes 4-7 chunk size (including this 8-byte preamble)<br />
bytes 8.. chunk payload<br />
<br />
The top-level chunk in a CUP file is the BEAN chunk which encapsulates the entire file and can also serve as a file signature:<br />
<br />
bytes 0-3 'BEAN' FourCC<br />
bytes 4-7 size of entire CUP file (including this preamble)<br />
bytes 8.. CUP file<br />
<br />
Following the BEAN signature is a HEAD chunk with the following format:<br />
<br />
bytes 0-3 'HEAD' FourCC<br />
bytes 4-7 size = 0x0E = 14 bytes<br />
bytes 8-9 playback rate in ms (66 by default)<br />
bytes 10-11 video width<br />
bytes 12-13 video height<br />
<br />
An RGBS chunk often appears after the HEAD chunk in a CUP file. It has the following layout:<br />
<br />
bytes 0-3 'RGBS' FourCC<br />
bytes 4-7 chunk size = 0x0308 = 776 bytes<br />
bytes 8..775 palette entries<br />
<br />
The palette entries are 256 3-byte triplets of red-green-blue palette components. Each component is 8 bits (as opposed to 6 bits which is often seen in palettized formats).<br />
<br />
The RGBS chunk is generally followed by the SFXB chunk which contains audio data. This is the typical hierarchical organization of the SFXB chunk and its constituent chunks:<br />
* SFXB<br />
** WRAP<br />
*** OFFS<br />
*** DATA<br />
*** DATA<br />
*** ..<br />
The SFXB chunk contains its preamble and the WRAP chunk. The WRAP chunk contains its preamble, an OFFS chunk and a series of DATA chunks. The OFFS chunk has the following format:<br />
<br />
bytes 0-3 'OFFS' FourCC<br />
bytes 4-7 chunk size<br />
bytes 8.. DATA chunk offsets<br />
<br />
The DATA chunk offsets are 4-byte numbers stored in little endian format that fill the remainder of the OFFS chunk after the preamble. They indicate the offsets (and, implicitly, the count) of audio DATA chunks. The offsets are relative to the start of the OFFS chunk. It is instructive to note that since the first DATA chunk immediately follows the OFFS chunk, its offset will be the same as the size of the OFFS chunk, though stored in the opposite byte order. For example, if there were only one audio DATA chunk in the file, and the OFFS chunk began at 0x32E:<br />
<br />
0x32E 4F 46 46 53 00 00 00 0C 0C 00 00 00 44 41 54 41 OFFS........DATA<br />
0x33E ....<br />
<br />
The audio DATA chunks usually contain uncompressed [[PCM]] in 8-bit, unsigned format. But they sometimes contain the following hierarchical organizations:<br />
* DATA<br />
** TALK<br />
*** HSHD<br />
*** SDAT<br />
In this case, the DATA chunk contains its preamble and the TALK chunk. The TALK chunk contains its preamble followed by the HSHD and SDAT chunks. The HSHD chunk has the following layout:<br />
<br />
bytes 0-3 'HSHD' FourCC<br />
bytes 4-7 chunk size = 0x18 = 24 bytes<br />
bytes 8-13 unknown<br />
bytes 14-15 sample rate<br />
bytes 16-23 unknown<br />
<br />
The SDAT chunk contains uncompressed, unsigned, 8-bit PCM data.<br />
<br />
After the SFXB is another chunk marked DATA. DATA has many meanings in this formats. This data chunk encapsulates a number of BLOK chunks. This is the hierarchical organization of BLOCK chunk:<br />
* BLOK<br />
** RGBS<br />
** RATE<br />
** SNDE<br />
** TOIL<br />
** FRAM<br />
** SRLE<br />
** WRLE<br />
** LZSS<br />
The RGBS chunk, already described, indicates that the palette can change during playback. The RATE chunk has the following layout:<br />
<br />
bytes 0-3 'RATE'<br />
bytes 4-7 chunk size = 0xA = 10 bytes<br />
bytes 8-9 playback rate in milliseconds<br />
<br />
This chunk allows to change the playback rate of the movie.<br />
<br />
The SNDE chunk has the following format:<br />
<br />
bytes 0-3 'SNDE'<br />
bytes 4-7 chunk size = 0x12 = 18 bytes<br />
bytes 8-11 unknown<br />
bytes 12-13 unknown<br />
bytes 13-15 unknown<br />
bytes 15-17 unknown<br />
<br />
While the purpose of this block is unknown, some of the numbers may reference back into the AUDIO data chunks to specify which piece of audio should be playing at the current time.<br />
<br />
The TOIL chunk allows to execute special operations, it has the following format:<br />
<br />
bytes 0-3 'TOIL'<br />
bytes 4-7 chunk size (variable)<br />
bytes 8-9 number of opcodes<br />
bytes 10- opcodes data<br />
<br />
Each TOIL opcode data has the following format :<br />
byte 0 size of opcode<br />
byte 1 opcode number<br />
<br />
The purpose of each opcode is :<br />
1 stop playback<br />
2 display copyright/information messageBox<br />
3 unknown<br />
4 restart playback<br />
5 disable screen update<br />
6 enable offscreen buffers swapping<br />
7 pause playback at specific frame<br />
<br />
The SRLE, WRLE, FRAM and LZSS chunk types indicate video compression types and will be explained in their own sections.<br />
<br />
== TRLE Compression ==<br />
TRLE (which presumably stands for "transparent run length encoding") is name of the bitmap compression algorithm used in a FRAM chunk.<br />
<br />
== SRLE Compression ==<br />
SRLE is the name of one of the video compression algorithms seen in CUP files. It is suspected to be a simple run length encoding scheme.<br />
<br />
== LZSS (Tri-LZ) Compression ==<br />
LZSS indicates one of the video compression algorithms seen in CUP files. It is a variant of the common [[LZ]] algorithm. An LZSS chunk has the following hierarchical organization:<br />
* LZSS<br />
** LZHD<br />
** DATA<br />
Thus, the LZSS chunk contains its preamble followed by an LZHD chunk and ''(another type of!)'' DATA chunk. The LZHD chunk has the following layout:<br />
<br />
bytes 0-3 'LZHD' FourCC<br />
bytes 4-7 size = 0x10 = 16 bytes<br />
bytes 8-11 compression type<br />
bytes 12-15 size of decompressed data<br />
<br />
The only valid compression type is 0x2000 which indicates the tri-lz method. The DATA chunk contains the compressed data.<br />
<br />
A block of tri-lz compressed data is stored in 3 parts. In a compressed data block, part 1 starts at byte 8. Part 2 starts at the offset formed from bytes 0-3 of the compressed buffer. Part 3 starts at the offset formed from bytes 4-7 of the compressed buffer.<br />
<br />
'''(TODO: finish description)'''<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Undiscovered Game Formats]]<br />
[[Category:Video Codecs]]<br />
[[Category:Undiscovered Video Codecs]]</div>Cyxhttps://wiki.multimedia.cx/index.php?title=DXA&diff=6061DXA2006-09-26T19:36:47Z<p>Cyx: </p>
<hr />
<div>* Extension: DXA<br />
* Company: [[Runesoft GmbH]]<br />
* Samples: http://samples.mplayerhq.hu/game-formats/dxa/<br />
<br />
The DXA format is used for videos in the Amiga and Macintosh versions of the [http://www.mobygames.com/game/feeble-files Feeble Files]. It is basically [[zlib]] compressed video frames, using [[WAV]] format for audio. The Macintosh version uses [[Microsoft ADPCM]] format for the audio.<br />
<br />
The source code of a player for the DXA format can be found at: http://membres.lycos.fr/cyxdown/scummvm/feeble/<br />
<br />
== Data Format ==<br />
All multi-byte numbers are stored in big endian format. A DXA file begins with a video header with is laid out as follows:<br />
<br />
dword Signature;<br />
byte Version;<br />
word Frames;<br />
dword FrameRate;<br />
word Width;<br />
word Height;<br />
<br />
* Signature - File signature 'DEXA'.<br />
* Frames - Number of logical frames.<br />
* FrameRate - can be determined this way:<br />
if (FrameRate > 0)<br />
fps = 1000 / FrameRate;<br />
else if (FrameRate < 0)<br />
fps = 100000 / (-FrameRate);<br />
else<br />
fps = 10;<br />
* Width, Height - Frame dimensions in pixels.<br />
<br />
If the file contains an audio chunk, a [[Microsoft Wave]] file will be appear in its entirety after the video header.<br />
<br />
Following any sound data there will be a sequence of CMAP, FRAM, and NULL chunks. The format of a CMAP chunk is as follows:<br />
<br />
bytes 0-3 chunk [[FourCC]]: 'CMAP'<br />
bytes 4-771 256 3-byte RGB palette triplets<br />
<br />
Each palette component has a full 8-bit range of 0..255. The FRAM chunk is formatted as follows:<br />
<br />
bytes 0-3 chunk FourCC: 'FRAM'<br />
byte 4 compression type<br />
bytes 5-8 chunk size (not including this 9-byte preamble)<br />
bytes 9.. chunk payload<br />
<br />
A NULL frame simply consists of the FourCC 'NULL'. There is no other data associated with it. A NULL frame instructs the decoder not to update the video buffer during this frame.<br />
<br />
== Video Coding ==<br />
Compression method 2 is the standard zlib algorithm. The entire payload data buffer is fed into zlib's inflate() method and the output is the decompressed video frame. That video frame is presented to the user.<br />
<br />
Compression method 3 is the same as method 2. However, the video data is decoded into a temporary buffer. Then, the entire frame is XOR'd against the previous frame and the result is presented to the user.<br />
<br />
Compression methods 4 and 6 are unknown. Compression methods 5 and 7 are the same as methods 4 and 6, respectively, but the decoded data is XOR'd against the previously decoded frame, as is done with method 3.<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Video Codecs]]</div>Cyxhttps://wiki.multimedia.cx/index.php?title=SEQ&diff=6060SEQ2006-09-26T19:36:08Z<p>Cyx: simplified RLE unpacking</p>
<hr />
<div>* Extension: seq<br />
<br />
SEQ files are an [[FMV]] format used in the game [http://www.mobygames.com/game/dos/flashback-the-quest-for-identity Flashback: The Quest for Identity].<br />
<br />
These files always contain one video stream in own format with image size 256x128 and 22 kHz 16-bit mono [[PCM]] audio.<br />
<br />
== File Format ==<br />
Data is stored in 6144-byte frames without any header. Each frame may contain sound data, palette data and up to 3 video frames data.<br />
Frame structure:<br />
<br />
bytes 0- 1 - sound data offset (0 = no sound)<br />
bytes 2- 3 - palette data offset (0 = no palette)<br />
byte 4 - what buffer to use (255 = skip)<br />
byte 5 - frame num 1<br />
byte 6 - frame num 2<br />
byte 7 - frame num 3<br />
bytes 8- 9 - video data offset 1<br />
bytes 10-11 - video data offset 2<br />
bytes 12-13 - video data offset 3<br />
bytes 14-15 - video data end<br />
<br />
== Video Codec ==<br />
Frame data is divided into 8x8 blocks, each block may be compressed with one of four methods. Those 2-bit method indices are packed in 16-bit little-endian words and stored in frame header.<br />
Methods:<br />
* 0 - skip block<br />
* 1 - most advanced coding mode. Data may be packed with RLE scheme described below or vector quantization (lookup table and 1-4 bits on index)<br />
* 2 - raw block<br />
* 3 - partial update of block, data is stored in pairs (skip, value) where skip = (x + y*8 + last*128), if last = 1 then end decoding, else put (value) at position (x,y)<br />
<br />
=== RLE Packing ===<br />
RLE data is also stored operations first, pixel data later. Operation byte consists of two signed nibbles, each meaning:<br />
if (n < 0) then set (-n) pixels to the next value<br />
else read (n) pixels values<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Game Formats]]</div>Cyxhttps://wiki.multimedia.cx/index.php?title=Delphine_CIN&diff=6059Delphine CIN2006-09-26T19:34:08Z<p>Cyx: </p>
<hr />
<div>* Extension: cin<br />
* Company: [[Delphine Software International]]<br />
<br />
Delphine CIN is an [[FMV]] format used in the DOS version of the game [http://www.mobygames.com/game/fade-to-black Fade To Black].<br />
<br />
The CIN files contains both video and audio data with custom compression methods.<br />
<br />
== Container Format ==<br />
<br />
The layout of a CIN file is :<br />
<br />
struct FileHeader<br />
foreach AnimationFrame {<br />
struct FrameHeader<br />
byte PaletteData[]<br />
byte VideoData[]<br />
byte AudioData[]<br />
}<br />
<br />
All data stored in the file and frame headers is in little endian.<br />
<br />
== File Header ==<br />
<br />
bytes 0- 3 - file signature marker (0x55AA0000)<br />
bytes 4- 7 - maximum size of a video frame<br />
bytes 8- 9 - video frame width<br />
bytes 10-11 - video frame height<br />
bytes 12-15 - audio frame frequency (always 22050)<br />
byte 16 - number of audio frame bits (always 16)<br />
byte 17 - 0 = mono, 1 = stereo (always stereo)<br />
bytes 18-19 - maximum size of a sound frame<br />
<br />
== Frame Header ==<br />
<br />
byte 0 - video frame type<br />
byte 1 - audio frame type<br />
bytes 2- 3 - number of palette colors<br />
bytes 4- 7 - video frame size<br />
bytes 8-11 - audio frame size<br />
bytes 12-15 - frame marker (0xAA55AA55)<br />
<br />
== Video Frame Types ==<br />
<br />
The video frame type field in the frame header specifies which set of decompression routines to use.<br />
<br />
type 9 - RLE decode<br />
type 34 - RLE decode, delta frame<br />
type 35 - Huffman decode, RLE decode<br />
type 36 - Huffman decode, RLE decode, delta frame<br />
type 37 - Huffman decode<br />
type 38 - LZSS decode<br />
type 39 - LZSS decode, delta frame<br />
<br />
== Video Frame Decoders ==<br />
<br />
=== RLE Decoding ===<br />
<br />
The following code is executed until end of data is reached :<br />
<br />
code = get next byte<br />
if (code & 0x80) repeat (code - 0x7f) times the following byte value<br />
else copy the following (code) bytes<br />
<br />
<br />
=== Huffman Decoding ===<br />
<br />
The first operation is to get the code_table :<br />
<br />
code_table = get first 15 bytes<br />
<br />
Then, the following code is executed until end of data is reached :<br />
<br />
code = get next byte<br />
if (code >> 4) == 15 {<br />
b = get next byte<br />
output (code << 4) | (b >> 4)<br />
code = b & 15<br />
} else {<br />
output code_table[code >> 4]<br />
code &= 15<br />
}<br />
if code == 15 {<br />
b = get next byte<br />
output b<br />
} else {<br />
output code_table[code >> 4]<br />
}<br />
<br />
<br />
=== Delta Frame Decoding ===<br />
<br />
Source bytes are just added to destination bytes.<br />
<br />
<br />
=== LZSS Decoding ===<br />
<br />
The following code is executed until end of data is reached :<br />
<br />
code = get_next_byte<br />
foreach (bit in code) {<br />
if (bit is set) {<br />
b = get next byte<br />
output b<br />
} else {<br />
cmd = get next word le<br />
offset = cmd >> 4<br />
size = (cmd & 15) + 2<br />
copy 'size' bytes from (dst - offset - 1) to dst<br />
// note: buffer overlapping is (ab)used to repeat bytes<br />
}<br />
<br />
<br />
== Audio Frame Types ==<br />
<br />
The audio frame type is always equal to 1.<br />
<br />
'''TODO add sound compression description (geometric sequence etc.)'''<br />
<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Game Formats]]</div>Cyx