MultimediaWiki - User contributions [en]

Talk:Bink Video

2009-06-28T08:23:49Z

Avenger teambg:

The linux version of BinkPlayer contains the following strings:
D:\Devel\projects\bink\build\temps\lnx\fft.obj
D:\Devel\projects\bink\build\temps\lnx\dct.obj

Probably it is worth to reverse engineer that program?
: The first version had lots more info in it, they forgot to strip it.--[[User:Merbanan|Merbanan]] 13:34, 14 January 2007 (EST)

How can one get the predefined huffman tree data?
--[[User:Avenger teambg|avenger_teambg]] 04:23, 28 June 2009 (EDT)

Bink Container

2009-03-19T15:04:50Z

Avenger teambg: /* Exe files */ better english

''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''

* Extenstions: bik
* Company: [[RAD Game Tools]]
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games

Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.

== File Format ==

'''This description is known to be incomplete.'''

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

Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.

bytes 0-2 file signature ('BIK')
byte 3 Bink Video codec revision (0x62, 0x64, 0x66, 0x67, 0x68, 0x69; b,d,f,g,h,i respectively)
bytes 4-7 file size not including the first 8 bytes
bytes 8-11 number of frames
bytes 12-15 largest frame size in bytes
bytes 16-19 number of frames again?
bytes 20-23 video width (less than or equal to 32767)
bytes 24-27 video height (less than or equal to 32767)
bytes 28-31 video frames per second dividend
bytes 32-35 video frames per second divider
bytes 36-39 video flags
bits 28-31: width and height scaling
1 = 2x height doubled
2 = 2x height interlaced
3 = 2x width doubled
4 = 2x width and height-doubled
5 = 2x width and height-interlaced
bit 20: has alpha plane
bit 17: grayscale
bytes 40-43 number of audio tracks (less than or equal to 256)

for each audio track
two bytes unknown
two bytes audio channels (1 or 2). Not authoritative, see flags below.

for each audio track
two bytes audio sample rate (Hz)
two bytes flags
bit 15: unknown (observed in some samples)
bit 14: unknown (observed in some samples)
bit 13: stereo flag
bit 12: Bink Audio algorithm
1 = use Bink Audio DCT
0 = use Bink Audio FFT

for each audio track
four bytes unknown

Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.

The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.

Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). If bit 0 of an entry is set, that frame is a keyframe; this bit should be masked off to find the actual offset of the frame data in the file.

Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:

for each audio track
four bytes length of audio packet (bytes) plus four bytes.
A value of zero indicates no audio is present for this track.
four bytes number of samples in packet
variable length [[Bink Audio]] packet

variable length [[Bink Video]] packet

== Exe files ==
Bink data can be contained in exe files. To find where to start decoding search for one of 4 id's in the file:
'fKIB'
'gKIB'
'hKIB'
'iKIB'

Note that this is the BIK value in machine order (therefore it appears backwards for x86 binaries).

== External Links ==
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]

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

Electronic Arts

2008-09-15T14:39:25Z

Avenger teambg:

Website: [http://www.ea.com http://www.ea.com]

Big player in the gaming business, bought up [[Westwood Studios]], [[Origin Systems]], Bullfrog, Maxis, BioWare and dozens of other game developers.

They have created various multimedia formats, see [[Electronic Arts Formats]] for details.

Description on EA's internal image/multimedia library: [http://www.cs.ualberta.ca/iip/IIP/C400/Files/2003/Ebinu.pdf http://www.cs.ualberta.ca/iip/IIP/C400/Files/2003/Ebinu.pdf].

[[Category:Multimedia-related Companies]]

Bink Container

2008-04-21T19:45:33Z

Avenger teambg: typo

''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''

* Extenstions: bik
* Company: [[RAD Game Tools]]
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games

Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.

== File Format ==

'''This description is known to be incomplete.'''

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

Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.

bytes 0-2 file signature ('BIK')
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)
bytes 4-7 file size not including the first 8 bytes
bytes 8-11 number of frames
bytes 12-15 largest frame size in bytes
bytes 16-19 number of frames again?
bytes 20-23 video width
bytes 24-27 video height
bytes 28-31 video frames per second dividend
bytes 32-35 video frames per second divider
bytes 36-39 unknown
bytes 40-43 number of audio tracks

for each audio track
two bytes unknown
two bytes audio channels (1 or 2). Not authoritative, see flags below.

for each audio track
two bytes audio sample rate (Hz)
two bytes flags
bit 15: unknown (observed in some samples)
bit 14: unknown (observed in some samples)
bit 13: stereo flag
bit 12: Bink Audio algorithm
1 = use Bink Audio DCT
0 = use Bink Audio FFT

for each audio track
four bytes unknown

The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.

Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.

Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:

for each audio track
four bytes length of audio packet (bytes) plus four bytes.
A value of zero indicates no audio is present for this track.
four bytes number of samples in packet
variable length [[Bink Audio]] packet

variable length [[Bink Video]] packet

== Exe files ==
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:
'fKIB'
'gKIB'
'hKIB'
'iKIB'

Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).

Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.

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

Discrete Cosine Transform

2008-04-21T19:43:18Z

Avenger teambg: typo

:''For the Electronic Arts DCT file format, see [[Electronic Arts DCT]].''

A '''discrete cosine transform''' (DCT) is a Fourier-related transform similar to the [[discrete Fourier transform]] (DFT), but using only real numbers. DCTs are equivalent to DFTs of roughly twice the length, operating on real data with even symmetry (since the Fourier transform of a real and even function is real and even), where in some variants the input and/or output data are shifted by half a sample. There are eight standard DCT variants, of which four are common.

[[Category:Compression Theory]]

Talk:Bink Container

2008-04-16T13:59:57Z

Avenger teambg:

Original:
bytes 28-31 video frames per second
bytes 32-35 image format

Suggested:
bytes 28-35 video frames per second in a/b format (real number)
bytes 28-31 a
bytes 32-35 b

I noticed numbers like:
6025/201
2997/100
Both are very close to 30 (a usual framerate for videos)

There is another error in the optional audio header:
Original:
bytes 44-45 audio channels (1 or 2)
bytes 46-47 unknown

Suggested:
bytes 44-45 unknown (but somehow related to samplerate)
bytes 46-47 audio channels (1 or 2)

* The framerate correction is indeed right. --[[User:VAG|VAG]] 19:23, 25 December 2006 (EST)

I'm not sure the audio sample rate is quite correct. I get slightly strange values like 44000 (logo_lucas.bik) and 22500 (AnivisionLogo.bik) on some of the samples provided, although I get sensible ones like 44100 (original.bik) on others... I'm not an audio expert by any means, but it seems strange that these values are so close to multiples of common audio sample rates and yet not equal to them. --[[User:DrV|DrV]] 00:25, 6 January 2007 (EST)

Isn't it 22050? That would be half of 44100 :) And probably because it is mono. I could be mistaken...

* Yes, 22050 and 44100 would be the ones I'd expect to see, but some of the files contain ones close to those but not equal. --[[User:DrV|DrV]]

logo_legal.bik (from the samples) has no audio (according to the headers), yet it seems its frame data doesn't start with 0 dwords.

User talk:Suxen drol

2008-04-08T19:55:52Z

Avenger teambg:

Please don't forget to categorize pages when you create new ones. You can do this by adding <nowiki>[[Category:foo bar]]</nowiki> to the bottom of the page. Thanks -- [[User:DonDiego|DonDiego]] 09:37, 30 March 2006 (EST)

== bink video ==

praises for the work on the bik format --[[User:Avenger teambg|Avenger teambg]] 10:27, 7 April 2008 (EDT)

