Archive for the ‘Screen Codecs’ Category


Saturday, October 6th, 2012

In the recent month I was not very productive, so I’d like to talk about codecs that I’m not likely to finish soon (not that I’m going to finish any codec soon anyway).

GoToMeeting 2/3

G2M2 decoder output (the best I could get)

Here’s the best output I could get from G2M2 or G2M3 data by decoding JPEG part of the tiles. ELS part still needs some work since it’s boring — 10-neighbour prediction, differential pixel decoding and other wonders of binary coder.

Certain Intermediate Codec

I managed to reverse engineer some parts of it. First you have so-called fixed header, then you have strip sizes and then strip data with some header as well. The way it’s coded is also more or less clear. But some connecting details — like how those strips are divided (now it looks like 96×1 macroblocks or equally ridiculous).

Since it’s QuickTime it’s hard to say where are the entry points to the codec and what functions are invoked.
Also the only usable binary (with debug symbols) is PowerPC only. It’s nice platform but I still need to learn some of its peculiarities.

VoxWare MetaSound

It turns out that it is slightly simplified variant of TwinVQ. It does not have variable-length codes, all values are read as fixed bits (depending on sampling rate and bitrate of course). The only catch is that it’s hard to find where such description is retrieved or generated. And existing codebooks are somewhat different.

An uninteresting decoder patch (contains G2M)

Sunday, August 5th, 2012

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.

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!

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…

Some Notes on Un-RE’d Codecs

Saturday, June 23rd, 2012

If I haven’t REd a codec that doesn’t mean I haven’t looked at them at all.
So today I want to talk a bit about some un-REd codecs and what peculiarities they have.

Looks like that all interesting codecs can be divided into three groups: screen codecs, intermediate codecs and speech codecs.
Since I don’t understand the latter group I shan’t give details on it.

Screen codecs

We have lots of them and they can be divided into two categories: simple and monsters.
Simple codecs usually employ some standard data compression library (zlib, FastLZ, LZO or LZF) or Huffman coding with standard median prediction and interframe difference.
I.e. boring, let’s talk about monsters.

  • Windows Media Video 9 Screen (aka MSS2) — combines palettised regions coded like in its predecessor with WMV9-coded regions.
  • M$ Expressions Encoder Screen (aka Titanium Screen codec) — it uses variable-length codes and codes frames with one of two methods. One of them is DCT exactly the same as in M$ ATC Screen codec.
  • MSU Screen Lossless Codec — this one seems simply code R,G,B values with some arithmetic coder and lots of context modeling and prediction.
  • Go2Meeting codecs — a good demonstration of the fact that the best strategy against REing is employing shitty coding monkey.
    Version 4 of decoder was monolithic 8 MB .dll file, version 4 is 15 MB already, all in “fine” C++.
    There are two compression methods known.
    Version 2 employs some weird arithmetic coder substitution (suspiciously like ELS-coder by Wm.D. Withers).
    Version 3 employs libjpeg and zlib for coding image blocks somehow, frame data doesn’t look like it at all.

Intermediate codecs

Cineform — looks like they use Huffman coding and wavelets and it codes 10-bit video.

Fruit Intermediate Codec — looks a lot like its successor (ProRes) but with different bitstream format and fixed coding scheme instead of adaptive ones.

BitJazz SheerVideo — the main problem with it is that most of the codec code performs conversion between any of couple dozens of formats (8- and 10-bit YUV and RGB packed in any possible way). Actual decompression code gets lost somewhere.

A Short MSS1/2 Description

Sunday, December 27th, 2009

Some of you may have heard of such thing as Mi***soft screen capture codecs (aka WM Screen decoder). Here I’ll try to present some known information about it.

First of all, this codec employs old-school arithmetic coder — traking high and low values instead of low and range, normalisation by one bit, and it’s used for decoding everything (1-bit numbers, 8-bit numbers and symbols with variable probabilities) without any additional context-dependency stuff.

This codec employs predicting pixel value by its 4 neighbours (up left, up, up right and left). Intraframes and interframes seem to be coded in same way, but intraframes may have first line(s) data coded explicitly as 8-bit values (or was that palette?).

Each frame is recursively partitioned, final partitions may be filled with some value, restored from predicted values or copied from somewhere else.

Partitioning is done in this way: decode mode, if its value is 2, do something on decoded rectangle, otherwise decode partitioning value and use it to split rectangle horizontally (when mode is zero) or vertically (mode=1) and perform the same operation on halves.

Do not expect decoder to be ready any time soon though. At least not if someone else makes it.

Fraps: path of trial and error

Sunday, November 5th, 2006

I’ve just committed fully working (I hope) support for newer Fraps videos. While RE’ing that stuff I made two big mistakes: misunderstood bit reader to read only 31 bits from 32-bit word (which is not correct) and that Fraps version 4 is not identical to Fraps version 2. All of these is corrected now.

And now is a new category that Mike forgot to add to MultimediaWiki (hint, hint).

Supported screen capture codecs:

  • TechSmith codec (aka Ensharpen)
  • VMWare VMnc
  • DosBox ZMBV
  • Fraps
  • CamStudio

Unsupported screen capture codecs:

  • M$ Screen codecs MSS1 and MSS2
  • MSU Screen Capture Lossless Codec (SCLS)

Interesting – all those unsupported codecs use arithmetic coding (and as I suspect don’t work with palletized  images).

Some notes on Fraps

Sunday, October 29th, 2006

Here is what I currently know about Fraps v2 (v1 is supported by FFmpeg):

  • all data is stored in 32-bit little-endian words
  • first word indicates codec version and flag 0x8000000 – delta frame
  • second word is zero
  • next word is ‘FPSx’ magic
  • next three words are offsets in frame (from position 8) to packed YUV planes
  • each plane starts with 256 words – frequencies for each possible value
  • the rest of data  is bits packed in words
  • each bit looks like an input to state machine which outputs pair (value, skip) and changes its internal state
  • the rest is still needs to be figured out

Codec Completeness: Report

Thursday, September 7th, 2006

Today I’ve committed (I hope) the last patches to VMware Video decoder (videos looked rather funny without mouse pointer).

So, here are the stats for decoders:

  • VMware Video: 98% (some blocks are unknown but don’t interfere with decoding process)
  • VC-1 Simple/Main Profile: 75% (downscaled frames won’t be supported and B/BI frames are in progress)
  • VC-1 Advanced Profile: 40% (interlaced mode is not supported and BDU coding is not parsed – samples, anyone?)