Archive for the ‘Game Video’ Category

A quick look at PDQ2

Friday, October 21st, 2022

So there’s this new service discmaster.textfiles.com for searching for files from some old disks and discs at archive.org and out of curiosity I took a look at what it offers.

While it’s physically impossible to check all hundreds of millions of files it indexes (even just videos), I took a look at one rather curious category called aviAudio. There are about six hundred files of such type found so I decided to check them to see what kind of beast that is.

Some files turned out to exactly AVI audio files—AVI files with single stream that turns out to be audio (I don’t know why but this happens). The rest of the files were AVIs with unrecognized video track (just what I was hoping for!). One set of the samples come from some game with IPMA codec, other sources mostly feature Motion Pixels video (which is horrible both to RE and to support so I’d rather not touch it), one sample was special “codec” for some russian erotic game (which means complete garbage even by russian game standards) that is really just obfuscated Indeo 5. And finally there was a single PDQ2 sample (from some Incredible Hulk game demo from 1997).

An interesting thing is that it’s a DOS game with built-in AVI demuxing and decoding of this codec. The codec turned out to be a lot like various lossless codecs (so its FOURCC probably stands for something like “pretty damn quick codec, version 2”). It splits video into 4×4 tiles and emits up to three streams stored one after another: tile opcode (copy previous tile, copy previous data with an arbitrary offset, skip tile, raw tile), variable offsets and tile pixels. Additionally frame data may be packed further with LZ77-based scheme. As I said, a rather familiar scheme for lossless video codecs and it makes me wonder whether it’s a codec developed specifically for the game(s) or it was borrowed from somewhere else.

Another bunch of interesting game codecs

Monday, October 17th, 2022

While Iran wages a proxy war with Ukraine (and I can easily believe they’re not against doing it to the last russian), I’m still trying to distract myself by looking at various video formats in games I have no intention to play.

Finding games with unknown formats gets harder and harder (or at least more tedious). So here are two games with an interesting approach to video compression.

Dark Earth packs frames as separate planes with 5-bit components and each plane is compressed using a peculiar modification of LZ77 scheme: depending on a bit set, it either codes a run or a forward reference in either the same or previous buffer. Additionally it codes it using non-bytealigned stream (run mode is coded in 13 bits and copy mode takes 25 bits).

There’s also Defcon 5 game (the one from the mid-1990s, do not confuse it with a game with the same name but from a previous decade). This one employs a different method I don’t remember seeing anywhere else: painting squares. Of course you’re used to various codecs splitting tiles in blocks and filling them (from older codecs using quadtrees to H.26x and its rip-offs). This one does it differently though: there is a fixed set of tile sizes selected for each video (I’ve seen only 32, 16, 8, 4, 2 set though) and frame data is essentially a list of commands telling at which offsets to paint a tile of this size with a given colour (those offsets may be completely arbitrary). It may be not the most efficient compression algorithm but it’s quite interesting. Also the container specifies palette as fixed and changing colours—first part is stored in the header and the second part is transmitted with each frame. Again, it’s not something extremely effective but I can’t easily remember any other format doing it that way.

I’ll probably try to do something different next time but I consider time spent on looking at these formats well-wasted.

Looking at yet another game format

Saturday, October 15th, 2022

Since I have nothing better to do and I don’t feel a desire to write a lengthy rant about what’s wrong with this world (beside the fact that russia still exists of course), I keep looking at various games I can find in order to see if they have some interesting format. Last time I’ve managed to locate an elusive Indeo IVF sample, now it’s rather curious FMV format.

So there’s an unpublished PC game called Highlander: The Last of the MacLeods which is apparently some kind of 3D action game based on the animated series (one of those, the franchise seems to have a lot in it beside the one good movie). And it turns out that it has a three dozen of FMV clips in proprietary format (stored inside mov.dat but extracting them is trivial).

