TM2X

From MultimediaWiki
Jump to navigation Jump to search

Duck TrueMotion 2X is believed to be related to Duck TrueMotion 2.

Coding principles

Truemotion 2X is different from Duck Truemotion 2 in its coding principles. Instead of delta coding 4x4 blocks with Huffman coded streams for each block type, TM2X has chunked frame format, inverse Huffman coding (i.e. instead of codes using variable number bits representing one token TM2X employs list of tokens assigned to single byte value) and tiles recursively divided into smaller blocks.

Each frame consists of chunks with the following structure:

 0-2 always 0xA0 0x00 0x01
 3      chunk identifier
 4-7 chunk size (big-endian)
 8-... chunk payload

Analyzed frames have chunks in the following order:

  • 0x06 (usually takes more than a half of coded frame)
  • 0x15- small, variable size
  • 0x09- 3 bytes long, seems to be some initialisation data
  • 0x02- two chunks of variable size
  • 0x0B- there are always 16 of them with size=4. Maybe for some Huffman tables?
  • 0x0A- variable size

In order to ease reverse-engineering Duck seemed to used pseudo-encryption on data. Pseudo-encryption means XORing some chunks with parts of LFSR which may be updated before some chunks. Register data is stored as big-endian number and looks like first 4 bytes of 0x06 chunk are used to initialize it (it also seems to be that chunk size minus four bytes).

LSFR update algorithm:

 calculate sum by modulo 2 of bits 31, 21, 3 and inverted bit 0
 shift register contents left by one bit and store new sum in LSB
 repeat 4 times

Known chunks

Each chunk starts with 32-bit identifier and 32-bit chunk size, both big-endian. Usually frame is composed of chunks for main data, configuration parameters and the last one is inverse Huffman list chunk.

0xA0000102

This chunk is obfuscated. It might contain delta tables to translate decoded token values for luma and chroma.

There should be up to two chunks.

First byte gives the chunk number (0 or 1).

Second byte tells how many 16-bit words of actual data this chunk has (up to 128).

The rest of chunk is 16-bit words.

0xA0000103

This chunk is obfuscated.

 byte  0     --- chunk ID 
 bytes 1-2   --- ???

Chunk ID is used instead of offset provided in 0xA000010B.

0xA0000105

Inverse Huffman list data.

 bytes 0-1   --- list size
 bytes 2-3   --- list length (usually 256)
 byte  4     --- list depth (should be 8)
 byte  5-... --- list data

0xA0000106

First 32-bit word is used to initialise LSFR key.

0xA0000108

Initialisation chunk for version 0.

0xA0000109

This chunk is obfuscated. It contains decoder configuration data.

 byte 0  --- some length parameter or block size
 byte 1  --- ???
 byte 2  --- also block size?

0xA000010A

Inverse Huffman list data.

 byte  0     --- escape value
 bytes 1-2   --- ???
 bytes 3-4   --- list size
 bytes 5-6   --- list length (usually 256)
 byte  7     --- list depth (should be 8)
 byte  8-... --- list data

0xA000010B

This chunk is obfuscated.

 byte  0     --- chunk ID 
 bytes 1-2   --- ???
 byte  3     --- some offset

The following codebook is used for nonzero chunk IDs, it seems to affect which block decoding functions are selected:

 0, 0, 0, 0,
 0, 1, 1, 1,
 0, 1, 1, 2,
 0, 1, 2, 4
 1, 1, 2, 4,
 0, 2, 2, 4,
 1, 2, 2, 4,
 2, 2, 2, 4
 1, 4, 2, 4,
 2, 4, 2, 4,
 2, 8, 3, 8,
 3, 4, 3, 8
 3, 8, 3, 8,
 0, 1, 1, 4,
 0, 1, 2, 2,
 0, 2, 1, 4
 1, 1, 2, 2,
 1, 4, 2, 8,
 2, 2, 3, 4,
 2, 4, 3, 8
 0, 1, 3, 8,
 1, 2, 3, 8,
 2, 4, 2, 4,
 2, 4, 3, 8
 3, 8, 3, 8

0xA000010C

Initialisation chunk for version 1.

0xA000010E

This chunk is obfuscated.

byte  0     --- chunk ID 
bytes 1-2   --- ???
bytes 3-6   --- some parameters used instead of codebook in 0xA000010B (offset = chunk ID as for 0xA00000103)

0xA0000110

Initialisation chunk for version 2.

0xA0000111

Initialisation chunk for version 3.

0xA0000112

This chunk is obfuscated. It contains some 2D array.

First byte is number of elements per line. Second byte seems to be padding. Following 16-bit word is number of lines.

The rest of chunk is 16-bit words forming some 2D array.

0xA0000115

Initialisation chunk for version 4.

0xA0000116

Initialisation chunk for version 5.

0xA0000117

Inverse Huffman list data.

 byte  0     --- escape value
 bytes 1-2   --- ???
 bytes 3-4   --- ???
 bytes 5-6   --- ???
 byte  7     --- ???
 byte  8     --- list length - 1
 byte  9-... --- list data

0xA0000118

Inverse Huffman list data.

 byte  0     --- escape value
 bytes 1-2   --- ???
 bytes 3-4   --- ???
 bytes 5-6   --- ???
 byte  7     --- list length - 1
 byte  8-... --- list data

0xA0000119

This chunk is obfuscated.

byte  0     --- number of parameter blocks
bytes 1-... --- parameter IDs (used in the same way as chunk ID in 0xA0000103)

Initialisation data

This data is obfuscated with the usual key.

For version 5 there's some 32-bit value first.

 bytes 0-1    --- frame height?
 bytes 2-3    --- frame width?

For version 5 there's some additional 32-bit value here.

 byte  4      --- maximum quadtree depth?
 byte  5      --- ???
 bytes 6-7    --- ???
 byte  8      --- bits per motion vector?

For version 5 there are some additional fields:

 16-bit       --- some flags?
 byte         --- ???
 byte         --- ???
 byte         --- ???
 32-bit       --- ???

Inverse Huffman list data format

The list is stored in sparse form --- first you have a byte for length of the entry and then the tokens themselves (each takes a byte too). For example 01 0A 02 2A 2A expands to { 0A }, { 2A, 2A } .