Bink Video: Difference between revisions
(→1) |
(Daniel should have filled that long time ago. Or Peter. Definitely not me.) |
||
Line 7: | Line 7: | ||
Each plane is coded separately. The Y plane is always coded first in each frame. | Each plane is coded separately. The Y plane is always coded first in each frame. | ||
== Block types == | == Format == | ||
Bitstream is read LSB from 32-bit little-endian words. | |||
Frame is coded as three planes. | |||
Each plane starts with Huffman codebooks: two 4-bit ones, one 8-bit (which really consists of seventeen (16 plus one special) 4-bit codebooks) and four 4-bit ones. | |||
=== Huffman trees === | |||
* 4 bits - huffman tree type. This selects one of the tables 16/32/64/128 bytes long. | |||
first table seems to correspond to raw nibble coding, so the rest of data exists only for types 1-15 | |||
* 1 bit - tree type: 1 - small tree, 0 - big tree | |||
For small tree: | |||
* 3 bits - number of leaves in tree | |||
* <code>[number of leaves in tree]</code> x 4 bits - leaves code length? | |||
Big trees are seemed to be generated first by making pairs (i ; i+1) or (i+1; i) depending on bit read and then sorted by using several passes of merge sort; this merge sort also uses bits instead of comparisons to sort that list in some order. | |||
== Decoding == | |||
=== Block types === | |||
'''NOTE: This section is incomplete''' | '''NOTE: This section is incomplete''' |
Revision as of 09:58, 26 June 2009
- 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/, countless video games
Bink is a video codec that purports to use every video coding technique (DCT, FFT, Wavelet Coding, Vector Quantization, Motion Compensation) under the sun and used in a large number of computer and console games. The video is packaged in custom Bink files.
Each plane is coded separately. The Y plane is always coded first in each frame.
Format
Bitstream is read LSB from 32-bit little-endian words.
Frame is coded as three planes.
Each plane starts with Huffman codebooks: two 4-bit ones, one 8-bit (which really consists of seventeen (16 plus one special) 4-bit codebooks) and four 4-bit ones.
Huffman trees
- 4 bits - huffman tree type. This selects one of the tables 16/32/64/128 bytes long.
first table seems to correspond to raw nibble coding, so the rest of data exists only for types 1-15
- 1 bit - tree type: 1 - small tree, 0 - big tree
For small tree:
- 3 bits - number of leaves in tree
[number of leaves in tree]
x 4 bits - leaves code length?
Big trees are seemed to be generated first by making pairs (i ; i+1) or (i+1; i) depending on bit read and then sorted by using several passes of merge sort; this merge sort also uses bits instead of comparisons to sort that list in some order.
Decoding
Block types
NOTE: This section is incomplete
0
Copy 8x8 block from previous frame to current frame
1
Read secondary block code
(TODO)
1 - 3
Fill 16x16 block with coded byte
6
Fill 8x8 block with coded byte