From technical point of view the format is rather simple but video compression is rather peculiar: each frame in coded independently by painting each 4×4 block with 1-16 pixels using a certain pattern. That’s common but this data is packed with a simple history-based method: depending on a flag a value is rather read raw or reused from a history buffer depending on two previously decoded values. And now there’s a twist—this compression is applied twice.

Overall, it was fun to look at the format even if I don’t care about the game itself and the video quality is rather poor (probably thanks to the rather low bitrate and fixed palette all those FMVs share despite half of them being digitised animation clips and half of them being recorded in-game 3D animation). Still, now I can play the files with NihAV if I ever get such desire.

German PEGs

Thursday, September 29th, 2022

Having said everything I could on the current political situation, I returned to looking at random codecs and I found one with a curious name.

The name is DPEG and it’s used in at least one random game I’ve never heard of. It turned out to be a rather simple tile-based codec with raw intra frames and inter frames that employ RLE and motion compensation.

So nothing interesting but then it struck me: wait a bit, I remember REing a codec with almost the same name, block-based RLE coding approach and also from a German company (a different one though).

And there’s this Fraunhofer society involved in MPEG Video and MPEG Audio (different branches though)…

So what’s the German fascination with naming codecs [A-Z]PEG and how many out of 22 possible codecs are really implemented?

Looking at some FMV formats

Wednesday, September 7th, 2022

It’ll take a long time to liberate Ukraine from the invaders, so while it goes on I have to entertain myself somehow.

Since I had nothing better to do I looked at two FMV games—Deadly Tide and Hot Wheels: Stunt Track Driver. Both of them have their levels packed as video data with some additional control data.

Deadly Tide is more complex one with its L96 format: it defines a resource file with several possible sub-levels and three different video streams (something like 320×240, 160×120 and 80×80) compressed with Cinepak plus half a dozen of various control resources and audio stream.

Hot Wheels uses JAM format which is a series of compressed chunks. 0 – frame data, 2 – palette update (strangely enough it updates palette not from the start but rather to the end), 3 – some control data. Frames are stored either unpacked, packed with LZSS or packed with differential LZSS (in this case copy operation takes bytes from the previous frame). Oh, and it uses obfuscated WAV files for audio that I didn’t bother to look at.

I’m still looking for an interesting format to RE, meanwhile those two were at least somewhat interesting.

Ripper: Smackered AVIs

Thursday, September 1st, 2022

Recently I’ve encountered a review of an old FMV game called Ripper and my professional interest was to look what formats it uses. Well, it turned out to use Smacker and AVI. And those AVI files are their own format that uses Smacker in perverse way: it stores a sequence of commands with 14-byte header that control video playback. The first dozen of commands are usually “fill audio buffer with this data” commands and there’s one command for initialising video that includes full Smacker header inside its payload. From what I see it abuses Smacker decoder by constructing file on the fly using the data from the commands (I’m pretty sure the following commands have video frames in their payload).

I’m not sure if I’d want to pursue it further and document it let alone adding support for it in NihAV but that format was definitely something.

A quick glance as Titanic: Adventure Out Of Time resources

Saturday, July 30th, 2022

Recently somebody asked me how to play MOV files from the game. My answer was that I don’t know and we need to wait until somebody reverse engineers of that engine. Meanwhile I took a second look to see if I missed something apparent (spoiler: no).
(more…)

Looking at Voyeur II videos

Saturday, March 26th, 2022

Here’s a result of another attempt to distract myself from the thoughts whether Ukraine will kick out the invaders in a steady manner or if the führer will resort to chemical or nuclear weapons.

So I decided to take a look at random FMV game and Voyeur II came to my attention. From what I know the first instalment uses RL2 videos and is supported by ScummVM. The second game, however, uses a completely different format and packs most of the data into few volumes (80% of the data on CD is in single diskN.vol and the rest of the data is mostly in endings.vol and slides.vol).

Those volume files turned out to be archives as expected, and the content of those archives turned out to be kinda archives too.

