Yeah, you’re jealous.

The back of the hat has an Easter egg for video codec nerds– the original Duck Corporation logo (On2′s original name):

Former employees of On2 (now Googlers) were well-represented. It was an emotional day of closure as I met the person — the only person to date — who contacted me with a legal threat so many years ago. He still remembered me too.

I met a lot of people involved in creating various Duck and On2 codecs and learned a lot of history and lore behind then– history I hope to be able to document one day.

I’m glad I got that first rough draft of a toy VP8 encoder done in time for the meeting. It was the subject of much mirth.

Pictured: All the proof you need that VP8 is superior to H.264
Update: The preceding comment is meant in sarcastic jest. Read on

The Official VP8 Facts:

• VP8 is superior to H.264. Source: On2′s website, many PSNR graphs.
• VP8 is free from patent worries. Source: On2′s website (“no patent-pool royalty hassles”).
• VP8 delivers objectively better visual quality than H.264 at the same bitrate. Source: Video encoded in On2 VP6, created by On2, posted on On2′s website.
• VP8 can be implemented on low-power hardware. Source: DSP Design Line article authored by On2′s CTO.
• VP8 uses golden frames (just like every On2 video codec since VP3). Source: On2′s website.
• VP8 uses loop filtering (another cornerstone of every On2 video codec since VP3). Source: On2′s website.
• VP8 is scalable to many cores. Source: On2′s website.
• VP8 produces objectively better results than even x264. Source: Again, On2′s website. Sorry, my x264 pals, but they have charts and graphs to back them up, so, you know…

That’s pretty much all we know about On2 VP8. Notice a common theme? That’s right: Everything we know about On2 VP8 comes from On2′s own publicity material. As of yet, we have no samples encoded in the format, and we certainly don’t have any public encoders or decoders.

So, yeah, you can write me off as being consistently annoyed when the VP8 topic crops up. Take a look at the subtitle of this blog: “Topics on multimedia…” Codecs are my business (well, hobby, anyway) and my multimedia pals and I have cataloged around 200 different video codecs on our little wiki. Call us codec snobs but we like to know technical details surrounding codecs. Or, failing that, we like to have samples we can study along with maybe a binary decoder and/or encoder so we can evaluate the suitability of the codec for certain tasks. Thus far, all we have to go on is On2′s own word about how awesome their technology is. It’s a bit odd to see so many people taking a (non-Apple) company’s claims at face value.

Do you believe the marketing material? As a baseline, you’re invited to read the VP6 and VP7 whitepapers which provide similar objective proof of those algorithms’ superiority over H.264 and other standard codecs.

Different Requirements
From most of the stuff I have been reading (articles, blog posts, and ensuing comment debates), people are lapping up the marketing material. I was incredulous until I realized that most of these observers are simply interested in different things than I am.

I — and, I suspect, many of my multimedia colleagues — are salivating for some more solid technical details surrounding this codec. It’s what we live for. I need to recognize that most outside observers take the view that a video codec is a video codec is a video codec, i.e., they’re all more or less the same and fairly interchangeable. The hope is that On2 VP8 will, at long last, provide patent and license purity that all relevant stakeholders (Google, Apple, Microsoft, Mozilla) will be able to agree on. Quality? That would be nice too, but it seems to be a foregone conclusion that VP8 offers more than enough quality, especially when considering that Theora is based on VP3, which many consider good enough, and VP8 has a higher number than VP3. Ergo, VP8 must be 5 times better than VP3/Theora. Or 5 more better. Or something. And besides, On2′s own marketing materials explicitly state that VP8 is better than H.264.

Flash-Killa
It would be disingenuous to omit the Flash-killer angle driving so much of the fervent anticipation surrounding the VP8 speculation. VP8 goes open source => all major browsers adopt it overnight as a standard video codec for HTML5 video => blight of Adobe Flash is eradicated the following week, since Flash’s only use is as a naive video player. Things move just that quickly. I’ve covered this ground already, i.e., how all of this HTML5 stuff is totally going to crush the stuff I work on at my day job.

