Parse block truncation coding (BTC) algorithm?

Question

Algorithms

Good to everyone!
There is a Harvester game, I want to figure out the video decoding algorithm, take out the video, overlay Russian titles and paste it back.
Link to description and algorithm — --> FutureVision_FST < — The block truncation coding (BTC) method, originally developed for coding two-level black and white images, can also be successfully applied to compress grayscale images (as black and white grayscale , and color).
The classical BTC method is extremely simple: the image is divided into non-intersecting rectangular blocks, for each block the average pixel brightness and variance are calculated, then the block pixels are divided into two groups - suprathreshold, whose brightness exceeds the calculated average, and subthreshold. In order to be able to establish which group the encoded pixel belongs to, a binary matrix is ​​transmitted (encoded), in addition, the calculated mean and variance are transmitted, which are used to restore the block during decoding.
I started to understand and did not understand the terminology of the pseudo-language, which describes the decoding algorithm.
Video format.
A video consists of many video+audio blocks.
All numbers shown are in Little Endian format.
The FST file header contains 8 * 4 (32 bytes, red blocks in the picture) of the following data:
for example ALARM.FST
The beginning of the file header:
u32 - Signature - file signature - "2TSF"
u32 - Width - frame width (number 320 pixels)
u32 - Height - frame height (number 200 pixels)
u32 - Ticks - frame rate in ticks? (questionable, frame rate in ticks, in many files the same number is 276480)
u32 - Frames - the number of frames-blocks of video + audio. (40)
u32 - Rate - frame rate per second (15 fps)
u32 - SoundRate - sound frequency (22050 Hz)
u32 - SoundBits - sound bit depth (16 bits)
Followed by blocks in the number specified in Frames (40 green blocks in the picture, 4+2 bytes, 40*6 bytes):
u32 VideoSize - video block size
u16 AudioSize - audio block size
End of file header.
Header illustration

Then comes arrays of bytes in the number of Frames:
u8 VideoData[VideoSize] - video data block, VideoSize size u8
AudioData[AudioSize] - audio data block, AudioSize size
Each VideoData block has the following format:
u16 - BitmapSize - size of the following bitmap, in bits (next raster/image size, in bits, unclear)
u8 Bitmap[BitmapSize/8+1] - flag bits (bit flags), array, bitstream? Unclear.
RGB Palette[256] - optional. 6-bit DAC values. (RGB and 256, that is, there are groups of 3 RGB colors and groups of 256, just a palette of 768 bytes)
u8 Data[] - to the end of frame (until the end of the frame 1 byte data)
And then the decoding algorithm goes:

The decoding cycle is not clear in the algorithm, or rather, where the next “GET BIT” comes from. Or is it a continuous stream of u8 Bitmap bits, or is it taken byte by byte and bits7 and bit6 are taken from there?
PS:
Judging by the wiki (--> Block_Truncation_Coding <--), bit 0 and 1 in BTCMap are just Tsvet0 and Tsvet1.
BTCMap is a 4x4 bitmap, 16 bits are encoded in 2 bytes, resulting in a 4x4 byte matrix.

Answer 1

I got something like this: gist.github.com/jcmvbkbc/6181029
I scored on error handling, palette usage and sound there. Sometimes, when decompressing, it tries to read a little more data than is written in the frame.

the decoding cycle is not clear, or rather where the next “GET BIT” comes from

- continuous stream of bits from bitmap: byte 0, bit 7; byte 0, bit 6; ...; byte 1, bit 7;…