The data stored in volume files is bits of video usually one or two seconds long but the way they’re stored is somewhat peculiar. The header defines (always?) four streams, two of which are dummy ones and the other two are audio and video correspondingly (and they can turn up in any order). The rest of the file is a collection of blocks with 8-byte header defining block size and to which stream it belongs to—and yes, blocks for different streams may be interleaved. Audio stream seems to be plain PCM and video stream is a sequence of frames (thankfully, 14-byte frame header contains packed frame size).

So, what about video compression? It’s RLE with a small twist: there are intra- and inter-frame RLE variants and they can use double-pixel mode (i.e. where you skip or fill the doubled amount of pixels and for raw pixel data each pixel is repeated twice on output). Inter-frame RLE compression has skip codes (i.e. at first you read how many pixels you need to skip, then you read either raw pixels to update the frame with or RLE data depending on opcode, and then you read next skip code and repeat it until the end of frame). Additionally it seems the video is always 320×160 and only video height is stored in the files.

All in all, the most interesting part there turned out to be the logical organisation of data and not the RLE compression or actual videos (I checked random couple of dozens of samples from over two thousands total videos and nothing piqued my interest). Maybe I’ll find something more interesting next time.

Revisiting legendary video format

Tuesday, March 22nd, 2022

So Ukraine is still holding against self-proclaimed second army of the world (though by this time it has earned the title of the most atrocious and hateful military force in the world, the title that had to be taken from the SS troops). And while I can’t stop worrying about my relatives, home city and home country in general, I still need something to distract me at least for a while.

While watching some video about video games, I spotted something surprising in it: a cutscene in Callahan’s Crosstime Saloon. While I worked on supporting Q video format in Legend Entertainment games I remember seeing just one video from that game (the animated title). So I tracked a full CD version of the game and discovered some surprising things about it.

First of all, it turned out to be version 7 of the format (and I’ve seen only versions 3-5 before). Second, it turned out to be mostly the same as version 5 but with F8 opcode in use. This opcode turned out to be used for compact representation of the colours where a code either introduces a cache of up to 15 colours or reuses some previous table and then tile colours are stored in a nibble. Third, beside cutscenes there are a couple of videos of some lady with a small child that look like a home video sneaked in by some developer.

There’s still a lot of work to be done to support it properly (because of the various quirks of the format) but I’ve managed to decode all of the videos from the game already, some of them even without artefacts. This is a pointless but fun distraction after all.

Looking at SMUSH/INSANE formats

Thursday, January 6th, 2022

As some of you might know, I had an interest for various game formats for decades (and that’s one of the reasons that brought me into opensource multimedia). And those formats include videos from LucasArts games as well. Actually SMUSH is not an ordinary video format but rather a sub-engine where both audio and video are objects (background, sprites, main audio, sound effects) that should be composed into final audiovisual experience. INSANE is the next iteration of the engine that became simpler (coding full frames, only one object per frame, just one codec, 16-bit video instead of paletted one) but it shares a lot in common with its predecessor.

As expected, the main source of information about those come from ScummVM (and one of their developers made smushplay to play the files in stand-alone matter). There’s a personal story related to that: one Cyril Zorin meddled with some formats from LucasArts games and wanted to add INSANE support (for Grim Fandango but it’s the same for all other games using SNM format) in FFmpeg, sadly he could not stomach review process there (which is hard to blame him for) and abandoned it; some time later I picked it up, added support for SMUSH codecs 37 and 47 (the ones used in adventure games) and got it committed; years later Paul B. Mahol (of future Bink2 decoder fame) added VIMA audio support to it.

Yet there are more games out there and some of them use different codecs, for which details were not previously known. So I decided to finally reverse engineer them to see how the development went. My implementation in NihAV is far from being perfect (there are many issues with transparency and coordinates) but it can decode all files I could encounter with very few exceptions.

So, let’s look at the codecs used for image coding. Audio is rather boring: there’s very old PCM format in SAUD chunks, scaled PCM audio in IACT chunks and VIMA is IMA ADPCM with 2-7 bits per step.
(more…)