pouët.net

For the curious, here are some production notes..

The video is encoded in 256 frame chunks

each chunk has its own codebook, multiple block lookups and frame-data

In order to minimize error during the first pass, A DCT transform is used which performs more efficient clustering and merging to a single character set.

Without the DCT, ideally would require many more charsets to achieve the same visual quality after quantization. Data is merged, parts of it are merged and replaced to minimize error via hill climbing methods

This data is then fed through a multiple block clustering encoder which reduces the size of each frame by a factor of 16 (from 1k down to 60 bytes).

Fuzzy matching is used in order to perform more efficient matches.

This then results in a 4k table consisting of 256 tile lookups (each taking 16 bytes of data) to block plot 4x4 chars for each lookup

Delta packing is used between each frame via 8 byte bit-table which skips or plots the tile cluster. This further reduces the size down to on average 30 bytes or so.

Including the 4k lookup tables and 2k codebook spread across the 256 frames, this gives the average total of each frame as 50 bytes.

The c64 side of the decoder is far trivial in comparison to the encoder.

Unrolled delta de-packer is used which can de-pack a frame of data from the packed source using around 10 raster-lines to around 135 or so dependent on frame difference.

Unsurprisingly the decode output is rather blocky in nature at this low file-size. I opted to use a noise overlay in order to reduce this. (This of course gives a fuzzy severely out of tune TV look, but I felt it also gave it more of a original feel to the demo)

Sprites are pointed to the packed data and changed and multiplexed over the whole screen via nmi interrupt. This also updates d016 registers multiple times at semi-random points in the image to distort it

The packed 256 frame data is loaded from disk while the previous 256 are played back, resulting in a continuous stream of 2048 frames.

There was still ample space left on the disk, (enough for another 600 frames or so) or more if using 40 tracks and no intro

The demo is more a demonstration of the encoder rather than the decoder and merit should be given to what it achieves at that low file size (rather than the output quality) :-)

On a more powerful machine, some more sophisticated de-blocking can be used to improve the output quality a lot. I was considering using bitmap mode for the c64 decoder and de-blocking in software, but that would have caused quite a hit to the frame-rate or/and loader being able to keep up with the constant unique frames..

For those not liking the noise, set d015 to $0 if using vice monitor for example (while main demo part is running)

If you read the description that I had posted previously here, its not just VQ. It is combined with a tile cluster former that gives the dramatic size reduction.
(packs a 1k VQ frame into 60 bytes) followed by delta packing which results in approx. 30 bytes per frame. Combined with the gfx data spread out across frames, this gives the 50 bytes per frame.

Without using the above two methods and just placing a 8x8 size image (Just over 60 bytes) to fit the screen it would look utter-crapx100 instead of crap :-)

Ofcourse with some additional post processing, the quality using even the same source packed data could have been improved (but I wanted fast frame update and the loader to keep up with the frames)