One other thing I've also noticed is that I seem to get slightly better compression results by length-limiting my huffman tree, since at some point the codes become longer than it would take to actually just encode the full block.
A dual-color block takes all of four bytes total to encode, so I limit length to 32 entries now. Past that it just encodes the block itself rather than the huffman code
My shitty Cronch video codec playing the Sonic 06 opening. At the moment the raw 320x200 3k+ frame video sits at nearly 200MB, and the cronched video is 30MB (not as good as it could be but still a savings)
Huffman coding is cool because everyone tells you how to build a huffman tree using a fancy priority-queue based algorithm to iteratively pop the two least used items and build a tree node out of them but nobody tells you you can just put your shit in a flat list, sort by ref count, and call it a day.
One of the things I'm doing at the moment is porting over from my original hacky-ass C# app to a C++ app and compiling in libavcodec instead of the really bad solution i used for the C# app which was call out to external FFMPEG bin -> generate PNG frames -> load PNG frames.
New C++ version will just decode that shit *directly*.
The other thing I wanna do is look into improving palette selection, and also look into huffman coding the aforementioned 4x4 blocks for further reduced size.
Current status: messing with a Cinepak/Smacker inspired video codec for a fantasy console I'm working on :)
@KillaMaaki It probably wouldn't be so bad for a non-VR app, but it becomes much more noticeable in VR I think.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!