BTIC Overview - cr88192/bgbtech_misc GitHub Wiki
What is this?
- A FAQ of sorts, but more just me trying to explain what is and is not the purpose of BTIC (particularly the BTIC1x family).
- BGBTech Image Codec
- Its early incarnations exist mostly for animated/videomap textures (in my older 3D engine).
- In concept, this is similar to how RoQ is used in Doom 3.
- It has since been applied more to things like streaming video from custom robots and for screen capture.
- Generally it can also be used as a conventional video codec, but has fewer advantages here.
- Though all with related uses, different codecs are done within different families.
- BTIC1x: Focuses on 4x4 blocks using Color Cell / Vector Quantization.
- BTIC2x: Generally focuses on blocky DCT or WHT with a JPEG-like structure.
- BTIC3x: Was generally attempts to combine CC/VQ with DCT or WHT.
- Most designs ended up too complex to make implementation worthwhile.
- BTIC4x: Thus far basically BTIC1x but with 8x8 pixel blocks.
- Most use a similar TLV packaging (originally developed for BTIC1C), BTIC-CTLV
- Many use some form of entropy coding.
- Most of the 1x family uses similar block formats and interpolation.
- Major areas of divergence are in terms of how the blocks are serialized.
- A number of the designs never got past design or early testing.
- Generally this was because serious design flaws became evident.
- Not so well, as they address very different use cases.
- H.264 is reasonably quick to decode via specialized HW, but absent specialized HW is very slow to encode.
- Most BTIC variants can be encoded in real-time at HD resolutions on the CPU.
- Many can achieve faster decoding speeds on the CPU than can H.264 via the hardware decoder (at least on my PC).
- If you just want to stream or play back video files, the BTIC family probably isn't really the best option.
- ... No ...
- Its design prioritizes speed over quality vs bitrate.
-
BTIC1C, an earlier design and one of my more widely used.
- It effectively revived BTIC, as 1A and 1B were pretty much failures.
- 1C evolved fairly directly out of the Apple RPZA codec.
- BTIC1D, briefly used.
- Initially seen as failure compared with either 1C or DCT codecs.
- It used a separate YUV interpolation scheme later adapted to higher-quality blocks in BTIC1H.
-
BTIC1G, meant as a simplistic design for video streaming for robots.
- Uses a byte-based serialization for speed.
- Realized that it was plenty fast for the use-case.
-
BTIC1H, meant as a successor to 1G for robot streaming.
- Realized that it could be made to do most things 1C did, but did them better.
- Uses primarily AdRice coding, initially to facilitate incremental encoding.
- 1A/1B: first experiments.
- Used a JPEG-like packaging and was based mostly on LZ-packed indices.
- Was fast to decode, but otherwise sucked really hard.
- BTIC1E: based on "block slicing" but would have sucked so bad as to be basically useless.
- BTIC1F: initial results looked promising, but design issues would have limited its usefulness.
-
BTIC1I: partial simplification of 1H, but not different enough to be worthwhile.
- Some aspects of this design were borrowed by 4B.
- 2A/2B: Designs based on BTJPEG, but too complex to be worthwhile.
-
BTIC2C: Design was simplified to a JPEG-like subset.
- Basically similar in concept to MPEG-1.
- Had neither the speed of 1x variants, and few real advantages over H.263 or H.264 variants.
- Can do alpha channel and HDR at least.
- BTIC2D: Failed experiment in being faster than 2C.
- BTIC2E: Manages to gain speed by switching to a byte serialization and blocky Haar wavelet.
- Fails to match 1H in terms of speed or Q/bpp.
- Nothing notable, few designs getting much past initial design.
-
BTIC4B: Initially rather promising on the speed front.
- It is thus far the fastest partial codec I have.
- There is a bit of design hair though.