What Is It, Really?
There’s too much speculation out there surrounding On2 VP8… but that won’t stop me from adding my own: Since, to my knowledge, VP8 has never actually been licensed or used outside of On2, the engineers could still be tweaking it behind the scenes, or even overhauling large segments of the algorithm. The list of publicly discussed features doesn’t explain a whole lot about the overall codec operation.

Writing this article motivated me to re-read and carefully study that DSP Design Line article and I must confess that there are some interesting tidbits in there. One item that caught my attention was their concept of SIMD without dedicated SIMD instructions. It’s nice to see On2 getting back to their roots– this concept forms the basis of On2′s very first video codec, Duck TrueMotion 1 (effectively VP1).

The DSP Design Line article is far more fascinating than any of the literature on On2′s site. The article paints a picture of a powerful and flexible codec that is suitable for low, medium, and high bandwidth applications and whose decoding algorithm can be scaled to operate realtime on low power, mobile CPUs all the way up to beefy, multicore desktop machines, all while offering efficient and accurate compression. If the codec offers all of these technical benefits, plus truly free licensing terms and is satisfactorily patent-free (or indemnified), I look forward to singing VP8′s praises.

But for the sake of discussion, let’s run with the idea: Let’s assume that Google open sources any of On2′s intellectual property. Be advised that if you’re the type who believes that all engineering problems large and small can be solved by applying, not thought, but a mystical, nebulous force called “open source”, you can go ahead and skip this post.

The Stack

I like thinking about specific multimedia problems on this blog because people who read this blog often know beans about multimedia technology and are equipped to think about the issues involved. So imagine that Google open sources On2′s video codecs. What does that mean? Free web video for all! Well, not so fast. There are a few issues to consider. While most observers can only see as far as the video codec portion, there are, at the very least, 3 things to consider when putting together a video for consumption:

1. Video codec — how are the pictures compressed and encoded?
2. Audio codec — presumably, you want some sound to go along with those moving pictures
3. Container format — there has to be a method for tying together audio and video for delivery and playback

So, Google open sourcing On2′s video codecs would address the first need. What about the second need? Obviously, MP3 and AAC — which represent the standards today — would just get the open video argument back to square one. “VORBIS!!!” would be the reflexive cry of the open source checklister crowd. Indeed, this just might work. Vorbis has problems and shortcomings but is generally considered a reasonable replacement for MP3, WMA, and AAC, at least for desktop computing applications (we’ll think outside of the desktop arena a little later). Actually, there is another option: Did you know that On2 dabbled in audio codecs at one time? They developed 2 IMA ADPCM variants (DK4 and DK3) which wouldn’t be seriously considered for this application. They also have something they simply called Audio for Video Codec (inspired). I know we have samples of the latter somewhere.

How about the last component on the list, the container format? How about Ogg? Ogg is not usually considered a general-purpose container format. It would require extension to be capable of storing any new codec (I argue that a container is not general-purpose if a demuxer has to have special code to handle every codec that could possibly be inside, which is pretty much how Ogg works). The prevailing container format on the standard MPEG side is the QuickTime-derived MP4 format. This could hold new On2 data (and probably does so in various applications today), but I’m not sure about encoding Vorbis data.

This is the part of the post where I learned something new (which is a big reason I like writing these blog posts). My theory was that there was no agreed-upon method for storing Vorbis audio data in QuickTime/MP4. But if there were something resembling a standard on this front, FFmpeg would implement it. So I tried transcoding an audio file to a Vorbis encoded .MOV or .MP4 and not only did both take, both played back in FFplay.

Mobile Considerations

Okay, so the MP4/VPn/Vorbis stack might just be crazy enough to work… in the desktop realm. There’s the emerging world out there collectively called “mobile” — cell phones, netbooks, tablet computers, and more — and they all want to be able to show video. They often do this with dedicated processors that are designed to decode the standard MPEG codecs (H.264 and AAC). I’ve read from various observers who wave away this problem of decoding a new stack on mobile by invoking 3 magic letters: ‘DSP’. This is a good example of how a little knowledge can be dangerous. There seems to be a general misconception that DSPs (digital signal processors) are extraordinary devices that can be programmed to accelerate the decoding of any video or audio codec. The reality isn’t so simple.

