MultimediaWiki - User contributions [en]

BRP

2006-07-24T10:41:51Z

John doe: clarified 0x02 type 2

* Extensions: brp
* Company: [[Argonaut Games]]
* Samples:
** Alien Odyssey: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/alienodyssey/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/alienodyssey/]
** FX Fighter: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/fxfighter/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/fxfighter/]

At least 2 games use an animation format with the extension .brp: [http://www.mobygames.com/game/dos/fx-fighter FX Fighter] and [http://www.mobygames.com/game/dos/alien-odyssey Alien Odyssey], both by Argonaut. The general container formats used in both games are similar, but differing fourccs inside may indicate that the games used different video coding algorithms (which are presently unknown). All multi-byte numbers are little endian.

== File Format ==

BRP files consist of multi-stream chunks, where video and audio located in separate, but interleaved streams.

File begins with following 12-byte header:
dword signature - "BRPP"
dword streams - number of streams in file
dword unknown - unknown, but equal to 640*480

File header followed by stream headers:
dword signature - stream [[FOURCC]]
dword index - logical index of the stream
dword unknown1 -
dword unknown2 -
dword plsize - size of the following payload data
byte payload[plsize] - stream-specific payload

Finally, actual data chunks follows, each one starts with chunk header:
dword index - logical index of the stream chunk belongs to
dword unknown
dword size - size of the chunk data
byte data[size] - stream-specific chunk data

== Streams ==
=== BVID Stream ===
The video stream. Stream header payload:
dword unknown1
dword width - width of the frame
dword height - height of the frame
dword unknown2

Each BVID's chunk data started with another [[FOURCC]], indicates chunk format:
==== PAL8 Chunk ====
word start - first color to update
word count - number of colors to update
byte rgb[count * 3] - [[RGB]] triplets

==== AVCF Chunk ====

Intraframe 2x2 [[VQ]], similar to one used in [[AVS]].

==== ALCD Chunk ====

Interframe 2x2 [[VQ]], similar to one used in [[AVS]].

==== RLED, RLEF Chunks ====

Rle-compressed frame.
while not all output processed
count = next byte of the input
pixel = next byte of the input
if count is zero
skip (pixel) bytes of ouput
else
fill count of bytes of output with pixel

==== MAD1 Chunk ====

'''TODO'''

This chunk type is made up of several subchunks. Each subchunk is identified by a single byte after which the subchunk data follows. Note that the size of each subchunk is not stored, you need to correctly process each subchunk to get to the next one.

These subchunk types are currently known:

* 0x02: RLE-type algorithm
* 0x03: unknown, first two bytes are some size (of output?)
* 0x05: half-resolution frame, scaled to full resolution (e.g. for a 320x200 BRP this would be 160x100 pixels upscaled to 320x200)
* 0x06: full frame, read width*height bytes of data
* 0x07: block copy / motion vectors
* 0xFF: marks end of MAD1 chunk

=== 0x02 algorithm ===

while input left
get a byte from the input
count = upper 2 bits of the byte
skip = lower 6 bits of the byte
if skip is 0x3F, skip 0x3E pixels in the output buffer
else
skip 'skip' pixels in the output buffer
while count is greater than zero
get a byte from the input as 'bitbuffer'
repeat the following four times
get next 2 bits from 'bitbuffer' ('bitbuffer' & 3) as 'code'
do one of the following according to 'code'
0: skip the next pixel in the output buffer
1: repeat the last output pixel
2: copy the pixel from output[output_positon - width] to the output buffer
3: copy next pixel from the input buffer

=== BASF Stream ===
Audio Stream. Stream header payload:

'''TODO'''

Details of the audio compression scheme are currently unknown. The audio chunks are apparently not preceeded by an ASCII chunk type name.

[[Category:Game Formats]]

BRP

2006-07-24T10:36:21Z

John doe: /* MAD1 Chunk */

* Extensions: brp
* Company: [[Argonaut Games]]
* Samples:
** Alien Odyssey: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/alienodyssey/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/alienodyssey/]
** FX Fighter: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/fxfighter/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/fxfighter/]

