Back in the day there was no Bob but he had toys nevertheless. And of those toys for Bob was Star Control II. It is not a game for me to play (since my reaction time is not good enough for space battles), its 3DO version mentions “TrueMotion “S” Video Compression by The Duck Corporation” in the credits. Now that’s more my thing! I looked at it once, found it to be a lot like TrueMotion 1 but split into different files and looked no further.
But recently I got a curious request: apparently some people want to reuse the player code out of the game for playing videos on the console. And since the console is too old to support even micro-transactions (despite coming from the EA founder) let alone FullHD AV1, they look for something more fitting, which is mostly TrueMotion and Cinepak. As I remember, this format offers a bit more flexibility than the usual TM1 in some aspects (since the tables are transmitted in the video data instead of being stored in the decoder), so writing an encoder for it may be more interesting than it was for plain TM1.
Anyway, here I’d like to talk about this technology and how it differs from the conventional TrueMotion 1.
First of all, separate files. Image parameters (codec flavour, dimensions and luma/chroma deltas) are stored in .HDR file (delta tables seem to be the same for all samples but in theory any other tables should work just fine), Tunstall codebook is stored in .TBL file (they are all the same except for LOGO.TBL which starts with an entry for ten zeroes—and no other known TM codebook has more than eight entries), .FRM contains offsets of the each frame inside .DUK file. And there may be a companion AIFF with audio track, but that’s it.
Now to the compression details. Apparently there are two compression types in use (the first entry in .HDR signals it), type 1 working on 4×2 blocks and type 3 working on 4×1 blocks.
Type 1 compression transmits 1 chroma delta per block and one corrector that gets ignored and maintains separate predictors and correctors for even and odd lines. You don’t remember what corrector is? Well, looks like they’re not present in TM1 any longer. Essentially it’s a different predictor but which is XORed with the value instead of being added to it (and delta is EORed with the corrector as well).
Type 3 compression also transmits 1 chroma delta per block and one ignored corrector. Then you have four luma deltas (accompanied by one ignored corrector value each) and repeat it all for the next block.
Overall, this looks like a predecessor to TrueMotion 1 we all know and tolerate. There’s more flexibility in some parts as if they haven’t settled on some pre-selected tables yet, coding method is simpler (TM1 uses escape values with a different delta set instead of a corrector), there’s a smaller variety of block sizes, the coding is intra-only.
But as I said, in some aspects it still looks more interesting than the conventional TM1 so even if I can’t fit its support into NihAV framework I’ll see if I can write a special encoder (and a decoder) for it anyway.
Update: I’ve finally got around to writing a decoder and some of my assumptions were not correct. Apparently frame data in .DUK files contains audio part (with Duck’ed version of IMA ADPCM) and video part (which, surprisingly, starts with 16-byte header full of little-endian values like actual frame compression algorithm and dimensions). Both coding types work with the quarter height so while block sizes are 8×1 and 8×2, in reality they correspond to 8×4 and 8×8 blocks (so the full video size is impressive 528×400). An example frame (from a promotional video) is presented below.
Overall, now I have a better understanding of a format (which is important before trying to write an encoder).
Update 2: considering the ongoing events I’m still not in the mood for writing an encoder yet I’ve progressed somewhat with it. And in order not to forget some of the information I discovered: TM data is aligned to multiple of four and the 16-byte header (little-endian one) contains data size (minus the header) in bits. Also the stored width there is half of the real one (e.g. those 528×400 frames are reported as 264×400 instead).
encoding ducks ?
did all formats of vivo get decoders ? or VDO* ?
i do like star control 2. ur quans and spaceship battles. trolling friends with homing missiles and parasites.
I have decoders for Vivo Video 1 and 2 along with Siren, all seem to work fine. As for VDO, I remember looking at one codec and discovering it mixed H.263 and wavelets (i.e. not a fun mix to implement but not uncommon back in the day).