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.