This is a story goes back to around 25 years. This a a story of Bogus Party III Video by Bogus Device computer demo that I was making in 1993.

The demoscene is an international computer art subculture focused on producing demos: self-contained, sometimes extremely small, computer programs that produce audio-visual presentations. The purpose of a demo is to show off programming, visual art, and musical skills. Demogroups are teams of demosceners, who make computer based audio-visual works of art known as demos. Demos and other demoscene productions are shared at festivals known as demoparties, voted on by those who attend, and released online (first on BBS and later in Internet). Demo groups spend days or weeks coding their demos. Demos are made for the big screen!

This a a story of Bogus Party III Video by Bogus Device demo I coded at in December 1993 at Party ’93 demo party. It was probably first PC demoscene video compression demo. Remember that this all (including video codec design and coding) was made in around 10 hours in 1993 and runs on 386 and fits to one 1.4MB disk

The idea in this production was to get as much video as possible to fit into the demo as possible. It was the time when computer video was in it’s infancy (no MPEG, no webcams, no video streaming). The idea was to push some the limits in PC video capabilities.

Here is a YouTube video of the demo (made with DOSbox emulator):

Bogus Party III Video Demo facts

- Demo needs at least 400k of DOS memory and 2 M of extended memory to run
- program runs in 386 protected mode using Tran’s pmode dos extender and need at leas 386 processor to run
- runs nicely in fast 386 and 486 computers, too slow in 386SX
- supports Gravis Ultrasound soundcard (GUS) but works without it also (no sound without GUS)

- fits to one 1.4MB 3.5″ disk

- all video material was shot using video camera at party place and digitized with Commodore Amiga video digitizer

- because we did not have fast party Ethernet network, we had to use “Adidas network” to transfer all video material from Amiga to PC in another room (this means all data is saved to 3.5″ disks, and then someone runs with disks back-and-forth between computers)

- all programming was done using 386 and 486 computers using 386 assembly and Turbo Pascal
- all video material is compressed to .jaf format (documentation of file format was included in distribution package)

- first version of demo was made in 10 hours practically from scratch
- first version took part in demo combo and got 15. place in combo (it crashed on the big screen)

Team

Bogus Device was a combination of talented programmers from many Finnish demo teams (Dante,  Brainwash Inc, Jeskola, Gazebo, etc.). The team was founded at Party III in Demark at the end of 1993. The team was founded at party place 10 hours before PC demo competition dead-line. The team was founded so that everybody that had interest and something to contribute could join. Some people had camera, some knew someone who had video digitizer, etc.. There was no clear roles. No list of all people involved has been saved.

We think that demo coding must be fun and we do this for fun. Bogus Device was designed to be a party team that tries to products at party place – this was first and last for this team. The idea is to try to implement crazy new coding ideas quickly time frame (kind of like in modern day Hackatlon).

The demo had intentionally obfuscated the information who made it, so all the names shown on productions are anagrams of the handle and demo team names (anagrams try to be funny).

Video compression

The video was compressed using ad-hoc video compression standard developed just after someone asked how could we compress lots of video to small size that fits to the given limits (1.4 megabytes). After some thinking I got some ideas and starting making my own.

Remember that this was very early days of video compression on home computers. If you never saw a digital video back in the 1990s, you’re not alone. The files were large and the downloads were slow. The MPEG-1 standard, established in 1992, is designed to produce reasonable quality images and sound at low bit rates. The MPEG-1 standard was standardized in 1993. But it was not widely used or available for normal computer users (no free open source video codecs then). Also an Intel 486 or Pentium would grind to a standstill trying to make sense of a simplistic Motion JPEG or MPEG-1 video, even at very low resolutions.

What I needed was something that would be simple to implement, push something viewable to screen and the decoding would be simple enough to be handled by common 386 computers. I was “crazy” enough to try to come up with something of my own, just having enough confidence and read something on video compression.

What I figured out that to be able to do something useful, I needed to figure out how I can determine the difference between different video frames, and store only the information what has changed. That would save a lot of data compared to whole picture. I could also maybe able to just skip storing the smallest changes (store only when pixel value clearly changes). Other tricks I used was just to have gray-scale video video that has limited number of different gray-scale values (in this case 16 values). I can also keep the amount of data low by keeping resolution low (114×82 and 160×100 pixels). I also found out that I don’t need full 24-60 Hz picture update rate, I could have something lower like 15 pictures or even less per second and people still see as video.

JAF video format decoding

