Kostya's Boring Codec World

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?