I realized recently that I have completed my initial goals laid out in this post. And since this is a post about PAVC, let’s start out with some pretty console screenshots:

Metalstorm, NES,
one of the most graphically complex games on the NES console

Strider, on the Sega Genesis,
as he strides his way past one of the single most beautiful panaromic vistas ever depicted in a video game

Anyway, the goals were as follows:

• Test vectors: Done at the time, and I have generated further movie vectors, and longer ones as well, depicting more animation circumstances.
• Codec development infrastructure: I have a basic FFmpeg module set up for encoding and decoding experimentation.
• Codec validation infrastructure: It has come to my attention that FFmpeg has a special mode (-f crc) that takes care of this.
• Develop a palette transport model: Done, in the early encoding experiments. It may be able to stand some improvement.
• Develop a basic coding model: Done, for better or worse.

Time for some new goals. First, I need to get some basic compression scheme to work for the intraframes. Keep experimenting with the BWT/MTF/entropy solution. However, take it one step at a time. Code a bitstream using the BWT. Then, make sure that it decodes correctly with the inverse BWT code. Then add the MTF to the mix and make sure it reverses correctly. Finally, experiment with different entropy methods including Golomb, range coding, and arithmetic coding (always risky to use but interesting as a basis for comparison). Another experiment to try on top of this is to search for redundant 8×8 blocks in the frame. Further, search for entire runs that are coded the same with the same block.

Next, it is time to stop running and hiding and finally attack the interframe challenge. Some of the sub-challenges include:

• detecting when the frame has not changed at all from the previous frame
• intelligently determining which palette entries have changed since last frame; code them efficiently in order to avoid coding graphics
• detecting whole-screen, single-plane scrolling, first on a screen basis and, failing that, on a slice basis, and then on a block basis
• after scrolling compensation is achieved, invariably, there will be some new pixels appearing on the screen (at the borders) that need to be coded in an efficient manner
• detecting when a frame is one solid color, coding it efficiently, yet not using it as a reference frame– the next non-solid color frame is more likely to resemble the most recent non-solid color frame