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.