I confess, I don’t know to what extent today’s generation of mobile devices employ general-purpose, programmable DSPs vs. custom MPEG ASICs but that would make for an interesting survey. While I’m confident that any device in the “mobile” category could likely be programmed to play data encoded in the MP4/VPn/Vorbis stack, the issue then becomes battery usage– how long can the custom programmed system play video vs. how long could the same unit play by pushing MPEG data through the custom ASICs? Again, don’t know, but it would be interesting to find some numbers or develop experiments to test this.

The Google/YouTube Factor

Observers obsess about the Google/YouTube angle in all this, which is understandable due to the large mindshare that YouTube controls when it comes to web video. “Control the YouTube video format, control the future of the internet,” or so the popular sentiment seems to go (be advised, however, that YouTube doesn’t necessarily represent as much online video viewing as you might think). One received bit of wisdom is that Google already stores multiple copies of every video in various formats, so one more shouldn’t be any big burden. Our thoughts are not Google’s thoughts, neither are Google’s ways our ways (I’m sure I read that somewhere). It’s hard to know exactly how YouTube operates, but we can always poke at it to find clues. Outside of Google, few people are as interested in YouTube’s operation as Dark Shikari of x264 fame and here are some interesting tidbits he has empirically determined. Of interest to this discussion is the following: “They could have saved 30-50% on bandwidth by offering an H.264 High stream for PC viewers, but they didn’t because it would have required they keep around a separate stream.” This indicates that Google doesn’t necessarily consider disk space to be limitless, at least not in the disk space vs. bandwidth trade-off calculation. I know for a fact that YouTube also keeps around the original copies of all the videos that have ever been uploaded (because certain videos that were not transcoded properly years ago are now correct). However, YouTube only needs to keep one copy of the original around (and maybe a backup somewhere) while transcoded videos need to be shipped off to any number of content distribution nodes.

This doesn’t rule out the possibility that Google could push an MP4/VPn/Vorbis stack as the new web video standard and maintain parallel MPEG & open copies of each YouTube video. But it’s not a foregone conclusion that it would be a drop in the bucket for Google’s resources. As a programmer for a large technology company, I endure more than my fair share of outside advice regarding what my company ought to do for the benefit of everyone else except the company. I can only imagine how frustrating it must be for Google people to constantly read declarations along the lines of, “Google needs to spend untold millions of its own money in order to do what I believe is right,” especially considering that whole “don’t be evil” charter/moral bludgeon.

In Closing

Anyway, I just wanted to think about these issues from a purely technical standpoint, a perspective that I really don’t see discussed anywhere else (except when I read Dark Shikari try to talk sense into online forums where video discussions abound). I don’t have all the facts but I enjoy not only searching for them, but also figuring out how to search for them.

Check out Silvia Pfeiffer’s recent blog post: Google’s challenges of freeing VP8. In addition to wondering about some of the same technical issues I have outlined here, she addresses the tough legal and patent issues surrounding a possible open sourcing. And none of this even begins to address the political and social issues surrounding the adoption of such a standard.

Google owns On2. They are going to open source all of On2′s codecs.

Well, no. Google does not own On2. They made a bid for the company last August, sweetened the offer somewhere along the line, and saw the offer accepted 2 days ago. From all of my reading, the deal is still not closed (though many reports are optimistic that today is the big day; and what do you know? As I was proofreading this entry, today turned out to be that big day.).

Whatever. Google is going to own On2 soon and then they’re going to open source all of On2′s codecs.

What on earth makes you think that they would do that?

Everyone is saying that Google is going to open source all of On2′s codecs.

Take a good look at this lengthy list of companies that Google has acquired. Can you name 3 instances where Google acquired a company with proprietary software technology and promptly released said technology as open source? I guess Etherpad counts as 1. That’s not exactly a trend.