At least 2 games use an animation format with the extension .brp: [http://www.mobygames.com/game/dos/fx-fighter FX Fighter] and [http://www.mobygames.com/game/dos/alien-odyssey Alien Odyssey], both by Argonaut. The general container formats used in both games are similar, but differing fourccs inside may indicate that the games used different video coding algorithms (which are presently unknown). All multi-byte numbers are little endian.

== File Format ==

BRP files consist of multi-stream chunks, where video and audio located in separate, but interleaved streams.

File begins with following 12-byte header:
dword signature - "BRPP"
dword streams - number of streams in file
dword unknown - unknown, but equal to 640*480

File header followed by stream headers:
dword signature - stream [[FOURCC]]
dword index - logical index of the stream
dword unknown1 -
dword unknown2 -
dword plsize - size of the following payload data
byte payload[plsize] - stream-specific payload

Finally, actual data chunks follows, each one starts with chunk header:
dword index - logical index of the stream chunk belongs to
dword unknown
dword size - size of the chunk data
byte data[size] - stream-specific chunk data

== Streams ==
=== BVID Stream ===
The video stream. Stream header payload:
dword unknown1
dword width - width of the frame
dword height - height of the frame
dword unknown2

Each BVID's chunk data started with another [[FOURCC]], indicates chunk format:
==== PAL8 Chunk ====
word start - first color to update
word count - number of colors to update
byte rgb[count * 3] - [[RGB]] triplets

==== AVCF Chunk ====

Intraframe 2x2 [[VQ]], similar to one used in [[AVS]].

==== ALCD Chunk ====

Interframe 2x2 [[VQ]], similar to one used in [[AVS]].

==== RLED, RLEF Chunks ====

Rle-compressed frame.
while not all output processed
count = next byte of the input
pixel = next byte of the input
if count is zero
skip (pixel) bytes of ouput
else
fill count of bytes of output with pixel

==== MAD1 Chunk ====

'''TODO'''

This chunk type is made up of several subchunks. Each subchunk is identified by a single byte after which the subchunk data follows. Note that the size of each subchunk is not stored, you need to correctly process each subchunk to get to the next one.

These subchunk types are currently known:

* 0x02: RLE-type algorithm
* 0x03: unknown, first two bytes are some size (of output?)
* 0x05: half-resolution frame, scaled to full resolution (e.g. for a 320x200 BRP this would be 160x100 pixels upscaled to 320x200)
* 0x06: full frame, read width*height bytes of data
* 0x07: block copy / motion vectors
* 0xFF: marks end of MAD1 chunk

=== 0x02 algorithm ===

while input left
get a byte from the input
count = upper 2 bits of the byte
skip = lower 6 bits of the byte
if skip is 0x3F, skip 0x3E pixels in the output buffer
else
skip 'skip' pixels in the output buffer
while count is greater than zero
get a byte from the input as 'bitbuffer'
repeat the following four times
get next 2 bits from 'bitbuffer' ('bitbuffer' & 3) as 'code'
do one of the following according to 'code'
0: skip the next pixel in the output buffer
1: repeat the last output pixel
2: copy the pixel from the line above to the output buffer
3: copy next pixel from the input buffer

=== BASF Stream ===
Audio Stream. Stream header payload:

'''TODO'''

Details of the audio compression scheme are currently unknown. The audio chunks are apparently not preceeded by an ASCII chunk type name.

[[Category:Game Formats]]

BRP

2006-07-24T10:35:07Z

John doe: /* MAD1 Chunk */

* Extensions: brp
* Company: [[Argonaut Games]]
* Samples:
** Alien Odyssey: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/alienodyssey/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/alienodyssey/]
** FX Fighter: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/fxfighter/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/brp/fxfighter/]

