Archive for the ‘Bink’ Category

Bink: ‘lossless’ block coding

Wednesday, September 2nd, 2009

First of all, I’d like to note that those names are taken from Bink code. In reality ‘lossy’ block is used as is and ‘lossless’ block is DCT coefficients.

And now, the differences:

  • in ‘lossless’ mode coefficients are decoded until mask becomes zero, there’s no explicit number of coefficients
  • coefficient bits are stored explicitly, not as several masks: coef[x] = mask | get_bits(log2(mask));
  • starting list somewhat differs

For those who for some unknown reason are interested in RE progress, I can say that my implementation is still far away from perfect. It crashes on 640×480 BIKi files and for those two files it plays (BIKf and BIKi) it gives barely recognisable image — I blame DCT and dequantisation (I haven’t looked at them yet).

Bink: ‘lossy’ coefficients reading.

Saturday, August 29th, 2009

RTMP client seems to work fine, RTMP support in FFserver is not that close, so I work on REing some codec which seems to be rather widespread in games.

OK, now to technical details. ‘Lossless’ coefficient coding is similar but a bit more complicated.

For each 8×8 block there is 7-bit number specifying number of masks to read (mask = part of the coefficient), slightly resembling progressive JPEG coding; coefficient value may be composed from several masks, high bits are decoded first. Decoding continues until all masks are read.

Coding method is not that comprehensible though: there is list of start coefficient and modes, so decoding iterates over this list and performs some action depending on mode. Have I mentioned that aforementioned list may change during operation?

And here’s decoding algorithm (if I got it right):


mask = 1 < < get_bits(3) iterate over already decoded coefficients, if read bit = 1 then add mask to the coefficient iterate over list of modes until end is reached, if (coef,mode)==(0,0) or read bit = 0 then skip current entry:   mode = 0:    set current entry to (cur_coef+4; mode = 1)    for(i=0;i<4;i++, cur_coef++){     if(get_bit()) prepend list with (cur_coef, mode = 3)     else coeffs[cur_coef] = get_bit() ? -mask : mask;    }   mode = 1:    set current entry to (cur_coef; mode = 2)    append (cur_coef+4; mode = 2), (cur_coef+8; mode = 2), (cur_coef+12; mode = 2) to the list   mode = 2:    set current entry to (0; mode = 0)    for(i=0;i<4;i++, cur_coef++){     if(get_bit()) prepend list with (cur_coef, mode = 3)     else coeffs[cur_coef] = get_bit() ? -mask : mask;    }   mode = 3:    coeffs[cur_coef] = get_bit() ? -mask : mask;

Brief notes about Bink

Monday, July 13th, 2009

If you play a lot of games (or maybe not that much) andd are interested in watching their FMVs you should hear about Bink sooner or later.

This is rather widespread codec in games and it’s sad we still don’t have an opensource decoder for it.

Here are some facts about it:

  • Container format seems to inherit a lot from Smacker.
  • There are two different audio codecs differing by transform.
  • Bink video is mostly static Huffman coding + vector quantisation or DCT

So, why not reimplement it?
Here are some more details about video:

  1. It employs static Huffman coding – there are 16 predefined trees which are used to decode a lot of data — the only exceptions are block coefficients. Tree definitions include only tree number and how to reorder table of symbols for current data.
  2. Almost all values are coded in bundles for several blocks at once (usually for half of a frame)
  3. 8-bit values may be encoded as independent nibbles or high nibble may have context-dependent encoding when it’s encoded with a tree number equal to the last high nibble (so you need 16+1 trees for that but who cares).

The rest will be available as it goes.