Google is going to open source VP6, VP7, and VP8, all of which come from the lineage of VP3 (the name indicates that, so it must be the case), which is what Theora is based on, which has been indisputably shown to be better than H.264, the current web standard. Therefore, these later codecs are going to be even more awesome than Theora, which is already more awesome than H.264.

Okay, it helps to understand how misleading those alleged benchmarks were. The distilled thesis that Theora is better than H.264… you know what? Go ahead and believe that Theora is technically superior to H.264 if you wish. It doesn’t matter. People who matter (i.e., decision-makers) know better.

Google is going to open source On2′s codecs and that’s going to kill Adobe Flash Player.

Every week, there’s something else that’s supposedly going to be the final nail in the coffin of what I work on at my day job. This week, the buzz was all about On2 (at least among people who grasp what a video codec is). Anyway, what makes you think that the open sourcing of said codecs would kill Flash Player?

People only use Flash Player to watch video on the web, and the only site that serves video on the web is YouTube, and Google owns YouTube.

You’re welcome to extrapolate general usage models based on your own perception and behavior while ignoring research from outfits who study these trends all day. I want to get back to this core assumption that Google is interested in On2 so that they can open source On2′s video codecs.

Due to the magical power of open source, as soon as Google open sources all of On2′s codecs, the open source community will embrace the code and integrate it into every relevant piece of software everywhere.

Okay, this is where I must issue a dire warning: Be careful what you wish for. You’re salivating at the prospect of being able to read and hack around with On2′s code? You can get a taste of On2′s code here: Download their VpVision product from back in the day. It includes VP3 (adapted to become Theora) as well as VP1 and VP2 (née Duck TrueMotion 1 and 2) along with 2 ADPCM audio codecs. Go ahead and try to make it compile. Some very talented multimedia hackers have studied it for 8 years and still haven’t figured out everything about those codecs in that code.

In summary: I don’t think Google is buying On2 so that they can open source On2′s codecs. I have absolutely no insight into why Google cares about On2. But then, neither does anyone else commenting on the matter. I’m just a codec nerd who has been watching On2/Duck for nearly as long as they have existed. Most people claiming that Google is going to open source On2′s codecs only seem to be citing as evidence their own wishes as well as those of their fellow bloggers/tweeters. But, hey, that’s the internet for you.

See also:

• Reflections on On2
• HTMLOL5 Video
• Assorted fruitless efforts to understand On2/Duck codecs (with the occassional success)
• That one time that On2 threatened to sue me: I ain’t mad at ya, homey; it’s all right

So Google has announced its intention to purchase On2. Wow, it feels like the end of an era. It seems like I’ve had some relationship with On2 for the entire 9 years I’ve been into multimedia hacking. Something that got lost in yesterday’s coverage and commentary was that On2 started life as the Duck Corporation, also a codec company. During this period, they largely focused on gaming applications. But I’m pretty sure that RAD Game Tools kicked them out of that market with their Smacker and Bink technologies. However, files encoded with the Duck’s multimedia codecs were among the first I studied back around 2000-2001. So that always makes me sentimental.

Somewhere along the line, they transformed into On2 and created VP3. Near the end of 2001, On2 announced they would release VP3 as open source (they were working on VP5 around this time), hoping that some nebulous open source community would make something useful out of it. I’ll have you know that I was that open source community for quite awhile. I delved into their code and wrote the first documentation about the codec bitstream and decoding process which would later serve as the foundation of the formal Theora specification. Then I wrote an independent implementation for FFmpeg.

And I never judged the codec either.

Ah, On2. People always worry that I’m going to get sued to death for writing this blog, but On2 remains the only company that has ever leveled any kind of legal threat against me. But I ain’t mad at ya. Later that same year, I went to work for Adobe where I gained official access to the very algorithm I was trying to reverse engineer. Strange how things work out.

And now I work on the Adobe Flash Player, arguably the single biggest use case for any technology that has ever come out of On2. At least, so far. What does Google want with On2? You’re asking the wrong person. My company’s official answer is to contact On2 or Google.

