MultimediaWiki - User contributions [en]

QDraw

2011-11-13T05:06:57Z

Clone2727: add link to Apple PICT documents; expand the description a bit (still very incomplete)

''This page is based on the codec description written by Konstantin Shishkov found in the document Description of the Apple QuickTime Animation (RLE) Format located at [http://multimedia.cx/qtrle.txt http://multimedia.cx/qtrle.txt].''

* FourCC: qdrw
* Company: [[Apple]]
* Specification: [http://developer.apple.com/legacy/mac/library/documentation/mac/QuickDraw/QuickDraw-333.html http://developer.apple.com/legacy/mac/library/documentation/mac/QuickDraw/QuickDraw-333.html]
* Samples: [http://samples.mplayerhq.hu/V-codecs/QT-qdrw/ http://samples.mplayerhq.hu/V-codecs/QT-qdrw/]

QDraw is really just a standard QuickDraw PICT resource inside of a QuickTime container. It is identified by the FOURCC 'qdrw'. The PICT format can support both vector- and raster-based images.

However, only v2 8-bit paletted PackBits images have been found in QuickTime files so far. Most of this document is based on this assumption as well as having no other QuickDraw opcodes present in the frame and is therefore incomplete.

== Data Format ==

All multi-byte numbers are encoded in big-endian format.

An encoded QDraw frame is laid out as follows:

bytes 0-1 low two bytes of the frame size
bytes 2-103 QuickDraw header/opcode data
bytes 104-107 number of colors - 1
bytes 108.. color table (8 bytes per entry)

One color table entry is laid out as:

byte 0-1 index of palette table entry to replace
byte 2-3 16-bit red component
byte 4-5 16-bit green component
byte 6-7 16-bit blue component

Thus, the color table can update arbitrary entries in the palette.

Following the color table are 18 bytes describing the PackBits source/destination rectangles and mode. After these bytes, there is a series of RLE-encoded lines using the standard PackBits compression (if mode is 0 "default" or greater than 2). For each line in the image:

if (row bytes is > 250)
two bytes compressed line size
else
one byte compressed line size

while (remaining bytes in compressed line)
code = next byte in encoded frame
if (top bit is set (code & 0x80))
output next byte in encoded frame to decoded frame (257-code)
times
else
copy (code + 1) bytes from encoded frame to decoded frame

[[Category:Video Codecs]]

Sega FILM

2011-07-05T13:39:58Z

Clone2727: byte 23 of FDSC is the audio compression field

''This page is based on the document 'Description of the Sega FILM/CPK File Format' by Mike Melanson found at [http://multimedia.cx/film-format.txt http://multimedia.cx/film-format.txt].''

* Extensions: cpk, cak, film
* Company: [[Sega (Company)|Sega]]
* Samples:
** [http://samples.mplayerhq.hu/game-formats/film-cpk/ http://samples.mplayerhq.hu/game-formats/film-cpk/]
** Batman and Robin Sega CD with 'Seg4' data: [http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/ http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/]
** Dracula Unleashed/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/ http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/]
** Jurassic Park/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/ http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/]

FILM is a multimedia container file format developed by Sega for use on its early CD-ROM home video game consoles. Based on analysis of a number of Sega CD and Saturn games, it appears that the format was first developed sometime during the era of the Sega CD, Sega's first CD-based video game console. There are many early variations of the FILM format observed on a number of Sega CD titles. Further, early FILM files have been observed on at least one 3DO game ([http://www.mobygames.com/game/3do/lemmings Lemmings]).

The Sega Saturn video game console, released in 1994, was also CD-ROM-based and apparently offered developers a standardized SDK for full motion video (FMV) playback using a modified variant of the well-known [[Cinepak]] video codec.

It is possible to store both audio and video in a FILM file. Alternatively, the format is able to handle either video without audio, or vice versa.

== Sega Saturn CPK File Format ==

All multi-byte numbers are stored in big endian format.

Many Sega Saturn CD-ROM games use this file format to store frames of a Cinepak-compressed video interleaved with uncompressed [[PCM]] audio. When this is the case, the files will typically have the extension .CPK (which is why FILM files are usually known as CPK files). Sometimes, audio-only FILM files will have a .SND extension.

The general format is laid out as follows:

+-----------------------+
| +-------------------+ |
| | FILM header | |
| | | |
| | +---------------+ | |
| | | FDSC chunk | | |
| | +---------------+ | |
| | | |
| | +---------------+ | |
| | | STAB chunk | | |
| | +---------------+ | |
| | | |
| +-------------------+ |
| |
| Audio or Video Data |
| .. |
| .. |
+-----------------------+

A FILM file will usually consist of a header followed by interleaved audio and video chunks. The FILM header has the following structure:

bytes 0-3 'FILM' signature
bytes 4-7 length of FILM header (including signature and length
fields)
bytes 8-11 FILM format version in ASCII (ex: '1.01' or '1.07')
bytes 12-15 unknown (may be reserved and set to 0)
bytes 16-n remainder of FILM header

Different Sega Saturn games include FILM files with a variety of FILM version numbers. Sometimes, the same game will include FILM files with a variety of format versions. A version number implies that there has been some change to the file format, but I have yet to observe any differences between different FILM file versions (except possibly for version '1.09'; see STAB chunk for more details).

The remainder of the FILM header contains a number of chunks describing the media data in the file. Usually, the number of chunks is 2: A FDSC chunk and a STAB chunk.

A FDSC chunk contains file description information. The chunk format is as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); an FDSC chunk should be 32 (0x20) bytes long
bytes 8-11 FOURCC of video codec (usually 'cvid' for Cinepak or null
for no video)
bytes 12-15 height of video frames
bytes 16-19 width of video frames
byte 20 bits per pixel (always seems to be 24)
byte 21 number of audio channels
byte 22 audio sampling resolution in bits (either 8 or 16)
byte 23 audio compression
bytes 24-25 audio sampling frequency in Hz
bytes 26-31 unknown (may be reserved and set to 0)

Note that the height field precedes the width field, which is unusual since width usually precedes height when expressing video resolution.

The fields pertaining to audio (channels, bits, compression, and sample rate) will all be 0 if there is no audio present in the file.

A STAB chunk contains a table of media sample information. The chunk format is as follows:

bytes 0-3 'STAB' chunk signature
bytes 4-7 length of STAB chunk (including signature and length
fields)
bytes 8-11 framerate base frequency in Hz
bytes 12-15 number of entries in the sample table
bytes 16-n sample table

Note that the length field ought to take the first 16 chunk bytes into account. However, it has been observed from some games (notably [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers] using '1.09' version FILM files) that the length field sometimes does not account for these 16 bytes.

The sample table consists of a series of 16-byte sample records. Each record is laid out as follows:

bytes 0-3 offset of sample chunk from beginning of sample data
bytes 4-7 length of sample chunk
bytes 8-11 sample info 1
bytes 12-15 sample info 2

The offset is the offset from the start of the sample data, not the absolute offset in the file. The length of the FILM header implicitly serves as a pointer to the beginning of the sample data in the file.

If the sample info 1 field is set to all ones, the sample is an audio chunk. Otherwise, it is a video chunk. If it is a video chunk, the top bit of the 32-bit number specifies whether the chunk is an inter-coded or an intra-coded frame. 0=intra-coded (a.k.a. keyframe), 1=inter-coded. This is useful for seeking since it is a good idea to only jump to key frames when seeking through a file.

The rest of the first sample info field and the second sample info field pertain to framerate calculation. Refer to the section on FILM framerate calculation for more information on proper FILM playback using these sample info fields.

== FILM Framerate Calculation ==

The STAB chunk contains a framerate base frequency in bytes 8-11. This frequency is expressed in ticks/second (Hz). Every video chunk has a frame tick count. For example, movie files in Panzer Dragoon I & II (FILM format versions 1.04 and 1.07, respectively) have a base frequency of 600 Hz. The frames have tick counts of 0, 20, 40, 60, 80, etc. Thus, there are 20 ticks between each successive frame.

(600 ticks/sec) / (20 ticks/frame) = 30 frames/second

However, not all FILM files exhibit such a nice, even framerate. Myst, for example, contains FILM files (version 1.01) with a base frequency of 30 Hz. Some of the frames skip 2, then 3 ticks. Here's a sample tick count progression: 0, 2, 5, 7, 10, 12, 15, 17...

Each STAB record has 2 32-bit sample info fields. For an audio chunk, sample info 1 is all ones and sample info 2 is always 1. For a video chunk, sample info 1 contains the keyframe bit (as described in the STAB section) and the absolute timestamp in clock ticks of the video frame with respect to the file's base frequency clock. The sample info 2 field contains the number of clock ticks until the next frame is rendered. This type of information would be particularly useful in an interrupt-driven, real-time multimedia system like, for instance, a video game console (such as the Sega Saturn).

It is important to note that an application that knows how to play FILM files can not assume a constant framerate. The files will not play correctly with such a method. It is also important to note that
converting FILM files to file formats that only support constant framerates (such as AVI) is not a winning strategy. The converted file will not play correctly.

== Video Codecs ==

If the video codec is 'cvid' in the FDSC chunk, the codec used is the deviant Cinepak format. A couple Dark Seed II videos also have the 'raw ' codec FourCC representing simple RGB888 data.

=== FILM Deviant Cinepak ('cvid') Video Data ===

The Cinepak data inside of a FILM file can not be decoded with a general purpose Cinepak decoding algorithm. It is reasonable to think that this was no accident. If FILM files contained standard CVID data, the files could be played on any computer that had some kind of Cinepak decoder implementation.

This document assumes familiarity with the [[Cinepak]] algorithm.

A CVID chunk is supposed to start with a 10-byte chunk header:

byte 0 flags
bytes 1-3 length of CVID data
bytes 4-5 width of coded frame
bytes 6-7 height of coded frame
bytes 8-9 number of coded strips

Following the chunk header ought to be the first byte of the first strip header. In the deviant CVID data stored in a FILM file, there appear to be an extra 2 bytes at the end of the chunk header, bringing the total header size to 12 bytes.

The length of the chunk as reported by the deviant CVID data chunk is also incorrect. The length field is supposed to report the length of the entire chunk including the header. The deviant CVID data reports a length that is 8 bytes too short. That is, the length reported in the CVID chunk is 8 bytes shorter than the length reported in the corresponding record of the FILM file's STAB chunk. The STAB chunk length takes into account the proper length, including the extra 2 bytes at the end of the chunk header.

Finally, the deviant CVID data appears to throw a potential decoder one more curveball with what appears to be data chunks that don't have, for lack of a better term, properly divisible chunk lengths. For example, a 0x2000 chunk commonly has a length of 0x604 bytes, which provides 2 bytes for the chunk ID, 2 bytes for the chunk length, and 0x600 bytes for 256 6-byte vectors. However, the deviant CVID data might have a 0x2000 chunk with a length of 0x600 bytes, which provides for the 4 chunk preamble bytes and 0x5FC bytes for the 6-byte vectors which is not evenly divisible by 6. This apparently confuses Cinepak decoders. The solution in this case is to unpack 255 6-byte vectors and then skip 2 bytes before attempting to decode the next chunk in the strip.

== FILM Audio Data ==

Audio data in a FILM file can be stored in a variety of formats which are mostly linear [[PCM]] variants.

The compression field of the FDSC chunk describes what kind of audio the video has. Two known values have been observed: 0 and 2. 0 is linear PCM and 2 is [[CRI ADX ADPCM]]. CRI ADX ADPCM has so far only been observed in Burning Rangers, with all other samples using linear PCM.

Saturn CPK audio data is always stored as signed data. This is important to remember when playing 8-bit CPK audio data on a PC which generally expects 8-bit data to be unsigned.

When a CPK file contains 16-bit audio data, the individual PCM samples are stored in big endian format. Again, this is important to remember when playing on a PC since a PC will generally expect little endian
16-bit data.

If the CPK audio data is stereo (8- or 16-bit), the channel data is non-interleaved. Usually, stereo data is stored interleaved as a left channel sample followed by a right channel sample as follows:

L R L R L R L R ...

In a stereo CPK file, for each audio data chunk, the first half of the chunk contains left channel samples and the second half contains right channel samples. The likely reason for this scheme is that console audio hardware such as that found on the Sega Saturn usually features a number of audio channels which can each play a mono PCM stream at a particular pan position (e.g., from 0-15 where 0 is extreme left, 7 and 8 are center, and 15 is extreme right). In order to play a stereo PCM stream, one physical audio channel must be assigned to extreme left while a second channel is assigned to extreme right. Then the appropriate channel samples are sent to the correct channel. Since these files are optimized for playback on the Sega Saturn it makes sense to arrange the audio samples like this.

The Sega CD audio playback hardware ostensibly supports native sign/magnitude audio samples. All Sega CD games studied use this format to store audio data. Sign/magnitude number coding for 8-bit numbers
means that for each 8-bit byte:

bit 7 sign
bits 6-0 magnitude (value)

This is slightly different from twos complement encoding which is how computers typically store signed numbers. For example, in the sign/magnitude scheme, 0x81 represents -1 and 0xFF represents -127. 0x01
and 0x7F still represent 1 and 127, respectively, just as in unsigned, and signed twos complement coding.

== Early Sega CD FILM Files ==

Some Sega CD games as well as at least one 3DO game (Lemmings) use an early version of the FILM format. Unfortunately, there are a lot of variations and a general-purpose player will probably require a lot of
special-case logic in order to deal with every known circumstance.

The first difference in these early files is the version number. These early files do not have ASCII-readable version fields. Some have NULL or other non-ASCII versions. This helps automatic detection.

The second major difference that all of these early files appear to exhibit is an abbreviated FDSC chunk which omits any audio information. Thus, the FDSC chunk is laid out as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); this FDSC chunk is 20 (0x14) bytes long
bytes 8-11 FOURCC of video codec
bytes 12-15 height of video frames
bytes 16-19 width of video frames

The lack of audio information leaves room for experimentation. The following is a list of known games which have early FILM files along with any special quirks observed.

On the Lemmings 3DO game, there are 2 files with the .film extension (the 3DO game console uses a custom filesystem which allows for file extensions longer than 3 characters). The files have a NULL version field. The files use CVID data which is deviant in the same manner as typical FILM CVID data with an added quirk: There appear to be 6 extra bytes between the end of the CVID chunk header and the start of the first strip header, rather than the usual 2 extra bytes. The Lemmings FILM files also contain 8-bit signed, monaural PCM data with a sampling frequency of 22050 Hz.

The Batman and Robin Sega CD title has a series of files with the extension .s. They are early FILM files with a version field of 0x00020000. Further, bytes 12-15 of the main FILM header are not set to 0 as is usually seen in FILM files. The files have a video fourcc of 'Seg4' which is probably Cinepak for Sega or a variant thereof. The files have STAB chunks which are a constant 0x20 (32) bytes long. This consists of the 'STAB' signature, a 4-byte chunk length, the base playback frequency, a sample count, and one 16-byte sample record. These files do not store the sample table in one place. Instead, they store one sample record followed immediately by the data corresponding to that sample record. Repeat until the end of the file.

The Dracula Unleashed Sega CD title contains a series of files beginning with video?? with no file extension. They are early FILM files with a NULL version field, abbreviated FDSC chunk, and 'sega' as a video codec (Cinepak for Sega). The audio is 8-bit sign/magnitude audio with a sampling frequency of 16000 Hz.

Jurassic Park for the Sega CD has a large number of files with the file extension .MVD. They are early FILM files with the same characteristics as the FILM files in Dracula Unleashed.

The Tomcat Alley title for the Sega CD has a massive data file called tca.bin. Inside this data file are a lot of FILM files. These files have NULL version fields. The files have abbreviated FDSC chunks and the
'sega' video fourcc. They also have short STAB chunks with an Apple Quicktime 'mdia' atom appended at the end.

== Strategy For Detecting FILM File Types ==

There are quite a few variations and deviations in the FILM file format. This section presents logic for detecting and dealing with the variations.

File extension detection is not especially useful since many games will masquerade their files with another extension. The best method to determine whether a file is a FILM file is to read the first 4 bytes and check for the signature 'FILM'.

Upon validating the signature:

* read the file version in the FILM header
* if the file version consists of ASCII characters
** if the file version is '1.09', watch out for bad length of STAB chunk as well as ADPCM audio
** load as standard FILM file, be sure to feed CVID data through Cinepak decoder that can handle it
* if the file version is 0x00020000
** read the video fourcc
** if the video fourcc is 'Seg4'
*** assume the file comes from Batman and Robin
* if the file version is NULL
** read the video fourcc
** if the video fourcc is 'cvid'
*** assume the file comes from the Lemmings 3DO game
*** be prepared to decode special variant of modified CVID data
*** assume 8-bit, mono, 22050 Hz PCM audio
** if the video fourcc is 'sega'
*** assume the file comes from one of several Sega CD games that agreed on this format
*** assume 8-bit, mono, 16000 Hz sign/magnitude audio

== Games That Use FILM Files ==

These games are known to use some variation of FILM files. Observed file version numbers are noted where known.

* [http://www.mobygames.com/game/saturn/astal Astal (Sega Saturn)]: '0.91', '1.06'
* [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/clockwork-knight Clockwork Knight (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/criticom Criticom (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/d D (Sega Saturn)]
* [http://www.mobygames.com/game/sega-saturn/dark-seed-ii Dark Seed II (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/defcon-5 Defcon 5 (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/iron-storm_ Iron Storm (Sega Saturn)]
* [http://www.mobygames.com/game/3do/lemmings Lemmings (3DO)]: unversioned
* [http://www.mobygames.com/game/saturn/myst Myst (Sega Saturn)]: '1.01'
* [http://www.mobygames.com/game/saturn/nights-into-dreams Nights Into Dreams (Sega Saturn)]: '0.91', '1.01', '1.06', '1.07', '1.08'
* [http://www.mobygames.com/game/saturn/panzer-dragoon Panzer Dragoon (Sega Saturn)]: '1.04'
* [http://www.mobygames.com/game/saturn/panzer-dragoon-ii-zwei Panzer Dragoon II: Zwei (Sega Saturn)]: '1.07'
* [http://www.mobygames.com/game/sega-saturn/roberta-williams-phantasmagoria Phantasm (Sega Saturn)]: '1.06', '1.08', '1.09'
* [http://www.mobygames.com/game/sega-saturn/return-to-zork Return to Zork (Sega Saturn)]: '1.02', '1.06', '1.07'
* Sega Saturn Bootleg Sampler (Sega Saturn): '1.04'
* [http://www.mobygames.com/game/saturn/shockwave-assault Shockwave Assault (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/skeleton-warriors Skeleton Warriors (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/space-jam Space Jam (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/street-fighter-the-movie Street Fighter: The Movie (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-squad-virtual-cop Virtua Cop (Sega Saturn)]: '1.08'
* World Series Baseball II (Sega Saturn)

[[Category:Container Formats]]
[[Category:Game Formats]]

Sega FILM

2011-07-05T13:31:16Z

Clone2727: /* Games That Use FILM Files */ add RTZ

''This page is based on the document 'Description of the Sega FILM/CPK File Format' by Mike Melanson found at [http://multimedia.cx/film-format.txt http://multimedia.cx/film-format.txt].''

* Extensions: cpk, cak, film
* Company: [[Sega (Company)|Sega]]
* Samples:
** [http://samples.mplayerhq.hu/game-formats/film-cpk/ http://samples.mplayerhq.hu/game-formats/film-cpk/]
** Batman and Robin Sega CD with 'Seg4' data: [http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/ http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/]
** Dracula Unleashed/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/ http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/]
** Jurassic Park/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/ http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/]

FILM is a multimedia container file format developed by Sega for use on its early CD-ROM home video game consoles. Based on analysis of a number of Sega CD and Saturn games, it appears that the format was first developed sometime during the era of the Sega CD, Sega's first CD-based video game console. There are many early variations of the FILM format observed on a number of Sega CD titles. Further, early FILM files have been observed on at least one 3DO game ([http://www.mobygames.com/game/3do/lemmings Lemmings]).

The Sega Saturn video game console, released in 1994, was also CD-ROM-based and apparently offered developers a standardized SDK for full motion video (FMV) playback using a modified variant of the well-known [[Cinepak]] video codec.

It is possible to store both audio and video in a FILM file. Alternatively, the format is able to handle either video without audio, or vice versa.

== Sega Saturn CPK File Format ==

All multi-byte numbers are stored in big endian format.

Many Sega Saturn CD-ROM games use this file format to store frames of a Cinepak-compressed video interleaved with uncompressed [[PCM]] audio. When this is the case, the files will typically have the extension .CPK (which is why FILM files are usually known as CPK files). Sometimes, audio-only FILM files will have a .SND extension.

The general format is laid out as follows:

+-----------------------+
| +-------------------+ |
| | FILM header | |
| | | |
| | +---------------+ | |
| | | FDSC chunk | | |
| | +---------------+ | |
| | | |
| | +---------------+ | |
| | | STAB chunk | | |
| | +---------------+ | |
| | | |
| +-------------------+ |
| |
| Audio or Video Data |
| .. |
| .. |
+-----------------------+

A FILM file will usually consist of a header followed by interleaved audio and video chunks. The FILM header has the following structure:

bytes 0-3 'FILM' signature
bytes 4-7 length of FILM header (including signature and length
fields)
bytes 8-11 FILM format version in ASCII (ex: '1.01' or '1.07')
bytes 12-15 unknown (may be reserved and set to 0)
bytes 16-n remainder of FILM header

Different Sega Saturn games include FILM files with a variety of FILM version numbers. Sometimes, the same game will include FILM files with a variety of format versions. A version number implies that there has been some change to the file format, but I have yet to observe any differences between different FILM file versions (except possibly for version '1.09'; see STAB chunk for more details).

The remainder of the FILM header contains a number of chunks describing the media data in the file. Usually, the number of chunks is 2: A FDSC chunk and a STAB chunk.

A FDSC chunk contains file description information. The chunk format is as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); an FDSC chunk should be 32 (0x20) bytes long
bytes 8-11 FOURCC of video codec (usually 'cvid' for Cinepak or null
for no video)
bytes 12-15 height of video frames
bytes 16-19 width of video frames
byte 20 bits per pixel (always seems to be 24)
byte 21 number of audio channels
byte 22 audio sampling resolution in bits (either 8 or 16)
byte 23 unknown
bytes 24-25 audio sampling frequency in Hz
bytes 26-31 unknown (may be reserved and set to 0)

Note that the height field precedes the width field, which is unusual since width usually precedes height when expressing video resolution.

The fields pertaining to audio (channels, bits, and sample rate) will all be 0 if there is no audio present in the file.

A STAB chunk contains a table of media sample information. The chunk format is as follows:

bytes 0-3 'STAB' chunk signature
bytes 4-7 length of STAB chunk (including signature and length
fields)
bytes 8-11 framerate base frequency in Hz
bytes 12-15 number of entries in the sample table
bytes 16-n sample table

Note that the length field ought to take the first 16 chunk bytes into account. However, it has been observed from some games (notably [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers] using '1.09' version FILM files) that the length field sometimes does not account for these 16 bytes.

The sample table consists of a series of 16-byte sample records. Each record is laid out as follows:

bytes 0-3 offset of sample chunk from beginning of sample data
bytes 4-7 length of sample chunk
bytes 8-11 sample info 1
bytes 12-15 sample info 2

The offset is the offset from the start of the sample data, not the absolute offset in the file. The length of the FILM header implicitly serves as a pointer to the beginning of the sample data in the file.

If the sample info 1 field is set to all ones, the sample is an audio chunk. Otherwise, it is a video chunk. If it is a video chunk, the top bit of the 32-bit number specifies whether the chunk is an inter-coded or an intra-coded frame. 0=intra-coded (a.k.a. keyframe), 1=inter-coded. This is useful for seeking since it is a good idea to only jump to key frames when seeking through a file.

The rest of the first sample info field and the second sample info field pertain to framerate calculation. Refer to the section on FILM framerate calculation for more information on proper FILM playback using these sample info fields.

== FILM Framerate Calculation ==

The STAB chunk contains a framerate base frequency in bytes 8-11. This frequency is expressed in ticks/second (Hz). Every video chunk has a frame tick count. For example, movie files in Panzer Dragoon I & II (FILM format versions 1.04 and 1.07, respectively) have a base frequency of 600 Hz. The frames have tick counts of 0, 20, 40, 60, 80, etc. Thus, there are 20 ticks between each successive frame.

(600 ticks/sec) / (20 ticks/frame) = 30 frames/second

However, not all FILM files exhibit such a nice, even framerate. Myst, for example, contains FILM files (version 1.01) with a base frequency of 30 Hz. Some of the frames skip 2, then 3 ticks. Here's a sample tick count progression: 0, 2, 5, 7, 10, 12, 15, 17...

Each STAB record has 2 32-bit sample info fields. For an audio chunk, sample info 1 is all ones and sample info 2 is always 1. For a video chunk, sample info 1 contains the keyframe bit (as described in the STAB section) and the absolute timestamp in clock ticks of the video frame with respect to the file's base frequency clock. The sample info 2 field contains the number of clock ticks until the next frame is rendered. This type of information would be particularly useful in an interrupt-driven, real-time multimedia system like, for instance, a video game console (such as the Sega Saturn).

It is important to note that an application that knows how to play FILM files can not assume a constant framerate. The files will not play correctly with such a method. It is also important to note that
converting FILM files to file formats that only support constant framerates (such as AVI) is not a winning strategy. The converted file will not play correctly.

== Video Codecs ==

If the video codec is 'cvid' in the FDSC chunk, the codec used is the deviant Cinepak format. A couple Dark Seed II videos also have the 'raw ' codec FourCC representing simple RGB888 data.

=== FILM Deviant Cinepak ('cvid') Video Data ===

The Cinepak data inside of a FILM file can not be decoded with a general purpose Cinepak decoding algorithm. It is reasonable to think that this was no accident. If FILM files contained standard CVID data, the files could be played on any computer that had some kind of Cinepak decoder implementation.

This document assumes familiarity with the [[Cinepak]] algorithm.

A CVID chunk is supposed to start with a 10-byte chunk header:

byte 0 flags
bytes 1-3 length of CVID data
bytes 4-5 width of coded frame
bytes 6-7 height of coded frame
bytes 8-9 number of coded strips

Following the chunk header ought to be the first byte of the first strip header. In the deviant CVID data stored in a FILM file, there appear to be an extra 2 bytes at the end of the chunk header, bringing the total header size to 12 bytes.

The length of the chunk as reported by the deviant CVID data chunk is also incorrect. The length field is supposed to report the length of the entire chunk including the header. The deviant CVID data reports a length that is 8 bytes too short. That is, the length reported in the CVID chunk is 8 bytes shorter than the length reported in the corresponding record of the FILM file's STAB chunk. The STAB chunk length takes into account the proper length, including the extra 2 bytes at the end of the chunk header.

Finally, the deviant CVID data appears to throw a potential decoder one more curveball with what appears to be data chunks that don't have, for lack of a better term, properly divisible chunk lengths. For example, a 0x2000 chunk commonly has a length of 0x604 bytes, which provides 2 bytes for the chunk ID, 2 bytes for the chunk length, and 0x600 bytes for 256 6-byte vectors. However, the deviant CVID data might have a 0x2000 chunk with a length of 0x600 bytes, which provides for the 4 chunk preamble bytes and 0x5FC bytes for the 6-byte vectors which is not evenly divisible by 6. This apparently confuses Cinepak decoders. The solution in this case is to unpack 255 6-byte vectors and then skip 2 bytes before attempting to decode the next chunk in the strip.

== FILM Audio Data ==

Audio data in a FILM file can be stored in a variety of formats which are mostly linear [[PCM]] variants.

CPK files from Sega Saturn games almost always contain linear PCM audio. The one known exception is Burning Rangers. This game apparently uses [[CRI ADX ADPCM]] audio coding.

Saturn CPK audio data is always stored as signed data. This is important to remember when playing 8-bit CPK audio data on a PC which generally expects 8-bit data to be unsigned.

When a CPK file contains 16-bit audio data, the individual PCM samples are stored in big endian format. Again, this is important to remember when playing on a PC since a PC will generally expect little endian
16-bit data.

If the CPK audio data is stereo (8- or 16-bit), the channel data is non-interleaved. Usually, stereo data is stored interleaved as a left channel sample followed by a right channel sample as follows:

L R L R L R L R ...

In a stereo CPK file, for each audio data chunk, the first half of the chunk contains left channel samples and the second half contains right channel samples. The likely reason for this scheme is that console audio hardware such as that found on the Sega Saturn usually features a number of audio channels which can each play a mono PCM stream at a particular pan position (e.g., from 0-15 where 0 is extreme left, 7 and 8 are center, and 15 is extreme right). In order to play a stereo PCM stream, one physical audio channel must be assigned to extreme left while a second channel is assigned to extreme right. Then the appropriate channel samples are sent to the correct channel. Since these files are optimized for playback on the Sega Saturn it makes sense to arrange the audio samples like this.

The Sega CD audio playback hardware ostensibly supports native sign/magnitude audio samples. All Sega CD games studied use this format to store audio data. Sign/magnitude number coding for 8-bit numbers
means that for each 8-bit byte:

bit 7 sign
bits 6-0 magnitude (value)

This is slightly different from twos complement encoding which is how computers typically store signed numbers. For example, in the sign/magnitude scheme, 0x81 represents -1 and 0xFF represents -127. 0x01
and 0x7F still represent 1 and 127, respectively, just as in unsigned, and signed twos complement coding.

== Early Sega CD FILM Files ==

Some Sega CD games as well as at least one 3DO game (Lemmings) use an early version of the FILM format. Unfortunately, there are a lot of variations and a general-purpose player will probably require a lot of
special-case logic in order to deal with every known circumstance.

The first difference in these early files is the version number. These early files do not have ASCII-readable version fields. Some have NULL or other non-ASCII versions. This helps automatic detection.

The second major difference that all of these early files appear to exhibit is an abbreviated FDSC chunk which omits any audio information. Thus, the FDSC chunk is laid out as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); this FDSC chunk is 20 (0x14) bytes long
bytes 8-11 FOURCC of video codec
bytes 12-15 height of video frames
bytes 16-19 width of video frames

The lack of audio information leaves room for experimentation. The following is a list of known games which have early FILM files along with any special quirks observed.

On the Lemmings 3DO game, there are 2 files with the .film extension (the 3DO game console uses a custom filesystem which allows for file extensions longer than 3 characters). The files have a NULL version field. The files use CVID data which is deviant in the same manner as typical FILM CVID data with an added quirk: There appear to be 6 extra bytes between the end of the CVID chunk header and the start of the first strip header, rather than the usual 2 extra bytes. The Lemmings FILM files also contain 8-bit signed, monaural PCM data with a sampling frequency of 22050 Hz.

The Batman and Robin Sega CD title has a series of files with the extension .s. They are early FILM files with a version field of 0x00020000. Further, bytes 12-15 of the main FILM header are not set to 0 as is usually seen in FILM files. The files have a video fourcc of 'Seg4' which is probably Cinepak for Sega or a variant thereof. The files have STAB chunks which are a constant 0x20 (32) bytes long. This consists of the 'STAB' signature, a 4-byte chunk length, the base playback frequency, a sample count, and one 16-byte sample record. These files do not store the sample table in one place. Instead, they store one sample record followed immediately by the data corresponding to that sample record. Repeat until the end of the file.

The Dracula Unleashed Sega CD title contains a series of files beginning with video?? with no file extension. They are early FILM files with a NULL version field, abbreviated FDSC chunk, and 'sega' as a video codec (Cinepak for Sega). The audio is 8-bit sign/magnitude audio with a sampling frequency of 16000 Hz.

Jurassic Park for the Sega CD has a large number of files with the file extension .MVD. They are early FILM files with the same characteristics as the FILM files in Dracula Unleashed.

The Tomcat Alley title for the Sega CD has a massive data file called tca.bin. Inside this data file are a lot of FILM files. These files have NULL version fields. The files have abbreviated FDSC chunks and the
'sega' video fourcc. They also have short STAB chunks with an Apple Quicktime 'mdia' atom appended at the end.

== Strategy For Detecting FILM File Types ==

There are quite a few variations and deviations in the FILM file format. This section presents logic for detecting and dealing with the variations.

File extension detection is not especially useful since many games will masquerade their files with another extension. The best method to determine whether a file is a FILM file is to read the first 4 bytes and check for the signature 'FILM'.

Upon validating the signature:

* read the file version in the FILM header
* if the file version consists of ASCII characters
** if the file version is '1.09', watch out for bad length of STAB chunk as well as ADPCM audio
** load as standard FILM file, be sure to feed CVID data through Cinepak decoder that can handle it
* if the file version is 0x00020000
** read the video fourcc
** if the video fourcc is 'Seg4'
*** assume the file comes from Batman and Robin
* if the file version is NULL
** read the video fourcc
** if the video fourcc is 'cvid'
*** assume the file comes from the Lemmings 3DO game
*** be prepared to decode special variant of modified CVID data
*** assume 8-bit, mono, 22050 Hz PCM audio
** if the video fourcc is 'sega'
*** assume the file comes from one of several Sega CD games that agreed on this format
*** assume 8-bit, mono, 16000 Hz sign/magnitude audio

== Games That Use FILM Files ==

These games are known to use some variation of FILM files. Observed file version numbers are noted where known.

* [http://www.mobygames.com/game/saturn/astal Astal (Sega Saturn)]: '0.91', '1.06'
* [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/clockwork-knight Clockwork Knight (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/criticom Criticom (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/d D (Sega Saturn)]
* [http://www.mobygames.com/game/sega-saturn/dark-seed-ii Dark Seed II (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/defcon-5 Defcon 5 (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/iron-storm_ Iron Storm (Sega Saturn)]
* [http://www.mobygames.com/game/3do/lemmings Lemmings (3DO)]: unversioned
* [http://www.mobygames.com/game/saturn/myst Myst (Sega Saturn)]: '1.01'
* [http://www.mobygames.com/game/saturn/nights-into-dreams Nights Into Dreams (Sega Saturn)]: '0.91', '1.01', '1.06', '1.07', '1.08'
* [http://www.mobygames.com/game/saturn/panzer-dragoon Panzer Dragoon (Sega Saturn)]: '1.04'
* [http://www.mobygames.com/game/saturn/panzer-dragoon-ii-zwei Panzer Dragoon II: Zwei (Sega Saturn)]: '1.07'
* [http://www.mobygames.com/game/sega-saturn/roberta-williams-phantasmagoria Phantasm (Sega Saturn)]: '1.06', '1.08', '1.09'
* [http://www.mobygames.com/game/sega-saturn/return-to-zork Return to Zork (Sega Saturn)]: '1.02', '1.06', '1.07'
* Sega Saturn Bootleg Sampler (Sega Saturn): '1.04'
* [http://www.mobygames.com/game/saturn/shockwave-assault Shockwave Assault (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/skeleton-warriors Skeleton Warriors (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/space-jam Space Jam (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/street-fighter-the-movie Street Fighter: The Movie (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-squad-virtual-cop Virtua Cop (Sega Saturn)]: '1.08'
* World Series Baseball II (Sega Saturn)

[[Category:Container Formats]]
[[Category:Game Formats]]

Sofdec

2011-04-23T23:15:44Z

Clone2727: typo

* Extension: sfd
* Company: [[CRI]]
* Website: http://www.cri-mw.co.jp/products/product_sfd_e.htm
* Samples: Official website above, http://samples.mplayerhq.hu/game-formats/sfd/

SFD is a format commonly found on [[Sega Dreamcast]] console games, and is also available for a number of other video game consoles. The files package [[MPEG]] video with a custom ADPCM audio codec called [[CRI ADX ADPCM]] in a standard [[MPEG-PS]] container.

Currently many MPEG decoders (ex. [[FFmpeg]]) fails to process recent SFD files properly, generating highly blocky/garbled output.

== Games Using Sofdec ==
* Battle Stadium DON (Nintendo GameCube)
* Crysis Demo (PC)
* [http://www.mobygames.com/game/gamecube/f-zero-gx F-Zero GX (Nintendo GameCube)]
* Marvel Ultimate Allience (PC, Sony Playstation 2)
* [http://www.mobygames.com/game/dreamcast/resident-evil-code-veronica Resident Evil: Code Veronica (Sega Dreamcast)]
* [http://www.mobygames.com/game/gamecube/resident-evil-code-veronica-x Resident Evil: Code Veronica X (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/resident-evil-4 Resident Evil 4 (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/sonic-adventure-2-battle Sonic Adventure 2: Battle (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/soulcalibur-ii SoulCalibur 2 (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/star-fox-assault Starfox Assault (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/star-wars-bounty-hunter Star Wars: Bounty Hunter (Nintendo GameCube)]

[[Category:Game Formats]]

Smush

2011-04-19T02:17:08Z

Clone2727: fill in some more versions; note that Rebel Assault has the old ANIM v1 format

This page attempts to document the [[LucasArts]] Smush codec. The [[SANM]] codec document is complete; the SAN codec is still under (de)construction.

Samples from various games are located at http://samples.mplayerhq.hu/game-formats/la-san/ and http://samples.mplayerhq.hu/game-formats/la-snm/.

== Usage Matrix ==
{| border="1" cellpadding="2"
! Name !! Variant !! Video Codec || Audio Codec
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault Rebel Assault]
| ANIM v1 ||   ||  
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault-ii-the-hidden-empire Rebel Assault II]
| ANIM v2 ||   ||  
|-
| Rebel Assault II demo
| ANIM v2 || FOBJ Codec 37 ||  
|-
| Rebel Assault II trailer
| ANIM v2 ||   || PSAD
|-
| [http://www.mobygames.com/game/dos/full-throttle Full Throttle]
| ANIM v2 || FOBJ Codec 37 || PSAD
|-
| [http://www.mobygames.com/game/dos/dig The Dig]
| ANIM v2 || FOBJ Codec 37 || IACT
|-
| [http://www.mobygames.com/game/windows/curse-of-monkey-island The Curse Of Monkey Island]
| ANIM v2 || FOBJ Codec 47 || IACT
|-
| [http://www.mobygames.com/game/windows/outlaws Outlaws]
| ANIM v2 ||   ||  
|-
| Outlaws demo
| ANIM v2 || FOBJ Codec 47 ||  
|-
| Grim Fandango demo
| ANIM v2 || FOBJ Codec 47 ||  
|-
| Grim Fandango trailer
| ANIM v2 ||   || IACT
|-
| [http://www.mobygames.com/game/windows/grim-fandango Grim Fandango]
| SANM || Bl16 (blocky16) || [[VIMA]]
|-
| [http://www.mobygames.com/game/windows/star-wars-shadows-of-the-empire Shadows of the Empire (PC)]
| ANIM v2 ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-x-wing-alliance X-Wing Alliance]
| SANM ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-episode-i-racer Star Wars Racer]
| SANM + gzip (ZNM) ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-droidworks Star Wars DroidWorks]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/indiana-jones-and-the-infernal-machine Indiana Jones and the Infernal Machine]
| SANM ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-jedi-knight-mysteries-of-the-sith Jedi Knight: Mysteries of the Sith]
| ANIM v2 ||   ||  
|-
| [http://www.mobygames.com/game/windows/mortimer-and-the-riddles-of-the-medallion Mortimer and the Riddles of the Medallion]
|   ||   ||  
|-
| Making Magic CDROM (not a game but still uses smush)
|   ||   ||  
|-
| [http://www.mobygames.com/game/escape-from-monkey-island Escape From Monkey Island]
|   || apparently has Smush headers but uses [[Bink Container|Bink]] ||  
|-
| Star Wars Episode 1: Insider's Guide
| SANM ||   ||  
|-
| Jar Jar's Journey Storybook
| SANM ||   ||  
|}

== Variants ==
Smush comes in two variants. FOURCC "[[SAN|ANIM]]" was used up until Grim Fandango, and this variant has two sub-variants: v1 (Rebel Assault only) and v2 (all others). FOURCC "[[SNM|SANM]]" was used from Grim Fandango up until its replacement by [[Bink Container|Bink]], possibly in Escape From Monkey Island.

[[Category:Game Formats]]
[[Category:Undiscovered Game Formats]]

Sega FILM

2010-08-12T02:23:56Z

Clone2727: add info on the Dark Seed II raw videos

''This page is based on the document 'Description of the Sega FILM/CPK File Format' by Mike Melanson found at [http://multimedia.cx/film-format.txt http://multimedia.cx/film-format.txt].''

* Extensions: cpk, cak, film
* Company: [[Sega (Company)|Sega]]
* Samples:
** [http://samples.mplayerhq.hu/game-formats/film-cpk/ http://samples.mplayerhq.hu/game-formats/film-cpk/]
** Batman and Robin Sega CD with 'Seg4' data: [http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/ http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/]
** Dracula Unleashed/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/ http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/]
** Jurassic Park/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/ http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/]

FILM is a multimedia container file format developed by Sega for use on its early CD-ROM home video game consoles. Based on analysis of a number of Sega CD and Saturn games, it appears that the format was first developed sometime during the era of the Sega CD, Sega's first CD-based video game console. There are many early variations of the FILM format observed on a number of Sega CD titles. Further, early FILM files have been observed on at least one 3DO game ([http://www.mobygames.com/game/3do/lemmings Lemmings]).

The Sega Saturn video game console, released in 1994, was also CD-ROM-based and apparently offered developers a standardized SDK for full motion video (FMV) playback using a modified variant of the well-known [[Cinepak]] video codec.

It is possible to store both audio and video in a FILM file. Alternatively, the format is able to handle either video without audio, or vice versa.

== Sega Saturn CPK File Format ==

All multi-byte numbers are stored in big endian format.

Many Sega Saturn CD-ROM games use this file format to store frames of a Cinepak-compressed video interleaved with uncompressed [[PCM]] audio. When this is the case, the files will typically have the extension .CPK (which is why FILM files are usually known as CPK files). Sometimes, audio-only FILM files will have a .SND extension.

The general format is laid out as follows:

+-----------------------+
| +-------------------+ |
| | FILM header | |
| | | |
| | +---------------+ | |
| | | FDSC chunk | | |
| | +---------------+ | |
| | | |
| | +---------------+ | |
| | | STAB chunk | | |
| | +---------------+ | |
| | | |
| +-------------------+ |
| |
| Audio or Video Data |
| .. |
| .. |
+-----------------------+

A FILM file will usually consist of a header followed by interleaved audio and video chunks. The FILM header has the following structure:

bytes 0-3 'FILM' signature
bytes 4-7 length of FILM header (including signature and length
fields)
bytes 8-11 FILM format version in ASCII (ex: '1.01' or '1.07')
bytes 12-15 unknown (may be reserved and set to 0)
bytes 16-n remainder of FILM header

Different Sega Saturn games include FILM files with a variety of FILM version numbers. Sometimes, the same game will include FILM files with a variety of format versions. A version number implies that there has been some change to the file format, but I have yet to observe any differences between different FILM file versions (except possibly for version '1.09'; see STAB chunk for more details).

The remainder of the FILM header contains a number of chunks describing the media data in the file. Usually, the number of chunks is 2: A FDSC chunk and a STAB chunk.

A FDSC chunk contains file description information. The chunk format is as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); an FDSC chunk should be 32 (0x20) bytes long
bytes 8-11 FOURCC of video codec (usually 'cvid' for Cinepak or null
for no video)
bytes 12-15 height of video frames
bytes 16-19 width of video frames
byte 20 bits per pixel (always seems to be 24)
byte 21 number of audio channels
byte 22 audio sampling resolution in bits (either 8 or 16)
byte 23 unknown
bytes 24-25 audio sampling frequency in Hz
bytes 26-31 unknown (may be reserved and set to 0)

Note that the height field precedes the width field, which is unusual since width usually precedes height when expressing video resolution.

The fields pertaining to audio (channels, bits, and sample rate) will all be 0 if there is no audio present in the file.

A STAB chunk contains a table of media sample information. The chunk format is as follows:

bytes 0-3 'STAB' chunk signature
bytes 4-7 length of STAB chunk (including signature and length
fields)
bytes 8-11 framerate base frequency in Hz
bytes 12-15 number of entries in the sample table
bytes 16-n sample table

Note that the length field ought to take the first 16 chunk bytes into account. However, it has been observed from some games (notably [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers] using '1.09' version FILM files) that the length field sometimes does not account for these 16 bytes.

The sample table consists of a series of 16-byte sample records. Each record is laid out as follows:

bytes 0-3 offset of sample chunk from beginning of sample data
bytes 4-7 length of sample chunk
bytes 8-11 sample info 1
bytes 12-15 sample info 2

The offset is the offset from the start of the sample data, not the absolute offset in the file. The length of the FILM header implicitly serves as a pointer to the beginning of the sample data in the file.

If the sample info 1 field is set to all ones, the sample is an audio chunk. Otherwise, it is a video chunk. If it is a video chunk, the top bit of the 32-bit number specifies whether the chunk is an inter-coded or an intra-coded frame. 0=intra-coded (a.k.a. keyframe), 1=inter-coded. This is useful for seeking since it is a good idea to only jump to key frames when seeking through a file.

The rest of the first sample info field and the second sample info field pertain to framerate calculation. Refer to the section on FILM framerate calculation for more information on proper FILM playback using these sample info fields.

== FILM Framerate Calculation ==

The STAB chunk contains a framerate base frequency in bytes 8-11. This frequency is expressed in ticks/second (Hz). Every video chunk has a frame tick count. For example, movie files in Panzer Dragoon I & II (FILM format versions 1.04 and 1.07, respectively) have a base frequency of 600 Hz. The frames have tick counts of 0, 20, 40, 60, 80, etc. Thus, there are 20 ticks between each successive frame.

(600 ticks/sec) / (20 ticks/frame) = 30 frames/second

However, not all FILM files exhibit such a nice, even framerate. Myst, for example, contains FILM files (version 1.01) with a base frequency of 30 Hz. Some of the frames skip 2, then 3 ticks. Here's a sample tick count progression: 0, 2, 5, 7, 10, 12, 15, 17...

Each STAB record has 2 32-bit sample info fields. For an audio chunk, sample info 1 is all ones and sample info 2 is always 1. For a video chunk, sample info 1 contains the keyframe bit (as described in the STAB section) and the absolute timestamp in clock ticks of the video frame with respect to the file's base frequency clock. The sample info 2 field contains the number of clock ticks until the next frame is rendered. This type of information would be particularly useful in an interrupt-driven, real-time multimedia system like, for instance, a video game console (such as the Sega Saturn).

It is important to note that an application that knows how to play FILM files can not assume a constant framerate. The files will not play correctly with such a method. It is also important to note that
converting FILM files to file formats that only support constant framerates (such as AVI) is not a winning strategy. The converted file will not play correctly.

== Video Codecs ==

If the video codec is 'cvid' in the FDSC chunk, the codec used is the deviant Cinepak format. A couple Dark Seed II videos also have the 'raw ' codec FourCC representing simple RGB888 data.

=== FILM Deviant Cinepak ('cvid') Video Data ===

The Cinepak data inside of a FILM file can not be decoded with a general purpose Cinepak decoding algorithm. It is reasonable to think that this was no accident. If FILM files contained standard CVID data, the files could be played on any computer that had some kind of Cinepak decoder implementation.

This document assumes familiarity with the [[Cinepak]] algorithm.

A CVID chunk is supposed to start with a 10-byte chunk header:

byte 0 flags
bytes 1-3 length of CVID data
bytes 4-5 width of coded frame
bytes 6-7 height of coded frame
bytes 8-9 number of coded strips

Following the chunk header ought to be the first byte of the first strip header. In the deviant CVID data stored in a FILM file, there appear to be an extra 2 bytes at the end of the chunk header, bringing the total header size to 12 bytes.

The length of the chunk as reported by the deviant CVID data chunk is also incorrect. The length field is supposed to report the length of the entire chunk including the header. The deviant CVID data reports a length that is 8 bytes too short. That is, the length reported in the CVID chunk is 8 bytes shorter than the length reported in the corresponding record of the FILM file's STAB chunk. The STAB chunk length takes into account the proper length, including the extra 2 bytes at the end of the chunk header.

Finally, the deviant CVID data appears to throw a potential decoder one more curveball with what appears to be data chunks that don't have, for lack of a better term, properly divisible chunk lengths. For example, a 0x2000 chunk commonly has a length of 0x604 bytes, which provides 2 bytes for the chunk ID, 2 bytes for the chunk length, and 0x600 bytes for 256 6-byte vectors. However, the deviant CVID data might have a 0x2000 chunk with a length of 0x600 bytes, which provides for the 4 chunk preamble bytes and 0x5FC bytes for the 6-byte vectors which is not evenly divisible by 6. This apparently confuses Cinepak decoders. The solution in this case is to unpack 255 6-byte vectors and then skip 2 bytes before attempting to decode the next chunk in the strip.

== FILM Audio Data ==

Audio data in a FILM file can be stored in a variety of formats which are mostly linear [[PCM]] variants.

CPK files from Sega Saturn games almost always contain linear PCM audio. The one known exception is Burning Rangers. This game apparently uses [[CRI ADX ADPCM]] audio coding.

Saturn CPK audio data is always stored as signed data. This is important to remember when playing 8-bit CPK audio data on a PC which generally expects 8-bit data to be unsigned.

When a CPK file contains 16-bit audio data, the individual PCM samples are stored in big endian format. Again, this is important to remember when playing on a PC since a PC will generally expect little endian
16-bit data.

If the CPK audio data is stereo (8- or 16-bit), the channel data is non-interleaved. Usually, stereo data is stored interleaved as a left channel sample followed by a right channel sample as follows:

L R L R L R L R ...

In a stereo CPK file, for each audio data chunk, the first half of the chunk contains left channel samples and the second half contains right channel samples. The likely reason for this scheme is that console audio hardware such as that found on the Sega Saturn usually features a number of audio channels which can each play a mono PCM stream at a particular pan position (e.g., from 0-15 where 0 is extreme left, 7 and 8 are center, and 15 is extreme right). In order to play a stereo PCM stream, one physical audio channel must be assigned to extreme left while a second channel is assigned to extreme right. Then the appropriate channel samples are sent to the correct channel. Since these files are optimized for playback on the Sega Saturn it makes sense to arrange the audio samples like this.

The Sega CD audio playback hardware ostensibly supports native sign/magnitude audio samples. All Sega CD games studied use this format to store audio data. Sign/magnitude number coding for 8-bit numbers
means that for each 8-bit byte:

bit 7 sign
bits 6-0 magnitude (value)

This is slightly different from twos complement encoding which is how computers typically store signed numbers. For example, in the sign/magnitude scheme, 0x81 represents -1 and 0xFF represents -127. 0x01
and 0x7F still represent 1 and 127, respectively, just as in unsigned, and signed twos complement coding.

== Early Sega CD FILM Files ==

Some Sega CD games as well as at least one 3DO game (Lemmings) use an early version of the FILM format. Unfortunately, there are a lot of variations and a general-purpose player will probably require a lot of
special-case logic in order to deal with every known circumstance.

The first difference in these early files is the version number. These early files do not have ASCII-readable version fields. Some have NULL or other non-ASCII versions. This helps automatic detection.

The second major difference that all of these early files appear to exhibit is an abbreviated FDSC chunk which omits any audio information. Thus, the FDSC chunk is laid out as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); this FDSC chunk is 20 (0x14) bytes long
bytes 8-11 FOURCC of video codec
bytes 12-15 height of video frames
bytes 16-19 width of video frames

The lack of audio information leaves room for experimentation. The following is a list of known games which have early FILM files along with any special quirks observed.

On the Lemmings 3DO game, there are 2 files with the .film extension (the 3DO game console uses a custom filesystem which allows for file extensions longer than 3 characters). The files have a NULL version field. The files use CVID data which is deviant in the same manner as typical FILM CVID data with an added quirk: There appear to be 6 extra bytes between the end of the CVID chunk header and the start of the first strip header, rather than the usual 2 extra bytes. The Lemmings FILM files also contain 8-bit signed, monaural PCM data with a sampling frequency of 22050 Hz.

The Batman and Robin Sega CD title has a series of files with the extension .s. They are early FILM files with a version field of 0x00020000. Further, bytes 12-15 of the main FILM header are not set to 0 as is usually seen in FILM files. The files have a video fourcc of 'Seg4' which is probably Cinepak for Sega or a variant thereof. The files have STAB chunks which are a constant 0x20 (32) bytes long. This consists of the 'STAB' signature, a 4-byte chunk length, the base playback frequency, a sample count, and one 16-byte sample record. These files do not store the sample table in one place. Instead, they store one sample record followed immediately by the data corresponding to that sample record. Repeat until the end of the file.

The Dracula Unleashed Sega CD title contains a series of files beginning with video?? with no file extension. They are early FILM files with a NULL version field, abbreviated FDSC chunk, and 'sega' as a video codec (Cinepak for Sega). The audio is 8-bit sign/magnitude audio with a sampling frequency of 16000 Hz.

Jurassic Park for the Sega CD has a large number of files with the file extension .MVD. They are early FILM files with the same characteristics as the FILM files in Dracula Unleashed.

The Tomcat Alley title for the Sega CD has a massive data file called tca.bin. Inside this data file are a lot of FILM files. These files have NULL version fields. The files have abbreviated FDSC chunks and the
'sega' video fourcc. They also have short STAB chunks with an Apple Quicktime 'mdia' atom appended at the end.

== Strategy For Detecting FILM File Types ==

There are quite a few variations and deviations in the FILM file format. This section presents logic for detecting and dealing with the variations.

File extension detection is not especially useful since many games will masquerade their files with another extension. The best method to determine whether a file is a FILM file is to read the first 4 bytes and check for the signature 'FILM'.

Upon validating the signature:

* read the file version in the FILM header
* if the file version consists of ASCII characters
** if the file version is '1.09', watch out for bad length of STAB chunk as well as ADPCM audio
** load as standard FILM file, be sure to feed CVID data through Cinepak decoder that can handle it
* if the file version is 0x00020000
** read the video fourcc
** if the video fourcc is 'Seg4'
*** assume the file comes from Batman and Robin
* if the file version is NULL
** read the video fourcc
** if the video fourcc is 'cvid'
*** assume the file comes from the Lemmings 3DO game
*** be prepared to decode special variant of modified CVID data
*** assume 8-bit, mono, 22050 Hz PCM audio
** if the video fourcc is 'sega'
*** assume the file comes from one of several Sega CD games that agreed on this format
*** assume 8-bit, mono, 16000 Hz sign/magnitude audio

== Games That Use FILM Files ==

These games are known to use some variation of FILM files. Observed file version numbers are noted where known.

* [http://www.mobygames.com/game/saturn/astal Astal (Sega Saturn)]: '0.91', '1.06'
* [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/clockwork-knight Clockwork Knight (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/criticom Criticom (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/d D (Sega Saturn)]
* [http://www.mobygames.com/game/sega-saturn/dark-seed-ii Dark Seed II (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/defcon-5 Defcon 5 (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/iron-storm_ Iron Storm (Sega Saturn)]
* [http://www.mobygames.com/game/3do/lemmings Lemmings (3DO)]: unversioned
* [http://www.mobygames.com/game/saturn/myst Myst (Sega Saturn)]: '1.01'
* [http://www.mobygames.com/game/saturn/nights-into-dreams Nights Into Dreams (Sega Saturn)]: '0.91', '1.01', '1.06', '1.07', '1.08'
* [http://www.mobygames.com/game/saturn/panzer-dragoon Panzer Dragoon (Sega Saturn)]: '1.04'
* [http://www.mobygames.com/game/saturn/panzer-dragoon-ii-zwei Panzer Dragoon II: Zwei (Sega Saturn)]: '1.07'
* [http://www.mobygames.com/game/sega-saturn/roberta-williams-phantasmagoria Phantasm (Sega Saturn)]: '1.06', '1.08', '1.09'
* Sega Saturn Bootleg Sampler (Sega Saturn): '1.04'
* [http://www.mobygames.com/game/saturn/shockwave-assault Shockwave Assault (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/skeleton-warriors Skeleton Warriors (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/space-jam Space Jam (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/street-fighter-the-movie Street Fighter: The Movie (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-squad-virtual-cop Virtua Cop (Sega Saturn)]: '1.08'
* World Series Baseball II (Sega Saturn)

[[Category:Container Formats]]
[[Category:Game Formats]]

Phantom Cine

2010-06-14T14:29:39Z

Clone2727: typo

Extensions: cine
* Company: [[Vision Research Inc.]]
* Samples: [http://samples.mplayerhq.hu/V-codecs/Phantom_Cine http://samples.mplayerhq.hu/V-codecs/Phantom_Cine]

The Phantom Cine format

Note: below information is based on looking at a sample file, please verify against the specification linked at the end.

This is a raw uncompressed format.

It contains a lot of metadata, and index and raw uncompressed frames, presumably in Bayer format.
Know samples store each Bayer sample with 16 bits, where only the lowest 14 bits are relevant (the value 16 can be determined from the BitmapInfoHeader, the 14 bits are somewhere in the file as well, as can be seen from the xml-representation of the metadata (the RealBPP entry) - all data in the xml file exists in the .cine file as well). Making the lowest instead of the highest 14 bits the relevant ones is a rather unfortunate choice since it makes conversion to standard formats more difficult.

Note: some of the fixed offsets below might not always be at that offset, though they are for the known samples and there are no length fields that would allow calculating them in a sensible way.

All values are stored in little-endian format.

The files start with the bytes "CI", followed by two bytes possibly giving a size or index (all files so far have the value 2c 00).

This "main header" contains this data:
2 bytes "CI"
2 bytes length
2 bytes "compression type" (always 2) ??
2 bytes version (always 1)
4 bytes number of first frame (usually negative)
4 bytes number of frames in files
4 bytes number of first frame (repeated?)
4 bytes number of frames in files (repeated?)
4 bytes offset of BitmapInfoHeader
4 bytes offset of ???
4 bytes offset of file index
8 bytes recording time stamp (?)

At offset 0x2c there is a BitmapInfoHeader structure. The first 4 bytes give its length (0x28).

The next sections starts with "ST" at offset 0xe0, again followed by two bytes giving a size or index (so far always 6c 16).

Variable length part seems to start at offset 0x16c0. Note that this is the sum of the possible length files from CI, ST and BitmapInfoHeader (i.e. 0x2c + 0x28 + 0x166c = 0x16c0).

It consists of 3 parts:

1) timestamps

2) exposure values

3) index

The timestamp and exposure values parts start with a 4-byte length field allowing to skip them.

The index contains a 8-byte offset value for each frame. It does not have a length field, the number of entries is determined from the number of frames in the main header.

At each offset indicated by the index, there is first a header. The first 4 bytes of the header give the length of the header. Only the value 8 has a known meaning, in which case the next 4 bytes give the length of the frame data.

== External Links ==
* [http://www.visionresearch.com/devzonedownloads/cine640.pdf http://www.visionresearch.com/devzonedownloads/cine640.pdf] The CINE File Format, Vision Research Inc., 2007

[[Category:Container Formats]]

Talk:IDA Pro

2010-03-11T06:48:20Z

Clone2727: reply

The freeware & graph tool link are both broken- time to put them on the mirror page if anyone knows of another link or has them downloaded. [[User:Dashcloud|Dashcloud]] 19:08, 10 March 2010 (EST)
: Done. -[[User:Clone2727|Clone2727]] 01:48, 11 March 2010 (EST)

IDA Pro

2010-03-11T06:47:56Z

Clone2727: update links

* Website: http://www.hex-rays.com/idapro/
* Demo version: http://www.hex-rays.com/idapro/idadowndemo.htm
* Freeware version (currently v4.9): http://www.hex-rays.com/idapro/idadownfreeware.htm
* Wingraph32 GPL source code: http://www.hex-rays.com/idapro/freefiles/wingraph32_src.zip

IDA Pro is a disassembler and debugger with a lot of features that is very useful for reverse engineering.

It is proprietary software that runs on Windows and Linux; there is a zero-cost evaluation version.

== Boosting the freeware version ==
The freeware version of IDA Pro is an invaluable tool. One important function is the ability to produce different flow graphs
from the disassembly. Sometimes these graphs can be quite messy and needs to be processed. The version of wingraph32.exe that
is included with the freeware version of IDA Pro can't save the generated graphs. Just replace it with a version from a demo
version of IDA Pro and the save option will be available. Saved graphs will have a .gdl suffix.

== Converting gdl flow graphs to dot files ==
Since there aren't any really good tools to display and edit gdl files, you can convert them with the following script

#!/usr/bin/perl

use strict;

my $FILE1 = $ARGV[0];
open(OUTFILE, ">".$FILE1.".dot") or die "File doesn't exist\n";
my $indata = `cat $FILE1`;
my @split = split(/node:/, $indata);
my $graphname = shift @split;
$graphname =~ s/^.*title:[^"]*"([^"]*)".*$/$1/s;
print OUTFILE "digraph \"$graphname\" {\n";
print OUTFILE "\tgraph [\n";
print OUTFILE "\t]\n";
print OUTFILE "\tnode [\n";
print OUTFILE "\t\tshape = \"box\"\n";
print OUTFILE "\t]\n";
print OUTFILE "\tedge [\n";
print OUTFILE "\t]\n";

# convert nodes
foreach my $n (@split) {
$n =~ s/}.*$//s;
my $label = my $title = $n;
$title =~ s/^.*title:[^"]*"([^"]*)".*$/$1/s;
$label =~ s/^.*label:[^"]*"([^"]*)".*$/$1/s;
$label =~ s/\n/\\n/sg;
print OUTFILE "\t\"$title\" [\n";
print OUTFILE "\t\tlabel = \"$label\"\n";
print OUTFILE "\t];\n";
}

@split = split(/edge:/, $indata);
shift @split;

# convert edges
foreach my $e (@split) {
$e =~ s/}.*$//s;
my $color = my $label = my $source = my $target = $e;
$source =~ s/^.*sourcename:[^"]*"([^"]*)".*$/$1/s;
$target =~ s/^.*targetname:[^"]*"([^"]*)".*$/$1/s;
print OUTFILE "\t\"$source\" -> \"$target\" [\n";
if ($label =~ s/^.*label:[^"]*"([^"]*)".*$/$1/s) {
$label =~ s/\n/\\n/sg;
print OUTFILE "\t\tlabel = \"$label\"\n";
}
if ($color =~ s/^.*color:<nowiki>[[:space:]]</nowiki>*([^ ]*)[[:space:]}].*$/$1/s) {
print OUTFILE "\t\tcolor = $color\n";
}
print OUTFILE "\t];\n";
}
print OUTFILE "}\n"

== Recovering the function prototypes from the disassembly ==
Well it's not really possible but a good hint is possible without much work. First load the binary you want to analyse. IDA Pro
will process the file for some time. If you start browsing around you will see that IDA Pro can make a good guess on how many
arguments a function have. That is one thing that can be extracted. The other is if a function returns something or not. The x86 C ABI
declares that the return type if any has to be left in the eax register. So if the eax register is used after a call the function
that was called returned something. The following not so nice perl script can process the asm file that can be produced from IDA Pro
with Produce->ASM-File (Alt+F10).

#!/usr/bin/perl
#Argument parser

if (@ARGV){
print "@ARGV\n";
if ($ARGV[0] eq "-f"){
$FILE1 = $ARGV[1];
$FILE2 = $ARGV[2];
$filter = 1;
}
}
else{
print "Usage:\n";
print "./argumentcounter.pl [command] file.asm output.txt\n";
print "-f dummy command\n";
exit;
}

#File IO
open(OUTFILE, ">$FILE2") or die "File problem\n";
@indata = `cat $FILE1`;

$fn = 0; #amount of founctions
$functions[$fn] = "";
$arguments[$fn] = 0;
$f_start = 0;
$links= 0;
foreach $rad (@indata)
{
$rowcounter++;

if ($rad =~ m/ proc near/) {
$functions[$fn] = $`;
$fn++;
$f_start = 1;
$arguments[$fn] = 0;
#print STDOUT "$`\n";
}
if ($f_start == 1) {
$radsubstring = (substr $rad,0,3);
if ($radsubstring eq "arg") {
$arguments[$fn]++;
}
}
if ($rad =~ m/ endp/) {
$f_start = 0;
}

#return type detector
if ($rad =~ m/call\t/) {
$retfunction = $';
$retfunction =~ m/\n/;
$retfunction = $`;
chop($retfunction);
$rowcounter = 0;
$callcheck = 1;
}
if (($callcheck) && ($rowcounter>0)) {

@tmpsplit=split /\t/,$rad;
chomp($tmpsplit[0]);
chomp($tmpsplit[1]);
chomp($tmpsplit[2]);
chomp($tmpsplit[3]);
$instruction = $tmpsplit[2];
$arguments = $tmpsplit[3];
chop($arguments);
if ($arguments =~ m/, /) {
@argum=split /, /,$arguments;
}
#chomp($argum[0]);
#chomp($instruction);
if ($argum[0] eq "eax") {
$callcheck = 0;
}
if ($argum[1] eq "eax") {
$callcheck = 0;
}

#check source operand if it is eax
if (($argum[1] eq "eax") && ($instruction ne "xor")) {
$callcheck = 0;
$nonvoid{$retfunction} = $nonvoid{$retfunction} +1;
#print STDOUT "$retfunction returns nonvoid\n";
}
if (($argum[0] eq "eax") && ($argum[1] ne "eax")){
$callcheck = 0;
$void{$retfunction} = $void{$retfunction} +1;
#print STDOUT "$retfunction returns void\n";
}
if ($instruction =~ /retn/) {
#stop searching when the current function returns
$callcheck = 0;
$void{$retfunction} = $void{$retfunction} +1;
#print STDOUT "$retfunction returns void\n";
}
if ($rowcounter > 10) {
$callcheck = 0;
}
$argum[0] = "";
$argum[1] = "";
}
}

for ($i=0 ; $i < $fn ; $i++){
#returntype handling
$returntype = "unknown";
if ($void{$functions[$i]} > 0) {
$returntype = "void";
}
if ($nonvoid{$functions[$i]} > 0) {
$returntype = "int";
}
if (($void{$functions[$i]} > 0) && ($nonvoid{$functions[$i]} > 0)){
$returntype = "void $void{$functions[$i]} - $nonvoid{$functions[$i]} int";
}
print STDOUT "$returntype $functions[$i] $arguments[$i]\n";
}

[[Category:RE Tools]]

Sega FILM

2010-02-22T02:51:27Z

Clone2727: /* Games That Use FILM Files */ Dark Seed II Saturn uses 1.09

''This page is based on the document 'Description of the Sega FILM/CPK File Format' by Mike Melanson found at [http://multimedia.cx/film-format.txt http://multimedia.cx/film-format.txt].''

* Extensions: cpk, cak, film
* Company: [[Sega (Company)|Sega]]
* Samples:
** [http://samples.mplayerhq.hu/game-formats/film-cpk/ http://samples.mplayerhq.hu/game-formats/film-cpk/]
** Batman and Robin Sega CD with 'Seg4' data: [http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/ http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/]
** Dracula Unleashed/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/ http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/]
** Jurassic Park/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/ http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/]

FILM is a multimedia container file format developed by Sega for use on its early CD-ROM home video game consoles. Based on analysis of a number of Sega CD and Saturn games, it appears that the format was first developed sometime during the era of the Sega CD, Sega's first CD-based video game console. There are many early variations of the FILM format observed on a number of Sega CD titles. Further, early FILM files have been observed on at least one 3DO game ([http://www.mobygames.com/game/3do/lemmings Lemmings]).

The Sega Saturn video game console, released in 1994, was also CD-ROM-based and apparently offered developers a standardized SDK for full motion video (FMV) playback using a modified variant of the well-known [[Cinepak]] video codec.

It is possible to store both audio and video in a FILM file. Alternatively, the format is able to handle either video without audio, or vice versa.

== Sega Saturn CPK File Format ==

All multi-byte numbers are stored in big endian format.

Many Sega Saturn CD-ROM games use this file format to store frames of a Cinepak-compressed video interleaved with uncompressed [[PCM]] audio. When this is the case, the files will typically have the extension .CPK (which is why FILM files are usually known as CPK files). Sometimes, audio-only FILM files will have a .SND extension.

The general format is laid out as follows:

+-----------------------+
| +-------------------+ |
| | FILM header | |
| | | |
| | +---------------+ | |
| | | FDSC chunk | | |
| | +---------------+ | |
| | | |
| | +---------------+ | |
| | | STAB chunk | | |
| | +---------------+ | |
| | | |
| +-------------------+ |
| |
| Audio or Video Data |
| .. |
| .. |
+-----------------------+

A FILM file will usually consist of a header followed by interleaved audio and video chunks. The FILM header has the following structure:

bytes 0-3 'FILM' signature
bytes 4-7 length of FILM header (including signature and length
fields)
bytes 8-11 FILM format version in ASCII (ex: '1.01' or '1.07')
bytes 12-15 unknown (may be reserved and set to 0)
bytes 16-n remainder of FILM header

Different Sega Saturn games include FILM files with a variety of FILM version numbers. Sometimes, the same game will include FILM files with a variety of format versions. A version number implies that there has been some change to the file format, but I have yet to observe any differences between different FILM file versions (except possibly for version '1.09'; see STAB chunk for more details).

The remainder of the FILM header contains a number of chunks describing the media data in the file. Usually, the number of chunks is 2: A FDSC chunk and a STAB chunk.

A FDSC chunk contains file description information. The chunk format is as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); an FDSC chunk should be 32 (0x20) bytes long
bytes 8-11 FOURCC of video codec (usually 'cvid' for Cinepak or null
for no video)
bytes 12-15 height of video frames
bytes 16-19 width of video frames
byte 20 unknown, but always seems to be 0x18 (24)
byte 21 number of audio channels
byte 22 audio sampling resolution in bits (either 8 or 16)
byte 23 unknown
bytes 24-25 audio sampling frequency in Hz
bytes 26-31 unknown (may be reserved and set to 0)

Note that the height field precedes the width field, which is unusual since width usually precedes height when expressing video resolution.

The fields pertaining to audio (channels, bits, and sample rate) will all be 0 if there is no audio present in the file.

A STAB chunk contains a table of media sample information. The chunk format is as follows:

bytes 0-3 'STAB' chunk signature
bytes 4-7 length of STAB chunk (including signature and length
fields)
bytes 8-11 framerate base frequency in Hz
bytes 12-15 number of entries in the sample table
bytes 16-n sample table

Note that the length field ought to take the first 16 chunk bytes into account. However, it has been observed from some games (notably [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers] using '1.09' version FILM files) that the length field sometimes does not account for these 16 bytes.

The sample table consists of a series of 16-byte sample records. Each record is laid out as follows:

bytes 0-3 offset of sample chunk from beginning of sample data
bytes 4-7 length of sample chunk
bytes 8-11 sample info 1
bytes 12-15 sample info 2

The offset is the offset from the start of the sample data, not the absolute offset in the file. The length of the FILM header implicitly serves as a pointer to the beginning of the sample data in the file.

If the sample info 1 field is set to all ones, the sample is an audio chunk. Otherwise, it is a video chunk. If it is a video chunk, the top bit of the 32-bit number specifies whether the chunk is an inter-coded or an intra-coded frame. 0=intra-coded (a.k.a. keyframe), 1=inter-coded. This is useful for seeking since it is a good idea to only jump to key frames when seeking through a file.

The rest of the first sample info field and the second sample info field pertain to framerate calculation. Refer to the section on FILM framerate calculation for more information on proper FILM playback using these sample info fields.

== FILM Framerate Calculation ==

The STAB chunk contains a framerate base frequency in bytes 8-11. This frequency is expressed in ticks/second (Hz). Every video chunk has a frame tick count. For example, movie files in Panzer Dragoon I & II (FILM format versions 1.04 and 1.07, respectively) have a base frequency of 600 Hz. The frames have tick counts of 0, 20, 40, 60, 80, etc. Thus, there are 20 ticks between each successive frame.

(600 ticks/sec) / (20 ticks/frame) = 30 frames/second

However, not all FILM files exhibit such a nice, even framerate. Myst, for example, contains FILM files (version 1.01) with a base frequency of 30 Hz. Some of the frames skip 2, then 3 ticks. Here's a sample tick count progression: 0, 2, 5, 7, 10, 12, 15, 17...

Each STAB record has 2 32-bit sample info fields. For an audio chunk, sample info 1 is all ones and sample info 2 is always 1. For a video chunk, sample info 1 contains the keyframe bit (as described in the STAB section) and the absolute timestamp in clock ticks of the video frame with respect to the file's base frequency clock. The sample info 2 field contains the number of clock ticks until the next frame is rendered. This type of information would be particularly useful in an interrupt-driven, real-time multimedia system like, for instance, a video game console (such as the Sega Saturn).

It is important to note that an application that knows how to play FILM files can not assume a constant framerate. The files will not play correctly with such a method. It is also important to note that
converting FILM files to file formats that only support constant framerates (such as AVI) is not a winning strategy. The converted file will not play correctly.

== FILM Deviant Cinepak (CVID) Video Data ==

The Cinepak data inside of a FILM file can not be decoded with a general purpose Cinepak decoding algorithm. It is reasonable to think that this was no accident. If FILM files contained standard CVID data, the files could be played on any computer that had some kind of Cinepak decoder implementation.

This document assumes familiarity with the [[Cinepak]] algorithm.

A CVID chunk is supposed to start with a 10-byte chunk header:

byte 0 flags
bytes 1-3 length of CVID data
bytes 4-5 width of coded frame
bytes 6-7 height of coded frame
bytes 8-9 number of coded strips

Following the chunk header ought to be the first byte of the first strip header. In the deviant CVID data stored in a FILM file, there appear to be an extra 2 bytes at the end of the chunk header, bringing the total header size to 12 bytes.

The length of the chunk as reported by the deviant CVID data chunk is also incorrect. The length field is supposed to report the length of the entire chunk including the header. The deviant CVID data reports a length that is 8 bytes too short. That is, the length reported in the CVID chunk is 8 bytes shorter than the length reported in the corresponding record of the FILM file's STAB chunk. The STAB chunk length takes into account the proper length, including the extra 2 bytes at the end of the chunk header.

Finally, the deviant CVID data appears to throw a potential decoder one more curveball with what appears to be data chunks that don't have, for lack of a better term, properly divisible chunk lengths. For example, a 0x2000 chunk commonly has a length of 0x604 bytes, which provides 2 bytes for the chunk ID, 2 bytes for the chunk length, and 0x600 bytes for 256 6-byte vectors. However, the deviant CVID data might have a 0x2000 chunk with a length of 0x600 bytes, which provides for the 4 chunk preamble bytes and 0x5FC bytes for the 6-byte vectors which is not evenly divisible by 6. This apparently confuses Cinepak decoders. The solution in this case is to unpack 255 6-byte vectors and then skip 2 bytes before attempting to decode the next chunk in the strip.

== FILM Audio Data ==

Audio data in a FILM file can be stored in a variety of formats which are mostly linear [[PCM]] variants.

CPK files from Sega Saturn games almost always contain linear PCM audio. The one known exception is Burning Rangers. This game apparently uses [[CRI ADX ADPCM]] audio coding.

Saturn CPK audio data is always stored as signed data. This is important to remember when playing 8-bit CPK audio data on a PC which generally expects 8-bit data to be unsigned.

When a CPK file contains 16-bit audio data, the individual PCM samples are stored in big endian format. Again, this is important to remember when playing on a PC since a PC will generally expect little endian
16-bit data.

If the CPK audio data is stereo (8- or 16-bit), the channel data is non-interleaved. Usually, stereo data is stored interleaved as a left channel sample followed by a right channel sample as follows:

L R L R L R L R ...

In a stereo CPK file, for each audio data chunk, the first half of the chunk contains left channel samples and the second half contains right channel samples. The likely reason for this scheme is that console audio hardware such as that found on the Sega Saturn usually features a number of audio channels which can each play a mono PCM stream at a particular pan position (e.g., from 0-15 where 0 is extreme left, 7 and 8 are center, and 15 is extreme right). In order to play a stereo PCM stream, one physical audio channel must be assigned to extreme left while a second channel is assigned to extreme right. Then the appropriate channel samples are sent to the correct channel. Since these files are optimized for playback on the Sega Saturn it makes sense to arrange the audio samples like this.

The Sega CD audio playback hardware ostensibly supports native sign/magnitude audio samples. All Sega CD games studied use this format to store audio data. Sign/magnitude number coding for 8-bit numbers
means that for each 8-bit byte:

bit 7 sign
bits 6-0 magnitude (value)

This is slightly different from twos complement encoding which is how computers typically store signed numbers. For example, in the sign/magnitude scheme, 0x81 represents -1 and 0xFF represents -127. 0x01
and 0x7F still represent 1 and 127, respectively, just as in unsigned, and signed twos complement coding.

== Early Sega CD FILM Files ==

Some Sega CD games as well as at least one 3DO game (Lemmings) use an early version of the FILM format. Unfortunately, there are a lot of variations and a general-purpose player will probably require a lot of
special-case logic in order to deal with every known circumstance.

The first difference in these early files is the version number. These early files do not have ASCII-readable version fields. Some have NULL or other non-ASCII versions. This helps automatic detection.

The second major difference that all of these early files appear to exhibit is an abbreviated FDSC chunk which omits any audio information. Thus, the FDSC chunk is laid out as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); this FDSC chunk is 20 (0x14) bytes long
bytes 8-11 FOURCC of video codec
bytes 12-15 height of video frames
bytes 16-19 width of video frames

The lack of audio information leaves room for experimentation. The following is a list of known games which have early FILM files along with any special quirks observed.

On the Lemmings 3DO game, there are 2 files with the .film extension (the 3DO game console uses a custom filesystem which allows for file extensions longer than 3 characters). The files have a NULL version field. The files use CVID data which is deviant in the same manner as typical FILM CVID data with an added quirk: There appear to be 6 extra bytes between the end of the CVID chunk header and the start of the first strip header, rather than the usual 2 extra bytes. The Lemmings FILM files also contain 8-bit signed, monaural PCM data with a sampling frequency of 22050 Hz.

The Batman and Robin Sega CD title has a series of files with the extension .s. They are early FILM files with a version field of 0x00020000. Further, bytes 12-15 of the main FILM header are not set to 0 as is usually seen in FILM files. The files have a video fourcc of 'Seg4' which is probably Cinepak for Sega or a variant thereof. The files have STAB chunks which are a constant 0x20 (32) bytes long. This consists of the 'STAB' signature, a 4-byte chunk length, the base playback frequency, a sample count, and one 16-byte sample record. These files do not store the sample table in one place. Instead, they store one sample record followed immediately by the data corresponding to that sample record. Repeat until the end of the file.

The Dracula Unleashed Sega CD title contains a series of files beginning with video?? with no file extension. They are early FILM files with a NULL version field, abbreviated FDSC chunk, and 'sega' as a video codec (Cinepak for Sega). The audio is 8-bit sign/magnitude audio with a sampling frequency of 16000 Hz.

Jurassic Park for the Sega CD has a large number of files with the file extension .MVD. They are early FILM files with the same characteristics as the FILM files in Dracula Unleashed.

The Tomcat Alley title for the Sega CD has a massive data file called tca.bin. Inside this data file are a lot of FILM files. These files have NULL version fields. The files have abbreviated FDSC chunks and the
'sega' video fourcc. They also have short STAB chunks with an Apple Quicktime 'mdia' atom appended at the end.

== Strategy For Detecting FILM File Types ==

There are quite a few variations and deviations in the FILM file format. This section presents logic for detecting and dealing with the variations.

File extension detection is not especially useful since many games will masquerade their files with another extension. The best method to determine whether a file is a FILM file is to read the first 4 bytes and check for the signature 'FILM'.

Upon validating the signature:

* read the file version in the FILM header
* if the file version consists of ASCII characters
** if the file version is '1.09', watch out for bad length of STAB chunk as well as ADPCM audio
** load as standard FILM file, be sure to feed CVID data through Cinepak decoder that can handle it
* if the file version is 0x00020000
** read the video fourcc
** if the video fourcc is 'Seg4'
*** assume the file comes from Batman and Robin
* if the file version is NULL
** read the video fourcc
** if the video fourcc is 'cvid'
*** assume the file comes from the Lemmings 3DO game
*** be prepared to decode special variant of modified CVID data
*** assume 8-bit, mono, 22050 Hz PCM audio
** if the video fourcc is 'sega'
*** assume the file comes from one of several Sega CD games that agreed on this format
*** assume 8-bit, mono, 16000 Hz sign/magnitude audio

== Games That Use FILM Files ==

These games are known to use some variation of FILM files. Observed file version numbers are noted where known.

* [http://www.mobygames.com/game/saturn/astal Astal (Sega Saturn)]: '0.91', '1.06'
* [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/clockwork-knight Clockwork Knight (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/criticom Criticom (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/d D (Sega Saturn)]
* [http://www.mobygames.com/game/sega-saturn/dark-seed-ii Dark Seed II (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/defcon-5 Defcon 5 (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/iron-storm_ Iron Storm (Sega Saturn)]
* [http://www.mobygames.com/game/3do/lemmings Lemmings (3DO)]: unversioned
* [http://www.mobygames.com/game/saturn/myst Myst (Sega Saturn)]: '1.01'
* [http://www.mobygames.com/game/saturn/nights-into-dreams Nights Into Dreams (Sega Saturn)]: '0.91', '1.01', '1.06', '1.07', '1.08'
* [http://www.mobygames.com/game/saturn/panzer-dragoon Panzer Dragoon (Sega Saturn)]: '1.04'
* [http://www.mobygames.com/game/saturn/panzer-dragoon-ii-zwei Panzer Dragoon II: Zwei (Sega Saturn)]: '1.07'
* [http://www.mobygames.com/game/sega-saturn/roberta-williams-phantasmagoria Phantasm (Sega Saturn)]: '1.06', '1.08', '1.09'
* Sega Saturn Bootleg Sampler (Sega Saturn): '1.04'
* [http://www.mobygames.com/game/saturn/shockwave-assault Shockwave Assault (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/skeleton-warriors Skeleton Warriors (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/space-jam Space Jam (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/street-fighter-the-movie Street Fighter: The Movie (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-squad-virtual-cop Virtua Cop (Sega Saturn)]: '1.08'
* World Series Baseball II (Sega Saturn)

[[Category:Container Formats]]
[[Category:Game Formats]]

Microsoft Audio/Video Interleaved

2010-02-05T05:06:07Z

Clone2727: typo

* Extensions: avi
* Company: [[Microsoft]]
* Technical Description From Microsoft: http://msdn.microsoft.com/en-us/library/ms779636(VS.85).aspx
* Another AVI format documentation: http://www.alexander-noe.com/video/documentation/avi.pdf
* John McGowan's AVI Overview: http://www.jmcgowan.com/avi.html
* MIME Types:
** video/msvideo
** video/x-msvideo

'''Microsoft Audio/Video Interleaved''' ('''AVI''') is a multimedia format based on the [[RIFF]] container format. For a long time, AVI was the de facto standard for multimedia files on Windows (recently, [[ASF]] has supplanted AVI on the Windows platform). While there is some contention
regarding the originator of the format, the fact remains that there were, and still are, a wide variety of computer applications that create AVI files. This leads to a lot of fragmentation and application-specific nuances in a standard that was never particularly well-defined in the first place.

== Structure ==

An AVI has this [[RIFF]] structure:

RIFF "AVI " (space at end)
LIST "hdrl"
DATA "avih", len: 56
LIST "strl"
DATA "strh", len: 56
DATA "strf"
''LIST "strl"''
...
''LIST: name: `INFO''' (optional)
...
LIST "movi"
DATA "00dc"
DATA "01wb"
...
DATA "idx1"

== Idiosyncracies ==
''This section comes from the document 'AVI Files: Tips & Quirks' by Arpad "A'rpi" Gereoffy found at http://multimedia.cx/avistuff.txt''

=== Introduction ===
A'rpi is the originator of the [[MPlayer]] media application for Linux. It's an open source movie player that can decode AVI files, as well as a number of other file formats. He has encountered a lot of AVIs created by a lot of different programs and is qualified to write about some of the quirks and nuances a programmer might encounter when writing a general purpose AVI file decoder.

=== Random Tips For Processing AVI File ===
In short, these are some things I discovered while writing/fixing my AVI demuxer:

* AVI files are built from variable length chunks.
* Each chunk has a 4-byte fourcc and a 4-byte length (dword).
* If the chunk size is bad/broken, it will kill the whole demuxer process.
* Chunks are padded to 2*n offset.

AVI files usually have:
* RIFF avi header, containing general parameters (used for file type detection)
* stream headers, containing common format stream descriptor, and type-specific audio/video/other header
* single 'movi' chunk contains the audio and video packets.
* index chunk contains index table (16 bytes for each chunk in 'movi')

The AVI header has a dwFlags field. It contains useful information, like type of interleaving, "have index" chunk and so on. Ignore it. Really. It's broken in too many files. Windows players ignore it too.

AVI docs say that 'XXdb' are uncompressed and 'XXdc' are compressed video chunk fourccs. (XX = stream id in HEX. Some specs says it's in DEC. Funny.) Ignore it. Just use the first 2 chars as a hex number, and get stream type from stream header for that stream id. I've seen even XXim FourCCs...

Stream header has some interesting fields:
* dwRate, dwScale: These specify the playback samplerate of the stream.
* dwStart: Specifies delay of the stream; rarely used, but must be supported.
* dwSampleSize: This is the sample size (bytes / sample). It may be 0, which means variable sample sizes -> 1 chunk == 1 sample. For non-zero samplesize, chunks may contain more than one sample.

Regarding VBR audio in AVI, see VirtualDub site mentioned in the references. The 3 AVI parsers in Windows behave differently with such streams. 1 normal (0=vbr), 1 tricky (rounds up zero to blockalign), 1 crashes.

In AVI, audio specific header contains WAVEFORMATEX and video spec. hdr contains BITMAPINFOHEADER. Both can have optional codec-dependent extra data appended after the struct. Don't crop it, it will break decoding!

About the movi chunk:
Recently I got some AVI files with bad movi chunk sizes. So, I have to say: Ignore it. Read chunks from the file while not EOF, and not while filepos < movi_end.

About index:
* It contains chunk pos, chunk size, chunk fourcc and flags. Bit 4 of the flags field (flags & 0x10) means that chunk represents a keyframe.
* Offset is relative to `cat /dev/urandom`. Really. Or dunno.
* I calculate an offset_of_offset value from the movi_start and first chunk offset. It works in 99% of cases. I saw different methods in other players, handling some common cases (such as relative to avi chunk, relative to movie chunk, etc.) and fallback to absolute value.
* Chunk info in chunk header (first 4+4 bytes of chunks) and index table should be equal. They aren't. Sometimes the size values differ by +/-1. Strange. Sometimes fourccs 'type' part (last 2 char) differ. Even more strange. Sometimes they leave chunk header. I think Windows parsers don't use chunk headers at all, and use only the index. This may be why they are unable to play files without index.

On the subject of interleaving, there are 3 categories of interleaving for AVI files (taken from DOCS/tech/formats.txt in the [[MPlayer]] distribution):
# Interleaved: Audio and video content is interleaved. It's faster and requires only 1 reading thread, so it's recommended (and most commonly used).
# Non-interleaved: Audio and video aren't interleaved. The file stores all of the video data followed by all the audio data. Such a file requires 2 reading processes or 1 reading with lots of seeking. This is very bad when playing the data from a network or CD-ROM.
# Badly-interleaved streams: Some AVI files claim to be interleaved but with bad sync. These files should be treated as non-interleaved.

About A/V sync, you should rely on samplerate (dwRate/dwScale), samplesize and stream positions. Use an integer, not a floating-point number, for byte positions. When calculating time for each frame:
time = ((dwSampleSize ? (bytepos / dwSampleSize) : chunkpos) * dwRate / dwScale
floats will gradually drift into error.

== Quirks ==
* Some AVI files are seen in the wild with the signature 'AVI\x19'. There is a 0x19 number in the fourth byte rather than a 0x20.

[[Category:Container Formats]]

Mirrored Files

2010-01-23T15:09:15Z

Clone2727: update QTFF link

This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/

Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.

* [[A52]]:
** mirror: http://multimedia.cx/mirror/a_52b.pdf
** original: http://www.atsc.org/standards/a_52b.pdf

* [[Apple Core Audio Format]] specification, dated 2006-03-08:
** mirror: http://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html

* Apple [[QuickTime container]] specification, dated 2007-09-04:
** mirror: http://multimedia.cx/mirror/qtff-2007-09-04.pdf
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF

* [[Audio Interchange File Format]]:
** mirror: http://multimedia.cx/mirror/AudioIFF1_2_1.htm

* [[Cinepak]]:
** mirror: http://multimedia.cx/mirror/cinepak.txt
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt

* [[CYUV]]:
** mirror: http://multimedia.cx/mirror/cyuv.txt
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt

* [[Dialogic IMA ADPCM]]:
** mirror: http://multimedia.cx/mirror/dialogic-adpcm.pdf

* [[DTS]]:
** mirror (whitepaper): http://multimedia.cx/mirror/dts-whitepaper.pdf
** mirror (document 1): http://multimedia.cx/mirror/dts1.pdf
** mirror (document 2): http://multimedia.cx/mirror/dts2.pdf
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): http://multimedia.cx/mirror/EP864146-53.pdf
** mirror (DCA transform): http://multimedia.cx/mirror/dca-transform.pdf

* [[H264]] draft specification, marked 2002 (E):
** mirror: http://multimedia.cx/mirror/JVT-G050.pdf

* [[IBM UltiMotion]] specification:
** mirror: http://multimedia.cx/mirror/UMSPEC.ZIP

* Id [[CIN]]:
** mirror: http://multimedia.cx/mirror/idcin.html
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html

* Id [[RoQ]]:
** mirror: http://multimedia.cx/mirror/idroq.txt
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt

* [[Indeo 3]]:
** mirror (partial specification): http://multimedia.cx/mirror/5386232.pdf
** mirror (header explanation): http://multimedia.cx/mirror/indeo3.txt
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt

* [[Meridian Lossless Packing]] whitepaper:
** mirror: http://multimedia.cx/mirror/mlp_jap_new.PDF
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF

* [[Nokia MVC]]:
** documentation:
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc
*** mirror: http://multimedia.cx/mirror/q15j19.doc
** reference codec:
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip
*** mirror: http://multimedia.cx/mirror/q15j20.zip

* [[On2 VP6]] whitepaper:
** mirror: http://multimedia.cx/mirror/vp6-white-paper.pdf
** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf

* [[On2 VP7]] whitepaper:
** mirror: http://multimedia.cx/mirror/vp7-white-paper.pdf
** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf

* [[PVA]] specification:
** mirror: http://multimedia.cx/mirror/av_format_v1.pdf

* [[RealAudio 14.4]]:
** mirror: http://multimedia.cx/mirror/spra136.pdf
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf

* [[VC-1]] (a.k.a. VC-9) draft specification:
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/s421m.pdf
** mirror: draft dated 2004-03-31: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf
** reference source code mirror: http://multimedia.cx/mirror/VC1_reference_decoder_release6.zip

QuickTime container

2010-01-23T15:08:37Z

Clone2727: update QTFF link

* Extensions: mov, qt, mp4, m4v, m4a, m4p, m4b, m4r, k3g, skm, 3gp, 3g2
* Company: [[Apple]]
* Official specification: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/index.html ([[Mirrored Files|mirrored PDF]])
** ISO base media file format: [http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip ISO/IEC 14496-12:2008]+[http://standards.iso.org/ittf/PubliclyAvailableStandards/c052970_ISO_IEC_14496-12_2008_Cor_1_2008.zip Cor.1]+[http://standards.iso.org/ittf/PubliclyAvailableStandards/c052971_ISO_IEC_14496-12_2008_Cor_2_2009.zip Cor.2]
* MIME Types:
** mov, qt: video/quicktime or video/x-quicktime
** m4a, m4b: audio/x-m4a

== Known FOURCCs ==

The following sections list FOURCCs known to appear in Apple QuickTime files. Note that sometimes the FOURCC is only 3 characters and there is a space (ASCII 0x20) to round out the full 4 characters.

=== Video FOURCCs ===

* [[Raw RGB|'raw ']]
* [[Apple QuickTime RLE|'rle ']]
* [[Apple SMC|'smc ']]
* [[Apple RPZA|'rpza']]
* [[8BPS|'8bps']]
* [[QDraw|'qdrw']]
* [[Cinepak|'cvid']]
* [[Sorenson Video 1|'svq1']]
* [[Sorenson Video 3|'svq3']]
* [[ISO MPEG-4|'DIVX']]
* [[H.263|'h263']]
* [[ISO MPEG-4|'mp4v']]
* [[mx5p|'mx5p']]: MPEG2 IMX 635/50 50mb/s produced by [[Final Cut Pro]]
* [[mx3n|'mx3n']]: MPEG2 IMX 635/50 30mb/s produced by [[Final Cut Pro]]
* [[dvpp|'dvpp']]: DVCPRO PAL produced by [[Final Cut Pro]]
* [[dv5p|'dv5p']]: DVCPRO50 produced by [[Final Cut Pro]]
* [[hdv3|'hdv3']]: HDV produced by [[Final Cut Pro]]

*8BPS "Apple Planar RGB"
*SVQ1 "Sorenson Video¬ Compressor"
*SVQ3 "Sorenson Video 3 Compressor"
*WRLE "Apple BMP"
*avc1 "H.264 Encoder"
*cvid "Apple Cinepak"
*dv5n "Apple DVCPRO50 - NTSC"
*dv5p "Apple DVCPRO50 - PAL"
*dvc "Apple DV/DVCPRO - NTSC"
*dvcp "Apple DV - PAL"
*dvpp "Apple DVCPRO - PAL"
*h261 "Apple H.261"
*h263 "H.263"
*h263 "Apple VC H.263"
*[[Apple_Intermediate_Codec|icod]] "Apple Intermediate Codec"
*jpeg "Apple Photo - JPEG"
*mjp2 "JPEG 2000 Encoder"
*mjpa "Apple Motion JPEG A"
*mjpb "Apple Motion JPEG B"
*mp4v "Apple MPEG4 Compressor"
*png "Apple PNG"
*pxlt "Apple Pixlet Video"
*raw "Apple None"
*rle "Apple Animation"
*rpza "Apple Video"
*smc "Apple Graphics"
*tga "Apple TGA"
*tiff "Apple TIFF"
*yuv2 "Apple Component Video - YUV422"
*.... "DivX 4 Decoder"
*.SGI "Apple SGI"
*2vuy "Apple YUV422 Codec (2vuy)"
*2vuy "YUV 4:2:2 Hardware Acceleration Codec (yuvs)"
*3IV2 "3ivx Decoder"
*3IVD "3ivx Decoder"
*3iv2 "3ivx Decoder"
*3ivd "3ivx Decoder"
*8BPS "Apple Planar RGB"
*AP41 "DivX 3 Decoder"
*BLZ0 "XVID Decoder"
*COL0 "DivX 3 Decoder"
*COL1 "DivX 3 Decoder"
*DAVC "H264 Decoder"
*DIV1 "MS-MPEG4 v1 Decoder"
*DIV2 "MS-MPEG4 v2 Decoder"
*DIV3 "DivX 3 Decoder"
*DIV4 "DivX 3 Decoder"
*DIV5 "DivX 3 Decoder"
*DIV6 "DivX 3 Decoder"
*DIVX "DivX 4 Decoder"
*DX50 "DivX 5 Decoder"
*FLV1 "Sorenson H.263 Decoder"
*FMP4 "MPEG-4 Decoder"
*FSV1 "Flash Screen Video Decoder"
*H264 "H264 Decoder"
*M4S2 "DivX 4 Decoder"
*M4s2 "WMV Image Codec"
*MP42 "MS-MPEG4 v2 Decoder"
*MP43 "DivX 3 Decoder"
*MP4S "DivX 4 Decoder"
*MPG3 "DivX 3 Decoder"
*MPG4 "MS-MPEG4 v1 Decoder"
*Mjpg "VCM Image Codec"
*Mp42 "WMV Image Codec"
*Mp43 "WMV Image Codec"
*Mp4S "WMV Image Codec"
*PNTG "Apple MacPaint"
*RMP4 "MPEG-4 Decoder"
*SEDG "MPEG-4 Decoder"
*SMP4 "MPEG-4 Decoder"
*SVQ1 "Sorenson Video¬ Decompressor"
*SVQ3 "Sorenson Video 3 Decompressor"
*UMP4 "DivX 4 Decoder"
*VP62 "TrueMotion VP6 Decoder"
*VP6F "TrueMotion VP6 Decoder"
*VSSH "H264 Decoder"
*WMV1 "WMV Image Codec"
*WMV2 "WMV Image Codec"
*WMV3 "WMV Image Codec"
*WRLE "Apple BMP"
*WV1F "MPEG-4 Decoder"
*X264 "H264 Decoder"
*XVID "XVID Decoder"
*XVIX "XVID Decoder"
*XviD "XVID Decoder"
*ac16 "YUV 4:2:2 Hardware Acceleration Codec (yuvs)"
*ac32 "YUV 4:2:2 Hardware Acceleration Codec (yuvs)"
*acBG "YUV 4:2:2 Hardware Acceleration Codec (yuvs)"
*avc1 "H.264 Decoder"
*avr "Apple AVR JPEG"
*b16g "Apple 16-bit Gray"
*b32a "Apple 32-bit Gray with Alpha"
*b48r "Apple 48-bit RGB"
*b64a "Apple 64-bit ARGB"
*base "Apple 64-bit ARGB"
*blit "Apple 64-bit ARGB"
*blnd "Alpha Compositor"
*blur "Blur"
*brco "Brightness and Contrast"
*chan "Channel Compositor"
*ckey "Chroma Key"
*clou "Cloud"
*cmyk "Apple CMYK"
*col0 "DivX 3 Decoder"
*col1 "DivX 3 Decoder"
*cupa "QTVR Cubic Codec"
*cvid "Apple Cinepak"
*div1 "MS-MPEG4 v1 Decoder"
*div2 "MS-MPEG4 v2 Decoder"
*div3 "DivX 3 Decoder"
*div4 "DivX 3 Decoder"
*div5 "DivX 3 Decoder"
*div6 "DivX 3 Decoder"
*divx "DivX 4 Decoder"
*dmb1 "Apple OpenDML JPEG"
*drmi "AVC0 Media"
*dslv "Cross Fade"
*dv5n "Apple DVCPRO50"
*dv5n "DVCPRO50"
*dv5p "Apple DVCPRO50"
*dv5p "DVCPRO50"
*dvc "Apple DV"
*dvcp "Apple DV"
*dvpp "Apple DVCPRO"
*edge "Edge Detection"
*embs "Emboss"
*fire "Fire"
*flic "Apple FLC"
*fmns "Film Noise"
*fpix "FlashPix Image"
*gain "Alpha Gain"
*geff "Special Effects and Filters"
*genk "General Convolution"
*gif "Apple GIF"
*glas "Glass"
*h261 "Apple H.261"
*h263 "H.263"
*h263 "Apple VC H.263"
*h264 "H264 Decoder"
*hslb "HSL Balance"
*j420 "Apple YUV420 Codec"
*jpeg "Apple Photo - JPEG"
*kpcd "Apple Photo CD"
*lens "Lens Flare"
*ltpa "QTVR Cylindrical Codec"
*m4s2 "DivX 4 Decoder"
*matt "Gradient Wipe"
*mjp2 "JPEG 2000 Decoder"
*mjpa "Apple Motion JPEG A"
*mjpb "Apple Motion JPEG B"
*mp42 "MS-MPEG4 v2 Decoder"
*mp43 "DivX 3 Decoder"
*mp4s "DivX 4 Decoder"
*mp4v "Apple MPEG4 Decompressor"
*mpg3 "DivX 3 Decoder"
*mpg4 "MS-MPEG4 v1 Decoder"
*mplo "Implode"
*msvc "Apple - Microsoft Video 1"
*myuv "Apple YUV420 Codec"
*path "Apple Curve"
*pdf "PDF Image"
*png "Apple PNG"
*push "Push"
*pxlt "Apple Pixlet Video"
*qdrw "Apple QuickDraw"
*r408 "Apple r408"
*raw "Apple None"
*raw "DV"
*raw "Apple RGB to YUV"
*rgbb "RGB Balance"
*ripl "Ripple"
*rle "Apple Animation"
*rpza "Apple Video"
*scal "Apple Scaling Codec"
*shrp "Sharpen"
*slid "Slide"
*smc "Apple Graphics"
*smp2 "Iris"
*smp3 "Radial"
*smp4 "Matrix Wipe"
*smpt "Wipe"
*solr "Color Style"
*sync "ColorSync"
*syv9 "Apple Sorenson YUV9 Codec"
*text "Apple Text ATSUI Codec"
*tga "Apple TGA"
*tiff "Apple TIFF"
*tint "Color Tint"
*trav "Traveling Matte"
*v408 "Apple v408"
*x264 "H264 Decoder"
*xplo "Explode"
*xvid "XVID Decoder"
*y420 "Apple YUV420 Codec"
*yuv2 "Apple Component Video - YUV422"
*yuvs "Apple YUV422 Codec (yuvs)"
*yuvs "YUV 4:2:2 Hardware Acceleration Codec (yuvs)"
*yuvu "Apple YUV422 Codec (yuvu)"
*yuvx "Apple YUV422 Codec"
*zoom "Zoom"

<pre>
imdc:2Vuy:Ajav "AJA Kona 2Vuy Codec"
imdc:2vuy:AjaV "AJA Kona 2vuy VideoOut Codec"
imdc:2Vuy:AjaV "AJA Kona 2Vuy VideoOut Codec"
imdc:2vuy:appl "Digital Cinema Desktop Transfer Codec"
imdc:2vuy:AVSI "Aurora 8bit eXtreme? UC"
imdc:2Vuy:AVSS "Aurora 8bit Advanced UC"
imdc:2VUY:AVSS "Aurora 8bit UC Legacy"
imdc:2Vuy:BMAG "Blackmagic 2Vuy 8 Bit"
imdc:2vuy:BMAG "Blackmagic 8 Bit"
imdc:2vuy:DV64 "Digital Voodoo SD? 8 Bit"
imdc:2vuy:KeyG "Apple FCP Uncompressed 8-bit 4:2:2"
imdc:BGGR:ASC "ASC Bayer Decompressor"
imdc:C310:GL3N "10-bit Cineon Decompressor"
imdc:cini:bsmt "Cineon Codec"
imdc:D210:GL3N "DPX 10-bit Y'CbCr 4:2:2 Decompressor"
imdc:DV10:AVSS "Aurora DV 10 Bit UC"
imdc:DV10:BMAG "Blackmagic DV10 10 Bit"
imdc:DV10:DV64 "Digital Voodoo SD 10 Bit"
imdc:DV10:DVOO "Digital Voodoo SD 10 Bit"
imdc:DVOO:AVSS "Aurora DV 8 Bit UC"
imdc:DVOO:BMAG "Blackmagic DVOO 8 Bit"
imdc:DVOO:DV64 "Digital Voodoo SD? 8 Bit"
imdc:DVOO:DVOO "Digital Voodoo SD? 8 Bit"
imdc:dx45:DARC "DivX 6.0"
imdc:DX45:DARC "DivX 6.0"
imdc:Mczm:Thry "Microcosm Codec"
imdc:MIFF:Maya "Maya IFF Image Codec"
imdc:NO16:Thry "None16 Codec"
imdc:pRiz:appl "LiveType Codec Decompressor"
imdc:R10g:Ajav "AJA Kona 10-bit Log RGB Codec"
imdc:R10k:Ajav "AJA Kona 10-bit RGB Codec"
imdc:r408:AVSI "Aurora r408 Transfer Decompressor"
imdc:Shr0:BtJz "Sheer"
imdc:Shr1:BtJz "Sheer RGB[A] 8b"
imdc:Shr2:BtJz "Sheer Y'CbCr[A] 8bv 4:4:4[:4]"
imdc:Shr3:BtJz "Sheer Y'CbCr[A] 8bv 4:2:2[:4]"
imdc:Shr4:BtJz "Sheer Y'CbCr 8bw 4:2:2"
imdc:Shr5:BtJz "Sheer Y'CbCr[A] 10bv 4:4:4[:4]"
imdc:Shr6:BtJz "Sheer Y'CbCr[A] 10bv 4:2:2[:4]"
imdc:Shr7:BtJz "Sheer RGB[A] 10b"
imdc:v408:AVSI "Aurora v408 Transfer Decompressor"
</pre>

=== Audio FOURCCs ===

* [[PCM|'raw ']]
* [[PCM|'twos']]
* [[PCM|'sowt']]
* [[Apple MACE|'mac3']]
* [[Apple MACE|'mac6']]
* [[Apple QuickTime IMA ADPCM|'ima4']]
* [[PCM#Logarithmic PCM|'ulaw']]
* [[PCM#Logarithmic PCM|'alaw']]
* [[MP3|'.mp3']]
* [[Vorbis|'OggS']]
* [[QDesign Music Codec|'QDMC']]
* [[QDesign Music Codec|'QDM2']]
* [[MPEG-4 Audio|'mp4a']]
* [[MPEG-4 Audio|'drms']]
* [[PCM|'in24']]
* [[PCM|'in32']]
* [[PCM|'fl32']]
* [[PCM|'fl64']]
* [[Qualcomm Voice Codec|'Qclp']]
* [[GSM 06.10|'agsm']]

*MAC3:appl "MACE 3:1"
*MAC6:appl "MACE 6:1"
*QDM2:QDes "QDesign Music 2"
*Qclp:QCOM "Qualcomm PureVoice¬"
*alac:appl "Apple Lossless"
*alaw:appl "ALaw 2:1"
*fl32:appl "32-bit Floating Point"
*fl64:appl "64-bit Floating Point"
*ima4:appl "IMA 4:1"
*in24:appl "24-bit Integer"
*in32:appl "32-bit Integer"
*mp4a:appl "MPEG-4 Audio"
*samr:appl "AMR Narrowband"
*sowt:appl "16-bit Little Endian"
*twos:appl "16-bit Big Endian"
*ulaw:appl "uLaw 2:1"
*.mp3:FhG "MPEG Layer-3 Audio"
*MAC3:appl "MACE 3:1"
*MAC6:appl "MACE 6:1"
*QDM2:QDes "QDesign Music 2"
*QDMC:QDes "QDesign Music 1 Decoder"
*Qclp:QCOM "Qualcomm PureVoice¬"
*Qclq:QCOM "Qualcomm [[QCELP]]"
*TS..:TELE "Microsoft ADPCM"
*TS..:TELE "Microsoft G.711 aLaw"
*TS..:TELE "Microsoft G.711 uLaw"
*TS..:TELE "Microsoft IMA ADPCM"
*TS.E:TELE "Microsoft G.726"
*TS.U:TELE "Microsoft MPEG Layer-3"
*WMA1:TELE "Windows Media Audio 7"
*WMA2:TELE "Windows Media Audio 9 Standard"
*WMA3:TELE "Windows Media Audio 9 Professional"
*agsm:appl "Apple GSM 10:1"
*alac:appl "Apple Lossless"
*alaw:appl "ALaw 2:1"
*drms:appl "DRM"
*dvca:appl "DV"
*dvi :appl "DVI 4:1"
*fl32:appl "32-bit Floating Point"
*fl64:appl "64-bit Floating Point"
*ima4:appl "IMA 4:1"
*in24:appl "24-bit Integer"
*in32:appl "32-bit Integer"
*lpc :appl "LPC 23:1"
*mp4a:appl "MPEG-4 Audio"
*ms..:appl "MS ADPCM"
*ms..:appl "DVI IMA"
*ms.1:appl "MS-GSM 6.10"
*ms.U:FhG "MPEG Layer-3 Audio"
*samr:appl "AMR Narrowband"
*sowt:appl "16-bit Little Endian"
*twos:appl "16-bit Big Endian"
*ulaw:appl "?Law 2:1"
*vdva:appl "DV"

=== Microsoft ID FOURCCs ===

These FOURCCs indicate that the audio information stsd atom also transports a Microsoft-style [[WAVEFORMATEX]] header.

* 'm', 's', 0x00, 0x02: [[Microsoft ADPCM]]
* 'm', 's', 0x00, 0x11: [[Microsoft IMA ADPCM]]
* 'm', 's', 0x00, 0x55: [[MP3]]

== Technical Description ==

The Apple Quicktime file format is an extremely well-defined file format. A little too well-defined, in fact. Some would even call it "over-engineered". The official Quicktime documentation is a magnificently
detailed beast that gives equal time to explaining all parts of the spec, no matter how important or ignored a particular component may be in the actual implementation. The official spec can be a lot to digest at once and this document is intended to help interested programmers come up to
speed on the Quicktime internals much more quickly.

This document emphasizes the components of the Quicktime file format that a programmer would need to know in order to write a general purpose Quicktime file decoder. This document also contains a discussion of
decoding strategies.

Note that this document will probably never be complete since there is so much flexibility in the Quicktime format. But it is designed to cover the majority of QT files ever produced.

=== Byte Ordering ===

The first important fact to know about Quicktime files when writing a decoder is that all multi-byte numbers are big endian owing to Apple's Motorola heritage.

=== Atoms: The Fundamental Quicktime Building Blocks ===

Apple's Quicktime designers were thinking differently when they came up with the notion of an "atom" as "something that can contain other atoms". Atoms are chunks of data in that comprise a Quicktime
file. Sometimes they contain data and sometimes they contain other atoms.

An atom consists of a size, a type, and a data payload. An atom is laid out as follows:

bytes 0-3 atom size (including 8-byte size and type preamble)
bytes 4-7 atom type
bytes 8..n data

The 4 bytes allotted for the atom size field limit the maximum size of an atom to 4 GB. Quicktime also has a provision to allow atoms with 64-bit atom size fields by setting the size field 1 and adding the 8-byte size field after the atom type:

bytes 0-3 always 0x00000001
bytes 4-7 atom type
bytes 8-15 atom size (including 16-byte size and type preamble)
bytes 16..n data

This is a logical exception since an atom always needs to be at least 8 bytes in length to account for the preamble. Therefore, if the size field is 1, load the 64-bit atom size from just after the atom type field.

=== Known Top-Level Atoms ===

These are all of the QuickTime atoms that are known to be legal top-level atoms.

* 'moov'
* 'mdat'
* 'free'
* 'junk'
* 'pnot'
* 'skip'
* 'wide'
* 'pict'
* 'ftyp'
* 'uuid' : Used by Sony's MSNV brand of MP4

=== QuickTime File Types ===

Somewhere along the line the 'ftyp' atom was added as a possible top-level QuickTime atom. It is supposed to appear first in a QuickTime file. There are the known ftyp values:

* 'qt '
* 'isom'
* 'mp41'
* 'mp42'
* '3gp1'
* '3gp2'
* '3gp3'
* '3gp4'
* '3gp5'
* '3g2a'
* 'mmp4' : Mobile MPEG-4
* 'M4A '
* 'M4P '
* 'M4V '
* 'mjp2' : Motion JPEG 2000
* 'MSNV' : Sonys private brand; Used for example to encode MP4s for the PSP

A more authoritative list can be found at http://ftyps.com/ .

=== General File Organization ===

In the abstract atom hierarchy, this is how a Quicktime file is laid out:

moov
mvhd
trak
tkhd
edts
elst
mdia
mdhd
minf
stbl
stsd
stco
co64
stts
stss
stsc
stsz
trak
trak
..
mdat
[data]
[data]
[...]

Note that this is not an exhaustive tree of all possible or known atoms; these are only the atoms that have been empirically determined as "interesting" for the purposes of writing a general-purpose decoder that can handle most Quicktime files.

All Quicktime files need to have a moov atom and a mdat atom at the top level. There are other top level atoms as well (e.g. the 'ftyp' atom), which generally are not interesting and can safely be skipped if encountered. The moov atom contains instructions for playing the data in the file. The mdat atom contains the data that will be played.

=== Meta Data ===

A 'meta' atom contains atoms containing human-readable textual data with meta information regarding the file. These atoms are marked with 4 bytes of course but the first byte is a value of 0xA9. The remaining 3 characters can be:

* nam: Name of song or video
* cpy: Copyright information
* des: File description
* cmt: General comment
* alb: Album name
* gen: Custom Genre
* ART: Artist name
* too: Encoder
* wrt: Writer
* day: Content created year

=== Decompressing Compressed moov Atoms With zlib ===

The prospect of having to decode compressed moov atoms in Quicktime files seems to give many programmers pause. This need not be the case. When a compressed moov atom is detected, the free, open source [[zlib]] compression library can be called upon to do all the hard work.

In the abstract atom hierarchy, a compressed moov atom is laid out like this:

moov
cmov
dcom
cmvd

On disk, a compressed moov atom will look this this:

bytes 0-3: atom size (including 8-byte size and type preamble)
bytes 4-7: atom type ('moov', movie header)
bytes 8-11: atom size (including 8-byte size and type preamble)
bytes 12-15: atom type ('cmov', compressed movie header)
bytes 16-19: atom size (this should be 12 bytes)
bytes 20-23: atom type ('dcom', decompressor)
bytes 24-27: decompression library used (usually 'zlib')
bytes 28-31: atom size (including 8-byte size and type preamble)
bytes 32-35: atom type ('cmvd', compressed movie header data)
bytes 36-39: size of decompressed data
bytes 40-n: compressed data

Note that this structure makes it theoretically possible to use other libraries to compress moov atoms, but zlib is most commonly used.

Here is a lazy algorithm for decompressing a compressed moov atom:

# check if bytes 12-15 contain 'cmov'; if yes:
# allocate a buffer for the decompressed moov atom, the size of which is specified by bytes 36-39
# initialize the zlib library, initialize a z_stream structure with pointers to the compressed and decompressed buffers, and all the other necessary variables
# call zlib to decompress the atom
# free the compressed moov atom, process the newly-decompressed moov atom (which will begin with a proper size and 'moov' type)

As an aside, one might wonder about the rationale behind compressing moov atoms. The data inside QT files can reach gargantuan sizes, and the moov atom will be rather tiny in comparison. Why bother saving a few tens of kilobytes on the moov atom? One suggestion I have received is data integrity: Compression with zlib offers CRC validation. If an error occurs in the data stream while transmitting the compressed moov atom, a problem will be detected during decompression.

== Audio Handling ==

=== Constant Bitrate Audio ===

=== Constant Bitrate Audio Width Header ===

=== Variable Bitrate Audio ===

== Palette Handling ==

== QuickTime Atom Reference ==

=== cmov ===
{{QT_Atom|atomName=cmov|function=compressed moov atom|containedIn={{QT|moov}}|canContain={{QT|cmvd}}, {{QT|dcom}}}}

=== cmvd ===
{{QT_Atom|atomName=cmvd|function=compressed moov atom data|containedIn={{QT|cmov}}|canContain=''leaf atom''}}

=== co64 ===
{{QT_Atom|atomName=co64|function=64-bit chunk offsets|containedIn={{QT|stbl}}|canContain=''leaf atom''}}
The co64 atom for a track lists the offsets for the various chunks that comprise a media track. These offsets are absolute offsets within the file starting from offset 0. Note that this atom allows for 64-bit offsets which is necessary for QuickTime files exceeding 4 gigabytes. Smaller files can save space in this table by using the {{QT|stco}} atom which only allows for 32-bit offsets.

''QT Atom Preamble''
1 byte version
3 bytes flags
4 bytes total entries in offset table (n)
8 bytes chunk offset 0
8 bytes chunk offset 1
..
..
8 bytes chunk offset n-1

=== ctts ===
{{QT_Atom|atomName=ctts|containedIn={{QT|stbl}}}}

=== dcom ===
{{QT_Atom|atomName=dcom|function=compressed moov compression method|containedIn={{QT|cmov}}|canContain=''leaf atom''}}

=== edts ===
{{QT_Atom|atomName=edts|function=edit samples|containedIn={{QT|trak}}|canContain={{QT|elst}}}}

=== elst ===
{{QT_Atom|atomName=elst|function=edit list|containedIn={{QT|edts}}|canContain=''leaf atom''}}
The elst atom contains the edit list. The edit list contains information about the times and durations that pieces of a media track are to be presented during playback. There are many Quicktime file decoders that choose to ignore this atom. This is not a good idea. The edit list atom must be taken into account to guarantee proper A/V sync on certain files.

An edit list atom has the following structure:

''QuickTime Atom Preamble''
1 byte version
3 bytes flags
4 bytes number of edit list entries
<edit list entries>

An individual edit list entry is 12 bytes in size and has the following structure:

bytes 0-3 edit duration (in global timescale units)
bytes 4-7 edit media time (in trak timescale units)
bytes 8-11 playback speed

=== esds ===
{{QT_Atom|atomName=esds|function=Elementary Stream Descriptors|containedIn=''tbd''|canContain=''tbd''}}

=== free ===
{{QT_Atom|atomName=free|function=free space|containedIn=''top level''|canContain=''tbd''}}

=== ftyp ===
{{QT_Atom|atomName=ftyp|function=file type|containedIn=''top level''|canContain=''tbd''}}

=== gmhd ===
{{QT_Atom|atomName=gmhd|function=generic media header|containedIn={{QT|minf}}|canContain=''leaf atom''}}

=== iods ===
{{QT_Atom|atomName=iods}}

=== junk ===
{{QT_Atom|atomName=junk|function=junk space|containedIn=''top level''|canContain=''tbd''}}

=== mdat ===
{{QT_Atom|atomName=mdat|function=media data|containedIn=''top level''|canContain=''media data''}}

=== mdhd ===
{{QT_Atom|atomName=mdhd|function=media header|containedIn={{QT|mdia}}|canContain=''leaf atom''}}

The mdhd atom is the media header atom, containing some parameters for the current stream. There are at least two versions available of the mdhd atom (which can be found in the first byte after the preamble).

An mdhd version 0 atom has the following structure:

''QuickTime Atom Preamble''
1 byte version
3 bytes flags
4 bytes creation time
4 bytes modification time
4 bytes time scale
4 bytes duration
2 bytes language
2 bytes quality

For version 1 instead a few entries have changed sizes from 4 to 8 bytes:

''QuickTime Atom Preamble''
1 byte version
3 bytes flags
8 bytes creation time
8 bytes modification time
4 bytes time scale
8 bytes duration
2 bytes language
2 bytes quality

The language value is a three letters ISO 639 language code represented with three 5-bit values (each of which is the ASCII value of the letter minus 0x60).

=== mdia ===
{{QT_Atom|atomName=mdia|function=media|containedIn={{QT|trak}}|canContain={{QT|mdhd}}, {{QT|minf}}}}

=== minf ===
{{QT_Atom|atomName=minf|function=media information|containedIn={{QT|mdia}}|canContain={{QT|gmhd}}, {{QT|smhd}}, {{QT|stbl}}, {{QT|vmhd}}}}

=== moov ===
{{QT_Atom|atomName=moov|function=movie header|containedIn=''top level''|canContain={{QT|mvhd}}}}

=== mvhd ===
{{QT_Atom|atomName=mvhd|function=movie header|containedIn={{QT|moov}}|canContain=''tbd''}}

=== pict ===
{{QT_Atom|atomName=pict|containedIn=''top level''|canContain=''tbd''}}

=== pnot ===
{{QT_Atom|atomName=pnot|containedIn=''top level''|canContain=''tbd''}}

=== rdrf ===
{{QT_Atom|atomName=rdrf|function=data reference|containedIn={{QT|rmda}}|canContain=none allowed}}
This atom defines where the reference movie can be found. The location can be given as an alias or as a URL.

Only one allowed data reference atom per movie reference descriptor atom.

=== rmcd ===
{{QT_Atom|atomName=rmcd|function=component detect|containedIn={{QT|rmda}}|canContain=none allowed}}
This atom specifies required Quicktime components, such as codecs, needed and can also specify the minimum version of the component.

Multiple component detect atoms are allowed in a reference movie descriptor atom and all minimum versions of all the components must be met.

=== rmcs ===
{{QT_Atom|atomName=rmcs|function=CPU speed atom|containedIn={{QT|rmda}}|canContain=none allowed}}

This atom describes the minimum amount of computer power required to play this reference movie. The computer power is given as a relative number on an unknown, from the documentation, scale. Examples from Apple's documentation include 100 being equivalent to a 166MHz Pentium and 500 for a 400MHz G4 PowerPC. The Apple documentation estimates that a gigahertz computer with a graphics accelerator might give a power number as high as 1000 and that future computers will allow even higher numbers. It seems that maybe this number isn't very useful since there doesn't seem to be anything to help determine what kind of computing power multi-gigahertz machines, that provide more computing power per Hz than previous generations did provides on this ill-defined scale.

If the CPU speed atom is given then a computer that does not meet the specifications will play the reference movie with the next lower power requirement that it meets.

An application should assume that the reference movie with the highest valued CPU speed will have the highest quality.

Only one allowed CPU speed atom per movie reference descriptor atom.

=== rmda ===
{{QT_Atom|atomName=rmda|function=reference movie descriptor atom|containedIn={{QT|rmra}}|canContain={{QT|rdrf}}, {{QT|rmdr}}, {{QT|rmcs}}, {{QT|rmvc}}, {{QT|rmcd}}, {{QT|rmqu}}}}

The reference movie descriptor contains atoms that describe where to find an alternate movie. It also may contain atoms for items such as system requirements and movie quality.

Multiple reference movie descriptors are usually found in a reference movie atom.

=== rmdr ===
{{QT_Atom|atomName=rmdr|function=minimum data rate|containedIn={{QT|rmda}}|canContain=none allowed}}
The data rate atom indicates the minimum connection speed needed to display this reference movie. The data rate is given in bits per second.

Only one data rate atom is allowed per container reference movie descriptor atom.

=== rmqu ===
{{QT_Atom|atomName=rmqu|function=quality atom|containedIn={{QT|rmda}}|canContain=none allowed}}
The quality atom acts as a tie breaker. It gives a relative quality number that helps the application decide which reference movie to play if all other quality-defining atoms are equal. A higher value indicates a higher quality.

Only one quality atom is allowed per container reference movie descriptor atom.

=== rmra ===
{{QT_Atom|atomName=rmra|function=reference movie|containedIn={{QT|moov}}|canContain={{QT|rmda}}}}

The reference movie atom typically contains data about alternate movies. Which alternate movie plays depends upon conditions such as the system requirements listed in the contained atoms. There can be only one reference movie atom per movie.

=== rmvc ===
{{QT_Atom|atomName=rmvc|function=version check|containedIn={{QT|rmda}}|canContain=none allowed}}
This atom indicates the minimum version of the software package, such as Quicktime or Quicktime VR, that is needed to play the reference movie. The application to match against is given as a Macintosh Gestalt type (e.g. 'qtim').

Multiple version check atom are allowed per reference movie descriptor atom. The application must meet all minimum version check requirements to play the reference movie.

=== skip ===
{{QT_Atom|atomName=skip|function=skipped space|containedIn=''top level''|canContain=''tbd''}}

=== smhd ===
{{QT_Atom|atomName=smhd|function=sound media header|containedIn={{QT|minf}}|canContain=''leaf atom''}}

=== stbl ===
{{QT_Atom|atomName=stbl|function=sample table|containedIn={{QT|minf}}|canContain={{QT|co64}}, {{QT|ctts}}, {{QT|stco}}, {{QT|stsc}}, {{QT|stsd}}, {{QT|stss}}, {{QT|stsz}}, {{QT|stts}}}}

=== stco ===
{{QT_Atom|atomName=stco|function=sample table chunk offset|containedIn={{QT|stbl}}|canContain=''leaf atom''}}
The stco atom for a track lists the offsets for the various chunks that comprise a media track. These offsets are absolute offsets within the file starting from offset 0. Note that this atom only allows for 32-bit offsets. Files requiring 64-bit offsets must use the {{QT|co64}} atom.

''QT Atom Preamble''
1 byte version
3 bytes flags
4 bytes total entries in offset table (n)
4 bytes chunk offset 0
4 bytes chunk offset 1
..
..
4 bytes chunk offset n-1

=== stsc ===
{{QT_Atom|atomName=stsc|function=sample table sample to chunk map|containedIn={{QT|stbl}}|canContain=''leaf atom''}}

=== stsd ===
{{QT_Atom|atomName=stsd|function=sample table sample description|containedIn={{QT|stbl}}|canContain=''leaf atom''}}

=== stss ===
{{QT_Atom|atomName=stss|function=sample table sync samples|containedIn={{QT|stbl}}|canContain=''leaf atom''}}

The stss atom is the sample table sync sample atom. This atom contains a list of all samples in the track that are marked as sync samples. Sync samples are also known as keyframes or intra-coded frames. These samples indicate which video frames can be completely decoded on their own, without any information from other video frames, thus making the frames safe to jump to randomly.

An stss atom has the following structure:

''QuickTime Atom Preamble''
1 byte version
3 bytes flags
4 bytes number of sync samples (n)
4 bytes sync sample 1
4 bytes sync sample 2
..
..
4 bytes sync sample n

Each entry in the sync sample table indicates the ID of a sample that is a sync sample. Note that this table begins numbering from 1 rather than 0.

As an example, if the stss atom of a video trak has 4 entries and those entries are 1, 9, 19, and 34, that means that video frames 1, 9, 19, and 34 (or 0, 8, 18, and 33 if your frames are numbered beginning at 0) are sync samples.

If a trak has no stss atom then all of the samples in the track are implicitly sync samples.

=== stsz ===
{{QT_Atom|atomName=stsz|function=sample table sizes|containedIn={{QT|stbl}}|canContain=''leaf atom''}}

The stsz atom is the sample table size size atom. This atom contains the sizes of all of the samples in a trak.

''QuickTime Atom Preamble''
1 byte version
3 bytes flags
4 bytes uniform size of each sample
4 bytes number of sample sizes (n)
4 bytes sample 0 size
4 bytes sample 1 size
..
..
4 bytes sample (n-1) size

The stsz atom can operate in one of two modes. First, it is possible that all of the samples in a trak have the same size. In this case, the uniform size fieldis set to the constant size. The number of sample sizes field is set to the total number samples in the trak, and there is no sample size table following. This mode is commonly used in the stsz atom of audio traks. For example, in an audio file with length of 2 seconds that has a sample rate of 22050 Hz, the uniform size field will be set to 1, indicating that the the size of each sample is 1. The number of sample sizes field will be set to 44100 (22050 samples/sec * 2 sec = 44100 samples).

In the second mode, all of the samples are a different size (logically, this mode would have to be used even if all of the samples were the same size except for one). In this case, the uniform size field is set to 0. The number of sample sizes field contains the number of entries in the sample size table. Each entry in the sample size table contains the size of a sample in the trak.

=== stts ===
{{QT_Atom|atomName=stts|function=sample table time to sample map|containedIn={{QT|stbl}}|canContain=''leaf atom''}}

=== tkhd ===
{{QT_Atom|atomName=tkhd|function=track header|containedIn={{QT|trak}}|canContain=''leaf atom''}}

=== trak ===
{{QT_Atom|atomName=trak|function=track header|containedIn={{QT|moov}}|canContain={{QT|tkhd}}}}

=== uuid ===
{{QT_Atom|atomName=uuid|function=Used by the PSP MSNV brand of MP4|containedIn=''tbd''|canContain=''tbd''}}

=== vmhd ===
{{QT_Atom|atomName=vmhd|function=video media header|containedIn={{QT|minf}}|canContain=''leaf atom''}}

=== wide ===
{{QT_Atom|atomName=wide|function=skipped data|containedIn=''top level''|canContain=''tbd''}}

== References ==
* [http://developer.apple.com/documentation/QuickTime/QTFF/index.html Quicktime File Format Specification]
* [http://www.zlib.org zlib compression/decompression library]
* [http://www.itscj.ipsj.or.jp/sc29/open/29view/29n5245t.doc Advanced Video Coding (AVC) file format]
* [http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip ISO 14496 specifications]
* [http://le-hacker.org/hacks/mpeg-drafts/is144961cd.pdf ISO 14496 draft specifications]
* [http://www.mp4ra.org/atoms.html List of mp4/mov atoms]
* [http://www.geocities.com/xhelmboyx/quicktime/formats/mp4-layout.txt MP4 layout]
* [http://docs.info.apple.com/article.html?artnum=75424 Some different Quicktime codec samples.]
* [http://www.medialooks.com/products/directshow_filters/quicktime_filter.html QuickTime for DirectShow]
* [http://ftyps.com Complete List of all known MP4 / QuickTime 'ftyp' designations]
[[Category:Container Formats]]
* [http://wiki.awkwardtv.org/wiki/QT_Codec_Information QT Codec list]

SANM

2009-10-15T19:05:40Z

Clone2727: update Residual link

This page attempts to document the [[LucasArts]] [[Smush]] v2 codec, FOURCC "SANM".

A GPL'd decoder for the SNM format and relevant codecs can be found in the [http://residual.svn.sourceforge.net/viewvc/residual/residual/trunk/engines/grim/smush/ Residual] reimplementation of the Grim Fandango Engine (GrimE), although it is largely unreadable because it was converted from the original assembler code to C.

= Samples =
* Grim Fandango: http://samples.mplayerhq.hu/game-formats/la-snm/grimfandango/
* Grim Fandango Demo uses older style videos (SAN, same codecs as Monkey Island 3) and 3D Models (text not binary format).
* X-Wing Alliance
* Find more games that use SNM.
== Unique Samples ==
The following Grim Fandango movies are unique in that they (used to) make the Residual smush implementation segfault, and the issue was (never) resolved by adding 5700 bytes of padding to some buffers. When writing a decoder, they may serve as helpful potential stress tests.
lol.snm, byeruba.snm, crushed.snm, eldepot.snm, heltrain.snm, hostage.snm, tb_kitty.snm

'''Note''' - The Residual implementation's segfaulting results in from improper breakdown of the destination image into 8x8 blocks, whereby the calculation will claim that an image with N height blocks has (N+1) height blocks (or similar), at which point the segfault is imminent. This can be solved by either trimming the remaining pixels that don't fit into the last 8x8 blocks (undesirable), or set the image buffer width/height to the image size in ''blocks * 8'', not ''pixels'', to account for said remaining pixels (desirable). We'll dismiss this as a Residual implementation issue.

== Use in Grim Fandango ==
SANM is used in Grim Fandango for cut-scenes and in-game animations. The actual SNM movie files are gzipped and stored inside LAB archive files (which are quite easy to extract, there are many tools). You must use a tool like *nix's "gunzip" to decompress the SNM files after extracting the SNM files out of the LAB files. A decompressed Smush file has the "SANM" FOURCC as the first four bytes.

= Organization =
This section deals with the structural properties of Smush movies. In other words, we describe the various headers used.

'''Note''': each "chunk size" entry in a particular chunk header indicates the size of the chunk's contents ''without'' the chunk's FOURCC and size.

== Preamble ==
The movie begins with a basic 8-byte section that looks like this:

0x00|"SANM" FOURCC |4 bytes big endian
0x04|Movie size (in bytes)|4 bytes big endian

== Video Header ==
This header immediately follows the preamble. It describes the movie's video properties.

0x000|"SHDR" FOURCC |4 bytes big endian
0x004|Header size (in bytes) |4 bytes big endian
0x008|Version value 1 |1 byte
0x009|Version value 2 |1 byte
0x00A|# of frames |2 bytes little endian
0x00C|Video's x-coordinate |2 bytes little endian
0x00E|Video's y-coordinate |2 bytes little endian
0x010|Width |2 bytes little endian
0x012|Height |2 bytes little endian
0x014|Image type (see notes) |2 bytes little endian
0x016|Frame delay (microseconds)|4 bytes little endian
0x01A|Maximal frame buffer size |4 bytes little endian
0x01E|Color Palette |256 colors, 4-bytes little endian each
0x41E|Unused (see notes) |16 bytes

=== Notes ===
* It appears as though the original decoder ignores the Frame delay field completely. Instead, all movies are played with a frame delay of 66667 microseconds. For now we ignore it and force the 66667 usec value, until we find a sample that breaks with this.
* Image type is "3" for all encountered samples so far. It might be helpful to assert() on this to easily single out samples that deviate from this.
* Looks like the original decoder ignores the last 16 bytes of the header.

== Audio/Keyframe Header ==
Smush supports variable-size keyframes. An example of this usage can be seen in the Full Throttle highway chase scenes, where different images are composited into the streaming video depending on the player's actions.

Curiously enough, this header includes both audio and keyframe information.

0x00|"FLHD" FOURCC |4 bytes big endian
0x04|Header size (in bytes)|4 bytes big endian

Followed by any number of keyframe dimension chunks, which should match the number of keyframes in the movie. Dimension chunks in this header specify the dimensions of corresponding keyframes in the stream, in the order they're encountered. This information has not been rigorously verified, though.
0x00|"Bl16" FOURCC |4 bytes big endian
0x04|Header size (in bytes)|4 bytes big endian
0x08|Padding? |2 bytes
0x0A|Width |2 bytes little endian
0x0C|Height |2 bytes little endian
0x0E|Padding? |2 bytes

Followed by exactly one audio info chunk.
0x00|"Wave" FOURCC |4 bytes big endian
0x04|Header size (in bytes)|4 bytes big endian
0x08|Frequency (Hz) |4 bytes little endian
0x0C|# of channels |4 bytes little endian
0x10|See notes |4 bytes

=== Notes ===
* For some movies, the "Wave" chunk contains an extra 4-byte field at its end, the purpose of which is unknown.
* Movies without audio do not contain an audio info chunk.
* The order in which Wave/Bl16 chunks are organized in the FLHD header is unspecified and is known to vary between movies.

== Annotation ==
Movies may contain an optional plaintext annotation. In Grim Fandango, the only such movies are in-game animations. Keep in mind that the string itself may not always be as large as the advertised annotation size. In that case, the remaining space is padded with zeros until the advertised length is reached.

0x00|"ANNO" FOURCC |4 bytes big endian
0x04|Annotation size (in bytes)|4 bytes big endian
0x08|Null-terminated string |(Annotation size) bytes

== Frame ==
This header is used as a container for a video frame and/or an audio frame, stored in an arbitrary order. In itself, it's just a FOURCC and a size.
0x00|"FRME" FOURCC |4 bytes big endian
0x04|Chunk size (in bytes)|4 bytes big endian

=== Audio ===
Please see the appropriate section in [[VIMA]] for an audio frame's header/codec details. Note that as far as we know right now, this codec is specific to Grim Fandango Smush files.

=== Video ===
This chunk stores a potentially encoded video frame, as well as various opcodes and other stuff that's used to decode it. More details downstairs.
0x000|"Bl16" FOURCC |4 bytes big endian
0x004|Chunk size (in bytes) |4 bytes big endian
0x008|Unknown |8 bytes
0x010|Width |4 bytes little endian
0x014|Height |4 bytes little endian
0x018|Sequence # |2 bytes little endian
0x01A|Subcodec ID |1 byte
0x01B|Diff buffer rotate code |1 byte
0x01C|Unknown |4 bytes
0x020|Small codebook |8 bytes, 4 color values 2 bytes little endian each
0x028|Background colour |2 bytes little endian
0x02A|Unknown |2 bytes
0x02C|RLE output size (bytes) |4 bytes little endian
0x030|Codebook |512 bytes, 256 color values each 2 bytes little endian
0x230|Unknown |8 bytes
0x238|Video stream |...

= Codec =
The codec is actually a combination of several subcodecs. The subcodec that's used for a particular frame is indicated by the appropriate field in the "Bl16" chunk of the frame.

Decompressed pixels come in 16-bit little endian, using the "565" bit arrangmenet.

== Triple Diff Buffering ==
Smush uses a triple diff buffer mechanism to decode image data. A decoder's state includes three buffers, which are occasionally referenced by various subcodecs to decode individual frames. We will hereafter refer to said buffers as "db0", "db1", and "db2", where "db0" is the logical "current" diff buffer. It is crucial to note that "dbX" is only an ''alias'' to a particular diff buffer and does not stand for the ''contents'' of the buffer itself. In other words, it's a pointer.

Each frame contains an opcode that specifies how said buffers are rotated. Only two opcodes are used. Any other opcodes are ignored as "no-ops."
Opcode 1:
swap(db0, db2)
Opcode 2:
swap(db1, db2)
swap(db2, db0)

== Initial Setup ==
We need to initialize two codebooks of 4x4 and 8x8 glyphs. The glyphs themselves are monochrome and thus consist of a foreground and background. We hereafter refer to said codebooks as glyph4_cb and glyph8_cb.

The construction algorithm iterates through two coordinate vectors, and interpolates an NxN glyph using every position in the x-vector with every position in the y-vector. Each vector contains 16 coordinates for a grand total of 256 glyphs per glyph size.

The vectors are defined for 4x4 and 8x8 glyphs as follows.
const int xvector4[] = { 0, 1, 2, 3, 3, 3, 3, 2, 1, 0, 0, 0, 1, 2, 2, 1 };
const int yvector4[] = { 0, 0, 0, 0, 1, 2, 3, 3, 3, 3, 2, 1, 1, 1, 2, 2 };

const int xvector8[] = { 0, 2, 5, 7, 7, 7, 7, 7, 7, 5, 2, 0, 0, 0, 0, 0 };
const int yvector8[] = { 0, 0, 0, 0, 1, 3, 4, 6, 7, 7, 7, 7, 6, 4, 3, 1 };

Here's how we make 4x4 glyphs. The algorithm for 8x8 glyphs is intuitively analogous.

for i = 0..16
{
for j = 0..16
{
glyph[4][4] = all zeros

vert1.x = xvector4[i]
vert1.y = yvector4[i]
vert2.x = xvector4[j]
vert2.y = yvector4[j]

edge1 = get_edge(vert1.x, vert1.y)
edge2 = get_edge(vert2.x, vert2.y)
direction = get_direction(edge1, edge2)

width = largest side of line's bounding rectangle
for each discrete point in _width_ points of our line (including the tips)
{
if direction is up, while row = point.y is >= 0, glyph[row--][point.x] = 1;
if direction is down, while row = point.y is < 4, glyph[row++][point.x] = 1;
if direction is left, while col = point.x is >= 0, glyph[point.y][col--] = 1;
if direction is right, while col = point.x is < 4, glyph[point.y][col++] = 1;
}

codebook4.push_back(glyph) // order is important here, so yes, it's a push_back or equivalent
}
}

And here are the supplementary functions:
get_edge(x, y)
{
if y == 0, return bottom_edge
else if y == 3, return top_edge
else if x == 0, return left_edge
else if x == 3, return right_edge
else, return no_edge
}

get_direction(2 edges)
{
if (edges are left/right or right/left) or (edges are bottom/!top or !top/bottom), return up
else if (edges are !bottom/top or top/!bottom), return down
else if (edges are left/!right or !right/left), return left,
else if (edges are bottom/top or top/bottom) or (edges are right/!left or !left/right), return right
}

== Main Algorithm ==
if 0 == sequence number:
{
// this is a keyframe
fill db1 and db2 with background color.
}
handle subcodec according to ID.
copy contents of db0 into output image.
rotate buffers according to opcode.

== Subcodecs ==
This section explains what the individual subcodecs mean, and how to suck out image data in each case. Note that ImageSize, in bytes, is defined as (Width * Height * 2)

ID|What
0|Keyframe. Copy ImageSize bytes from video stream into db0, loop by 16-bit values and reinterpret each one as little endian.
1|Never encountered so far.
2|Hierarchical VQ and motion compensation.
3|Copy ImageSize bytes from db2 into db0.
4|Copy ImageSize bytes from db1 into db0.
5|RLE decode. See below.
6|Simple lookup/write. See below.
7|Never encountered so far.
8|RLE-encoded codebook indices. See below.

=== Subcodec 2 ===
This codec is broken up into a three-level hierarchy, where each level decodes differently sized image blocks. The decoding algorithms are chosen based on opcodes provided by the video stream. Block sizes are 8x8, 4x4, and 2x2. Even though different block sizes exist, one pass through the decoding algorithm will always(!) decode an 8x8 block by either decoding an entire 8x8 block, by breaking the 8x8 block into four 4x4 blocks (and decoding each one), or by breaking a 4x4 block into four 2x2 blocks (and decoding each one). Any combination of said breakdown is possible and is up to the video stream.

* We indicate the current x/y coordinates in db0 by "cx" and "cy", respectively.
* We assume that two-dimensional arrays are row-major. That is, to access pixel(s) (x, y) at array, we write array[y][x].

Decoding is done by breaking the image into 8x8 blocks (rounding up where appropriate), and starting at the top, decoding each row from left to right with Level1. (Level1 will invoke any required levels, as described below.) For example:
int hblocks = round Height to next multiple of 8
int wblocks = round Width to next multiple of 8

cy = 0
for hblock in range(0, hblocks)
{
cx = 0 // beginning of row
for wblock in range(0, wblocks)
{
level1(cx, cy)
cx += 8 // 8 pixels right
}

cy += 8 // 8 pixels down
}

We now describe the decoding algorithm for each opcode, per level. The general decoding algorithm of a level looks like this:
opcode = next byte in stream
handle opcode (see below)

==== Level 1 (8x8 blocks) ====
===== 0x00 ... 0xF4 =====
x, y = motion_vectors[opcode]
copy 8x8 block from db2[y + cy][x + cx] to db0[cy][cx]

===== 0xF5 =====
motion_vector = next 2 bytes of stream, little endian
x = motion_vector % image_width
y = motion_vector / image_width
copy 8x8 block from (db2[y + cy][x + cx]) to db0[cy][cx]

===== 0xF6 =====
copy 8x8 block from db1[cy][cx] to db0[cy][cx]

===== 0xF7 =====
glyph8_index = next byte of stream
indices = next 2 bytes of stream, little endian
fg_index = hi8bits(indices)
bg_index = lo8bits(indices)
fgcolor = codebook[fg_index]
bgcolor = codebook[bg_index]
draw 8x8 glyph from glyph8_cb[glyph8_index] into db0[cy][cx] using fgcolor and bgcolor

===== 0xF8 =====
glyph8_index = next byte of stream
colors = next 4 bytes of stream, little endian
fgcolor = hi16bits(colors)
bgcolor = lo16bits(colors)
draw 8x8 glyph from glyph8_cb[glyph8_index] into db0[cy][cx] using fgcolor and bgcolor

===== 0xF9, 0xFA, 0xFB, 0xFC =====
color = value from small_codebook[opcode - 0xf9], little endian
fill 8x8 block in db0[cy][cx] with color

===== 0xFD =====
index = value of next byte in stream
color = value from codebook[index], little endian
fill 8x8 block in db0[cy][cx] with color

===== 0xFE =====
color = next 2 bytes in stream, little endian
fill 8x8 block in db0[cy][cx] with color

===== 0xFF =====
This effectively breaks this block up into four 4x4 blocks and invokes the next level to decode them.
next_level(cx , cy)
next_level(cx + 4, cy)
next_level(cx , cy + 4)
next_level(cx + 4, cy + 4)

==== Level 2 (4x4 blocks) ====
Exactly the same as Level 1, except with 4x4 blocks.

==== Level 3 (2x2 blocks) ====
Same as the other levels except with 2x2 blocks, and with the following differences.

===== 0xF7 =====
indices[2][2] = next 4 bytes of stream, little endian
write a 2x2 block into db0[cy][cx] using codebook[indices[][]] for colors

===== 0xF8, 0xFF =====
db0[cy][cx] = next 2 bytes of stream, little endian
db0[cy][cx + 1] = next 2 bytes of stream, little endian
db0[cy + 1][cx] = next 2 bytes of stream, little endian
db0[cy + 1][cx + 1] = next 2 bytes of stream, little endian

=== Subcodec 5 ===
This is an RLE scheme.
size = RLE output size field from Bl16 header
rle_decode(db0, video stream, size)
for each 16-bit value of (size / 2) values starting at db0
{
little_endian(value)
}

And here's the routine itself:
rle_decode(dst, src, const size)
{
remaining = size
while (remaining)
{
code = next byte of stream
line_length = (code >> 1) + 1

if (code & 1) // RLE run
{
color = next byte of input stream
fill line_length bytes in dst with color
}
else // raw image data
{
copy line_length bytes from src into dst
}

remaining -= line_length
}
}

=== Subcodec 6 ===
This is a straightforward codebook lookup/write routine.
for each pixel in db0:
{
index = value of next byte in video stream;
pixel = (2 bytes little endian) codebook[index];
}

=== Subcodec 8 ===
Used by loladies.snm, and repmec3c.snm.

Another RLE scheme, where the actual indices into the codebook are RLE-compressed. The decompression algorithm uses the same RLE decoding as in Subcodec 5.
indices = []
rle_decode(indices, video stream, width * height)
for each pixel in db0, i in range(0, indices.size())
{
pixel = codebook[indices[i]], as little endian
}

= Appendix A: Motion Vectors =
This is the static motion vector table used in Subcodec 2. Each element is an (x, y) pair.
int motion_vectors[256][2] =
{
{0, 0}, {-1, -43}, {6, -43}, {-9, -42}, {13, -41},
{-16, -40}, {19, -39}, {-23, -36}, {26, -34}, {-2, -33},
{4, -33}, {-29, -32}, {-9, -32}, {11, -31}, {-16, -29},
{32, -29}, {18, -28}, {-34, -26}, {-22, -25}, {-1, -25},
{3, -25}, {-7, -24}, {8, -24}, {24, -23}, {36, -23},
{-12, -22}, {13, -21}, {-38, -20}, {0, -20}, {-27, -19},
{-4, -19}, {4, -19}, {-17, -18}, {-8, -17}, {8, -17},
{18, -17}, {28, -17}, {39, -17}, {-12, -15}, {12, -15},
{-21, -14}, {-1, -14}, {1, -14}, {-41, -13}, {-5, -13},
{5, -13}, {21, -13}, {-31, -12}, {-15, -11}, {-8, -11},
{8, -11}, {15, -11}, {-2, -10}, {1, -10}, {31, -10},
{-23, -9}, {-11, -9}, {-5, -9}, {4, -9}, {11, -9},
{42, -9}, {6, -8}, {24, -8}, {-18, -7}, {-7, -7},
{-3, -7}, {-1, -7}, {2, -7}, {18, -7}, {-43, -6},
{-13, -6}, {-4, -6}, {4, -6}, {8, -6}, {-33, -5},
{-9, -5}, {-2, -5}, {0, -5}, {2, -5}, {5, -5},
{13, -5}, {-25, -4}, {-6, -4}, {-3, -4}, {3, -4},
{9, -4}, {-19, -3}, {-7, -3}, {-4, -3}, {-2, -3},
{-1, -3}, {0, -3}, {1, -3}, {2, -3}, {4, -3},
{6, -3}, {33, -3}, {-14, -2}, {-10, -2}, {-5, -2},
{-3, -2}, {-2, -2}, {-1, -2}, {0, -2}, {1, -2},
{2, -2}, {3, -2}, {5, -2}, {7, -2}, {14, -2},
{19, -2}, {25, -2}, {43, -2}, {-7, -1}, {-3, -1},
{-2, -1}, {-1, -1}, {0, -1}, {1, -1}, {2, -1},
{3, -1}, {10, -1}, {-5, 0}, {-3, 0}, {-2, 0},
{-1, 0}, {1, 0}, {2, 0}, {3, 0}, {5, 0},
{7, 0}, {-10, 1}, {-7, 1}, {-3, 1}, {-2, 1},
{-1, 1}, {0, 1}, {1, 1}, {2, 1}, {3, 1},
{-43, 2}, {-25, 2}, {-19, 2}, {-14, 2}, {-5, 2},
{-3, 2}, {-2, 2}, {-1, 2}, {0, 2}, {1, 2},
{2, 2}, {3, 2}, {5, 2}, {7, 2}, {10, 2},
{14, 2}, {-33, 3}, {-6, 3}, {-4, 3}, {-2, 3},
{-1, 3}, {0, 3}, {1, 3}, {2, 3}, {4, 3},
{19, 3}, {-9, 4}, {-3, 4}, {3, 4}, {7, 4},
{25, 4}, {-13, 5}, {-5, 5}, {-2, 5}, {0, 5},
{2, 5}, {5, 5}, {9, 5}, {33, 5}, {-8, 6},
{-4, 6}, {4, 6}, {13, 6}, {43, 6}, {-18, 7},
{-2, 7}, {0, 7}, {2, 7}, {7, 7}, {18, 7},
{-24, 8}, {-6, 8}, {-42, 9}, {-11, 9}, {-4, 9},
{5, 9}, {11, 9}, {23, 9}, {-31, 10}, {-1, 10},
{2, 10}, {-15, 11}, {-8, 11}, {8, 11}, {15, 11},
{31, 12}, {-21, 13}, {-5, 13}, {5, 13}, {41, 13},
{-1, 14}, {1, 14}, {21, 14}, {-12, 15}, {12, 15},
{-39, 17}, {-28, 17}, {-18, 17}, {-8, 17}, {8, 17},
{17, 18}, {-4, 19}, {0, 19}, {4, 19}, {27, 19},
{38, 20}, {-13, 21}, {12, 22}, {-36, 23}, {-24, 23},
{-8, 24}, {7, 24}, {-3, 25}, {1, 25}, {22, 25},
{34, 26}, {-18, 28}, {-32, 29}, {16, 29}, {-11, 31},
{9, 32}, {29, 32}, {-4, 33}, {2, 33}, {-26, 34},
{23, 36}, {-19, 39}, {16, 40}, {-13, 41}, {9, 42},
{-6, 43}, {1, 43}, {0, 0}, {0, 0}, {0, 0}
};

[[Category:Game Formats]]
[[Category:Video Codecs]]
[[Category: Video FourCCs]]
[[Category:Formats missing in FFmpeg]]

Sega FILM

2009-08-22T19:01:11Z

Clone2727: /* Games That Use FILM Files */ Phantasm uses three different versions of Sega FILM

''This page is based on the document 'Description of the Sega FILM/CPK File Format' by Mike Melanson found at [http://multimedia.cx/film-format.txt http://multimedia.cx/film-format.txt].''

* Extensions: cpk, cak, film
* Company: [[Sega (Company)|Sega]]
* Samples:
** [http://samples.mplayerhq.hu/game-formats/film-cpk/ http://samples.mplayerhq.hu/game-formats/film-cpk/]
** Batman and Robin Sega CD with 'Seg4' data: [http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/ http://samples.mplayerhq.hu/game-formats/segacd/batmanandrobin-film-seg4/]
** Dracula Unleashed/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/ http://samples.mplayerhq.hu/game-formats/segacd/dracula-unleashed-film/]
** Jurassic Park/Sega CD: [http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/ http://samples.mplayerhq.hu/game-formats/segacd/jurassicpark-film/]

FILM is a multimedia container file format developed by Sega for use on its early CD-ROM home video game consoles. Based on analysis of a number of Sega CD and Saturn games, it appears that the format was first developed sometime during the era of the Sega CD, Sega's first CD-based video game console. There are many early variations of the FILM format observed on a number of Sega CD titles. Further, early FILM files have been observed on at least one 3DO game ([http://www.mobygames.com/game/3do/lemmings Lemmings]).

The Sega Saturn video game console, released in 1994, was also CD-ROM-based and apparently offered developers a standardized SDK for full motion video (FMV) playback using a modified variant of the well-known [[Cinepak]] video codec.

It is possible to store both audio and video in a FILM file. Alternatively, the format is able to handle either video without audio, or vice versa.

== Sega Saturn CPK File Format ==

All multi-byte numbers are stored in big endian format.

Many Sega Saturn CD-ROM games use this file format to store frames of a Cinepak-compressed video interleaved with uncompressed [[PCM]] audio. When this is the case, the files will typically have the extension .CPK (which is why FILM files are usually known as CPK files). Sometimes, audio-only FILM files will have a .SND extension.

The general format is laid out as follows:

+-----------------------+
| +-------------------+ |
| | FILM header | |
| | | |
| | +---------------+ | |
| | | FDSC chunk | | |
| | +---------------+ | |
| | | |
| | +---------------+ | |
| | | STAB chunk | | |
| | +---------------+ | |
| | | |
| +-------------------+ |
| |
| Audio or Video Data |
| .. |
| .. |
+-----------------------+

A FILM file will usually consist of a header followed by interleaved audio and video chunks. The FILM header has the following structure:

bytes 0-3 'FILM' signature
bytes 4-7 length of FILM header (including signature and length
fields)
bytes 8-11 FILM format version in ASCII (ex: '1.01' or '1.07')
bytes 12-15 unknown (may be reserved and set to 0)
bytes 16-n remainder of FILM header

Different Sega Saturn games include FILM files with a variety of FILM version numbers. Sometimes, the same game will include FILM files with a variety of format versions. A version number implies that there has been some change to the file format, but I have yet to observe any differences between different FILM file versions (except possibly for version '1.09'; see STAB chunk for more details).

The remainder of the FILM header contains a number of chunks describing the media data in the file. Usually, the number of chunks is 2: A FDSC chunk and a STAB chunk.

A FDSC chunk contains file description information. The chunk format is as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); an FDSC chunk should be 32 (0x20) bytes long
bytes 8-11 FOURCC of video codec (usually 'cvid' for Cinepak or null
for no video)
bytes 12-15 height of video frames
bytes 16-19 width of video frames
byte 20 unknown, but always seems to be 0x18 (24)
byte 21 number of audio channels
byte 22 audio sampling resolution in bits (either 8 or 16)
byte 23 unknown
bytes 24-25 audio sampling frequency in Hz
bytes 26-31 unknown (may be reserved and set to 0)

Note that the height field precedes the width field, which is unusual since width usually precedes height when expressing video resolution.

The fields pertaining to audio (channels, bits, and sample rate) will all be 0 if there is no audio present in the file.

A STAB chunk contains a table of media sample information. The chunk format is as follows:

bytes 0-3 'STAB' chunk signature
bytes 4-7 length of STAB chunk (including signature and length
fields)
bytes 8-11 framerate base frequency in Hz
bytes 12-15 number of entries in the sample table
bytes 16-n sample table

Note that the length field ought to take the first 16 chunk bytes into account. However, it has been observed from some games (notably [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers] using '1.09' version FILM files) that the length field sometimes does not account for these 16 bytes.

The sample table consists of a series of 16-byte sample records. Each record is laid out as follows:

bytes 0-3 offset of sample chunk from beginning of sample data
bytes 4-7 length of sample chunk
bytes 8-11 sample info 1
bytes 12-15 sample info 2

The offset is the offset from the start of the sample data, not the absolute offset in the file. The length of the FILM header implicitly serves as a pointer to the beginning of the sample data in the file.

If the sample info 1 field is set to all ones, the sample is an audio chunk. Otherwise, it is a video chunk. If it is a video chunk, the top bit of the 32-bit number specifies whether the chunk is an inter-coded or an intra-coded frame. 0=intra-coded (a.k.a. keyframe), 1=inter-coded. This is useful for seeking since it is a good idea to only jump to key frames when seeking through a file.

The rest of the first sample info field and the second sample info field pertain to framerate calculation. Refer to the section on FILM framerate calculation for more information on proper FILM playback using these sample info fields.

== FILM Framerate Calculation ==

The STAB chunk contains a framerate base frequency in bytes 8-11. This frequency is expressed in ticks/second (Hz). Every video chunk has a frame tick count. For example, movie files in Panzer Dragoon I & II (FILM format versions 1.04 and 1.07, respectively) have a base frequency of 600 Hz. The frames have tick counts of 0, 20, 40, 60, 80, etc. Thus, there are 20 ticks between each successive frame.

(600 ticks/sec) / (20 ticks/frame) = 30 frames/second

However, not all FILM files exhibit such a nice, even framerate. Myst, for example, contains FILM files (version 1.01) with a base frequency of 30 Hz. Some of the frames skip 2, then 3 ticks. Here's a sample tick count progression: 0, 2, 5, 7, 10, 12, 15, 17...

Each STAB record has 2 32-bit sample info fields. For an audio chunk, sample info 1 is all ones and sample info 2 is always 1. For a video chunk, sample info 1 contains the keyframe bit (as described in the STAB section) and the absolute timestamp in clock ticks of the video frame with respect to the file's base frequency clock. The sample info 2 field contains the number of clock ticks until the next frame is rendered. This type of information would be particularly useful in an interrupt-driven, real-time multimedia system like, for instance, a video game console (such as the Sega Saturn).

It is important to note that an application that knows how to play FILM files can not assume a constant framerate. The files will not play correctly with such a method. It is also important to note that
converting FILM files to file formats that only support constant framerates (such as AVI) is not a winning strategy. The converted file will not play correctly.

== FILM Deviant Cinepak (CVID) Video Data ==

The Cinepak data inside of a FILM file can not be decoded with a general purpose Cinepak decoding algorithm. It is reasonable to think that this was no accident. If FILM files contained standard CVID data, the files could be played on any computer that had some kind of Cinepak decoder implementation.

This document assumes familiarity with the [[Cinepak]] algorithm.

A CVID chunk is supposed to start with a 10-byte chunk header:

byte 0 flags
bytes 1-3 length of CVID data
bytes 4-5 width of coded frame
bytes 6-7 height of coded frame
bytes 8-9 number of coded strips

Following the chunk header ought to be the first byte of the first strip header. In the deviant CVID data stored in a FILM file, there appear to be an extra 2 bytes at the end of the chunk header, bringing the total header size to 12 bytes.

The length of the chunk as reported by the deviant CVID data chunk is also incorrect. The length field is supposed to report the length of the entire chunk including the header. The deviant CVID data reports a length that is 8 bytes too short. That is, the length reported in the CVID chunk is 8 bytes shorter than the length reported in the corresponding record of the FILM file's STAB chunk. The STAB chunk length takes into account the proper length, including the extra 2 bytes at the end of the chunk header.

Finally, the deviant CVID data appears to throw a potential decoder one more curveball with what appears to be data chunks that don't have, for lack of a better term, properly divisible chunk lengths. For example, a 0x2000 chunk commonly has a length of 0x604 bytes, which provides 2 bytes for the chunk ID, 2 bytes for the chunk length, and 0x600 bytes for 256 6-byte vectors. However, the deviant CVID data might have a 0x2000 chunk with a length of 0x600 bytes, which provides for the 4 chunk preamble bytes and 0x5FC bytes for the 6-byte vectors which is not evenly divisible by 6. This apparently confuses Cinepak decoders. The solution in this case is to unpack 255 6-byte vectors and then skip 2 bytes before attempting to decode the next chunk in the strip.

== FILM Audio Data ==

Audio data in a FILM file can be stored in a variety of formats which are mostly linear [[PCM]] variants.

CPK files from Sega Saturn games almost always contain linear PCM audio. The one known exception is Burning Rangers. This game apparently uses [[CRI ADX ADPCM]] audio coding.

Saturn CPK audio data is always stored as signed data. This is important to remember when playing 8-bit CPK audio data on a PC which generally expects 8-bit data to be unsigned.

When a CPK file contains 16-bit audio data, the individual PCM samples are stored in big endian format. Again, this is important to remember when playing on a PC since a PC will generally expect little endian
16-bit data.

If the CPK audio data is stereo (8- or 16-bit), the channel data is non-interleaved. Usually, stereo data is stored interleaved as a left channel sample followed by a right channel sample as follows:

L R L R L R L R ...

In a stereo CPK file, for each audio data chunk, the first half of the chunk contains left channel samples and the second half contains right channel samples. The likely reason for this scheme is that console audio hardware such as that found on the Sega Saturn usually features a number of audio channels which can each play a mono PCM stream at a particular pan position (e.g., from 0-15 where 0 is extreme left, 7 and 8 are center, and 15 is extreme right). In order to play a stereo PCM stream, one physical audio channel must be assigned to extreme left while a second channel is assigned to extreme right. Then the appropriate channel samples are sent to the correct channel. Since these files are optimized for playback on the Sega Saturn it makes sense to arrange the audio samples like this.

The Sega CD audio playback hardware ostensibly supports native sign/magnitude audio samples. All Sega CD games studied use this format to store audio data. Sign/magnitude number coding for 8-bit numbers
means that for each 8-bit byte:

bit 7 sign
bits 6-0 magnitude (value)

This is slightly different from twos complement encoding which is how computers typically store signed numbers. For example, in the sign/magnitude scheme, 0x81 represents -1 and 0xFF represents -127. 0x01
and 0x7F still represent 1 and 127, respectively, just as in unsigned, and signed twos complement coding.

== Early Sega CD FILM Files ==

Some Sega CD games as well as at least one 3DO game (Lemmings) use an early version of the FILM format. Unfortunately, there are a lot of variations and a general-purpose player will probably require a lot of
special-case logic in order to deal with every known circumstance.

The first difference in these early files is the version number. These early files do not have ASCII-readable version fields. Some have NULL or other non-ASCII versions. This helps automatic detection.

The second major difference that all of these early files appear to exhibit is an abbreviated FDSC chunk which omits any audio information. Thus, the FDSC chunk is laid out as follows:

bytes 0-3 'FDSC' chunk signature
bytes 4-7 length of FDSC chunk (including signature and length
fields); this FDSC chunk is 20 (0x14) bytes long
bytes 8-11 FOURCC of video codec
bytes 12-15 height of video frames
bytes 16-19 width of video frames

The lack of audio information leaves room for experimentation. The following is a list of known games which have early FILM files along with any special quirks observed.

On the Lemmings 3DO game, there are 2 files with the .film extension (the 3DO game console uses a custom filesystem which allows for file extensions longer than 3 characters). The files have a NULL version field. The files use CVID data which is deviant in the same manner as typical FILM CVID data with an added quirk: There appear to be 6 extra bytes between the end of the CVID chunk header and the start of the first strip header, rather than the usual 2 extra bytes. The Lemmings FILM files also contain 8-bit signed, monaural PCM data with a sampling frequency of 22050 Hz.

The Batman and Robin Sega CD title has a series of files with the extension .s. They are early FILM files with a version field of 0x00020000. Further, bytes 12-15 of the main FILM header are not set to 0 as is usually seen in FILM files. The files have a video fourcc of 'Seg4' which is probably Cinepak for Sega or a variant thereof. The files have STAB chunks which are a constant 0x20 (32) bytes long. This consists of the 'STAB' signature, a 4-byte chunk length, the base playback frequency, a sample count, and one 16-byte sample record. These files do not store the sample table in one place. Instead, they store one sample record followed immediately by the data corresponding to that sample record. Repeat until the end of the file.

The Dracula Unleashed Sega CD title contains a series of files beginning with video?? with no file extension. They are early FILM files with a NULL version field, abbreviated FDSC chunk, and 'sega' as a video codec (Cinepak for Sega). The audio is 8-bit sign/magnitude audio with a sampling frequency of 16000 Hz.

Jurassic Park for the Sega CD has a large number of files with the file extension .MVD. They are early FILM files with the same characteristics as the FILM files in Dracula Unleashed.

The Tomcat Alley title for the Sega CD has a massive data file called tca.bin. Inside this data file are a lot of FILM files. These files have NULL version fields. The files have abbreviated FDSC chunks and the
'sega' video fourcc. They also have short STAB chunks with an Apple Quicktime 'mdia' atom appended at the end.

== Strategy For Detecting FILM File Types ==

There are quite a few variations and deviations in the FILM file format. This section presents logic for detecting and dealing with the variations.

File extension detection is not especially useful since many games will masquerade their files with another extension. The best method to determine whether a file is a FILM file is to read the first 4 bytes and check for the signature 'FILM'.

Upon validating the signature:

* read the file version in the FILM header
* if the file version consists of ASCII characters
** if the file version is '1.09', watch out for bad length of STAB chunk as well as ADPCM audio
** load as standard FILM file, be sure to feed CVID data through Cinepak decoder that can handle it
* if the file version is 0x00020000
** read the video fourcc
** if the video fourcc is 'Seg4'
*** assume the file comes from Batman and Robin
* if the file version is NULL
** read the video fourcc
** if the video fourcc is 'cvid'
*** assume the file comes from the Lemmings 3DO game
*** be prepared to decode special variant of modified CVID data
*** assume 8-bit, mono, 22050 Hz PCM audio
** if the video fourcc is 'sega'
*** assume the file comes from one of several Sega CD games that agreed on this format
*** assume 8-bit, mono, 16000 Hz sign/magnitude audio

== Games That Use FILM Files ==

These games are known to use some variation of FILM files. Observed file version numbers are noted where known.

* [http://www.mobygames.com/game/saturn/astal Astal (Sega Saturn)]: '0.91', '1.06'
* [http://www.mobygames.com/game/saturn/burning-rangers Burning Rangers (Sega Saturn)]: '1.09'
* [http://www.mobygames.com/game/saturn/clockwork-knight Clockwork Knight (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/criticom Criticom (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/d D (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/defcon-5 Defcon 5 (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/iron-storm_ Iron Storm (Sega Saturn)]
* [http://www.mobygames.com/game/3do/lemmings Lemmings (3DO)]: unversioned
* [http://www.mobygames.com/game/saturn/myst Myst (Sega Saturn)]: '1.01'
* [http://www.mobygames.com/game/saturn/nights-into-dreams Nights Into Dreams (Sega Saturn)]: '0.91', '1.01', '1.06', '1.07', '1.08'
* [http://www.mobygames.com/game/saturn/panzer-dragoon Panzer Dragoon (Sega Saturn)]: '1.04'
* [http://www.mobygames.com/game/saturn/panzer-dragoon-ii-zwei Panzer Dragoon II: Zwei (Sega Saturn)]: '1.07'
* [http://www.mobygames.com/game/sega-saturn/roberta-williams-phantasmagoria Phantasm (Sega Saturn)]: '1.06', '1.08', '1.09'
* Sega Saturn Bootleg Sampler (Sega Saturn): '1.04'
* [http://www.mobygames.com/game/saturn/shockwave-assault Shockwave Assault (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/skeleton-warriors Skeleton Warriors (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/space-jam Space Jam (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/street-fighter-the-movie Street Fighter: The Movie (Sega Saturn)]
* [http://www.mobygames.com/game/saturn/virtua-squad-virtual-cop Virtua Cop (Sega Saturn)]: '1.08'
* World Series Baseball II (Sega Saturn)

[[Category:Container Formats]]
[[Category:Game Formats]]

Smush

2007-02-26T21:38:43Z

Clone2727: oops... confused XvT:BOP with XWA

This page attempts to document the [[LucasArts]] Smush codec. Note that at this stage the document is quite incomplete as the codec is still being reverse engineered.

Samples from various games are located at http://samples.mplayerhq.hu/game-formats/la-san/ and http://samples.mplayerhq.hu/game-formats/la-snm/.

== Usage Matrix ==
{| border="1" cellpadding="2"
! Name !! Variant !! Video Codec || Audio Codec
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault Rebel Assault]
|   ||   ||  
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault-ii-the-hidden-empire Rebel Assault II]
|   ||   ||  
|-
| Rebel Assault II demo
|   || FOBJ Codec 37 ||  
|-
| Rebel Assault II trailer
| SAN ||   || PSAD
|-
| [http://www.mobygames.com/game/dos/full-throttle Full Throttle]
| SAN/NUT || FOBJ Codec 37 || PSAD
|-
| [http://www.mobygames.com/game/dos/dig The Dig]
| SAN || FOBJ Codec 37 || IACT
|-
| [http://www.mobygames.com/game/windows/curse-of-monkey-island The Curse Of Monkey Island]
| SAN || FOBJ Codec 47 || IACT
|-
| [http://www.mobygames.com/game/windows/outlaws Outlaws]
|   ||   ||  
|-
| Outlaws demo
|   || FOBJ Codec 47 ||  
|-
| Grim Fandango demo
|   || FOBJ Codec 47 ||  
|-
| Grim Fandango trailer
| SAN ||   || IACT
|-
| [http://www.mobygames.com/game/windows/grim-fandango Grim Fandango]
| SNM || Bl16 (blocky16) || [[VIMA]]
|-
| [http://www.mobygames.com/game/windows/star-wars-shadows-of-the-empire Shadows of the Empire (PC)]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-x-wing-alliance X-Wing Alliance]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-episode-i-racer Star Wars Racer]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-droidworks Star Wars DroidWorks]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/indiana-jones-and-the-infernal-machine Indiana Jones and the Infernal Machine]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-jedi-knight-mysteries-of-the-sith Jedi Knight: Mysteries of the Sith]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/mortimer-and-the-riddles-of-the-medallion Mortimer and the Riddles of the Medallion]
|   ||   ||  
|-
| Making Magic CDROM (not a game but still uses smush)
|   ||   ||  
|-
| [http://www.mobygames.com/game/escape-from-monkey-island Escape From Monkey Island]
|   || apparently has Smush headers but uses [[Bink Container|Bink]] ||  
|-
| Star Wars Episode 1: Insider's Guide
| SNM ||   ||  
|-
| Jar Jar's Journey Storybook
| SNM ||   ||  
|}

== Variants ==
Smush comes in two variants. [[SAN|Version 1]], FOURCC "ANIM" was used up until Grim Fandango. [[SNM|Version 2]], FOURCC "SANM" was used from Grim Fandango up until its replacement by [[Bink Container|Bink]], possibly in Escape From Monkey Island.

[[Category:Game Formats]]

Smush

2007-02-26T21:33:46Z

Clone2727: typos

This page attempts to document the [[LucasArts]] Smush codec. Note that at this stage the document is quite incomplete as the codec is still being reverse engineered.

Samples from various games are located at http://samples.mplayerhq.hu/game-formats/la-san/ and http://samples.mplayerhq.hu/game-formats/la-snm/.

== Usage Matrix ==
{| border="1" cellpadding="2"
! Name !! Variant !! Video Codec || Audio Codec
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault Rebel Assault]
|   ||   ||  
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault-ii-the-hidden-empire Rebel Assault II]
|   ||   ||  
|-
| Rebel Assault II demo
|   || FOBJ Codec 37 ||  
|-
| Rebel Assault II trailer
| SAN ||   || PSAD
|-
| [http://www.mobygames.com/game/dos/full-throttle Full Throttle]
| SAN/NUT || FOBJ Codec 37 || PSAD
|-
| [http://www.mobygames.com/game/dos/dig The Dig]
| SAN || FOBJ Codec 37 || IACT
|-
| [http://www.mobygames.com/game/windows/curse-of-monkey-island The Curse Of Monkey Island]
| SAN || FOBJ Codec 47 || IACT
|-
| [http://www.mobygames.com/game/windows/outlaws Outlaws]
|   ||   ||  
|-
| Outlaws demo
|   || FOBJ Codec 47 ||  
|-
| Grim Fandango demo
|   || FOBJ Codec 47 ||  
|-
| Grim Fandango trailer
| SAN ||   || IACT
|-
| [http://www.mobygames.com/game/windows/grim-fandango Grim Fandango]
| SNM || Bl16 (blocky16) || [[VIMA]]
|-
| [http://www.mobygames.com/game/windows/star-wars-shadows-of-the-empire Shadows of the Empire (PC)]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-episode-i-racer Star Wars Racer]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-droidworks Star Wars DroidWorks]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/indiana-jones-and-the-infernal-machine Indiana Jones and the Infernal Machine]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-jedi-knight-mysteries-of-the-sith Jedi Knight: Mysteries of the Sith]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/mortimer-and-the-riddles-of-the-medallion Mortimer and the Riddles of the Medallion]
|   ||   ||  
|-
| Making Magic CDROM (not a game but still uses smush)
|   ||   ||  
|-
| [http://www.mobygames.com/game/escape-from-monkey-island Escape From Monkey Island]
|   || apparently has Smush headers but uses [[Bink Container|Bink]] ||  
|-
| Star Wars Episode 1: Insider's Guide
| SNM ||   ||  
|-
| Jar Jar's Journey Storybook
| SNM ||   ||  
|}

== Variants ==
Smush comes in two variants. [[SAN|Version 1]], FOURCC "ANIM" was used up until Grim Fandango. [[SNM|Version 2]], FOURCC "SANM" was used from Grim Fandango up until its replacement by [[Bink Container|Bink]], possibly in Escape From Monkey Island.

[[Category:Game Formats]]

Smush

2007-02-26T21:32:41Z

Clone2727: X-Wing Alliance uses Smacker

This page attempts to document the [[LucasArts]] Smush codec. Note that at this stage the document is quite incomplete as the codec is still being reverse engineered.

Samples from various games are located at http://samples.mplayerhq.hu/game-formats/la-san/ and http://samples.mplayerhq.hu/game-formats/la-snm/.

== Usage Matrix ==
{| border="1" cellpadding="2"
! Name !! Variant !! Video Codec || Audio Codec
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault Rebel Assault]
|   ||   ||  
|-
| [http://www.mobygames.com/game/dos/star-wars-rebel-assault-ii-the-hidden-empire Rebel Assualt II]
|   ||   ||  
|-
| Rebel Assault II demo
|   || FOBJ Codec 37 ||  
|-
| Rebel Assault II trailer
| SAN ||   || PSAD
|-
| [http://www.mobygames.com/game/dos/full-throttle Full Throttle]
| SAN/NUT || FOBJ Codec 37 || PSAD
|-
| [http://www.mobygames.com/game/dos/dig The Dig]
| SAN || FOBJ Codec 37 || IACT
|-
| [http://www.mobygames.com/game/windows/curse-of-monkey-island The Curse Of Monkey Island]
| SAN || FOBJ Codec 47 || IACT
|-
| [http://www.mobygames.com/game/windows/outlaws Outlaws]
|   ||   ||  
|-
| Outlaws demo
|   || FOBJ Codec 47 ||  
|-
| Grim Fandango demo
|   || FOBJ Codec 47 ||  
|-
| Grim Fandango trailer
| SAN ||   || IACT
|-
| [http://www.mobygames.com/game/windows/grim-fandango Grim Fandango]
| SNM || Bl16 (blocky16) || [[VIMA]]
|-
| [http://www.mobygames.com/game/windows/star-wars-shadows-of-the-empire Shadows of the Empire (PC)]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-episode-i-racer Star Wars Racer]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-droidworks Star Wars DroidWorks]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/indiana-jones-and-the-infernal-machine Indiana Jones and the Infernal Machine]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/star-wars-jedi-knight-mysteries-of-the-sith Jedi Knight: Mysteries of the Sith]
|   ||   ||  
|-
| [http://www.mobygames.com/game/windows/mortimer-and-the-riddles-of-the-medallion Mortimer and the Riddles of the Medallion]
|   ||   ||  
|-
| Making Magic CDROM (not a game but still uses smush)
|   ||   ||  
|-
| [http://www.mobygames.com/game/escape-from-monkey-island Escape From Monkey Island]
|   || apparently has Smush headers but uses [[Bink Container|Bink]] ||  
|-
| StarWars Episode 1: Insider's Guide
| SNM ||   ||  
|-
| Jar Jar's Journey Storybook
| SNM ||   ||  
|}

== Variants ==
Smush comes in two variants. [[SAN|Version 1]], FOURCC "ANIM" was used up until Grim Fandango. [[SNM|Version 2]], FOURCC "SANM" was used from Grim Fandango up until its replacement by [[Bink Container|Bink]], possibly in Escape From Monkey Island.

[[Category:Game Formats]]