TM2X - Revision history

Kostya: update information

2021-01-01T11:33:58Z

update information

← Older revision		Revision as of 04:33, 1 January 2021
Line 4:		Line 4:
	* Sample: http://samples.mplayerhq.hu/V-codecs/TM2x.avi		* Sample: http://samples.mplayerhq.hu/V-codecs/TM2x.avi

	Duck TrueMotion 2X is ~~believed to be~~ related to [[Duck TrueMotion 2]].		Duck TrueMotion 2X is related to both [[Duck TrueMotion 1]] and [[Duck TrueMotion 2]]. This codec stored images in YUV444 format.

	== Coding principles ==		== 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~~.		Truemotion 2X is a mix of technologies from both [[Duck TrueMotion 1]] and [[Duck Truemotion 2]]. From the former it takes codebook approach related to Tunstall codes (i.e. when codes are all fixed size but corresponding output sequence length may vary), from the latter it takes splitting frames into chunks for separate data sources.

	Each frame consists of chunks with the following structure:		Each frame consists of chunks with the following structure:
Line 18:		Line 18:

	Analyzed frames have chunks in the following order:		Analyzed frames have chunks in the following order:
	* <code>0x06</code> ~~(usually takes more than a half of~~ coded ~~frame)~~		* <code>0x06</code>- coded deltas
	* <code>0x15</code>- ~~small, variable size~~		* <code>0x15</code>- frame decoding parameters
	* <code>0x09</code>- 3 bytes long, ~~seems to be some~~ initialisation data		* <code>0x09</code>- 3 bytes long, initialisation data
	* <code>0x02</code>- two chunks ~~of variable size~~		* <code>0x02</code>- two chunks for delta values
	* <code>0x0B</code>- there are always 16 of them with size=4. ~~Maybe~~ for ~~some Huffman tables?~~		* <code>0x0B</code>- there are always 16 of them with size=4. They define coding parameters for different block modes.
	* <code>0x0A</code>- ~~variable size~~		* <code>0x0A</code>- codebook for decoding first chunk

	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 <code>0x06</code> chunk are used to initialize it (it also seems to be that chunk size minus four bytes).		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 <code>0x06</code> chunk are used to initialize it (it also seems to be that chunk size minus four bytes).
Line 39:		Line 39:
	=== 0xA0000102 ===		=== 0xA0000102 ===

	This chunk is obfuscated. It ~~might contain~~ delta tables to translate decoded token values for luma and chroma.		This chunk is obfuscated. It containc 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 60:		Line 60:
	=== 0xA0000105 ===		=== 0xA0000105 ===

	~~Inverse Huffman list~~ data.		Codebook data.

	bytes 0-1 --- list size		bytes 0-1 --- list size
Line 125:		Line 125:
	}		}

	The rest of the chunk data ~~seems to be~~ coded block data.		The rest of the chunk data is coded block data.

	=== 0xA0000108 ===		=== 0xA0000108 ===
Line 141:		Line 141:
	=== 0xA000010A ===		=== 0xA000010A ===

	~~Inverse Huffman list~~ data.		Codebook data.

	byte 0 --- escape value		byte 0 --- escape value
Line 152:		Line 152:
	=== 0xA000010B ===		=== 0xA000010B ===

	This chunk is obfuscated.		This chunk is obfuscated. It contains coding parameters for the different block types.

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

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

	~~Inverse Huffman list~~ data.		Codebook data.

	byte 0 --- escape value		byte 0 --- escape value
Line 238:		Line 238:
	=== 0xA0000118 ===		=== 0xA0000118 ===

	~~Inverse Huffman list~~ data.		Codebook data.

	byte 0 --- escape value		byte 0 --- escape value
Line 278:		Line 278:
	32-bit --- ???		32-bit --- ???

	=== ~~Inverse Huffman list data~~ format ===		=== Codebook 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 <code> 01 0A 02 2A 2A </code> expands to <code> { 0A }, { 2A, 2A } </code>.		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 <code> 01 0A 02 2A 2A </code> expands to <code> { 0A }, { 2A, 2A } </code>.

	~~[[Category~~:~~Undiscovered Video Codecs]]~~		== Frame decoding ==
			After decoding the information from the various chunks it is used to reconstruct the frame.

			First frame is split into tiles of the size provided in one of the chunks and then for each tile perform the following:

			* for all 8x8 blocks in tile get codes for block type, MV flag and (if MV flag is true) motion vector
			* for each line in tile get required deltas for this line depending on block mode and apply them (or perform motion compensation instead).


	[[Category:Video Codecs]]		[[Category:Video Codecs]]
	[[Category:Video FourCCs]]		[[Category:Video FourCCs]]

Kostya: /* 0xA0000106 */

2016-04-09T09:29:16Z

0xA0000106

← Older revision		Revision as of 02:29, 9 April 2016
Line 124:		Line 124:
	}		}
	}		}

			The rest of the chunk data seems to be coded block data.

	=== 0xA0000108 ===		=== 0xA0000108 ===

Kostya: /* 0xA0000106 */

2016-04-09T09:21:29Z

0xA0000106

