I am being moved to a secret, classified, undisclosed location.

Well, no, not the old experimental forest…

Not sure when I will be back online. Be sure to keep reading Michael Niedermayer’s Lair Of The Multimedia Guru. He has a lot to say.

To the best of my knowledge, I have finished documenting both the GDV file format and the associated video coding format. Now let’s see who can first implement a file demuxer and video decoder for the format. Remember, samples are here.

The only part of the video decoding process that gives me pause is in coding method 8 where the decoder copies a run a pixels from an offset that’s further in the image buffer than the current decoded offset. I believe this is assuming that the current buffer also holds the previously decoded frame. If true, this constitutes a run-based interframe motion compensation scheme.

And you had better listen. Michael Niedermayer, multimedia guru and leader of the FFmpeg project, writes at his new blog. Settle in at the Lair Of The Multimedia Guru.

I have written some more documentation for the GDV file format. VAG’s decoding functions are pretty straightforward but the documentation process gets tedious in a hurry. The more advanced coding methods use a bizarre bit packing method interleaved with data bytes that I can almost guarantee FFmpeg does not support with its native bitstream readers.

I have the game Realms Of The Haunting which is 4 CD-ROMs packed full of FMV goodness using the GDV format. Two other games, Hardwar and Normality, are known to use the GDV format, but with other color depths and perhaps other coding modes. If anyone has those games, I would like to see some GDV samples from each.

I am a big fan of Rooster Teeth’s Red vs. Blue Machinima series– in fact, I own all 3 of the DVDs so far. I was excited to see that Rooster Teeth was commissioned to create a Machinima mini-series for the new F.E.A.R. game called P.A.N.I.C.S.

Funny stuff. Download and enjoy. But to be safe, use an open source multimedia playback application. Here is a curious excerpt from the P.A.N.I.C.S. FAQ:

Q: When I play the video my firewall says it’s trying to access the internet, what’s the deal?
A: The producers and promotions company wanted to track the popularity of the videos, so they added a small tag that hits a server, much like a webpage counter. No information besides the IP and the hit are recorded.

I have been trying to figure out if the tracking mechanism is embedded in the multimedia files somehow. My hypothesis is that there is some kind of information embedded in the multimedia files that instructs the multimedia player to perform an HTTP GET request to a web server. Each of the 4 downloadable files is available in both Windows Media and QuickTime formats. I know that QuickTime is hyper-flexible enough to allow for arbitrary things like requesting web pages; it’s reasonable that WMV supports a similar feature. However, looking through the files with a hex editor reveals no obvious “http://…” strings, even when I decompress the QuickTime header in the .mov files.

If anyone knows how this tracking tech operates, I’m sure I’m not the only interested party.

The moral of the story is to always use open source software to view your multimedia. You can trust that the open source multimedia players do not implement user-surveillance features because we developers do not even know how the features work!

Believe it or not, security is a high priority among open source multimedia hackers. For example, on the FFmpeg project, the decree is in place that no file creation facilities (like file muxers) may place valid timestamp data into the file which would indicate when the file was created. It was believed among some that this is tantamount to spyware. If you have trouble swallowing that reasoning, a less tinfoil-hat-like explanation is that arbitrary timestamps create havoc with regression testing.

I just thought you might like to know that we’re looking out for you and your safe computing experience.

If you care, I have enabled comments on the last few posts and will have comments enabled on future posts.

Say what you gotta say…

As I read new trivia additions on MobyGames, I see more and more bits about commercial games being open sourced. I figured that there must be some site out there that documents such transitions and lo and behold:

http://www.liberatedgames.com/

I wager there is some custom FMV code in there somewhere. We already know for a fact that:

• Descent II source contains a 16-bit Interplay MVE decoder
• Quake II source contains a Quake II Cinematic (.cin) decoder
• Quake III source contains a RoQ decoder

A number of the games listed at Liberated Games are only free in that the binary executable and data are available, but no source code.

A few more items I would like to investigate:

• Hexen II is open source (GPL). This screenshot makes it look like the game has some FMV. This game is based on the Quake engine. Per my understanding, Quake did not feature FMV. Quake II did.
• Stargunner is free for download. This screenshot looks like it might be FMV.
• Hidden & Dangerous is free for download. These screenshots may or may not represent FMV.
• Further, The Ur-quan Masters (Star Control 2) has released both source and data. Part of the data available for download is a speech pack. Nothing too special; all of the speech is available in Ogg Vorbis format.

Update: Trixter sends this intelligence about the titles above:

• Hexen II — can’t verify if that’s video, but there are Animation credits in the game so it is probably yes. However, most times that stuff is a FLIC file. (BTW, don’t get all bunched up over FLIC — there are two main variants that are easy to support; the rest of all that junk was introduced and supported by only that one company you found the info on.)
• Stargunner: same thing, most likely a 320×200 VGA FLIC.
• H&D: no video as far as I know.

I recently learned that Wikipedia has an entry for Microsoft Video-1. The entry makes two assertions of which I was heretofore unaware:

1. the codec was licensed from Media Vision and is based on a codec called MotiVE
2. the codec was based on the discrete cosine transform (DCT)

I can accept assertion #1 but I have trouble with the second. I just don’t see it. Per my understanding Video-1 falls into the category of vector quantizer. I did a quick Google search for “media vision motive cosine” to search for supporting details. This page supports the DCT claim. But it also claims that Duck TrueMotion 1 is a vector quantizer (nope). Here is another page that mentions the MotiVE connection but pegs Video-1 as a vector quantizer.

At least the Wikipedia article links to my Video-1 description so interested parties can investigate the details for themselves.

Ordinarily, I disdain overpriced gourmet food stores (in fact, I research my own low-cost knock-offs). Though I will still browse through them. And I actually caved and bought this item because I thought it would be an appropriate addition to my extensive collection of CD-ROM media:

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.