There has been no shortage of speculation on Google’s motives, most of it misinformed at best, outright silly at worst. Dan Rayburn has a fantastic “day after” piece debunking myths about the deal: Debunking Myths, Questioning VP8′s Quality. His piece, however, does not address the idea floating around that Google will open source all of On2′s technologies. That’s certainly in keeping with the idealistic Google image of a promoter of free and open technologies, even if it would cause a lot of extra work for FFmpeg developers and multimedia historians alike. But seriously, take a look at the list of companies Google has acquired. Can you pick out any proprietary, closed source technologies they have purchased and subsequently released under an open source license? I don’t recognize Google’s history of doing this. Quite the contrary, it seems that when they buy closed source programs they keep them closed, like Picasa, and in cases like SketchUp, they even charge for upgraded versions.

My colleague Dark Shikari has some choice words to say on this situation. He remains extremely sceptical of any literature On2 has published regarding their codecs’ performance. Remember also the nonsense that circulated a few months ago regarding specious comparisons claiming that Theora is better than H.264 (more accurately stated: Theora can be tweaked enough to encode arguably better video than what YouTube’s H.264 encoder can generate in its default, lowest quality mode; but that entire thesis usually gets distilled into simpler, less accurate headlines). Finally, I have read some speculation that Google might want On2 not for any specific multimedia-related intellectual property, but for their talent pool.

To tie together all of the items in the previous paragraph: It’s possible that Google needs the expertise in cooking codec comparisons to keep the Theora faithful at bay.

For those keeping track, this is On2′s codec scorecard as of this writing:

Video Codecs

If you have ever wondered what happened to VP1 and VP2, you may assume that TrueMotion 1 and 2 filled those positions.

Audio Codecs

It still annoys me that I reverse engineered DK4 and DK3 from binary only to later discover that they were already open sourced along with TrueMotion 1 and 2, and VP3.

Who knows? Maybe they actually are using the classic Duck TrueMotion video codec in JavaFX.

Curiously, there is no word on what JavaFX will use for audio. Maybe logarithmic PCM in au/snd files?

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.

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.

Eventually, I noticed a .txt file somewhere in the original source tree. I have no idea what ‘hfb’ means in the tree so I’ll have a look in hfb/corelibs/hfb/generic/readme.txt:

 Testing

Not so useful. Let’s try a file called iva/iva.txt:

 no documentation yet

Why do I bother? Why do I devote time to a hobby of interpreting the scrawlings that cavemen engineers splattered on their cube walls?

There are 2 copies of a file called ccreadme.txt that have statistics on the performance of various optimized colorspace converters. Someone was obviously proud of that work and saw fit to preserve the numbers for future generations.

Perhaps the only semi-useful document file I found is b_readme.txt, in the main tm1.0 source directory. See, there are 25 of these files in the tm1.0 source directory that have the format bXYmn.c ‘b’ is ‘b’. As for the remainder of the characters, well, here’s where we get into the hieroglyphics– the letters ‘X’ and ‘Y’ represent a character, either s, f, t, or e. What do they mean? 16, 24, 32, or 8 bits, respectively. Huh? Your guess on the mapping logic is as valid as mine. ‘m’ is a number 0-3. This has to do with stretching mode, apparently, but what the modes exactly represent is not clearly explained (“Next character is a mode (0-3) such as same, stretch, and bright (implemented with interpolation or otherwise).”). ‘n’ is a number (0-2) indicating, I suppose, a stretching algorithm (“dumb, smart, or fat-freddy”). I googled for a fat freddy algorithm but only found reference to an aberrant cartoon character. Apparently, even Duck/On2′s algorithms are inside jokes.

The file singles out a particular engineer, one Scott LaVarnway, for his exemplary work in the blitter department, and for one blitter in particular which is extra special and deviates from the naming convention somewhat.

I don’t know how, or if, I missed this file when I studied this codec the first time around. I do remember that it was painful to figure out which of the b????.c files I was supposed to RE. I could tell that different ones were used for 16- or 24-bit source data and implemented different interpolation modes. Now I recognize that, for understanding 24-bit decoding, bft00.c is perhaps my best bet (24-bit source data, 32-bit output target, no stretching, no interpolation algorithm).

