BTIC

BTIC is a family of specialized video codecs.

Naming:
 * BTICxy or BTICxyz
 * x (digit) is the family.
 * y (letter) is the particular codec.
 * z (digit) if included, is a major version (breaking changes).

Some Theory:
 * Efficiency and Blocky VQ BT_FastVQ

BTIC1x family:
 * Used for speed-oriented blocky VQ codecs.
 * BTIC1A and BTIC1B
 * Were very fast, but had horrible compression.
 * Had started as experiments to pack / LZ-compress DXT1 and DXT5.
 * BTIC1C
 * First generally successful design.
 * Based initially on Apple Video / RPZA.
 * Hacked/extended significantly to improve image quality and compression.
 * BTIC1D
 * Used similar technology to 1C, but was based on YUV & 4:2:0 chroma subsampling.
 * It was neither good nor fast. Bitrate was poor, codec speed was lackluster.
 * And was not readily convertible to DXTn or BCn.
 * Loosely similar technology was later added to 1C.
 * BTIC1G and BTIC1H also are based around similar technology for some blocks.
 * One difference was that it had stored UV ranges and had interpolated all 3.
 * Ex: block had 48 bits pixel data, 32 for Y and 16 for U&V (2x 2x2x2bpp).
 * Could possibly be added to BTIC1H (YUVDyuv 4:2:0).
 * BTIC1E
 * Design, never implemented as I soon realized it would suck really hard.
 * Was based on byte-slicing BC7 blocks.
 * Speed and compression were likely to be worse than merely using Deflate compression on BC6H or BC7.
 * BTIC1F
 * Initial results looked promising, but never fully implemented.
 * Split color and pixel data into separate buffers.
 * Color data was akin to a command-based lossy PNG.
 * Problem domain had moved, and the design had limitations.
 * Multiple planar buffers was problematic.
 * Design would not have been well suited to incremental compression.
 * BTIC1G
 * Was designed with an emphasis on low implementation complexity and incremental encoding.
 * Used YUV partly because the image-sensor data is available as YUV (or Bayer).
 * Didn't use entropy coding partly for speed.
 * Raspberry Pi doesn't have super powerful CPU.
 * Can't currently make much use of VideoCore.
 * Console operation, very latency sensitive, UDP-based communication, ...
 * This hindered use of more traditional codecs.
 * Would need a larger latency window and to use TCP.
 * BTIC1H
 * Based mostly on BTIC1G and BTIF1F.
 * Unique in that it uses AdRice coding instead of Deflate or BTLZH coding.
 * Mostly this is for better supporting incremental encoding.
 * Huffman is generally better on both the speed and compression front.
 * However, AdRice is better able to exploit specialized contexts vs Huffman.
 * Given UDP, can't ensure messages arrive or in correct order, making Huff problematic.
 * Constant overhead for static Huffman is also not good for small messages.
 * Vitter was slower and compressed worse in prior experiments than AdRice.
 * Generally, compression is better but decode speed is worse than BTIC1C.

BTIC2x family:
 * BTIC2A / BTIC2B
 * Too complex to be easily implemented, gave up.
 * BTIC2C
 * Essentially JPEG-like design with some tweaks and similar.
 * Basic motion compensation and differential coding in P-Frames.
 * Was intended for high decode speed, but results were lackluster here.
 * Can do high-quality or lossless video though at a sane bitrate.
 * However, encode speed is too slow to be viable for screen capture.
 * I have generally used BTIC1C or BTIC1H for PC screen-capture.
 * My PC is too slow to get good results with more traditional options/codecs.
 * BTIC2D
 * Was an attempt at a high-speed DCT-based design.
 * Was not able to sufficiently outperform BTIC2C or M-JPEG to be worthwhile.
 * It had made use of asymmetric Y and UV blocks, rather than solely 8x8 blocks.
 * Ex: 4x4+2x 2x2 or 8x8+ 2x 4x4.
 * This led to a smaller macroblock size.
 * While the DCT was cheaper, entropy coding/... was more expensive.
 * Blocks had far fewer zeroes, ...

BTIC3x family:
 * Attempts to combine DCT and VQ technology.
 * Thus far nothing in this group has been effective.
 * Most designs become excessively complicated.
 * Compression does not generally outperform BTIC1x designs.
 * Can use mixed 1x and 2C or JPEG (Say, JPG I-Frame and 1C or 1H P-Frames).
 * Limited effectiveness for the issues this introduces.
 * This is detrimental to codec speeds.
 * For I-Frames, 1H isn't drastically worse than JPEG.