TM2X: Difference between revisions
Jump to navigation
Jump to search
(formatting) |
No edit summary |
||
Line 22: | Line 22: | ||
* <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. Maybe for some Huffman tables? | ||
* <code>0x0A</code>- variable size | * <code>0x0A</code>- 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 <code>0x06</code> 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 | |||
[[Category:Undiscovered Video Codecs]] | [[Category:Undiscovered Video Codecs]] | ||
[[Category:Video Codecs]] | [[Category:Video Codecs]] | ||
[[Category:Video FourCCs]] | [[Category:Video FourCCs]] |
Revision as of 02:43, 6 February 2010
- 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.
Frame structure
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 long0x02
- 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