Which version of BIK are you yeaning for? --[[User:Suxen drol|Suxen drol]] 05:33, 8 April 2008 (EDT)

The one used in IWD2, FOURCC: BIKi. --[[User:Avenger teambg|Avenger teambg]] 06:51, 8 April 2008 (EDT)

User talk:Suxen drol

2008-04-08T10:51:37Z

Avenger teambg: /* bink video */

Please don't forget to categorize pages when you create new ones. You can do this by adding <nowiki>[[Category:foo bar]]</nowiki> to the bottom of the page. Thanks -- [[User:DonDiego|DonDiego]] 09:37, 30 March 2006 (EST)

== bink video ==

praises for the work on the bik format --[[User:Avenger teambg|Avenger teambg]] 10:27, 7 April 2008 (EDT)

Which version of BIK are you yeaning for? --[[User:Suxen drol|Suxen drol]] 05:33, 8 April 2008 (EDT)

The one used in IWD2, gotta check its exact magic cookie, but i guess it is a relatively recent one. --[[User:Avenger teambg|Avenger teambg]] 06:51, 8 April 2008 (EDT)

User talk:Avenger teambg

2008-04-08T10:48:58Z

Avenger teambg:

Though i'm an IE modder, the rogue rebalancing mod isn't my work.
I play bigger, working on an IE clone :>
That's why i'm interested in the bink and interplay acm formats.

User:Avenger teambg

2008-04-08T10:47:29Z

Avenger teambg:

GemRB project leader (Infinity Engine rewrite): http://sourceforge.net/projects/gemrb

User talk:Suxen drol

2008-04-07T14:27:46Z

Avenger teambg: bink video

PIX FMT YUV420P

2007-06-03T15:03:44Z

Avenger teambg: fixed category link

PIX_FMT_YUV420P contains three channels (or components):
* Y' ([[luminance]]) channel
* Cb ([[chrominance]] blue) channel
* Cr ([[chrominance]] red) channel.

The [[chrominance]] is [[subsampled]] using the '''420''' scheme:

Note: Be careful not to confuse this pixel format with [[PIX_FMT_YUVJ420P]].

YCbCr 4:2:0 indicates a planar [[YCbCr]] colorspace where a 2x2 block of pixels in an image is represented by 4 Y samples, 1 for each pixel, but all 4 pixels share a Cb sample and a Cr sample.

Note: The '''P''' in YUV420P indicates '''[[planar]]''' not [[progressive]] or [[palette]] or [[packed]].

It has the following characteristics:
* YUV colorspace.
* 12bits per pixel '''average'''.

[[Category:Pixel Formats]]
[[Category:FFmpeg Pixel Formats]]

Lossless compression

2007-05-29T16:07:30Z

Avenger teambg:

A lossless compression method reduces the size of the data with no lost information. The decompressed data is exactly the same as the original. This is typically not as efficient as [[lossy]] compression due to the restrictions of retaining all information.

Lossless compression

2007-05-29T16:05:27Z

Avenger teambg:

A lossless compression method reduces the size of the image with no lost information. The decompressed image is exactly the same as the original image. A lossless compression scheme retains all the information but typically is not as efficient due to the restrictions of retaining all data.

Interplay MVE

2007-05-12T12:53:00Z

Avenger teambg:

