Category Archives: Reverse Engineering

Brainstorming and case studies relating to craft of software reverse engineering.

GDV Video Doc Complete (?)

To the best of my knowledge, I have finished documenting both the GDV file format and the associated video coding format. Now let’s see who can first implement a file demuxer and video decoder for the format. Remember, samples are here.

The only part of the video decoding process that gives me pause is in coding method 8 where the decoder copies a run a pixels from an offset that’s further in the image buffer than the current decoded offset. I believe this is assuming that the current buffer also holds the previously decoded frame. If true, this constitutes a run-based interframe motion compensation scheme.

More GDV Documentation

I have written some more documentation for the GDV file format. VAG’s decoding functions are pretty straightforward but the documentation process gets tedious in a hurry. The more advanced coding methods use a bizarre bit packing method interleaved with data bytes that I can almost guarantee FFmpeg does not support with its native bitstream readers.

I have the game Realms Of The Haunting which is 4 CD-ROMs packed full of FMV goodness using the GDV format. Two other games, Hardwar and Normality, are known to use the GDV format, but with other color depths and perhaps other coding modes. If anyone has those games, I would like to see some GDV samples from each.

Duck TrueMotion 1 Progress

Reimar Döffinger has submitted some work for FFmpeg’s Duck TrueMotion 1 decoder. Now the decoder can output a frame that looks reasonably correct but only paints the left half of the frame:


Sonic 3D Blast - Left Half

So we’re close, we’re very close on this variant. My guess would be that the OUTPUT_PIXEL_PAIR(), which is used in both the 16- and 24-bit variants, is not doing the right thing in the latter mode.

Further, Kostya has fixed some bugs in the TrueMotion 1 data tables that caused decoding problems with the data files from Phantasmagoria: A Puzzle of Flesh.

One more problem (which may or may not be a single problem): I still have several 16-bit TM1 samples that do not decode correctly. They decode as colorful static that looks like this:


Bug Decoding Bug

Duck TM1 actually produces some very curious artifacts due to its bidirectional predictive coding method and this frame does not do the artifact bug justice. Incidentally, this particular frame comes from the the sampler disc for the Sega Saturn game Bug! and the file can be found in the samples archive: http://samples.mplayerhq.hu/V-codecs/DUCK/ (file is bugsampler-m01-16bit.avi).

What could be the problem? Many of the frames toss off the error message “help! truemotion1 decoder went out of bounds” which is a message I added in the early days of development to indicate that the decoder had exhausted the encoded bytestream. My first impulse is that there must be something wrong with the data tables. Seems unlikely, though, since I more or less ripped the tables directly from the original VpVision source. As for the tables I had to retype, Kostya has apparently corrected mistakes in those.

There are 3 large, important tables found in libavcodec/truemotion1data.h: pc_tbl2[], pc_tbl3[], and pc_tbl4[]. Where’s pc_tbl1[]? Darned if I know but I guess the original source didn’t need it or declare it. Tables #2 and 4 begin with 10 and 9 4-entry delta runs, respectively. Table #3, however, has no 4-entry delta runs. Thus, if table #3 were mistakenly selected instead of 2 or 4 and the bytestream had a good number of low-numbered delta indices, the bytestream would be exhausted sooner than it should be.

Where are these tables selected? In TM1’s overly-complicated header decoding logic. It may be time to review that for correctness.