Kostya's Boring Codec World

For those, who are interested in playing 16-bit MVE files (yes, Mike, I am talking about you) here are some bits of information I’ve gathered at my leisure:

• you have to skip 16 bytes from block map at the beginning instead of 14 for 8-bit MVE
• colours are now stored as 15-bit (obvious, isn’t it), and high bit may be set for pattern fill order (8-bit MVE just compared colour values, which still works)
• for some opcodes pattern fill order was changed a bit (i.e. subblocks scan order)
• some opcodes meaning was changed completely. Opcode 3 does not requires additional bytes to be read anymore.

I didn’t have a desire to complete it, especially because it’s no fun to debug how motion is stored, so I just hacked existing decoder a bit to decode 16-bit files. Here’s a picture produced by maimed libavcodec/ipvideo.c:

One of FFmpeg advantages is that it supports decoding of many fringe formats, especially game formats. My favourite is Sierra VMD but there are several other formats I’d like to be able to play:

• LucasArts SMUSH (there was a patch for playing some variants, the rest could be made from ScummVM code)
• Discworld II and III video format (if only ScummVM developers got the code for DW2 at least)
• Indeo 4 and 5
• Bink (if only certain person worked on REing it instead of formats used in EA games)

Code donations are welcomed 😉

Update: ScummVM has DW2 BMV decoder now.

There is a codec, little is know about it.

Here are some of its features:

• it codes frame as a three planes
• it employs motion compensation
• it employs old-school vector quantization — fill block, fill block with mask, …
• each value in the stream is coded as the run of values plus actual value coded as several Huffman-coded nibbles (yes, each 4 bits are coded with own Huffman tree) plus sign bit if applicable
• sometimes it performs DCT to restore block content

Try to guess what’s its name.

Hint: MultimediaWiki contains a description of the codec with the similar bitstream reading techniques, which is a relative of this codec.

And, no, since I’m engaged in AAC encoder, I won’t RE nor write decoder for it (at least in the near future).

I’ve managed to make another bunch of Worms videos to work correctly and plan to commit that patch soon. Here is one frame from TV.AVI:

Looks like they’re watching UZI.AVI from previous Worms, eh?

Too bad that correct output can be obtained through FFmpeg transcoding only. Those happens because of different handling of ‘palette change’ block in AVI:

• FFmpeg handles it okay
• FFplay also handles it but palette change event is de-synchronized and usually displayed frame has wrong colors.
• MPlayer is treating palette change chunks in AVI as usual frame data, thus causing decoder errors and wrong colors.

I don’t know the situation with Xine and VLC but suspect it’s nothing good there also.

I have looked at about dozen of codecs and for me KMVC (codec used for FMV in Worms games) is surely the kinkiest.
Here is what I think is kinky:

1. Usability – there are two version of codecs, one uses for decoding kmvidc32.dll, other can be played by DOS player (player and samples for second type can be found atMPlayer samples repository). DLL cannot play files played by DOS player and vice versa and all these two types differ is just extradata (another 12 bytes), frame format is the same!
2. Strange bit reading policy: read 8 bits at once, when this bit buffer exhausts, read another byte (and a lot of data may be read between those two bitbuffer reads). I understand that was made to avoid bit reading issues, but it’s still very strange.
3. Another credit goes straight to m$ visual C. I cannot make myself think that any more or less sane coder would write this:
   
jmp L2
L1:
; load something into al
jmp L3
L2:
add al, al
jz L1
L3:

   And that is the simplest example of this – sometimes block L2 occurs in the beginning of function and L1 is near the end of it! Is this some kind of disoptimization to run the code on modern CPUs (which don’t like branching) with the speed of ol’ good i486?

I hope to finish spec and decoder to May.

Yesterday I’ve added implementation of Smacker demuxer and decoder, so you can enjoy you favourite pieces of video from various games.

I cannot credit the person who did the actual reverse engineering as he prefers to stay anonymous. Anyway, thank you very much!

The most interesting things in Smacker are Huffman trees. Smacker has trees by principle “every byte must have a tree”. Video operates with 16-bits values from Huffman trees, every of this trees stores values as two codes from Huffman trees. So you must construct two smaller Huffman trees before decoding large one. And packed audio data has also 1,2 or 4 Huffman trees depending if we have 8-bit or 16-bit data and stereo or not.

And now spotted inefficiencies in Smacker:

• Smacker stores header information for 7 audio streams (!) yet I’ve never seen Smacker with two audio streams. Was that intended for internationalization?
• Due to weird Huffman tree decoding procedure one bit is constantly wasted on stream. That means global Huffman trees for video lack 12 bits of waste (two support Huffman trees, one large Huffman tree, repeat four times) and audio chunks waste 1-4 bits depending on size. Not a big deal though.

And the final thought – the main difference between Smacker and M$ Video 1 is the packing scheme, block structure is almost identical. Anyone volunteering to write convertor from one format to another?