GoToMeeting Codec
- FourCC: G2M2, G2M3, G2M4
- Company: GoToMeeting (Citrix)
- Samples:
This is a codec used to save recordings in GoToMeeting. The codec also calls itself GoToWebinar (see http://www.gotowebinar.com/).
Win32 binary decoder available here: http://www.gotomeeting.com/codec
According to samples, all G2M video frames begin with the characters 'G2M[2-4]', followed by a series of chunks. Each chunk has the following layout:
bytes 0-3 length of chunk payload, not including this length field byte 4 type of chunk bytes 5.. remainder of payload, format unknown
Supported chunk types are 0xC8-0xCD.
It appears that the minimum size for a G2M frame (possibly a no-change frame) is 14 bytes. This includes the 4 signature bytes, a 4-byte length indicating a chunk length of 6, and a 6-byte payload of type 0xCA followed by 5 more bytes.
G2M3 is the same as G2M2. G2M4 introduces new compression method but the structure remains the same.
In general frame is divided into the number of tiles and each tile is coded separately. Usual tile size is 192x128 pixels
Chunk C8
Display information.
Chunk contents (all values are big-endian):
4 bytes image width 4 bytes image height 4 bytes compression mode (should be 2 or 3) 4 bytes tile width 4 bytes tile height 1 byte colour depth (4, 8, 16, 24 or 32) for 4/8bpp there is a palette in standard RGBTUPLE format for 16-32bpp there are four bitmasks for each field
Chunk C9
Image update.
1 byte tile position in row 1 byte tile position in column ... compressed data
Chunk CA
Mouse cursor position.
2 bytes cursor position X 2 bytes cursor position Y 1 byte seems to be always 1
Chunk CB
Mouse cursor shape:
4 bytes data size 1 byte width 1 byte height 1 byte hotspot x 1 byte hotspot y ... cursor bitmask and its inverse (in M$ format)
Chunk CC
Maybe some resync chunk, it's supposed to contain only 4-byte value equal to 2000.
Chunk CD
One dword, something to do with time.
Video compression methods
Compression method 1 (ELS image)
ELS data
ELS-coded data seems to consist of coded flags and differences for RGB triplets.
Vanilla augmented ELS coder is used (The ELS-coder: a rapid entropy coder). .
Unsigned values are coded as a number with all bits set to one and an addition to it:
mask = 1; val = 0; while (decode_bit()) { val += mask; mask <<= 1; } while (mask > 1) { mask >>= 1; if (decode_bit()) val += mask; }
E.g. number 5 will be coded as 11 0 10
(i.e. 3 + stop bit + 2).
Signed values use last bit for sign:
if (val & 1) val = - ((val + 1) >> 1); else val = val >> 1;
Image data is composed this way:
single pixel value that is used for transparency colour full tile image
Pixels in image can be coded as the one of 10 already decoded neighbours depending on which of them equal to which (a bit like JBIG compression), as some cached value or as the difference to the predicted one from left+top+topleft neighbours.
Compression method 2 (ELS image + JPEG)
This enhances compression method 1 by separating image into two pictures - the one with sharp details and the one with smooth details. The former is compressed as in compression method 1, the latter is coded as JPEG image. One of the layers can be absent in the tile.
Overall coding is quite simple: ELS layer is coded as first 1x1 image containing value that will be used as a transparent color (i.e. the value that should be replaced with JPEG data) and the whole picture.
JPEG data consists of raw scan data for the baseline JPEG with the standard quantisation matrix and VLCs. Only the macroblocks for the ELS image blocks with transparency are coded (or the whole image when ELS data is not present).
ELS-coded data size ELS-coded data for transparency pixel ELS-coded data for whole image JPEG data
ELS-coded data size:
0xxxxxxx 10xxxxxx xxxxxxxx 110xxxxx xxxxxxxx xxxxxxxx 111xxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Compression method 3 (deflated image + JPEG)
This method resembles compression method 2 except that ELS image is replaced with simple deflated image and macroblock map (what blocks in image to code) is stored explicitly too.
compression subtype (1 byte) transparent pixel value (3 bytes) number of palette entries minus one (1 byte) palette (3-byte entries) deflated data size (2 bytes big-endian) deflated data JPEG macroblock map JPEG data
Compression subtype (top 3 bits) tells what exact parts are present and how they should be decoded.
- 0 - fill block with the following pixel value
- 1 - decode JPEG only, only JPEG data is present
- 2 - decode only deflated data, no transparent pixel or JPEG data present
- 3 - all features are present
Deflated image data describes palettised mask image (or "synthetic layer"). The image is also compressed further by using the minimal amount of bits for palette indices (e.g. only 2 bits for 3- or 4-colour images) and every line can be skipped instead of coding.
for (y = 0; y < height; y++, dst += stride) { if (get_bits(8)) // 'line coded' flag continue; for (x = 0; x < width; x++) dst[x] = get_bit(bits_per_index); }
JPEG macroblock map consists of byte with the number of macroblocks coded minus one and an array of flags packed into bytes LSB first. Zero bit means that the next macroblock should be skipped, set bit means that the next decoded macroblock should be put here. This array continues until all coded macroblocks are flagges. Right after that information an actual JPEG data is stored.