I’ll update codec details on our wiki and hopefully can forget about it. Let somebody French-speaking complete it.
There are many codecs out there to reverse engineer, including worthier ones. On the second thought that would define almost every codec.
Update: filled all information I had, the rest is up to somebody with the debugger and motivation to do it.
After investigating the smallest available pile of fossilised dung called Go2Cesspit (only 2.5MB instead of 15MB for the current version) the G2M1 can be reconstructed. It had the same tiled structure as its successors but it coded all tiles with ELS only, no combining with JPEG data.
And the full history of Go2UnwantedPlaces evolution (there definitely was no intelligent design for obvious reasons):
Further findings may correct this system of course but so far it looks like this.
P.S. If you want to have G2M1 supported then send samples and support requests to VideoLAN. They will be grateful for sure.
Now I can officially say that G2M4 is essentially reverse engineered. It indeed uses zlib-compressed image for sharp details (it’s called “synthetic layer” internally) and JPEG compression for smooth detail (it’s called “natural layer” internally). The only catch — it’s not plain JPEG coding, it codes only some block with JPEG and uses a special way to restore a sparse image.
The idea of this J-BKoding (not the same as J-BKoder in Go2Coven!) is simple: only the blocks referenced from top layer are coded and to save space and improve compression they are coded continuously. So how you know how to restore the picture back? Easy! JPEG data is preceeded by number of macroblocks coded and flags (in bytes, LSB first) telling whether the block is decoded one or skipped. I suspect that something similar might be true for the previous versions of the codec too, because quite often decoded JPEG data showed that its width is less than expected.
Here’s the output of the previous version with synthetic layer only (demonstrated at FOSDEM to the close circle of trolled people):
New version (quick hack):
Now any VideoLAN guy should be able to implement a decoder for it.
As some people know, there was Go2UselessActivity decoder for Libav showcased at FOSDEM (on an ARM-based laptop even). It decoded all known variants of the codec with varying degress of success (i.e. output ranged from being completely garbage to being slightly recognizable). Some guy nicknamed “j-b” was really happy for some unknown reason.
Let’s consider a purely theoretical situation that somebody needs Go2EncountersOfTheWorstKind 2/3 and wants to know how it works (usually it’s either one or another or none). As it’s known already it combines ELS-coded images with JPEG-coded data for some pixels that are coded transparent in ELS. JPEG data, to quote j-b is boring, so let’s look at ELS image coding.
The coder used is the augmented ELS coder by Douglas M. Withers (still available somewhere in Internet insize OSAUGELS.ZIP) with the same tables (36 jots per byte). The only interesting thing is how the image itself is coded with this binary coder.
x -> 2*x, -x -> 2*x - 1 (zero is explicitly signalled by number of bits being zero of course).(G, R-G, B-G) predicted value.Here’s slightly more detailed image decoding description:
for (y = 0; y < height; y++) {
x = 0;
while (x < width) {
if (x > 1 && y > 0 &&
rgb[x - 1][y] != rgb[x - 2][y] &&
rgb[x - 1][y] != rgb[x ][y - 1] &&
rgb[x - 1][y] != rgb[x - 1][y - 1] &&
rgb[x - 1][y] != rgb[x - 2][y - 1] &&
pixel_in_cache(rgb[x - 1][y]) {
rgb[x][y] = decode_pixel_with_prediction(x, y);
x++;
continue;
}
decode_run(x, y, &run_length, &pix);
if (run_length > 0) {
// pixel value may get changed here
decode_modified_pix(x, y, run_length, &pix);
while (run_length--)
rgb[x++][y] = pix;
} else if (decode_from_cache(&pix)) {
rgb[x][y] = pix;
x++;
} else {
rgb[x][y] = decode_pixel_with_prediction(x, y);
x++;
}
}
}
Hopefully no more information will follow soon.
Okay, I looked into G2M4 closer, here’s the output:
As with the previous beast, there are two types of images combined in single tile — so-called synthetic layer and natural layer. What you see if the first layer decoded.
Here’s the general tile structure:
Synthetic layer image is (after decompression) contains packed bitmap that uses palette from above, each row is coded as 8-bit flag [packed row data]. If the flag is zero then row data is present (that’s my guess, it always seems to be zero). Row data is just palette indices stored as 1/2/4 or 8 bits per index depending on palette size. Sample output you can see above.
Feel free to complete RE.
Just to clarify status: I’m not working on this anymore so anyone can pick it up and finish.
And here are some possible questions that might be asked but more probably won’t.
Q: who cares about this codec anyway?
A: Not me. VLC does.
Q: so why don’t you do it?
A: there are several reasons. First, now I have idea how it works and it’s not that interesting anymore. Second, it would require some debugging and I cannot run that decoder under MPlayer2 (and I don’t use Windows at all).
Q: but wait, there’s G2M4!
A: right, and it uses completely different coding. I might look at it but no promises either.
Q: so, how does it work?
A: the idea is simple. Every frame is divided into tiles and some tiles can be updated from the previous frame or not; some additional information (i.e. mouse cursor shape and position) is also stored in the frame.
G2M2/G2M3 use the technology licensed from Accusoft that combines JPEG and ELS-coded image.
Q: how do they do it?
A: the approach (I call it JPEG-Binary Koder or J-BK for short) is quite simple. Every tile has ELS-coded picture with possible transparency. Transparent areas should be replaced with headerless JPEG data (i.e. only scan data without any markers but with escapes).
Q: sounds easy, where’s the catch?
A: I’m too lazy to catch bugs in my quick JPEG decoder reimplementation and ELS-coded image requires some debugging which I can’t do.
Q: okay, I want to do it, where shall I start?
A: is it the first of April? No? Hmm… Okay, here’s what I would do: grab a copy of g2m.dll (there are enough of them around, in various sizes too), disassemble it.
Find the ELS thresholds table (referenced values are 0x10000, 0x12A00, 0x15C00, 0x19600, 0x1DA00, 0x22800, 0x28500, ...) — the function referencing it is the one used to update ELS coder state, go up from there. Feel free to look at the wiki entry about G2M. Bonne chance!
I’ve stumbled upon decoder for Go2Meeting, I don’t remember the link but I’ve made a copy here.
Since it’s obviously for FFmpeg I wonder if it’s made it to their repository yet.
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).
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!