← Older revision		Revision as of 02:21, 9 April 2016
Line 70:		Line 70:

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

			For version 5 there's motion vector data:

			npasses = get_bits(3);
			maxd = max(width, height) rounded up to the power of two;
			for (i = 0; i < npasses; i++) {
			mvbits = get_bits(5);
			get_mv_recursive(0, 0, maxd, maxd, mvbits);
			}

			nblocks = get_bits(16);
			for (i = 0; i < nblocks; i++) {
			idx = get_bits(16);
			mb[idx]->mv_x = get_sbits(8) << 1;
			mb[idx]->mv_y = get_sbits(8) << 1;
			}

			idx = 0;
			do {
			type = get_bits(2);
			if (type == 3) {
			run = get_bits(8);
			type = get_bits(2);
			} else {
			run = 1;
			}
			for (i = 0; i < run; i++)
			mb[idx++].type = type;
			} while (idx < num_mb_blocks);

			mv_bits = get_bits(4);
			for (i = 0; i < num_mb_blocks; i++) {
			if (mb[i].type == 2) {
			mb[i].mv_x += get_sbits(mv_bits);
			mb[i].mv_y += get_sbits(mv_bits);
			}
			}

			get_mv_recursive(int off_w, int off_h, int w, int h, int mvbits)
			{
			if (get_bit()) {
			w >>= 1;
			h >>= 1;
			get_mv_recursive(off_w, off_h, w, h, mvbits);
			get_mv_recursive(off_w + w, off_h, w, h, mvbits);
			get_mv_recursive(off_w, off_h + h, w, h, mvbits);
			off_w += w;
			off_h += h;
			}
			for (all MBs in this subdivision) {
			mb->mv_x += get_sbits(mvbits);
			mb->mv_y += get_sbits(mvbits);
			}
			}

	=== 0xA0000108 ===		=== 0xA0000108 ===

Kostya: /* Coding principles */

2016-04-09T08:22:55Z

Coding principles

← Older revision		Revision as of 01:22, 9 April 2016
Line 8:		Line 8:
	== Coding principles ==		== 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.		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:		Each frame consists of chunks with the following structure:

Kostya: /* Known chunks */

2016-04-09T08:22:07Z

Known chunks

@@ Line 70: / Line 70: @@
 First 32-bit word is used to initialise LSFR key.
 === 0xA0000109 ===
@@ Line 125: / Line 129: @@
 , 4, 3, 8
 , 8, 3, 8
 === 0xA000010E ===
@@ Line 133: / Line 141: @@
   bytes 1-2   --- ???
   bytes 3-6   --- some parameters used instead of codebook in 0xA000010B (offset = chunk ID as for 0xA00000103)
 === 0xA0000112 ===
@@ Line 143: / Line 159: @@
 The rest of chunk is 16-bit words forming some 2D array.
 === 0xA0000117 ===
@@ Line 173: / Line 197: @@
   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 ===

Kostya: /* 0xA0000102 */

2016-04-03T11:49:38Z

0xA0000102

← Older revision		Revision as of 04:49, 3 April 2016
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 ~~dat~~ this chunk has (up to 128).		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.

Kostya: /* 0xA0000112 */

2016-04-03T11:43:14Z

0xA0000112

← Older revision		Revision as of 04:43, 3 April 2016
Line 134:		Line 134:
	=== 0xA0000112 ===		=== 0xA0000112 ===

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

	First byte is number of elements per line.		First byte is number of elements per line.

Kostya: /* 0xA0000109 */

2016-04-03T11:40:43Z

0xA0000109

← Older revision		Revision as of 04:40, 3 April 2016
Line 71:		Line 71:
	=== 0xA0000109 ===		=== 0xA0000109 ===

	This chunk is obfuscated.		This chunk is obfuscated. It contains decoder configuration data.

	byte 0 --- ~~chunk ID~~		byte 0 --- some length parameter or block size
	~~bytes~~ 1-2 --- ???		byte 1 --- ???
			byte 2 --- also block size?
	~~Chunk ID is used instead of offset provided in <code>0xA000010B</code>.~~

	=== 0xA000010A ===		=== 0xA000010A ===

Kostya: /* 0xA0000103 */

2016-04-03T11:38:58Z

0xA0000103

← Older revision		Revision as of 04:38, 3 April 2016
Line 49:		Line 49:
	=== 0xA0000103 ===		=== 0xA0000103 ===

	~~First byte - ID?~~		This chunk is obfuscated.

	~~Seems to be similar to~~ <code>0xA000010B</code>		byte 0 --- chunk ID
			bytes 1-2 --- ???

			Chunk ID is used instead of offset provided in <code>0xA000010B</code>.

	=== 0xA0000105 ===		=== 0xA0000105 ===

Kostya: /* 0xA0000109 */

2016-04-03T11:38:14Z

0xA0000109

← Older revision		Revision as of 04:38, 3 April 2016
Line 68:		Line 68:
	=== 0xA0000109 ===		=== 0xA0000109 ===

	~~his~~ chunk is obfuscated.		This chunk is obfuscated.

	byte 0 --- chunk ID		byte 0 --- chunk ID