One option might be to attempt to actually reduce the entire screen down into a smaller set of repeating patterns, Cinepak style, to reduce the number of totally unique symbols in the huffman tree but meh that sounds like effort and I'm not convinced it will save me much.
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
Though I'm a little less worried about how big it is and more focused on making sure it can decode super fast so I can write a playback library for my fantasy console LOL
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)
https://streamable.com/yef0e
Think I fixed it, was some slightly wrong logic in how I serialized my huffman codes. Amazing it still managed to play as far into the stream as it did haha
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.
Video is restricted to 256 color paletted, 320x200 (which is the resolution of mode 1 of my fantasy console's graphics system). Encodes 4x4 blocks of pixels which can be unchanged since last frame, single color fill, dual color, or full/uncompressed. Still lots of work to do.
Current status: messing with a Cinepak/Smacker inspired video codec for a fantasy console I'm working on :)
https://streamable.com/808av
@KillaMaaki It probably wouldn't be so bad for a non-VR app, but it becomes much more noticeable in VR I think.