Bink Video version b
- FourCC: BIKb (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/bikb/
Bink is a video codec that uses Vector Quantization along with DCT and Motion Compensation). This version of codec was used in Heroes of Might and Magic III. The video is packaged in custom Bink files.
Each plane is coded separately. The Y plane is always coded first in each frame.
It differs from its successor used in versions 'f'-'i' (at least) in some details.
Bundle size lengths are always 13 bits while newer codec calculates size lengths from plane width. Also bundle data is stored in plain with known number of bits per entry, no Huffman coding is employed.
|pattern||8||no||pattern value for each line of pattern block fill (type 6)|
|?||5||yes||probably X motion vector component|
|?||5||yes||probably Y motion vector component|
|intra block DC||11||no|
|inter block DC||11||yes|
|intra quant?||4||no||presumably quantizer for intra block|
|inter quant?||4||no||presumably quantizer for inter block|
|?||7||no||used in residue block (type 3), might be number of residue coefficients coded|
0 - skip block?
not sure whether it exists at all
1 - pattern run block
4 bits - scan type
The rest is coded like
bit, length. colour(s).
length is coded as 0-6 bits depending on number of elements left not filled yet. Depending on
bit value that part of block (mind the scan pattern though) is either filled with single colour or with many colours read from bundle.
2 - intra DCT?
looks like this one uses floating-point DCT
3 - residue block?
4 - inter DCT?
5 - fill block
6 - pattern fill
It's standard 2-colour fill.