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.