Monthly Archives: November 2005

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.

New Format/Problem: ratDVD

You might think I would hear about these things sooner. Here is a project that has been around since last May that I just learned about yesterday:


ratDVD logo
ratDVD Official Site

From what I gather based on the website, it is a container format that allows complete encapsulation of a DVD for internet distribution. It can retain menus, navigation, subtitles, special features, etc. It apparently also transcodes video to a custom format named XEB. It also uses some custom variant of the Dolby AC-3 codec called AC-3 VS (virtual surround). These details are a bit sketchy since there is not much code available. The developer claims to want to work with the Linux community to come up with a suitable playback solution.

My first impulse at seeing this was similar to my reaction towards Matroska: Special Microsoft operatives attempting to distract open source multimedia hackers from focusing on more important matters. Not to be outdone in the more-work-for-the-community department, the Matroska developers have a draft of a similarly capable system.

An impromptu search on BitTorrent networks reveals that people are already pressing ratDVD into service for its stated purpose, e.g., making available for P2P distribution such niche-interest media content as Star Wars Episode III and full seasons of 24. So I imagine the demand for this format will eventually grow.