ClearVideo: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(Update some information)
Line 12: Line 12:


=== Extradata ===
=== Extradata ===
Extradata differs for all container formats. AVI variant stores values in little-endian words and half-words, RealMedia variant stores the same values in big-endian order, and QuickTime has completely different format that does not seem to look like either.
AVI/RM format looks like this:
* the usual <code>BITMAPINFOHEADER</code> (even in RealMedia—right after the RM-specific stream information but also in big-endian order)
* byte sequence <code>00 01 00 01</code>
* two sixteen-bit values <code>0x0001 0x0001</code> (probably to detect endianness)
* 8 zero bytes
* image width and height (two 32-bit words)
* unused 32-bit word
* block version parameter 1 (32-bit word)
* tile size (usually 16 or 32)
* unused 32-bit word
* block version parameter 2 (32-bit word)
* block version parameter 3 (32-bit word)
Block version parameter 1 seems to be some flag that should take only 0 and 1 values and affects block decoding variant for inter-frame selection. Block version parameter 2 selects the block handler depending on version, valid values are 0, 1, 2 and 6 (or 4, 1, 5 and 6 is the previously described flag is 6); most common value is 5. Block version parameter 3 seems to be a duplicate in meaning and it's not really used by the decoder.
Quadtree version is also devised from the block version: block versions 0-5 map to quadtree version 0, block version 6 maps to quadtree version 2 (block versions 0-2 map to quadtree ''codes'' version 0 (unpacked), 3-5 map to codes version 1 (default), 6 maps to version 3).
All of these is needed to decode inter frames, for intra frames only codebooks and the frame dimensions are required to be provided.


=== Intraframe decoding ===
=== Intraframe decoding ===

Revision as of 10:34, 3 February 2018

ClearVideo is a video encoder ostensibly based on fractals. Alleged to be the basis of certain RealVideo codecs. Also alleged to be patented. A patent search with "iterated" as the assignee name indeed turns up over 20 patents, many of which mention "fractals" and "image compression" in the title. The same decoder core is used for VfW, QT and Real decoders.

One of the peculiarities of the codec is that the codebooks are provided to it externally and usually they are stored as the resources in decoder (or encoder) wrapper. Those tables include:

  • CVLHUFF — single large codebook for 64x64 tile mode interframes (first 1/5th of it is 8-bit code lengths, next 2/5 is 16-bit code values, the rest is 16-bit code symbols)
  • HUFF — codebooks for interframe tree information coding.
  • DCT — intraframe coefficients codebooks
  • VQ — probably suggested block configurations for the encoder, not used by decoder

Extradata

Extradata differs for all container formats. AVI variant stores values in little-endian words and half-words, RealMedia variant stores the same values in big-endian order, and QuickTime has completely different format that does not seem to look like either.

AVI/RM format looks like this:

  • the usual BITMAPINFOHEADER (even in RealMedia—right after the RM-specific stream information but also in big-endian order)
  • byte sequence 00 01 00 01
  • two sixteen-bit values 0x0001 0x0001 (probably to detect endianness)
  • 8 zero bytes
  • image width and height (two 32-bit words)
  • unused 32-bit word
  • block version parameter 1 (32-bit word)
  • tile size (usually 16 or 32)
  • unused 32-bit word
  • block version parameter 2 (32-bit word)
  • block version parameter 3 (32-bit word)

Block version parameter 1 seems to be some flag that should take only 0 and 1 values and affects block decoding variant for inter-frame selection. Block version parameter 2 selects the block handler depending on version, valid values are 0, 1, 2 and 6 (or 4, 1, 5 and 6 is the previously described flag is 6); most common value is 5. Block version parameter 3 seems to be a duplicate in meaning and it's not really used by the decoder.

Quadtree version is also devised from the block version: block versions 0-5 map to quadtree version 0, block version 6 maps to quadtree version 2 (block versions 0-2 map to quadtree codes version 0 (unpacked), 3-5 map to codes version 1 (default), 6 maps to version 3).

All of these is needed to decode inter frames, for intra frames only codebooks and the frame dimensions are required to be provided.

Intraframe decoding

Codebooks

Codebooks are stored in DCT table as the arrays of (32-bit word for code value, 32-bit word for code length) pairs with zero codes for unused entries. There are following tables stored one after another:

  • AC table 1, 24 entries
  • AC table 2, 100 entries
  • AC table 3, 6 entries
  • AC table 4, 40 entries
  • 112*8 bytes - some lookup table
  • 96*8 bytes - some lookup table
  • 120*8 bytes - some lookup table
  • DC table, 127 entries

Bitstream

Bitreader uses 32-bit little-endian words and reads data from MSB.

At least one of the coding methods is based on DCT and works in YUV420 colourspace:

 ac_quant = get_bits(8); // DC quantisers are always 32
 for (all macroblocks) {
    for (i = 0; i < 6; i++)
      block_coded[i] = get_bit();
    for (i = 0; i < 6; i++) {
      if (!block_coded[i]) continue;
      idx = 0;
      while (idx < 64) {
        val = get_code();
        if (val != ESCAPE) {
          unpack val into last, value and skip
          if (get_bit())
            value = -value;
        } else {
          last = get_bit();
          skip = get_bits(6);
          value = get_bits(8); // signed value
        }
        blk[idx] = value;
        idx += skip;
        if (last)
          break;
      }
      unquantise block (with separate quantiser for DC)
      IDCT();
      put_block_clamped();
    }
 }

Interframe decoding

Codebook description

      • TODO***

Bitstream decoding

      • TODO***