Category Archives: On2/Duck

Quacking Like Duck

I don’t learn very quickly. A good illustration of this personal shortcoming is my ongoing battle with the Duck TrueMotion 1 video codec, a conflict that is well into its 8th year at this point. This was one of my first exposures to the field of multimedia hacking as I discovered some Duck TM1-encoded AVI files on select Sega Saturn console games all the way back in 1998. I found a few Japanese Windows programs that could play the files. Early in my multimedia hacking career, I worked hard to reverse engineer the TM1 algorithm.

In 2002, On2 (formerly Duck) open sourced their VP3 codec (which would later become Theora). I kept stubbornly trying to RE TM1 from the binary when Alex notified me that On2’s open source VpVision package contains the decoders for TrueMotion 1 and 2. It also included the decoders for Duck DK3 and DK4 ADPCM, both of which I successfully had RE’d from binary code, and at around the time that VpVision had been released as open source.

The VpVision source has been quite valuable in RE’ing both the TM1 and TM2 algorithms. It’s extremely difficult to understand, however, as is often the case with code produced on a deadline. Some TM1 files still fail to work correctly with the native FFmpeg decoder. I always thought it would be useful if I could compile the code and run it in a step debugger, or perhaps profile it with other tools, in order to sort out the correct operation when decoding certain files. But the code seemed like such a mess that I didn’t think it would compile on Linux. It looked like it would only compile on Windows or maybe Mac, and only with some effort.

Continue reading →

Duck TrueMotion-S

The FOURCC List affords us many scattered bits of intelligence on various codecs used throughout the history of multimedia technology. Duck/On2’s early TrueMotion codecs are assigned a variety of FOURCCs– such as DUCK, TMOT, and PVEZ– which may or may not refer to distinct TrueMotion variants.

Serge van den Boom informed me that the 3DO version of Star Control II made use of some TM variation named TrueMotion-S. The open sourced Star Control II effort includes code to decode this video. The relevant files are dukvid.[ch] in this directory. A sample (logo.tar.bz2) is available in my Duck TM1 samples directory. Interestingly, the bundle actually contains 4 files. The .duk file has all of the video data stuffed together. The .hdr file contains some header information. The .frm file contains the frame offset boundaries for the .duk data file. And the .tbl file apparently contains data for initializing the delta table to use for decoding the data.

I am not yet sure if the data is decoded to 16- or 24-bit video. If someone is willing to jump in and figure this out, it might help us sort out the remaining pieces of the generalized Duck TM1 decoder for FFmpeg. It stands to reason, however, that the data is 16-bit at best since Star Control 2 is such an early game in terms of the multimedia genre. The game is reportedly one of the earliest games that Duck TM1 was used for so it may be on the bottom rung of the Duck predictive evolutionary ladder.

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:

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:

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.

Duck TrueMotion 1 Redux

Some time ago, Alex Beregszaszi and I created an FFmpeg video decoder to handle Duck TrueMotion 1 data. However, there are two major variations of this data format: 16-bit and 24-bit. The FFmpeg decoder presently only handles 16-bit data. There is a non-negligible number of games from the mid- to late-1990s that used this format for their FMV and many of them use the 24-bit variant.

Virtua Cop 2, Sega Saturn,
one of the Duck TM1-using games that uses the 16-bit variant