I came up first with my own JAF video data format that was even documented on the text file that was disributed with the demo. The name JAF was originally “Jeskola Animation Format”, because it first looked that this could be Jeskola production. From the original documentation:

“JAF format is designed for compressing low resolution digitized vide animations which have 16 gray levels. Format can also be used for any 16 colour animation also. The 16 gray levels were chosen because our material we needed to compress was at that format. There is nooption for other picture formats.”
“JAF file contais only picture data. There are NOT any fancy header block which contains information about file. So the infomation aboupicture size and number of frames etc. should be stored elsewhere.”

“JAF animations can be concatenated simply by copying those files after each other with dos copy command”

“The file consists of data blocs which have following format: A B C

A = number of pixels to skip (one byte number)
B = number of data bytes in C block (one byte number)
C = the pixel data of changes between pictures”´

The pixel data organized so that each byte consist of two screen pixel data. Bits D7-D4 have the value for left pixel and D3-D0 for right pixel.”

The file format is very easy to decode. I wrote a video decoding routine that decoded the picture to the screen and even did some “anti aliasing” to make picture smoother. When you smooth out the edges between pixels when you scale the video to full screen resolution, the video looks sharper than it really. The decoding anti-aliasing could also could generate more gray scales than was on original video.

The decoding routine was written using 32 bit Intel assembly language.

Video compression software

The most straightforward way to store the animation is to compare two pictures which come after each other and store those are which change. This compression should work effectively with  computer generated images that have static background and small part of picture change.

Video images from analogue video sources (like VHS vdeo camera) can be compressed in the way, but they don’t always compress that well because the noise in source data. Noise in video signal causes changes in picture data even when the picture should be static (problem with recorded video and cheap digitizers).

To overcome some of those problems I used some video pre-processing and lossy video compression. I first used some filtering (low pass, medial filter, I don’t remember exactly) before I scaled the pictures to final resolution (114×82 or 160×100 pixels).

To actually do the video compression, I used lossy compression on storing the differences between video frames: I store only the pixels which change enough to be well noticed. I could leave out pixels that change in their brightness only slightly, or the pixels are just single pixels that might not be noticed to well.

In this way I cut down the number of pixels I needed to store quite significantly. Lossy image compression is always compromise between compression ratio, picture quality and processing speed. I tried different setting for my compression code for different video parts.

I found that in practice my lossy compression can sometimes leave annoying pixels stay not changing for long time and some other artifacts. On some video material this was very annoying, and on some other material it looked as “artistic” video effect. I left some of the “artisticly flawed” material intentionally to production, but for some material I aimed for better. I developed a system so that in most frames I do the compression in pretty lossy way, but after every N very lossy frames there will be one frame that is stored with less compression. In this way those less compressed frames will clean up the messy pixels “that too much” compressed frames had left.

Generally I tried to chose quite high compression and fast decompression speed, so the quality was not best possible. In my final compression program I had a pretty aggressive noise filter to filter out some usual error caused by video tape and cheap digitizers. The system filtered out pixels which have no nearby  pixels which change. Those pixels are usually caused by transient noise is video system. In this way the picture quality become better and compression ratio became better. I know that I might loose some of the smallest details of the picture, but the picture looked better with filtering. Even thought the video compression was simple (no DCT, no movement vectors, no different frame types) it worked better than I originally expected.

The video compression program was written using Turbo Pascal. The program and parameter for it was fine-tuned for each video part that was compressed to get the results wanted.

Relation to other video demos

Bogus Party III video is hardly the first video compression demo in demoscene, but is was one of the early ones and first one released on big party for PC. The idea for making this product was inspired by Amiga Demo 242 by Fairlight & Virtual Dreams, that was released in summer 1993 and used video clips as part of the demo (view video of demo).

Then then half year later video we decided to make this video compression demo on PC that would pack even more video material to the same file size.

At the same party for Amiga compo there was released a famous 9 Fingers by Spaceballs demo that used a lot of video that had a new twist on video compression – the raw video material was encoded to become vector graphics on the demo (view video of the demo).

Few years later Finnish demo team Coma made some more artistic PC demos that used video as integral part of their art. Most well known are their products ‘The control’ by Coma (view video) and Paimen by Coma (video video). COMA (shortform for Community Of Moral Advancement) is a Finnish pc demo group formed by previous members of Dante. I was a member of Dante in 1993. I suspect what Bogus Devices did once had some effect on what Coma did later at their own style.