hardeware hungry videos
category: general [glöplog]
At school I once connected a timer to the IRQ on a prety much homemade computer, all it did was reboot on the timer interrupt. I named it AMIGA.
topo: "There are a missing line every other row in the picture" - just in the windows/hires versions which used 640x400. the original videos are 320x200 (actually 320x154 IIRC for most of them). scaling them up to 640x400 looks pretty blocky, leaving out every other scanline avoids that.
the colors look fake because the videos are paletted, with no palette changes while the video is running, so that's 256 colors for the whole video, which certainly isn't much. the codec uses vector quantization (like all early video codecs): it uses a codebook of 4x2 pixel blocks, IIRC usually 2000 such codebook vectors in the first command&conquer. a new codebook is used every 8 frames, which is why even static images would sometimes slightly change about every half second (c&c had 15fps videos). the new codebook vectors are spread over 8 frames to get a steady data rate instead of peaks every few frames. per-frame, it stores which codebook entry to use for every 4x2 pixel block and codes that with a simple, fast LZ coder. the depacker is really simple (as with every VQ codec) which is why it worked on relatively low-spec PCs; packing, however, is pretty computation- and time-intensive (again, as with every VQ codec).
other paletted codecs using vq: smacker (.smk files, was pretty popular during the mid-90s), trilobyte groovy (used for 7th guest), lucasarts smush (used in pretty much all 90s lucasarts games that use video, from rebel assault on) and radius cinepak (also has a yuv 4:2:0 and grayscale mode). the early truecolor video codecs were basically all VQ too, including for example intel indeo 3/4/5, trilobyte RoQ (used for 11th hour and later by quake3/doom3 after graeme devine went to id) and an extended version of westwood's VQA (of course, VQA=vector quantized animation ;) codec used in some of their later games.
it's pretty much the ONLY video coding technique that was actually used for FMV in the early to mid 90s, because more complicated codecs like MPEG just took too much cpu to depack these days.
the colors look fake because the videos are paletted, with no palette changes while the video is running, so that's 256 colors for the whole video, which certainly isn't much. the codec uses vector quantization (like all early video codecs): it uses a codebook of 4x2 pixel blocks, IIRC usually 2000 such codebook vectors in the first command&conquer. a new codebook is used every 8 frames, which is why even static images would sometimes slightly change about every half second (c&c had 15fps videos). the new codebook vectors are spread over 8 frames to get a steady data rate instead of peaks every few frames. per-frame, it stores which codebook entry to use for every 4x2 pixel block and codes that with a simple, fast LZ coder. the depacker is really simple (as with every VQ codec) which is why it worked on relatively low-spec PCs; packing, however, is pretty computation- and time-intensive (again, as with every VQ codec).
other paletted codecs using vq: smacker (.smk files, was pretty popular during the mid-90s), trilobyte groovy (used for 7th guest), lucasarts smush (used in pretty much all 90s lucasarts games that use video, from rebel assault on) and radius cinepak (also has a yuv 4:2:0 and grayscale mode). the early truecolor video codecs were basically all VQ too, including for example intel indeo 3/4/5, trilobyte RoQ (used for 11th hour and later by quake3/doom3 after graeme devine went to id) and an extended version of westwood's VQA (of course, VQA=vector quantized animation ;) codec used in some of their later games.
it's pretty much the ONLY video coding technique that was actually used for FMV in the early to mid 90s, because more complicated codecs like MPEG just took too much cpu to depack these days.
oops, correction, just looked it up and it seems that smacker didn't do VQ after all :)
Thanks for the info ryg! 
Maybe soon I'll be able to do my own fakelooking vids :)
Maybe soon I'll be able to do my own fakelooking vids :)
at least you should be able to play/decode them, ffmpeg (and so also everything that uses libavcodec/libavformat) has a vqa decoder :)
Maybe FLI sequences should have been better for old demos, in 320x200...
Indeed, some of the very high quality demos I downloaded from scene.org (Like the XBOX demos from Assembly) were too heavy for my machine (AthlonXP2600+), which seemed strange to me. Too big to download anyways. DemosceneTV and YouTube for me too!
You can watch those videos you can't play on your PC on cheap DVD-Players that play DivX/Xvid/MP4 stuff. There are a lot of them around.
My 1.8GHz PentiumM Laptop can play 800x600@60Hz Xvid/MP3 without problems. It can't play the H.264/AAC versions I encode without dropping some frames though. But that is for the future and archival purposes IMHO.
If people have a 500MHz Laptop they can't be helped though I suppose... sry.
IMHO it makes no sense to encode a demo that runs in 800x600 natively into something like 400x300 and scale it up to 1024x768 again on the display. That'll probably look rather shitty and you should consider watching the real thing or not watching it at all...
Oh, and Youtube is shit. Stage6 looks rather promising though...
My 1.8GHz PentiumM Laptop can play 800x600@60Hz Xvid/MP3 without problems. It can't play the H.264/AAC versions I encode without dropping some frames though. But that is for the future and archival purposes IMHO.
If people have a 500MHz Laptop they can't be helped though I suppose... sry.
IMHO it makes no sense to encode a demo that runs in 800x600 natively into something like 400x300 and scale it up to 1024x768 again on the display. That'll probably look rather shitty and you should consider watching the real thing or not watching it at all...
Oh, and Youtube is shit. Stage6 looks rather promising though...