At least 2 games use an animation format with the extension .brp: [http://www.mobygames.com/game/dos/fx-fighter FX Fighter] and [http://www.mobygames.com/game/dos/alien-odyssey Alien Odyssey], both by Argonaut. The general container formats used in both games are similar, but differing fourccs inside may indicate that the games used different video coding algorithms (which are presently unknown). All multi-byte numbers are little endian.

== File Format ==

BRP files consist of multi-stream chunks, where video and audio located in separate, but interleaved streams.

File begins with following 12-byte header:
dword signature - "BRPP"
dword streams - number of streams in file
dword unknown - unknown, but equal to 640*480

File header followed by stream headers:
dword signature - stream [[FOURCC]]
dword index - logical index of the stream
dword unknown1 -
dword unknown2 -
dword plsize - size of the following payload data
byte payload[plsize] - stream-specific payload

Finally, actual data chunks follows, each one starts with chunk header:
dword index - logical index of the stream chunk belongs to
dword unknown
dword size - size of the chunk data
byte data[size] - stream-specific chunk data

== Streams ==
=== BVID Stream ===
The video stream. Stream header payload:
dword unknown1
dword width - width of the frame
dword height - height of the frame
dword unknown2

Each BVID's chunk data started with another [[FOURCC]], indicates chunk format:
==== PAL8 Chunk ====
word start - first color to update
word count - number of colors to update
byte rgb[count * 3] - [[RGB]] triplets

==== AVCF Chunk ====

Intraframe 2x2 [[VQ]], similar to one used in [[AVS]].

==== ALCD Chunk ====

Interframe 2x2 [[VQ]], similar to one used in [[AVS]].

==== RLED, RLEF Chunks ====

Rle-compressed frame.
while not all output processed
count = next byte of the input
pixel = next byte of the input
if count is zero
skip (pixel) bytes of ouput
else
fill count of bytes of output with pixel

==== MAD1 Chunk ====

'''TODO'''

This chunk type is made up of several subchunks. Each subchunk is identified by a single byte after which the subchunk data follows.

These subchunk types are currently known:

* 0x02: RLE-type algorithm
* 0x03: unknown, first two bytes are some size (of output?)
* 0x05: half-resolution frame, scaled to full resolution (e.g. for a 320x200 BRP this would be 160x100 pixels upscaled to 320x200)
* 0x06: full frame, read width*height bytes of data
* 0x07: block copy / motion vectors
* 0xFF: marks end of MAD1 chunk

=== 0x02 algorithm ===

while input left
get a byte from the input
count = upper 2 bits of the byte
skip = lower 6 bits of the byte
if skip is 0x3F, skip 0x3E pixels in the output buffer
else
skip 'skip' pixels in the output buffer
while count is greater than zero
get a byte from the input as 'bitbuffer'
repeat the following four times
get next 2 bits from 'bitbuffer' ('bitbuffer' & 3) as 'code'
do one of the following according to 'code'
0: skip the next pixel in the output buffer
1: repeat the last output pixel
2: copy the pixel from the line above to the output buffer
3: copy next pixel from the input buffer

=== BASF Stream ===
Audio Stream. Stream header payload:

'''TODO'''

Details of the audio compression scheme are currently unknown. The audio chunks are apparently not preceeded by an ASCII chunk type name.

[[Category:Game Formats]]

Shockwave Stream

2006-06-27T12:32:01Z

John doe: Forgot a closing brace

* Extension: stream
* Samples: http://www.mplayerhq.hu/MPlayer/samples/game-formats/shockwave-stream/

Files with the .stream extension are found on the [[3DO]] game Shockwave. The files apparently use [[Cinepak]] for video compression but it is unclear if the version used is compatible with standard Cinepak.

The Cinepak data is almost compatible to the standard Cinepak. In the Cinepak decoder, after the number of strips is read, 8 bytes need to be skipped. The meaning of these bytes is currently unknown.
Also, the chunk sizes do not always equal the amount of data actually read. This has been tested with of a modified version of Dr. Ferguson's decoder [1].

The audio data is uncompressed, signed 16-Bit.

The general file layout is made up of chunks (similar to IFF).

[1] http://www.csse.monash.edu.au/~timf/videocodec.html

[[Category:Game Formats]]

Shockwave Stream

2006-06-27T12:31:20Z

John doe: Added some more information on Cinepak and structure

* Extension: stream
* Samples: http://www.mplayerhq.hu/MPlayer/samples/game-formats/shockwave-stream/

Files with the .stream extension are found on the [[3DO]] game Shockwave. The files apparently use [[Cinepak]] for video compression but it is unclear if the version used is compatible with standard Cinepak.

The Cinepak data is almost compatible to the standard Cinepak. In the Cinepak decoder, after the number of strips is read, 8 bytes need to be skipped. The meaning of these bytes is currently unknown.
Also, the chunk sizes do not always equal the amount of data actually read. This has been tested with of a modified version of Dr. Ferguson's decoder [1].

The audio data is uncompressed, signed 16-Bit.

The general file layout is made up of chunks (similar to IFF.

[1] http://www.csse.monash.edu.au/~timf/videocodec.html

[[Category:Game Formats]]

Shockwave Stream

2006-06-27T12:29:39Z

John doe:

* Extension: stream
* Samples: http://www.mplayerhq.hu/MPlayer/samples/game-formats/shockwave-stream/

Files with the .stream extension are found on the [[3DO]] game Shockwave. The files apparently use [[Cinepak]] for video compression but it is unclear if the version used is compatible with standard Cinepak.

The Cinepak data is almost compatible to the standard Cinepak. In the Cinepak decoder, after the number of strips is read, 8 bytes need to be skipped. The meaning of these bytes is currently unknown.
Also, the chunk sizes do not always equal the amount of data actually read. This has been tested with of a modified version of Dr. Ferguson's decoder [1].

The audio data is uncompressed, signed 16-Bit.

[1] http://www.csse.monash.edu.au/~timf/videocodec.html

[[Category:Game Formats]]

HNM

2006-05-19T17:57:22Z

John doe: HNM formats, game links

* Extension: hnm
* Company: [[CRYO Interactive Entertainment]]

HNM is a multimedia format used in some computer games by CRYO.

There are at least three versions of the HNM format:
HNM, HNM4 and HNM6.

HNM and HNM4 format animations are used in games like Commander Blood and Lost Eden. One of the differences is that HNM4 animations don't seem to contain an audio track, while the HNM ones do contain uncompressed PCM audio data.
Both HNM and HNM4 are palette-based formats.

HNM6 is used by newer Cryo games made in the late 1990ies, e.g. China: The Forbidden City and probably the Atlantis games. The audio format in these animations is similar to Cryo's Apc audio format.

== Games Using HNM ==
* [http://www.mobygames.com/game/windows/persian-wars Persian Wars]
* [http://www.mobygames.com/game/windows/philip-jos-farmers-riverworld Riverworld]
* [http://www.mobygames.com/game/commander-blood Commander Blood]
* [http://www.mobygames.com/game/dos/lost-eden Lost Eden]
* [http://www.mobygames.com/game/china-the-forbidden-city China: The Forbidden City]

[[Category:Game Formats]]

BRP

2006-02-15T08:39:08Z

John doe: Video chunks and audio; removed part about AO and MAD1 as it also uses ALCD/AVCF

* Extensions: BRP
* Company: [[Argonaut Games]]

At least 2 games use an animation format with the extension .brp: [http://www.mobygames.com/game/dos/fx-fighter FX Fighter] and [http://www.mobygames.com/game/dos/alien-odyssey Alien Odyssey], both by Argonaut. The general container formats used in both games are similar, but differing fourccs inside may indicate that the games used different video coding algorithms (which are presently unknown).

All multi-byte numbers are little endian. The fourcc chunk format is as follows:

bytes 0-3 chunk size, not including 12-byte preamble
bytes 4-7 chunk type
bytes 8-11 unknown
bytes 12.. chunk payload

A BRP file begins with the following header:

bytes 0-3 file signature: 'BRPP'
bytes 4-7 version number
bytes 8-11 unknown, but always seems to be 307200 in decimal which,
for trivia, is the product of 640 * 480
bytes 12-15 fourcc: 'BVID', possibly a file sub-type
bytes 16-31 unknown
bytes 32-35 total number of video frames in file
bytes 36-39 video width
bytes 40-43 video height
bytes 44-47 possibly video depth (8-bit, palettized video)

There are 2 known versions: 1 and 2. The version 1 file proceeds as follows:

bytes 48-55 unknown

A version 2 file header proceeds with a BASF chunk which appears to have an unknown 8-byte payload. This is followed by a 'ASF\0' chunk which has an 0x18-byte payload. Bytes 8-15 of this payload appear to be the 8 bytes of the DOS base filename (e.g., file 'foo.brp' would contain 'foo' with 5 0s after). The rest of the payload is unknown. The next 4 bytes of a v2 header contains the length of the remainder of the header, minus 12 bytes. An audio sample rate sits occupies 2 bytes in the space 16 bytes after these four bytes. The rest of the header is unknown. However, the presence of what looks like an audio sampling rate strongly indicates that these files carry audio data.

Following the header is a 'PAL8' chunk (presumably, this would only occur in a 8-bit file if other bit depth files exist). This chunk contains full 8-bit RGB palette triplets.

The video frames follow the header and palette chunk. In F/X Fighter, there are 2 frame types: AVCF and ALCD. Based on their relative occurrence frequencies, AVCF frames may be intracoded while ALCD frames
are intercoded.

The following chunk types are currently known:

PAL8 8-bit palette, range 0-255
MAD1 contains sub-chunks using different codecs like RLE-compression
AVCF vector quantized keyframe (similar to the algorithm used in Creature Shock)
ALCD vector quantized deltaframe

In the examined files only either the MAD1 or the AVCF/ALCD types are used throughout one file.

Details of the audio compression scheme are currently unknown. The audio chunks are apparently not preceeded by an ASCII chunk type name.

[[Category:Game Formats]]

RoQ

2006-02-15T08:24:58Z

John doe: Little info about RoQ differences in The 11th Hour and Clandestiny

* Extensions: roq
* Company: [[Id Software]]
* Technical Description: [http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt]
* Official Encoder (win32): [ftp://ftp.idsoftware.com/idstuff/quake3/tools/roq.zip ftp://ftp.idsoftware.com/idstuff/quake3/tools/roq.zip]

RoQ is a full motion video format originally developed for [http://www.mobygames.com/game/dos/11th-hour The 11th Hour] by Graeme Devine. The format was later used as the FMV format for [http://www.mobygames.com/game/windows/quake-iii-arena Quake III: Arena] and derivative games.

According to excerpts of Devine's ''11th Hour'' development journal published in Wired at [http://www.wired.com/wired/archive/3.08/shipping.html http://www.wired.com/wired/archive/3.08/shipping.html], the RoQ format was named after Devine's newborn daughter, Roqee.

Switchblade roq encoder with source can be found here http://icculus.org/homepages/riot/

The RoQ files used in The 11th Hour and Clandestiny are a superset of the format used in Q3-Engine based games. They include chunk types not used in Q3 and supported in the current impelentations of the format. These two games, among other differences, also include support for JPEG encoded keyframes.

== Games Using RoQ ==

These games are known to use the RoQ format, often because they are based on the ''Quake III'' engine.

* [http://www.mobygames.com/game/dos/11th-hour The 11th Hour]
* [http://www.mobygames.com/game/windows/american-mcgees-alice American McGee's Alice]
* [http://www.mobygames.com/game/windows/quake-iii-arena Quake III: Arena]
* [http://www.mobygames.com/game/windows/return-to-castle-wolfenstein Return To Castle Wolfenstein]
* [http://www.mobygames.com/game/windows/star-wars-jedi-knight-ii-jedi-outcast Star Wars: Jedi Knight II - Jedi Outcast]
* [http://www.mobygames.com/game/windows/clandestiny Clandestiny]

[[Category:Game Formats]]

RoQ

2006-02-15T08:20:19Z

John doe: added Clandestiny to /* Game Using RoQ */

* Extensions: roq
* Company: [[Id Software]]
* Technical Description: [http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt]
* Official Encoder (win32): [ftp://ftp.idsoftware.com/idstuff/quake3/tools/roq.zip ftp://ftp.idsoftware.com/idstuff/quake3/tools/roq.zip]

RoQ is a full motion video format originally developed for [http://www.mobygames.com/game/dos/11th-hour The 11th Hour] by Graeme Devine. The format was later used as the FMV format for [http://www.mobygames.com/game/windows/quake-iii-arena Quake III: Arena] and derivative games.

According to excerpts of Devine's ''11th Hour'' development journal published in Wired at [http://www.wired.com/wired/archive/3.08/shipping.html http://www.wired.com/wired/archive/3.08/shipping.html], the RoQ format was named after Devine's newborn daughter, Roqee.

Switchblade roq encoder with source can be found here http://icculus.org/homepages/riot/

== Games Using RoQ ==

These games are known to use the RoQ format, often because they are based on the ''Quake III'' engine.

* [http://www.mobygames.com/game/dos/11th-hour The 11th Hour]
* [http://www.mobygames.com/game/windows/american-mcgees-alice American McGee's Alice]
* [http://www.mobygames.com/game/windows/quake-iii-arena Quake III: Arena]
* [http://www.mobygames.com/game/windows/return-to-castle-wolfenstein Return To Castle Wolfenstein]
* [http://www.mobygames.com/game/windows/star-wars-jedi-knight-ii-jedi-outcast Star Wars: Jedi Knight II - Jedi Outcast]
* [http://www.mobygames.com/game/windows/clandestiny Clandestiny]

[[Category:Game Formats]]

MUX

2006-02-15T08:17:19Z

John doe: /* Games That Use MUX */

* Extension: mux

MUX is a full motion video format used in a small number of computer games. The format packages raw, unsigned, 8-bit PCM audio along with a custom video coding format.

== File Format ==

All multi-byte numbers are little endian. The file format is laid out as follows:

bytes 0-27 unknown
bytes 28-29 video width
bytes 30-31 video height
bytes 32-16383 frame offset table

Each frame offset is 32 bits. There is enough space in the chunk offset table for 4087 media chunks. The top 2 bits of each offset always appear to be 1 (so the top byte of the chunk is always 0xC0), so these are probably flags of some sort. The last entry in the table is all 1s (0xFFFFFFFF) and the remainder of the table is all 0s.

Frames contain 1 or more chunks, each of which are formatted in a manner that is reminiscent of the [[Flic Video|Autodesk FLIC format]]:

bytes 0-1 chunk type
bytes 2-5 chunk size, not including this 6-byte header
bytes 6.. chunk payload

Known chunk types appear to include:

0007 unsigned, 8-bit PCM audio
0070 apparently a palette chunk, 0x300 (768) bytes, and each
component is 8 bits (not 6 bits, like VGA palettes are
normally stored)
006F video chunk
0005 frame count: 2-byte payload contains frame number

== Video Format ==

The corresponding video coding format is presently unknown.

== Games That Use MUX ==

These games are known to use MUX files for FMV:

* [http://www.mobygames.com/game/dos/chaos-control Chaos Control]
* [http://www.mobygames.com/game/dos/prisoner-of-ice Prisoner of Ice]
* [http://www.mobygames.com/game/dos/time-gate-knights-chase Time Gate: Knight's Chase]

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]
[[Category:Game Formats]]