Video Compression / Decompression

[snicklin]

Other than TIP animation, has there even been any other serious attempts at a video decompression system for the Atari 8-bit?

 

I've been thinking out (though not implementing) a lossy fractal method for compression (to do on the PC) and then decompressing on the 8-bit.

 

One thing that I've considered is that on some frames, there may be too much to do in the 1 frame. But for such cases, I then considered that if you knew how many cycles each type of compressed item takes to decompress, you could get the compressor to prioritise what gets compressed in each frame.

 

Then for the actual compression, you can encode whether an 8x8 or 4x8 square needs to be become more like some other square or not... (1 or 0 - with RLE).

 

My inspiration came from this rotating video on the C64 at 28s on here:

 

 

[ilmenit]

What Algorithm is doing on C64 for the last few years is much more complex and requires a lot of experimenting, coding and different skills with optimizations, encoding, video and sound processing. On Pouet he usually writes info about techniques implemented in released prods. I don't think we have anyone on Atari scene who could currently do something similar.

[snicklin]

I don't have the time to implement anything but I do enjoy reading about such things.

 

I did some modules at university which means that I could understand if not implement these things.

 

Do you have any links to his conversations as I cannot find any myself.

[Rybags]

The technique used might be highly variable depending on what's to be displayed.

A lot of this stuff seems to use dithering, possibly that is generated at display time.

 

Anything of this on C64 should translate to Atari but for a couple of issues - if it's in character mode then the 128 limitation becomes a right PITA. And, although the C64 method of bitmapping is somewhat clunky and hinders performance in most applications it would lend itself well to cell-based compression methods where Atari's linear layout would be a hinderance.

[snicklin]

The 128 character limit would be a PITA (pain in the "bottom" for anyone who doesn't know) but it wouldn't be insurmountable.

 

You could either stick to 128 characters for the whole screen or you could limit the top half to the first 128 and the bottom half to the 2nd 128.

 

And (with thanks to Wikipedia), you could work from the following "base patterns" as like JPEG does...

http://en.wikipedia.org/wiki/File:Dctjpeg.png

[ilmenit]

I don't have the time to implement anything but I do enjoy reading about such things.

 

I did some modules at university which means that I could understand if not implement these things.

 

Do you have any links to his conversations as I cannot find any myself.

 

Examples:

http://www.pouet.net/prod.php?which=63649#c694082

http://www.pouet.net/prod.php?which=64142#c704430

http://www.pouet.net/prod.php?which=63945#c699608

[Rybags]

No doubt for these productions a lot of the heavy lifting is done using PC tools - although you could probably equally do it on an emulated Atari using turbo speed + H: to speed up the process.

 

Realistically, these things could probably be ported over without too much trouble. Of course, original productions are more desirable but then again, a good few Amiga demos have been ported over and improved for the Falcon.

[snicklin]

Thank you Ilmenit for the links. They were three interesting reads and most definitely something possible on the A8. I didn't read in so much detail about the audio encoding - one step at a time.

 

Rybags, yes, most definitely, the heavy load should be done on a PC. Then you don't particularly need to worry about refining the encoder too much for speed. Just get it working first and then look at speed later.

 

It would be an original production if you use your own video sequence. The encoding techniques will always be slightly different I guess according to implementation.

[+David_P]

With film generally in a 16x9 presentation, what if we use a narrow playfield to keep the aspect ratio: 32 bytes wide x 144 bits tall. That's 18 characters tall, or 576 characters / frame uncompressed. 30 fps = 17280 Bps.

 

Use a well-designed custom charset and you have 256 characters to choose from because of the inverted characters.

 

Heck, you could even add closed captions below in a text window

[snicklin]

Yes, you could do that with a narrow play field. It would give a bit more CPU time.

 

Not all character blocks are updated each frame so this gives more CPU time back.

 

If you just wanted an atASCII art video, you could do it with the closest characters in the atascii character set. If you wanted something more realistic, you would use some JPEG blocks as per my link.

 

I see this as very doable but the PC must do the grunt work.