Kostya's Boring Codec World

RV8 or RV30 is close to earlier H.264 drafts and Sorenson Video 3, because they both use one variable-length code (Golomb codes in case of SVQ3, something special in RV30/RV40) to represent macroblock information (type, intra prediction modes). RV40 uses this code only to represent motion vectors and number of macroblocks to skip, macroblock type and intra prediction modes are coded with variable-length codes chosen from the set of them depending on context.

Here are the main differences from H.264:

1. Different bitstream. Special codes for elements and own substitution of Golomb code.
2. Intra prediction types are specified only for luma subblocks, chroma subblocks use some of them for prediction too.
3. Intra prediction modes are slightly different and some of them require additional context (down left neighbour).
4. Bidirectionally predicted blocks in B-frames do not use motion vectors from the previous/next frame in motion vector prediction while using them in motion compensation.
5. Intra prediction for intra blocks in interframes is performed even when neighbouring blocks are not intra blocks.

Main differences between RV30 and RV40:

1. Bitstream syntax and different codes (RV30 is easier in this matter).
2. RV30 does not have 8×16 and 16×8 motion compensation modes (while 8×8 mode exists).
3. Different motion vector prediction algorithm.
4. B-frames in RV30 do not contain some variant of bidirectionally predicted blocks which RV40 has.

And now here is the list of things I didn’t like in RV30/40:

1. Slice header does not contain number of macroblocks coded in this title. While it saves whopping 6-13 bits per slice (and frames usually have less than a dozen of slices, usually two or three), it gives unnecessary pain to implementor.
2. Vertical left intra prediction method uses down left neighbour pixels in calculation for one insignificant pixel (it’s insignificant because it does not affect further intra prediction).
3. Motion vector prediction is a bit complicated too.
4. And, of course, the lack of good documentation

It was very hot summer – both in terms of temperature and development process. I was writting decoder for the some codec (look at the category of this post if you don’t know what codec family was that, the fourth incarnation of it).

The main difficulty was
With the help of this tool written by Mike both he and I were able to capture some dynamic data during execution of the reference decoder and, basing on that information – to reconstruct execution flow, debug some variables and guess how some functions work. Still there were many functions that required assembly-human dictionary and took plenty of time.

What has surprised me during this work:

• That is the first time I work with PIC code. Now I understand why some people believe it’s evil thing. Constantly calculating real addresses from offsets from GOT (global offset table) is no fun and switch(){} construction becomes extremely complicated. But now I know GOT address of that decoder by heart.
• Passing parameters partly via stack and partly via registers (for example, source and stride are passed in register and destination as an argument) is also fun to watch
• It’s quite unexciting when one function does virtually nothing except calling other function (with the same arguments).
• There are several VLC reading techniques employed in reference decoder:
  1. Peeking if the next bits match some codeword in the table (i.e. iterate over table of codewords, look at the next k bits of bitstream and compare them with codeword)
  2. Using next 16 bits from the bitstream to find out code length (by finding prefix corresponding to the given length), then the difference between prefix and actual code (minus unused bits of course) is used to determine actual code value
  3. Using 256-element lookup table on the next 8 bits in bitstream to determine code length and value
• And that’s not all – codeset for the first case may be stored in two ways – in pairs (code, length) and in one value using formula (1 << length) | code. And function using this has to determine most significant one position, remove it and then call show_bits().

I plan to give codec architecture review in my next post.