Monthly Archives: April 2006

Mimic Doc

Browsing through the MultimediaWiki I found a codec called Mimic that I previously had not paid too much attention to. I remember someone on the ffmpeg-devel list inquiring about some reverse engineering advice regarding the codec with the FourCC ML20, which is a.k.a. Mimic. The FourCC was apparently a bit frustrating to work with because it only occurs on the wire– it is only used for teleconferencing app and there are no apps to easily save the encoded data into a handy container format.

Anyway, someone persisted (one Ole André Vadla Ravnås according to the source headers) and eventually reverse engineered the complete codec and created an open source library called libmimic, according to the Wiki page. The link on the Wiki page for libmimic does not seem to work. However, another open source teleconferencing app called Farsight incorporates the full library, which even knows how to encode video.

It’s a very simple codec for those of us — ahem — skilled in the art. I’ve done my best to document the details based on the RE’d source code. Stop me if you’ve heard this one before: Transform 8×8 blocks of data with discrete cosine transform -> quantize DCT coefficients -> zigzag coefficients -> Huffman code the non-zero coefficients and zero-runs between the non-zero coefficients. The only major intraframe coding concepts the codec is missing are macroblocks and delta coding. Interframes feature frame differencing– if a block is unchanged from the block at the same position in the previous frame, leave it alone. Good design decision for a teleconferencing video codec.

Everyone Looks Good

Here’s yet another article about that U.S. government-funded bug scan that Coverity is performing for various prominent open source projects: Developers fast to fix open-source bugs. From the graph accompanying the article, it looks like the exercise has been an unqualified success. However, I’m privy to the results of some of those scans. I can tell you that the scanning tools are highly paranoid and report large numbers of “bugs” that are non-issues. It’s curious to note that this has dual positive effects:

  1. Coverity’s tools look good due to the sheer volume of “bugs” they detect
  2. Open source developers look awesome in light of their ability to fix hundreds of bugs in a week

4 Additions Are Faster Than 1?

Today’s wacky ASM construct shows us four sequential additions to the same register:

  add ecx, 00000004
  add ecx, 00000004
  add ecx, 00000004
  add ecx, 00000004

Does this have some great advantage over, say:

  add ecx, 00000010

Who knows? But I dare you to claim that this is some compiler optimization technique. You can’t claim that it’s minimizing branch prediction error this time since there are no branches to be seen for miles (kilometers, if you must) on either side. In fact, here is a little ASM context on either side of the block:

  xor ebx, ebx
  mov bl, byte[esp+26]
  add ecx, 00000004
  add ecx, 00000004
  add ecx, 00000004
  add ecx, 00000004
  mov ebx, dword[esi+4*ebx]

Hmm, now that I look at it after an indignant rant, I realize that maybe the compiler decided to delay after a byte is loaded from memory before accessing memory again.