* Extension: mve
* Company: [[Interplay Entertainment]]
* Samples: http://samples.mplayerhq.hu/game-formats/interplay-mve/]
* Sample Parser: [http://multimedia.cx/parse-ipmve.c http://multimedia.cx/parse-ipmve.c]

Interplay MVE is a full motion video format used in a number of PC games published by Interplay. It combines a custom [[Interplay Video|video codec]] and either [[PCM]] or a [[Interplay DPCM|custom DPCM]] coding scheme for audio.

== Credits ==

The technical description on this page is originally based on an anonymous and thorough description of the format published when Interplay was proactive about pursuing individuals who tried to understand their data format. "BG" refers to the PC game Baldur's Gate, the apparent focus of the author's analysis.

== Interplay MVE Format==

Throughout this description, a "word" is a 16-bit value. All values are little-endian, unless otherwise specified.

The high-level format of an Interplay MVE file is a small header, followed by variable sized stream chunks; each stream chunk consists of a word giving the length of the chunk, and another giving the type, followed by a stream of 1 or more stream opcodes, which consist of a two-word count for the length of the
stream opcode, a single byte for the type, a single byte (which I believe to be a "version" field, to allow backwards compatibility ), and then variable data depending on the type of opcode.

So, just to make sure that's clear, we've got the header, followed by a 2-level hierarchical structure:

|| CHUNK1 || CHUNK2 ||
header || op1 || op2 || op3 || op4 || op1 || op2 || op3 || op4 || ...

=== Header ===

The Header of an Interplay MVE file must start with the sequence of bytes:

"Interplay MVE File\x1A\0"

where \x1A represents ASCII 0x1a (^Z), the old DOS end-of-file character, and \0 represents ASCII 0x00 (NUL). The reason for this is then, under DOS, if you do:

C:\>TYPE foobar.MVE

you'll see

Interplay MVE File

After these 20 bytes, there are 6 more bytes, which I believe are either a file format version, a "magic" number, or were, once upon a time, parameters. In modern Interplay games, these parameters appear to need to be hard-coded. They take the form of 3 words:

001a 0100 1133

Immediately following this are the chunks.

=== Chunks ===

Each chunk consists of a word giving the total length of the data contained in the chunk, and another word which represents the type of the chunk. After these four bytes (which are NOT included in the chunk length), comes the chunk data. The types of chunks I know about (i.e. which are used in BG/BG2 movies that I've examined; the chunk types are not used at all in the movie playback code in BG/BG2) are:

0000: initialize audio
0001: audio only chunk (or maybe only used for audio pre-buffering)
0002: initialize video
0003: video chunk (usually includes audio. possibly always includes audio)
0004: shutdown chunk
0005: end chunk

I don't know why an "end chunk" is needed, since the "shutdown chunk" seems to do that job nicely. The "end chunk" appears to contain no opcodes.

=== Opcodes ===

The opcodes I've observed range from 0x00 to 0x15. Of these, the current code used in BG/BG2 uses only from 0x00 through 0x11, so any guesses as to the function of 0x12 through 0x15 would be merely speculation. I have no idea what any of these opcodes are used for. But, again, since they are unused in
the BG/BG2 movie player code, they are unnecessary for playback.

==== Opcode 0x00: End Of Stream ====

No data associated with this. When this opcode is seen, the playback of the movie stops immediately.

==== Opcode 0x01: End Of Chunk ====
All this opcode does in theory is to terminate a chunk. In practice, it signals the code to fetch and decode the next chunk.

==== Opcode 0x02: Create Timer ====

DWORD timer rate
WORD timer subdivision

This sets up the timer that drives the animation. Basically, every time the timer expires, it should be starting to pump out the next frame in order to keep up with the desired frame rate.

The normal values I've seen here are 0x2095 for the timer rate (8341), and 8 for the timer subdivision. What this means in practice is that every 8*8341 (=66728) microseconds, it should be ready to send out the next frame. So... 10000000/66728 == 14.9 frames per second typically. The exact purpose for the timer subdivision is unclear to me, but it may be an artifact of earlier methods of timer handling, since some of the code here appears to possibly even date back to the DOS days.

==== Opcode 0x03: Initialize Audio Buffers ====

version 0:
WORD (unknown)
WORD flags
WORD sample rate
WORD min buffer length

version 1:
WORD (unknown)
WORD flags
WORD sample rate
DWORD min buffer length

The flags recognized, as of version 0 are:
bit 0: 0=mono, 1=stereo
bit 1: 0=8-bit, 1=16-bit

The flags recognized, as of version 1 are:
bit 0: 0=mono, 1=stereo
bit 1: 0=8-bit, 1=16-bit
bit 2: 0=uncompressed, 1=compressed

Only uncompressed audio is supported in the version 0 opcode. I ''think'' the other 13 bits (14 bits for ver. 0) here may be garbage. Whatever they are, they are not apparently used for the playback engine inside BG/BG2.

The sample rate is the standard sampling rate in kHz; typically 22050 in the BG movies. Buffer length is the size (in bytes) of the buffer that needs to be allocated for the audio. (I don't remember if this is the ''total'' audio buffer size needed, or if this number is a "per-channel" number that needs to be doubled for "stereo" audio streams.) They use 1.5 times the original buffer size in order to have a "safety zone".

I will cover the format of the compressed audio data in the audio data opcode section.

==== Opcode 0x04: Start/Stop Audio ====

This seems to start and/or stop the audio playback. This opcode contains no data.

==== Opcode 0x05: Initialize Video Buffer(s) ====
version 0:
WORD width
WORD height

version 1:
WORD width
WORD height
WORD ?count?

version 2:
WORD width
WORD height
WORD ?count?
WORD true-color

'''(I think width and height are actually expressed as 8x8 pixel blocks. Need to verify. --[[User:Multimedia Mike|Multimedia Mike]] 13:52, 5 February 2006 (EST))'''

Width is the width of the buffer to allocate, and height is the height. Both are given in terms of pixels. Now, the count appears to be used to over-allocate the video buffer. To compute the size to allocate for the video buffer, they take 2 bytes per pixel, and multiply by the height and the width, and then multiply by the count. If scan-line doubling is enabled (which it is not in BG/BG2), it then divides this value by two, on the assumption that there is only enough data for half the resolution. Anyway, the over-allocation may be used to create a larger movie area and pan smoothly or something. I haven't seen a way to use the overallocation with the format details that I've discerned, but the video coding is particularly hairy, as the decoder relies on self-modifying x86 code to function. Yick. Anyway, I'm still in the process of looking for a file that uses over-allocation so that I can figure out exactly why it is used and what it is used for. (Again, this feature doesn't appear to be widely used in the sampling of BG/BG2 movies that I've examined.) Note that an alternate possibility for the usage of the over-allocated space is as scratch space. This possibility will be addressed in the (voluminous!) documentation for opcode 0x11.

==== Opcode 0x06: unknown ====

4 bytes apparently unused?
WORD unknown
WORD unknown
WORD unknown
WORD flip back buffer? (0=no, 1=yes)
bytes unknown

I haven't seen this opcode used in any BG/BG2 movies; however, this may be used for the panning or some clever usage of the over-allocation mentioned in opcode 0x05. If "flip back buffer?" has bit 0 set, it will flip the two allocated buffers before it does whatever it is that it does.

The "whatever it does" appears to be characterized by bulk memory moves, which makes it possible that it _is_ used in conjunction with the over-allocated video buffers.

No "version" check is made for this opcode, which makes me suspect that there is only 1 supported version of this opcode. (version 0, presumably)

==== Opcode 0x07: Send Buffer to Display ====
version 0:
WORD palette start
WORD palette count

version 1:
WORD palette start
WORD palette count
WORD ???

palette start is the index of the first palette entry to be installed before copying from the current back buffer to the display. palette count is the number of palette entries to be installed. As for the mysterious other flag... I am still unclear on its usage. Again, I've seen no example of its usage yet.

==== Opcode 0x08: Audio Frame (data)/Opcode 0x09: Audio Frame (silence) ====
WORD seq-index
WORD stream-mask
WORD stream-len
data audio data (only for Opcode 0x08)

seq-index is the sequential index of this audio chunk, numbered from 0000 (0000 being the first chunk in the audio file). stream-mask works as follows:

A given mve file can contain up to 16 parallel audio streams. Presumably this is for alternate languages. The stream-mask determines which stream(s) a given audio chunk belongs to. So, if bit 0 is set in the stream-mask, it belongs to stream 0. Typically, in the English language version of BG, I've seen the sole audio frame (opcode 8) having bit 0 set, and the next silent frame having all 15 of the other bits set.

So, just to make this clear, what we see is:
opcode 8: idx=0 mask=0x0001 len=0x16d8 data=...
opcode 9: idx=0 mask=0xfffe len=0x16d8

These audio chunks appear to always come in pairs.

stream-len is the total number of samples in the chunk.

For more information on the DPCM format used in Interplay MVE files, see [[Interplay DPCM]].

==== Opcode 0xa: Initialize Video Mode ====
WORD X-resolution
WORD Y-resolution
WORD flags

The usage of the flags field appears to be largely historical. Perhaps with the introduction of DirectX as the underlying medium, rather than the direct graphics hardware manipulation that was, apparently, used in an earlier version, this field is unnecessary. (In fact, in BG, this entire opcode turns into a no-op.) (Note, for the curious: BG actually contains assembly code to do register level manipulation of VGA hardware. Not enough to actually really do much, but it's there, anyway.

==== Opcode 0xb: Create Gradient ====
BYTE baseRB
BYTE numR_RB
BYTE numB_RB
BYTE baseRG
BYTE numR_RG
BYTE numG_RG

I haven't seen this particular opcode used, but it is clear that it generates a gradient palette. It appears that it will generate two gradient palettes, if both count0 and count1 are non-zero. The first gradient is a pure red-blue gradient, and the second a pure red-green gradient. It appears to be designed for EGA/VGA hardware, since it uses 0-63 as the maximum range for a component within a color. The red component of each gradient moves linearly from 0 to 63 within numR_RB (resp. numR_RG) rows, and the blue or green component moves linearly from 0 to 39 within numB_RB (resp numG_RG) columns for the blue or green gradient respectively.

The colors are ordered in row-major ordering, starting at the 'base'th entry. So, if you had:

baseRB=12
numR_RB=5
numB_RB=4

You'd get 20 colors starting at index #12, with a row-major gradient. Specifically you'd see:

( 0,0,0) ( 0,0,13) ( 0,0,26) ( 0,0,39) ; 12...15
(15,0,0) (15,0,13) (15,0,26) (15,0,39) ; 16...19
(31,0,0) (31,0,13) (31,0,26) (31,0,39) ; 20...23
(47,0,0) (47,0,13) (47,0,26) (47,0,39) ; 24...27
(63,0,0) (63,0,13) (63,0,26) (63,0,39) ; 28...31

==== Opcode 0xc: Set Palette ====
WORD pal-start
WORD pal-count
data pal-data

* pal-start indicates the first palette entry to fill
* pal-count indicates the number of palette entries to fill
* pal-data is the palette data, 3 bytes per palette entry, packed as RGBRGBRGB

Note that the palette components are 6-bit VGA palette values and only range from 0..63. The values must be shifted to display properly in higher resolution color formats where RGB components are generally 8 bits.

==== Opcode 0xd: Set Palette Entries Compressed ====
data compressed palette data

This doesn't appear to have been used in the BG movies. This is a series of 32 entries of the following form:

<byte> <RGB> <RGB> ... <RGB>

Where there are between 0 and 8 <RGB> values, taking 3 bytes apiece.

Each bit in the preceding byte determines which of the 8 palette entries have an RGB value stored for them, with the least significant bit corresponding to the first entry in the group of 8. So, in order to set only the 240th entry in the palette, the data would be:

00 ;; 00-07
00 ;; 08-0f
00 ;; 10-17
00 ;; 18-1f
00 ;; 20-27
00 ;; 28-2f
00 ;; 30-37
00 ;; 38-3f
00 ;; 40-47
00 ;; 48-4f
00 ;; 50-57
00 ;; 58-5f
00 ;; 60-67
00 ;; 68-6f
00 ;; 70-77
00 ;; 78-7f
00 ;; 80-87
00 ;; 88-8f
00 ;; 90-97
00 ;; 98-9f
00 ;; a0-a7
00 ;; a8-af
00 ;; b0-b7
00 ;; b8-bf
00 ;; c0-c7
00 ;; c8-cf
00 ;; d0-d7
00 ;; d8-df
01 rr gg bb ;; e0-e7
00 ;; e8-ef
00 ;; f0-f7
00 ;; f8-ff

Giving:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 01 rr gg bb
00 00 00

35 bytes of data instead of 768 to store the whole palette.

==== Opcode 0xe: ??? ====
data unknown length

I haven't encountered this value before. What it does is set a pointer to an array of words used during decoding of data using the 0x10 opcode, which I have also not encountered.

I'm still working on figuring out the use of this opcode and the 0x10 opcode, but they don't appear to be used in the BG movies, again. See my comments at opcode 0x10 for more details.

==== Opcode 0xf: Set Decoding Map ====
data decoding map

The decoding map is a particular data block used in the decoding of video frames, as encoded via opcode 0x11. I'll cover it in detail when I get to opcode 0x11.

==== Opcode 0x10: ??? ====

This is another means of storing video data. I haven't seen it used yet, and am still sorting through the details. This seems to be tied in with the issue of multiple pages of video memory, as with opcode 6 and the "count" field of opcode 5.

Note that this opcode makes use of 3 (!) data streams, as opposed to 2 for 0x11. Even so, it appears to be a much simpler encoding. The data streams used for this are the most recent 0xe opcode data stream, the most recent 0xf opcode data stream, and this opcode's data stream.

There appears to be verbatim pixel data encoded in the 0x10 stream, but the which pixels have been stored, among other things, is determined by the other streams. It also appears that in this stream all pixel manipulation is done in 8-pixel wide and 8-pixel tall units. This is set-up to loop first over each column, then over each row, then finally over each page:

foreach page
foreach row
foreach col
decode opcode data

If I can find an example of one of these files to mess around with, I will complete my analysis of this opcode.

==== Opcode 0x11: Video Data ====

Ok, this is the big killer opcode. See [[Interplay Video]] for a detailed description of the video coding format.

==== Opcode 0x12 ====
Not observed in BG movies, and not used by the player.

==== Opcode 0x13 ====
Unknown. Used in the BG movies, but not used by the player. Appears to always(?) have 0x84 bytes of data. This is a recurrent opcode, appearing in most, if not all video chunks.

==== Opcode 0x14 ====
Not observed in BG movies, and not used by the player.

==== Opcode 0x15 ====
Unknown. Used in the BG movies, but not used by the player. Appears to always(?) have 4 bytes of data. This one appears in the "video initialization chunk"

=== Typical Chunk Formation ===

Audio chunks:
opcode 0x8
opcode 0x9

Video chunks:
opcode 0x2
opcode 0xf
opcode 0x8
opcode 0x9
opcode 0x11
opcode 0x13
opcode 0x4
opcode 0x7

video init chunk (type 2):
opcode 0xa
opcode 0x5
opcode 0xc
opcode 0x15

audio init chunk (type 0):
opcode 0x3

== PC Games Using Interplay MVE Files ==

* [http://www.mobygames.com/game_group/sheet/gameGroupId,287/ Baldur's Gate]
* [http://www.mobygames.com/game/dos/descent-ii Descent II]
* Descent II: Destination Quartzon 3D
* [http://www.mobygames.com/game/windows/descent-3 Descent III]
* [http://www.mobygames.com/game/windows/fallout Fallout]
* [http://www.mobygames.com/game/windows/of-light-and-darkness-the-prophecy Of Light and Darkness: The Prophecy]
* [http://www.mobygames.com/game/dos/stonekeep Stonekeep]
* [http://www.mobygames.com/game/windows/virtual-pool Virtual Pool]
* [http://www.mobygames.com/game/windows/waterworld Waterworld]

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

Interplay ACM

2007-04-21T17:22:31Z

Avenger teambg:

* Extension: acm or wav
* Company: [[Interplay Entertainment]]
* Samples:
* Sample Parser:

* Usage: Sound format
* Examples: all Infinity Engine games (baldur's gate, icewind dale, planescape: torment)
* FourCC: 0x97 0x28 0x03 0x01
* tools: [[acmlab]] from teamx.ru

This is a lossy compressed audio format with a rather weak compression ratio. (converted to WAV then recompressed to OGG makes it roughly half size). ACM files can be in varying sample rates, but the common one is 22050 Hz, 16 bits and stereo.

The ACM header:
0x00 FOURCC
0x04 sample count
0x08 channel count (some ACM files lie about the channel count)
0x0a sample rate
0x0c levels (4 bits) and subblocks (12 bits)
0x0e <data>

struct ACM_Header {
long fourcc;
long samples;
unsigned short channels;
unsigned short rate;
unsigned short levels : 4;
unsigned short subblocks : 12;
};

The infinity games also contain a WAVC header which contains mostly redundant information. These files are used for all sound except music (ambients, voice over, sound effects).

The WAVC header:

struct WAVC_HEADER {
char wavc_sig[4]; //WAVC
char wavc_ver[4]; //V1.0
long uncompressed; //the uncompressed length (i guess it is raw pcm)
long compressed; //the compressed length
long headersize; //28 (the size of this header, also the offset to the ACM header)
short channels; //1 or 2
short bits; //8 or 16
short samplespersec; //usually 22050
short unknown;
};

[[Category:Game Formats]]

Interplay ACM

2007-04-21T17:21:37Z

Avenger teambg:

Interplay ACM

2007-04-21T17:18:43Z

Avenger teambg:

Company: Interplay
Usage: Sound format
Examples: all Infinity Engine games (baldur's gate, icewind dale, planescape: torment)
FourCC: 0x97 0x28 0x03 0x01
tools: acmlab from teamx.ru

This is a lossy compressed audio format with a rather weak compression ratio. (converted to WAV then recompressed to OGG makes it roughly half size). ACM files can be in varying sample rates, but the common one is 22050 Hz, 16 bits and stereo.

The ACM header:
0x00 FOURCC
0x04 sample count
0x08 channel count (some ACM files lie about the channel count)
0x0a sample rate
0x0c levels (4 bits) and subblocks (12 bits)
0x0e <data>

struct ACM_Header {
long fourcc;
long samples;
unsigned short channels;
unsigned short rate;
unsigned short levels : 4;
unsigned short subblocks : 12;
};

The infinity games also contain a WAVC header which contains mostly redundant information. These files are used for all sound except music (ambients, voice over, sound effects).

The WAVC header:

struct WAVC_HEADER {
char wavc_sig[4]; //WAVC
char wavc_ver[4]; //V1.0
long uncompressed; //the uncompressed length (i guess it is raw pcm)
long compressed; //the compressed length
long headersize; //28 (the size of this header, also the offset to the ACM header)
short channels; //1 or 2
short bits; //8 or 16
short samplespersec; //usually 22050
short unknown;
};

Talk:Interplay ACM

2007-04-20T18:33:28Z

Avenger teambg:

Since i'm not used to wikis, i thought i just start a talk about this topic before adding it to the normal pages.
Anyone feel free to format this info into a regular page.

Here is what i know about the ACM format (not to confuse with Microsoft's ACM):
Company: Interplay
Usage: Sound format
Examples: all Infinity Engine games (baldur's gate, icewind dale, planescape: torment)
FourCC: 0x97 0x28 0x03 0x01
tools: acmlab from teamx.ru

This is a lossy compressed audio format with a rather weak compression ratio. (converted to WAV then recompressed to OGG makes it roughly half size). ACM files can be in varying sample rates, but the common one is 22050 Hz, 16 bits and stereo.

The ACM header:
0x00 FOURCC
0x04 sample count
0x08 channel count (some ACM files lie about the channel count)
0x0a sample rate
0x0c levels (4 bits) and subblocks (12 bits)
0x0e <data>

struct ACM_Header {
long fourcc;
long samples;
unsigned short channels;
unsigned short rate;
unsigned short levels : 4;
unsigned short subblocks : 12;
};

The infinity games also contain a WAVC header which contains mostly redundant information. These files are used for all sound except music (ambients, voice over, sound effects).

The WAVC header:

struct WAVC_HEADER {
char wavc_sig[4]; //WAVC
char wavc_ver[4]; //V1.0
long uncompressed; //the uncompressed length (i guess it is raw pcm)
long compressed; //the compressed length
long headersize; //28 (the size of this header, also the offset to the ACM header)
short channels; //1 or 2
short bits; //8 or 16
short samplespersec; //usually 22050
short unknown;
};

--[[User:Avenger teambg|Avenger teambg]] 14:33, 20 April 2007 (EDT)

Smacker

2007-04-11T10:31:08Z

Avenger teambg: typo fix

* Extension: smk
* Website: [http://www.radgametools.com/smkmain.htm http://www.radgametools.com/smkmain.htm]
* Company: [[RAD Game Tools]]
* Samples: [http://samples.mplayerhq.hu/game-formats/smacker/ http://samples.mplayerhq.hu/game-formats/smacker/], many computer games

Smacker is a technology that has been used in games and other entertainment software titles since the dawn of multimedia-era video games. The Smacker website claims that the format has been used for [http://www.radgametools.com/smkgames.htm over 2600 titles].

Smacker files contain Smacker Video and one of a few different custom audio codecs.

== Container Format ==

These are the data conventions used in this description:

* All multi-byte numbers are stored in little-endian (Intel) format.
* byte - 8 bits value
* word - 16 bits value
* dword - 32 bits value
* All values are unsigned, unless stated otherwise.

This is the general layout of a Smacker file:

struct Header
dword FrameSizes[];
byte FrameTypes[];
byte HuffmanTrees[];
byte FramesData[];

== Header ==

General file description header. Total size is 104 (0x68) bytes.

dword Signature;
dword Width;
dword Height;
dword Frames;
dword FrameRate;
dword Flags;
dword AudioSize[7];
dword TreesSize;
dword MMap_Size;
dword MClr_Size;
dword Full_Size;
dword Type_Size;
dword AudioRate[7];
dword Dummy;

* Signature - File signature. Either "SMK2" for original Smacker or "SMK4" for latest revisions.
* Width, Height - Frame dimensions in pixels.
* Frames - Number of logical frames. File may contain extra "ring" frame, but it's not counted here.
* FrameRate - can be determined this way:
if (FrameRate > 0)
fps = 1000 / FrameRate;
else if (FrameRate < 0)
fps = 100000 / (-FrameRate);
else
fps = 10;
* Flags - Only bits 0, 1 and 2 are used so far:
Flag bits
---------
0 - set to 1 if file contains a ring frame.
1 - set to 1 if file is Y-interlaced, meaning that the frame should be
scaled to twice its height before it is displayed.
2 - set to 1 if file is Y-doubled, meaning that the frame should be
scaled to twice its height before it is displayed.
* AudioSize - Size of the largest unpacked audio data buffer in bytes; this is provided for up to 7 audio tracks.
* TreesSize - Total size in bytes of HuffmanTrees stored in file.
* MMap_Size, MClr_Size, Full_Size, Type_Size - Allocation size of corresponding Huffman table in memory.
* AudioRate - Frequency and format information for each sound track, up to 7 audio tracks. The 32 constituent bits have the following meaning:
** bit 31 - data is compressed
** bit 30 - indicates that audio data is present for this track
** bit 29 - 1 = 16-bit audio; 0 = 8-bit audio
** bit 28 - 1 = stereo audio; 0 = mono audio
** bits 27-26 - if both set to zero - use v2 sound decompression
** bits 25-24 - unused
** bits 23-0 - audio sample rate
* Dummy - Unused.

== FrameSizes ==

Following the header is an array of sizes (lengths) of each physical frame in the file. Each size is a 32-bit number stored in little endian format. Additionally, if bit 0 of a frame size is 1 then that frame is a keyframe. Bit 1 is also used for some undetermined purpose. NB: You DO NOT need to shift these bits out to get the proper length but you do need to clear both of these bottom bits.

== FrameTypes ==

The FrameTypes section of a Smacker file contains an array of bytes, where the 8 bits of each byte describe the contents of the corresponding frame. The 8 bits have the following meaning when set:

* 7 - frame contains audio data corresponding to track 6
* 6 - frame contains audio data corresponding to track 5
* 5 - frame contains audio data corresponding to track 4
* 4 - frame contains audio data corresponding to track 3
* 3 - frame contains audio data corresponding to track 2
* 2 - frame contains audio data corresponding to track 1
* 1 - frame contains audio data corresponding to track 0
* 0 - frame contains a palette record

== HuffmanTrees ==
The HuffmanTrees section contains Huffman tree data for each decoding table. The tables are stored in this order:
* MMap
* MClr
* Full
* Type

Each tree consists of four parts:
* Huffman tree for low byte values
* Huffman tree for high byte values
* 3 escape codes
* Huffman tree data

The first two trees are decoded as described in section [[Smacker#Packed Huffman Trees|Packed Huffman Trees]]. The actual tree data is decoded in mostly the same way except that a leaf value is 16 bits long and decoded from two Huffman trees (low byte first). You should also store pointers to nodes with values equal to escape values.

== FramesData ==
The FramesData section contains the data for each frame. Additionally, each frame can be subdivided into multiple chunks and stored in this order:
* new palette
* audio stream(s)
* video data

=== Palette Chunk ===
A palette chunk contains palette change information. Note that Smacker files use a 256-entry RGB where each component is 8 bits large. I.e., individual red, green, and blue palette components have a possible range of 0..255.

The layout of a palette chunk is:

byte Length;
byte Blocks[];

* Length - Size of the entire palette chunk, including this length byte, divided by 4.
* Blocks - One or more blocks of palette data.

Each block may be either 1, 2, or 3 bytes long, depending on the top one or two bits of the first byte. These are the 3 possible cases:

* 1ccccccc: The top bit of the first byte in the block is 1. Copy next (c + 1) color entries of the previous palette to the next entries of the new palette.
* 01cccccc, ssssssss: The top 2 bits of the first byte in the block are 01. Copy (c + 1) color entries of the previous palette, starting from entry (s) to the next entries of the new palette.
* 00bbbbbb, 00gggggg, 00rrrrrr: The top 2 bits of the first byte in the block are 00. Use (b, g, r) to create the next entry of the new palette. Note, that each component in this case is only 6 bits long. You need to upscale them to the full 8-bit values using the following lookup table:

unsigned char palmap[64] = {
0x00, 0x04, 0x08, 0x0C, 0x10, 0x14, 0x18, 0x1C,
0x20, 0x24, 0x28, 0x2C, 0x30, 0x34, 0x38, 0x3C,
0x41, 0x45, 0x49, 0x4D, 0x51, 0x55, 0x59, 0x5D,
0x61, 0x65, 0x69, 0x6D, 0x71, 0x75, 0x79, 0x7D,
0x82, 0x86, 0x8A, 0x8E, 0x92, 0x96, 0x9A, 0x9E,
0xA2, 0xA6, 0xAA, 0xAE, 0xB2, 0xB6, 0xBA, 0xBE,
0xC3, 0xC7, 0xCB, 0xCF, 0xD3, 0xD7, 0xDB, 0xDF,
0xE3, 0xE7, 0xEB, 0xEF, 0xF3, 0xF7, 0xFB, 0xFF
};

Keep parsing palette blocks until all 256 colors of the new palette have been filled, or until the palette chunk has been depleted.

=== Audio Track Chunk ===
An audio track chunk contains a portion of audio data corresponding to a single track. A Smacker file can contain up to 7 audio tracks and a single frame may have several audio track chunks. The layout of a single audio track chunk is:

dword Length;
dword UnpackedLength; (optional)
byte Data[];

* Length - Size of the entire chunk, including this length field.
* UnpackedLength - Size of decompressed Data. This field is present only if the corresponding AudioRate header field indicates that this track uses compressed data.
* Data - Audio data, encoded as specified by corresponding AudioRate header field.

=== Video Chunk ===

A video chunk contains compressed video data for the remainder of a frame.

== Bit Streams ==

HuffmanTrees, video and audio data, stored and accessed via bit streams. Bits counted from the lower bit of each new byte. Thus if we have stream of bytes 0x5C, 0x96, 0xEF and sequentially read 5, 6 and 7 bits, we'll get this output: 0x1C, 0x32, 0x72.

== Packed Huffman Trees ==

Huffman trees are stored in the bitstream in a compressed format. Basic stream layout:

Tag
Flag[, Leaf][, Flag[, Leaf]][, ...]

Tag - Single bit, indicates that tree is present.
Flag - Single bit, indicates whether tree entry is a Node (1) or Leaf (0).
Leaf - If Flag bit is zero, then next 8 bits or variable size field follow,
representing a tree leaf value.

== Reconstructing the Tree ==

Before trees can be used, they need to be unpacked into an easily seekable form. Reconstruction algorithm ('stream' denotes packed tree, 'tree' - unpacked):

1: Read Tag
2: If Tag is zero, finish
3: Read Flag
4a: If Flag is non-zero:
5a: Remember current tree node
5b: Advance to its '0' branch
5c: Repeat recursively from step 3 (one level down)
4b: If flag is zero:
5a: Read Leaf from stream
5b: Assign Leaf value to current node (convert it to leaf)
6: If no node previously remembered, finish (one level up)
7: Use node's '1' branch from step 5a as current tree position
8: Repeat from step 3

Imagine, we have following packed tree stream (these are not bytes, just a sequence of codes!):

1, 1, 1, 1, 0, 3, 1, 0, 4, 0, 5, 0, 6, 1, 0, 7, 0, 8

Decompressing the tree, we'll get:

<--'0'- -'1'-->
( )
/ \
/ ( )
/ / \
( ) (7) (8)
/ \
( ) (6)
/ \
(3) ( )
/ \
(4) (5)

== Optimized Compression ==
Smacker uses several techniques to improve compression ratio. When Huffman codes are used to compress 8-bit values (bytes) each Leaf entry holds raw 8 bits of data. When Huffman codes are used to compress 16-bit values (even if the actual value requires fewer than 16 bits), the packed tree's Leaves do not contain all 16 bits. Instead, the stored bits are decompressed using the two previously initialized 8-bit Huffman decoders (each with its own tree). The lower byte is decompressed first, then highest. So when you enter steps 4b-5a of the tree unpacking algorithm, you need to invoke another Huffman decoder twice to read the full 16-bit Leaf value.

Another optimization technique employed is semi-dynamic trees. When you unpack codes from a tree and a code is not the same as previously unpacked one, it will be moved together with another two recent codes to the shortest tree's branches. Shortest branches are explicitly marked with special Leaf values and replaced with zeros during tree reconstruction.

Both optimization methods are used together, so typical tree initialization involves the following steps:

1a: Read Tag (of main tree)
1b: If Tag is zero, finish
2: Read Huffman tree for low bytes
3: Read Huffman tree for high bytes
4a: Read 16-bit marker of shortest node #1
4b: Read 16-bit marker of shortest node #2
4c: Read 16-bit marker of shortest node #3
5: Read the rest of Huffman tree, contains 16-bit values
5a: When you read Leaf and it's value matches one of the markers obtained on step
4, remember the leaf for this marker and set leaf's value to zero.

== Unpacking Data Using Huffman Trees ==

The unpacking process is fairly simple. Start from the top of the Huffman tree. Read and examine the next bit of packed bitstream. According to its value, choose either the '0' or '1' branch of the tree. As soon as you encounter a leaf, the unpacking is finished and a value is obtained. Otherwise, repeat bit reading and tree branching. If a dynamic tree used, compare unpacked value with previously unpacked one. If the value is different, move two previously remembered values to shortest branches #2 and #3, and newly unpacked value to #1.

== Unpacking Audio Track ==

Depending on AudioRate flags, sound can be stored in either uncompressed or packed form.

Uncompressed data is stored as raw [[PCM]] samples.

Compressed audio may be stored in Huffman-packed DPCM format or, in case of perceptual coding used (that is [[Bink Audio]]), as rle-packed coefficients.

=== Huffman DPCM ===

DPCM-packed stream has the following format:

DataPresent, IsStereo, Is16Bits, Trees[], Bases[], Data[]

* DataPresent - Bit, indicates sound presence
* IsStereo - Bit, indicates mono or stereo sound
* Is16Bits - Bit, indicates 8 or 16 bits samples
* Trees - 8-bits Huffman trees, one tree per each byte of unpacked sample (i.e. single tree for 8bit mono sound, 4 trees for 16bits stereo sound).
* Bases - One to four 8-bits starting values for each of sample' bytes
* Data - Huffman-packed stream of 8-bit deltas for each byte of samples

Obviously, Is16Bits and IsStereo must match flags of AudioRate field.

Decompression steps:

# Read DataPresent; if no DataPresent, finish
# Read IsStereo
# Read Is16Bits
# Read number of Trees, according to resulting sample size (see above)
# Read number of Bases, according to resulting sample size (see above). If sample is 16-bits wide, it's highest base byte stored first. First comes right-channel bases, then left-channel one(s).
# Output Base bytes is an unpacked sample.
# For every byte part of sample, Huffman decompress delta from Data using its Tree and add it to the Base byte. If sample is 16-bits wide, low byte stored first, then high, left channel, then right (opposing to step 5). When you unpack 16-bits sample, take in to account possible overflow of lower byte and adjust high byte accordingly.
# Repeat step 6 until all data decompressed (UnpackedLength bytes of samples processed)

== Unpacking Video ==
The video in a Smacker is encoded as a series of 4x4 pixel blocks. The image is decoded left to right, top to bottom. If the original image size is not divisible by 4, it is padded up to the next block boundary.

=== Block Types ===

* Mono Block (0) - Whole block contains only pixels of two colors and special map of their order.
* Full Block (1) - Normal full-color block. v4 may perform extra compession of this block.
* Void Block (2) - Empty (skip) block, indicates that whole block data is unchanged from previous frame.
* Solid Block (3) - Whole block is filled with single color.

Mono blocks colors, Mono blocks maps and Full blocks have it's own 16-bit Huffman tables, stored in the beginning of the file (MClr, MMap and Full respectively).

Compressed frame stream consists of a packed block Types descriptors and actual blocks data. Another 16-bits Huffman table stored in the file header for Type descriptors decompression.

Type descriptors have the following format in bits:
1..0 - Type of block
7..2 - Blocks chain length. Not a real length, but index in the table:
unsigned int sizetable[64] = {
1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30, 31, 32,
33, 34, 35, 36, 37, 38, 39, 40,
41, 42, 43, 44, 45, 46, 47, 48,
49, 50, 51, 52, 53, 54, 55, 56,
57, 58, 59, 128, 256, 512, 1024, 2048};
15..8 - Extra data, mainly contains fill color for Solid block.

Frame painting steps:

# Read Type descriptor
# Draw single block selected by Type bits
# If whole image drawn, finish
# Repeat from step 2 until whole chain complete
# Repeat from step 1

=== Mono Block ===

Mono block contains 16 pixels of two colors. First, you need to unpack the pixel's color from the stream using the MClr Huffman table. The high byte of the unpacked value contains color1 and lower byte contains color2. Next, decode the pixels map, using MMap table. For each bit of the map, starting from the least significant bit, if the value is zero, paint pixel using color0, if bit is set paint with color1. Repeat until all 16 pixels are painted.

=== Full Block ===

Full block contains 16 pixels of any color. Format of this block has been changed in v4.

==== v2 Full Block ====

Decompress 16-bit value and use it draw pixels 3 and 4. Use lower byte for pixel 3 and high byte for pixel 4. Then, decompress next value and paint pixels 1 and 2 using same technique. Advance to the next 4 pixels. Repeat these steps to draw all 16 pixels.

==== v4 Full Block ====

Chain of v4 Full blocks prepended with extra bits, determinating sub-type of all following blocks in the chain. If first bit is 0, paint chain of blocks as v2 Full blocks. Otherwise, read next bit. If bit is zero, paint chain of Double-blocks; if one, paint chain of Half-blocks.

===== v4 Double Block =====

Decompress 16-bits value and use it to draw first two 2x2 subblocks (left to right, top to bottom), filling whole subblock with single color (i.e low byte used for pixels 1, 2, 5, 6 and high byte for pixels 3, 4, 7, 8). Advance to the next two subblocks and repeat again to paint all 16 pixels.

===== v4 Half Block =====

Perform steps similar to v2 Full block, but instead of drawing each even line, just duplicate if from previous line.

=== Void Block ===

All 16 pixels in the block are unchanged from the previous frame.

=== Solid Block ===

Fill whole block using color obtained as Extra value during Type descriptor decoding.

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

Electronic Arts MAD

2007-04-11T10:20:43Z

Avenger teambg: reverted vandalism to last good page

* Extension: mad
* Company: [[Electronic Arts]]
* Samples: http://samples.mplayerhq.hu/game-formats/dct-mad/

MAD is a video codec used in various games published by companies under the Electronic Arts umbrella. The codec is an evolution of the earlier [[Electronic_Arts_TGQ|TGQ]] and [[Electronic_Arts_TQI|TQI]] codecs, adding motion compensation and low-quality frame concepts. MAD is an abbreviation for "Madcow Movie".

== Chunk Types ==
See [[Electronic Arts Formats]] for file format description. Each MADk, MADm and MADe chunk corresponds to a video frame, where MADk is an intra-frame, MADm is an inter-frame and MADe is a low-quality-inter frame. Low-quality-inter frames are identical to inter frames, but are not used for motion compensation and are discarded immediately after presentation. Each frame is divided into 16x16 pixel macroblocks, with each macroblock further divided into with four 8x8 luma and two half-resolution 8x8 chroma blocks. Standard [[MPEG-1]] block ordering is used.

Each chunk begins with a 16 byte header, followed by a bitstream. Symbols within the header are encoded using 16-bit little-endian most-to-least-significant bit packing. <FIXME: explain bit packing>. Although frame type is reported within the header, the field is not valid in some samples, and is therefore unreliable. Frame type should be inferred from the chunk type.

Offset Data_type Name Description
0x0000 four bytes unknown always zero
0x0000 le_u16 unknown
0x0006 le_u16 frame_rate milliseconds per frame
0x0008 le_u16 width image width (pixels)
0x000a le_u16 height image height (pixels)
0x000c u8 unknown
0x000d u8 quantizer frame quantizer
0x000e u8 frame_type not valid for all samples
0x000f u8 unknown
for each vertical macroblock
for each horizontal macroblock
decode_mb

== Macroblock Decoding ==
Macroblock composition is based on a 6-bit block type, where each bit indicates the type of an 8x8 block within macroblock. The least-significant-bit corresponds to the first block. A clear bit indicates an intra-block, and a set bit indicates a motion-compensated block.

For intra frames, the block type is assumed to be all clear. For inter and low-quality inter frames, the block type is derived from a VLC. If the block type is none zero, then a full-pel motion vector is read from the bitstream. A description of the block_type VLC and decoding algorithm is provided below.

if (intra frame)
block_type = 000000b
else // inter or low-quality-inter frame
switch get_vlc()
case 1b : block_type = 111111b
case 01b : block_type = get_bits(6);
case 00b : block_type = 000000b

if (block_type != 0)
x = GetVector();
y = GetVector();

for i = 0 through 5 // for each block
if block_type & (1<<i)
mc_offset = GetVector()
motion_compensation
else
decode_coeffs

Full-pel 8x8 block motion compensation is performed using the motion vector. Following the compensation step, each pixel in the block is offset by the mc_offset value and clipped to 0, 255.

==GetVector Definition==
Vector values are read from the bitstream using the following algorithm.

value = 0
if (get_bits(1))
if (get_bits(1))
value = -17
value += get_bits(4) + 1

==Coefficient Decoding==
All coefficients, including DC, are decoded using the MPEG-1 AC [[Run_Length_Encoding|run-length]] VLC technique. The RLVLC table is identical to that used for the [[Electronic_Arts_TGQ|TGQ]] codec and coefficients are ordered using the [http://wiki.multimedia.cx/index.php?title=Image:Ea_tgq_zigzag.png EA zigzag scan pattern]. Dequantization is performed by multiplying the coefficients by a dequantization table. This table is calculated for each frame using the frame quantizer.

dequant_table[0] = base_table[0] * base_table2[0]
for i equals 0 through 63
dequant_table[i] = (base_table[i]*base_table2[i]*frame_quant + 4) / 8

where base_table and base_table2 are defined in [[Electronic_Arts_TGQ|TGQ]] and [[Electronic_Arts_TGQ|TQI]] respectively.

==Inverse DCT and Clipping==
An IDCT-based algorithm is applied to each block. <FIXME: hyperlink to implementation>. The resulting values are offset by 128, and clipped to 0, 255 to give 8-bit luma and chroma pixel levels.

== Games Using MAD ==
See [[Electronic Arts Formats]] for listing.

[[Category:Game Formats]]

Bethsoft VID

2007-04-11T10:19:54Z

Avenger teambg: reverted vandalism to last good page

* Company: [[Bethesda Softworks]]
* Specification: http://www.svatopluk.com/andux/docs/dfvid.html
* Samples: http://samples.mplayerhq.hu/game-formats/bethsoft-vid/

[[Run Length Encoding|RLE]]-based format used in ''The Elder Scrolls II: Daggerfall'',''Terminator: Skynet'' and ''Terminator: Future Shock''.

==Related software==
*[http://www.svatopluk.com/daggerfall/download/dagvid.stm DagVid]—a player
*[http://www.svatopluk.com/daggerfall/download/vid2avi.stm DFVid2AVI]
*[http://www.svatopluk.com/andux/ Andux's] VID tools
**VIDDump—dumps audio, palette, and raw frame data
**VID Audio Dumper
**MakeVID (prototype)

[[Category:Video Codecs|VID (Bethsoft)]]
[[Category:Game Formats|VID (Bethsoft)]]

Xan DPCM

2007-04-11T10:18:22Z

Avenger teambg:

Company: [[Origin Systems]]

Origin's [http://www.mobygames.com/game/dos/wing-commander-iv-the-price-of-freedom Wing Commander IV: The Price of Freedom] computer game transports multimedia cutscenes in standard Microsoft [[Microsoft Audio/Video Interleaved|AVI]] files. The audio in these files is encoded using a custom format that this page takes the liberty of naming Xan DPCM.

Note that an AVI file demuxer will probably need to be modified to support the algorithm. The [[WAVEFORMATEX]] headers in the Xan AVI files report the audio coding as format 0x0001: [[PCM]]. However, the file's 'auds' chunk begins with the fourcc 'Axan'. A program can either check for this or assume that the file uses Xan DPCM if it uses [[Origin Xan Codec|Xan]] video.

Classifying the Xan audio coding method as a DPCM algorithm is a little shaky. It actually resembles a cross between a DPCM algorithm and a APDCM algorithm. Perhaps the designers could not decide between the two algorithm families and decided to split the difference. The algorithm encodes 16-bit PCM samples as 8-bit bytes by packing a 6-bit delta value along with a 2-bit delta modifier into a byte.

For each chunk of Xan DPCM data, the first 2 or 4 bytes are the initial predictors for that chunk, depending on mono or stereo data, and are encoded as signed, 16-bit, little-endian numbers. A shifter value for each channel is initialized to 4. For each byte in the stream (assuming mono data):

byte = next byte in stream
diff = (byte & 0xFC) << 8
if bottom 2 bits of byte are both 1 (byte & 0x03)
shifter++
else
shifter -= (2 * (byte & 3))
note that the shift value may not go below 0 and must be saturated here
shift diff right by shifter value
apply diff to the current predictor
saturate predictor to signed, 16-bit range

Note that diff must be treated as a signed 16-bit number. For stereo data, the bytes represent interleaved samples in LRLR order.

[[Category:Audio Codecs]]
[[Category:DPCM Audio Codecs]]
[[Category:Game Formats]]

Talk:YouTube

2007-04-06T11:42:17Z

Avenger teambg: where is theora?

haha , fun way to check if youtube is using ffmpeg or not :) i was going to email them, guess i'll give that a chance right now.
-[[User:Compn|Compn]] 20:57, 4 January 2007 (EST)

You should be able to get around the file too long message by having the upgraded youtube account (called something like director). It allows you to post movies that last more than 10 minutes. According to the website, the maximum size is 100 MB.

Mentioned in the Troubleshooting:Uploads section is that Real media (.rm) and Flash (.flv) are not supported. They mention using Windows Movie Maker or iMovie, so all the formats that either one can produce should work.
[[User:Dashcloud|Dashcloud]] 00:04, 5 January 2007 (EST)

:I thought I remembered reading forums somewhere about people transcoding to FLV and uploading to YouTube. They reported it worked, but there was generational loss since YouTube transcodes it to a new FLV anyway. I have yet to test it personally. Also, I tend to think that any length error indicated in this table is a malfunction on the part of the trancoding software since none of the files were anywhere near the file size limit nor time limit. --[[User:Multimedia Mike|Multimedia Mike]] 00:44, 5 January 2007 (EST)

::Just added RealVideo versions 1..3 to the list (they all work). If those 3 work, I wager #4 will work as soon as it has been given enough time to process. FLV/Sorenson works but not the other codecs. --[[User:Multimedia Mike|Multimedia Mike]] 03:31, 5 January 2007 (EST)

anyone try some h264 samples?
-[[User:Compn|Compn]] 15:35, 9 January 2007 (EST)

:I haven't tried any yet. If you know of some specific samples I should try, particularly ones that flex particular H.264 properties, either try uploading them, or let me know the links so I can try them. --[[User:Multimedia Mike|Multimedia Mike]] 18:18, 9 January 2007 (EST)

::You can easily create h264 samples, and a lot of other formats using LiVES (http://lives.sourceforge.net). I'd be interested to know which of LiVES formats are supported, particularly the Free ones like theora and dirac. [[User:Salsaman|Salsaman]] 19:39, 25 January 2007 (EST)

I wonder why i can't find theora on this list (neither on supported nor on the non-supported part).
Shouldn't it be listed somewhere???
Excuse me, i'm largely ignorant, so enlighten me :)
--[[User:Avenger teambg|Avenger teambg]] 07:42, 6 April 2007 (EDT)

Dirac

2007-01-26T14:27:03Z

Avenger teambg:

* FOURCC: BBCD
* Company: [[BBC]]
* Website: [http://dirac.sf.net/ http://dirac.sf.net/]

Experimental wavelet-based video codec being developed by the [[BBC]]. The development of a C++ Dirac implementation under the MPL license is hosted at SourceForge.
[http://schrodinger.sf.net The Schrödinger Project] is an implementation written in ANSI C89, jointly developed by [[Fluendo]] and [[BBC]].

[[Category: Video Codecs]]

Interplay Entertainment

2007-01-19T10:25:02Z

Avenger teambg:

Website: [http://www.interplay.com/ http://www.interplay.com/]

Gaming company from 1983, best known for Lost Vikings and a number of role-playing games. Creators of the [[Interplay MVE]] format.
Interplay became extinct in 2005.

[[Category:Multimedia-related Companies]]

Talk:Bink Video

2007-01-14T10:24:27Z

Avenger teambg:

Bink Video

2007-01-14T10:21:12Z

Avenger teambg:

* FourCC: BINK (note that some FourCC lists assert that BINK is a FourCC for general-purpose multimedia containers; however, Bink data is always known to be encapsulated in a custom container format)
* Company: [[RAD Game Tools]]
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games

A video codec that purports to use every video coding technique ([[DCT]],[[FFT]]) under the sun and used in a large number of computer and console games. The video is packaged in custom [[Bink Container|Bink]] files.

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

Talk:Bink Container

2007-01-07T16:05:20Z

Avenger teambg:

Bink Container

2007-01-04T09:48:14Z

Avenger teambg:

Vodei

2007-01-04T09:46:44Z

Avenger teambg: typo fix

* Company: Vodei

Vodei is a file format consisting of a short [[AVI]] file with an additional encrypted/obfuscated segment appended to the end.

The AVI portion of the file usually contains a short advertisement for vodei.com encoded with [[Microsoft RLE]]. Vodei.com sells software which will decode the additional segment. Although advertised as a "free download", this is adware which will persistently nag the user for payment.

Vodei is not a codec, and after extracting the additional data from the end of the AVI file, simply passes it to the standard [[VfW|Video For Windows]] interface for decoding. (Since the Vodei software contains no codecs, the Vodei web site recommends that the user install ffdshow.)

It is also believed that Vodei itself is encoding movies in vodei format to entice users into buying vodei just for a few movies.

[[Category:Container Formats]]

Talk:Bink Container

2006-12-20T15:21:16Z

Avenger teambg:

Talk:Bink Container

2006-12-20T14:55:12Z

Avenger teambg: suggested correction for bink container