USM: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
| Line 11: | Line 11: | ||
The format of a chunk is | The format of a chunk is | ||
* 4 byte identifier string | * 4 byte identifier string | ||
* 4 byte length, big-endian | * 4 byte length of data not including 8 bytes for identifier and length, big-endian | ||
* 2 byte unknown | * 2 byte unknown | ||
* 2 byte padding bytes | * 2 byte padding bytes | ||
| Line 20: | Line 20: | ||
The known indentifier strings are: | The known indentifier strings are: | ||
* CRID | * CRID Main header, usually 512 bytes long | ||
* @UTF Used only as a sub-chunk, only 32 byte aligned. Header/meta data, consisting of first the (binary) real data, followed by a textual description of the fields. | * @UTF Used only as a sub-chunk, only 32 byte aligned. Header/meta data, consisting of first the (binary) real data, followed by a textual description of the fields. | ||
* @SFV Video stream. If type is "data", the actual data seems to start only at offset 0x60. | * @SFV Video stream. If type is "data", the actual data seems to start only at offset 0x60. | ||
Revision as of 09:35, 1 September 2013
USM Container format
This format is used by e.g. "The Witcher 2".
It contains ordinary MPEG (probably MPEG-2) video, with the encoder string "TMPGEXE" being very obvious.
The file consists of (in the header nested) chunks.
Each main chunk is at least 64 byte aligned (though the design of the format should allow anything between including 0 and 64kB alignment if desired).
The format of a chunk is
- 4 byte identifier string
- 4 byte length of data not including 8 bytes for identifier and length, big-endian
- 2 byte unknown
- 2 byte padding bytes
- 4 byte probably type 1 = header, 2 = metadata, 3 = index, 0 = data
- 4 byte timestamp
- 4 byte unknown
- 8 byte unknown
The known indentifier strings are:
- CRID Main header, usually 512 bytes long
- @UTF Used only as a sub-chunk, only 32 byte aligned. Header/meta data, consisting of first the (binary) real data, followed by a textual description of the fields.
- @SFV Video stream. If type is "data", the actual data seems to start only at offset 0x60.
- @SFA Audio stream. If type is "data", the actual data just like for metadata seems to start at offset 0x20.
An index (called SEEKINFO) seems to only exist for video (it is placed into a @SFV tag), probably assuming the audio to be correct interleaved.