I actually got the original Duck TM1 decoder compiled and hooked up to a small test bench app. It even runs without crashing. However, it produces unequivocally incorrect output:

I was expecting something more in a solid white for this particular frame. This doesn’t exhibit the normal Duck TM1 bidirectional artifacts that I’m used to seeing. I also wired up a number of different blitting calls with both 16- and 24-bit data, to no avail.

I’ll give the API calls another look to see if I’m missing anything obvious in that department (this approach is unlikely to bear fruit, considering the dearth of documentation). Failing that, I might find myself in the ironic position of using libavcodec’s native Duck TM1 decoder to verify the operation of the original decoder to see what is going wrong with files that are known to work correctly in lavc, so that the original decoder will work completely and yield clues about the large body of problem TM1 files.

Addendum: I decided to enlist Valgrind’s assistance against the adversary. This is the first time I have touched the utility in awhile. Let’s see what it has to say…

  valgrind: the 'impossible' happened:
     Killed by fatal signal

I’m not sure what to think about that. Should I feel proud? Fortunately, leading up to the impossible condition are plenty of other memory errors, all ripe for investigation.

It’s like digital archaeology– understanding the ancient (by internet time) workings of less advanced engineering efforts. Pop culture depictions of archaeology would have us believe that those who toil in the field are searching for that one artifact that would neatly solve the entire puzzle at hand. Historically, perhaps the artifact that came closest to fitting this archetype was the Rosetta Stone, and even that was incomplete (if I’m observing the pictures correctly).

So it is with my current investigation. Much like Sean Connery playing Indiana Jones’ dad searching for the Holy Grail in The Last Crusade, I run the risk of making the Duck TrueMotion 1 algorithm my lifelong obsession. I got that Duck TM1 source code into a state where I could compile it against a standalone program. It only required 38 C source files from the original vpvision source tree and a mess of attendant header files to boot.

Continue reading →