So hopefully, that will help in figuring out the 24-bit mode. There is still the matter of many corrupted DUCK TM1 files that don’t work with the libavcodec TM1 decoder. It will be useful to feed them into this decoder somehow and see if it can handle them, and then figure out what the official decoder is doing that the lavc decoder needs to do. I thought I had a good idea of what the relevant functions were until I noticed that these particular functions were static within the file.

Now I think I have the real API figured out, at least partially– I believe I know how the data goes in, though I’m not clear on where the data comes out just yet. The initialization also doesn’t get very far before erroring out. Now I’m just debugging the thing using gdb to figure out why it’s not responding as expected.

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.

I feel a little silly since I discovered today how simple it is to compile the TM1 code on Linux. This is how I got it to compile:

• download and unpack vpvision0.5_source.zip
• ‘cd vpvision/ducksoft/’
• edit private.h/duck_dxl.h and comment out the definition of DXL_GetXImageFrameBuffer() at lines 190-192
• ‘cd tm1.0/linux’
• ‘make’

This produces a nice little file called libtm1.a in the obj/ directory. Similar work could probably get the TrueMotion 2 library into shape, but Kostya already has that algorithm locked down.

In retrospect, I think I had previously opted not to try compiling the smaller modules in the package based on my foul experience attempting to compile the VP3 decoder. That module has a lot of dependencies on Win32 or Mac platform facilities. Eventually, I did separate out and modify just enough VP3 code to make a standalone decoder that compiles with gcc on Linux. I have since forgotten where I put that code but at the time, it helped me validate my new FFmpeg VP3 decoder.

So, how to make this useful? I suppose we could concatenate all of the files together as a new TM1 decoder and submit a mega-patch to the ffmpeg-devel list, if only to get a rise out of the Guru. However, our new decoder seems to be a bit more efficient, size-wise. Under gcc 4.1.1 on an i386, libavcodec/truemotion1.o compiles to 13304 bytes while obj/libtm1.a weighs in at 59432 bytes (both counts represent strip’d binaries). The TM1 algorithm is fairly simple but does rely on a mess of data tables.

I still want to incorporate this library into FFmpeg, at least on an experimental basis so that I learn the code paths being executed for certain problem files. Now the issue is understanding the API by which one is expected to interact with this beast. And a beast it is. Forget about developer documentation. It’s all up to the developer. I started with a function that I remember as being core to the decoding process and traced up the call tree. Using this strategy, the functions in tm1.c appear to be top level functions. However, the corresponding tm1.h file does not have any useful information. The developers didn’t even want to create that header file based on the comment “To appease the strict Mac”.

However, the real break in the case comes when I recall that decoding the TM1 frame header involves a XOR operation. There is only one ‘^’ operator in the code and that leads me to where encoded data is unequivocally accessed in the decoder. It is beginning to look as though the API works something like:

• init TM1 system with tm1_Init()
• allocate xImage with tm1_xImageCreate()
• call methods assigned within xImage: seedData() specifies a new data buffer to be decoded and dx() asks for a decode operation

So I decide to give it a whirl with just a simple C program calling tm1_Init(). No go, because there are a bunch of support functions required that live in other directories in the VpVision tree. It should be possible to pull these things in. However, I don’t have time to pursue this idea further at this time. Until such time that I do, this blog entry will just serve as a notepad for where I am along this path.

In case someone else wants to take up this task, the immediate goal is to figure out how the API operates and plug it into the FFmpeg decoder for testing purposes. Use the existing truemotion1.c file and reroute the decoding logic to this decoder library. The API is quite mysterious, though. The tm1_Init() function wants a parameter that specifies “maxframes”. I have no idea what kind of number is expected. Further, the seedData() function that apparently receives an encoded data buffer to be decoded only takes a char* parameter. Such functions generally need a buffer length parameter to go along with the raw buffer. I don’t remember anything special about the TM1 coding method where a particular byte value indicated that the end of the stream had been reached.

Related posts:

• Duck TrueMotion 1 Redux
• Duck TrueMotion 1 Progress

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.