Then what you were describing wasn't actually a compression technique, like I read it as, but a pre-process technique that was relying on zLib to do the actual heavy-weight compression.
Technically speaking, you may be right. I think that what I was doing before giving the data to zlib to compress is called a filter in compression techniques.
A filter does not actually reduce the size of the data (in some cases it may even increase it), but it modifies it so that it will compress better, and that's exactly what I was doing.
(As a curiosity, filtering is the reason why a PNG will often be smaller than taking the raw image and compressing with an archiver program.)
Anyways, that's just semantics. The end result is what's important. :P
Very true. If what I wrote sounded confrontational, my appologies. Most of what I was describing is utterly useless and counter-productive in many cases for a 'video filter' that wasn't actually doing compression. :-)
I'm curious to see how this idea would perform :
Dump every data sent to the PPU and compress it. Then, make a video codec that emulate a PPU and process the data back
Well I tried it
I modified a Gameboy emulator to dump every memory write to video ram and io (0x8000 to 0x9fff,0xfe00 to 0xfeff and 0xff40 to 0xff59). For timing, I added symbols to indicate Hsyncs and Vsyncs. For a 30 seconds game of Tennis, the raw file was 669k. Compressed, the file was 44k ! Only 44k for 30 seconds of lossless 160x144x2bit video. And further optimizations are possible to generate a better raw file.
Of course this example has flaws. Tennis doesn't have much graphic activity. Game that rewrite tile data every scanline or multiplex sprites would make bigger files. Other systems wouldn't perferm as well as the Gameboy . For exemple, it would be almost impossible to have perfect Atari 2600 graphics without cycle perfect synchronisation.
Although this method isn't really suited for a video codec, there are still some ideas we can take from it. You could code a video codec that try to encode the movie file as data sent to a PPU. It could guess what in the image is made of palettized tile and what is made of sprite. It could encode the image as a multi layered tilemap (with tile property that could be modified each scanline) with sprite on top of it. Then make a pseudocode to describe image (scroll tilemap 1 tile to the left, move sprite z at xy, change palette y to x, etc...)
