Archive for July, 2012

A followup on Go2Webcrap codec details

Friday, July 20th, 2012

I didn’t have much interest in this codec to start with. So I’ll just leave it here.

I suspect that both newer and older versions of the codec divide it into sharp details overlay over smooth image a bit like DjVu format does.

For compression method 2 (G2M2/G2M3) sharp details and filled regions are coded with ELS (weird binary coder). There’s also a special transparent pixel value of course. Smooth image seems to JPEG scan data without any other headers. They just use standard codes and default quantisation matrix from libjpeg6b with default quality setting 75.
I’d name this scheme JPEG-Binary Coder or J-B_K for short.

Here’s an example of something I hacked this morning to somehow decode baseline JPEG:
Would you be able to recognize any details here? I guess not.

And just think how wonderful to decode RGB mask and JPEG data in YUV format and combine them in the same image.

Compression scheme 3 talks about natural and synthetic image layers. It uses zlib to code some chunks inside tile data. And something else in addition to it.

Here’s an example of data there:

I remind that everybody is welcome to RE this codec (and I have more interesting codecs to deal with; I’m not VLC after all).

On Monster Codec

Sunday, July 15th, 2012

There is one codec unrivaled in its monstrosity. I’m talking about GoToMeetingAndNeverReturn.

First of all, look at its size. The oldest version I could find (it decodes only G2M2 and G2M3) occupies 6196600 bytes. Newer one with G2M4 support (and that’s an additional compressor too) is 8247160 bytes, Current version (with seemingly the same functionality) is 15665528 bytes.

What does it contain? Everything. I kid you not, All (maybe except one) GoToUnpleasantPlace utilities refer this small file and actually export their real main() function out from it. And their size is about forty kilobytes each.

What does it contain from code point of view? Some libraries for networking, cryptography, speech codecs library, libjpeg, zlib, some internal code and tons of C++-induced crap. When you see wrapper calling wrapper calling wrapper calling something trivial (and the wrappers just pass arguments as is and do nothing else), or when you see that 90% of any function is used for exception handling, then we’re talking about enterprise-grade C++ indeed. And of course absolute bloatedness (including making indirect calls where unneccessary) and inability to run on Linux (not with Wine or MPlayer2 loader) greatly help debugging.

Now to the codec details: every frame consists of chunks which hold different kind of data — frame information, mouse cursor shape, mouse cursor position, image data, etc. Frame is divided into tiles (usually 8×8 tiles in frame) and each tile is coded separately.

There are two compression methods, known by their numbers stored in frame header. For G2M2 and G2M3 it’s compression method 2, for G2M4 it’s compression method 3. Both are horrible.

Method 2 seems to have some completely unrelated submethods.

Here’s the call graph from method 2 decompression function.

Looks like there are several possibilities when coding with this method.

There is a possibility to use JPEG compression but I don’t know under what circumstances it’s used.
Also I’ve discovered that MSA1(MSS3) and MTS2(MSS4) actually use standard recommended quantisation tables from ITU T.81 Appendix K.1 (they are not used by libavcodec JPEG decoder though) and quality to quantisation mapping from libjpeg6.

Another coding method employs ELS codes I’ve described in the previous post and uses it to code some bit plane and RGB triplet in dependent form (i.e. with prediction from two previous pixels and using R-G, G, B-G components).

For method 3 so far I know only a few facts. First byte contains image type and depending on it decoding may vary a bit. For example, for image type 0 and 3 three following bytes contain some RGB value, other image types don’t have it. And internally it’s called MPCCoder or SMPCCoder.

In conclusion I want to say that this codec is too large and horrible to use only static reverse-engineering (because it’s very hard even to determine what is the next function called indirectly) and debugging it requires Windows, so don’t expect me to RE it. But if you do you’ll get many thanks and some money from these guys. Good luck!

About some weird coding methods in various codecs

Friday, July 13th, 2012

Today I (not really) want to talk about some weird coding methods employed by two codecs.

Monstrous Go2Meeting. To my very deep surprise its compression method 2 uses ELS coder, a curious binary arithmetic coder replacement. In essence it operates on fraction of bits (called jots by its autor) and uses something like state machine for model (i.e. depending on state and decoded jot value — 0 or 1 — move to one of two possible other states and subtract some state-defined value from input value). This implementation uses 36 jots per byte, has ladder with 174 rungs and operates on 24-bit state instead of 16-bit in the paper.

From a cursory glance on TAK it seems to be more or less ordinary lossless audio codec — i.e. LPC plus residue coding. The only peculiar thing is that residue coding. While other codecs use mostly adaptive coding, this one seems to employ fixed coding parameters for segments of residues and bitstream also contain parameter set indices for all these segments.

Scheme is rather simple: read predefined number of bits, if it’s not the escape value then reinterpret code as signed. For escape value get unary code, if it’s not equal to the secondary escape value then scale that value and reinterpret as signed. Else just read some additional number of bits, scale them and reinterpret as signed. Number of bits to read and escape values make those coding parameters (about 52 total).

Also even if it might provoke small flame war, I publicly say that I’d rather not see TAK supported in opensource. We have enough lossless codecs already, especially with their own containers. And they cover all possible uses already (don’t tell me about insignificantly higher compression ratio).

On Some Screen Codecs, including TSCC2

Thursday, July 5th, 2012

Two days ago I’ve heard about the release of new screen codec from TechSmith. Since TSCC was the first codec I’ve REd (even without looking at decoder) I could not resist and looked at it.

This codec is completely different from its predecessor. While TSCC was simple deflate+RLE, this one operates on blocks. It splits frame into slices 16×8, which are split into 4×4 blocks in YUV 4:4:4 format and 16-240 range. And those blocks are coded with DCT-like transform and quantised with one of two possible quantisers. Pretty easy, isn’t it? Oh, and internally codec is called “Dora”.

And looks like DCT is what some more advanced screen codecs use (and they are usually not lossless anymore).

For example, Micro$oft has about five screen codecs (maybe more):

  1. M$ Camcorder Video (CGDI) — somebody had rather stupid idea “ooh, let’s simply record GDI events and store them into frame”. Including commands for drawing text (and damned be you if your system fonts differ) and such. That’s the reason why we never get a decoder for it.
  2. M$ Screen 1 (WMV 7 Screen, MSS1) — palettised codec that employed classical arithmetic coding and modelling and coded frame by recursive sub-partitioning and pixel prediction for image areas.
  3. M$ Screen 2 (WMV 9 Screen, MSS2) — hybrid codec with enhanced coding method from Screen Codec 1, 16-bit RLE and coding some image areas with WMV 9. (And it was not REd by me BTW).
  4. M$ ATC Screen (MSA1) — internally it’s still known as MSS3. This codec operates in YUV 4:2:0 and uses range coder and modelling for coding macroblocks as solid fill, vector-quantised image, Haar wavelet or DCT.
  5. M$ Expression.Encoder Screen (aka Titanium Screen, MTS2) — this codec uses variable-length codes and only two coding methods left: DCT (exactly as in MSA1) and vector quantising which looks like a mix of MSA1 and MSS1.

I really should end it and move to something else…