TM2X: Difference between revisions
Line 38: | Line 38: | ||
=== 0xA0000102 === | === 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. | There should be up to two chunks. | ||
Line 43: | Line 45: | ||
First byte gives the chunk number (0 or 1). | First byte gives the chunk number (0 or 1). | ||
Second byte tells how many 16-bit words of actual | 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. | The rest of chunk is 16-bit words. |
Revision as of 04:49, 3 April 2016
- FOURCCs: TM2A, TM2X
- Company: On2 (formerly Duck)
- Sample: http://samples.mplayerhq.hu/V-codecs/TM2a.avi
- Sample: http://samples.mplayerhq.hu/V-codecs/TM2x.avi
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 8x8 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 size0x09
- 3 bytes long, seems to be some initialisation data0x02
- two chunks of variable size0x0B
- 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.
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
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)
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.
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)
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 }
.