MovieMan: lets write the technical stuff

Sega

2007-03-12T02:36:19Z

MovieMan: it's a four cc first and a company second

Sega is a [[FourCC]] indicating [[Cinepak For Sega]] video.
Sega is also the name of a [[Sega (Company)|company]] involved in video game production.

The FourCC 'Seg4' is believed to be a variation of this format.

[[Category:Video FourCCs]]

HNM (1)

2007-03-12T02:24:17Z

MovieMan: company name, improve english

HNM 1, developed and used by Cryo Interactive, is a second generation FMV format. It operates in fixed 320x200x256 resolution.

All numbers are litte endian.

== File Structure ==

File consist of series of chunks, where all single frame related chunks (e.g.
it's video and audio portion) enclosed in a "superchunks".

Each file begins with a header chunk, carrying palette and superchunk offsets
table:
word header_size - size of this header chunk
byte palette - palette block
byte padding[] - zero or more 0xFF bytes of padding
dword offsets[] - 32-bit offsets of each superchunk, to the end of header chunk.
All offsets are relative to the first superchunk.
Last table entry points to the end of file.

* It is not neccessary to use offsets table to (quickly) navigate through the file. All superchunks comes without gaps inbetween.

Header chunk followed by one or more frame superchunks. Superchunk format:
word superchunk_size - size of the whole superchunk
byte chunk1[]
... - zero or more typed chunks
byte chunkN[]
byte videoframe - video chunk to the end of superchunk
As soon as videoframe chunk encountered and processed, decoder should continue to the next superchunk.

Typed chunk format:
word chunk_tag - [[TwoCC]] chunk id
word chunk_size - size of the chunk
byte data[chunk_size-4] - chunk data of (chunk_size-4) bytes total

== Palette Block ==

Palette block contains one or more palette ranges to update.
byte start - index of the first entry to update
byte count - number of entries to update (0 means 256)
byte rgb[count*3] - RGB triplets of the new palette

Start and count both set to 0xFF indicates end of the palette block. Otherwise, change specified colors and process to the next range update block.

== Typed chunks ==
=== pl Chunk ===

New palette block. See description above.

=== sd Chunk ===

Sound data. Contains complete [[VOC]] file splitted over several blocks.

=== pt Chunk ===

Game related, ignore.

=== kl Chunk ===

Collision map? Game related, ignore.

== Video Chunk ==

Unlike typed chunks, video chunk has no standard chunk header, thus, it's the last chunk of superblock. It has at least following 4-byte header in bits:
0..8 width - width of the frame
9 flag1 - supposedly, indicates video data presence
10 flag2 - supposedly, indicates that the frame is not overlayed
12..14 unused - you can use these (zero) bits to distinguish this chunk from typed ones
15 flag3 - rarely seen set on some frames, purpose not yet known
16..23 height - height of the frame
24..31 mode - frame rendering mode
* Each new frame may update only partial area of actual 320x200 viewport.
* Zero frame width/height indicates that video is not changed from the previous frame, thus, no any video data follows this header.
* Mode 0xFE renders whole unpacked frame over previous frame.
* Mode 0xFF overlays unpacked frame with previous frame, it's pixels with color index 0 indicates transparency.

== Video Decompression ==

If video height is non-zero, frame chunks continues with actual compressed frame data. It may be either legacy LZ-compressed raster or RLE-encoded overlay frame.

First, calculate sum of the first 6 bytes of the frame data. Depending on the calculated value, choose apropriate method.

=== Video Block 171 ===

A keyframe. Unpack whole block using following algorithm (same algorithm used to decode some other game's resources as well).

First, reinterpret 6-byte header (the one you've calculated checksum of before) as follows:
word unpacked_len - size of the unpacked data
byte zero - should be zero
word packed_len - size of the packed data, including this header
byte salt - adjust checksum to 171 (0xAB)

Next, perform actual decompression:
Initialize bit-reader with 16-bits internal queue. When you need to take next bit from queue but it's already fully depleted, refill it with next 16-bits value from the stream. Straw queue bits from lowest to highest.
repeat
get next bit of the queue
if bit is non-zero
copy next byte of the input to the output
else
get next bit of the queue
if bit is non-zero
count = next 3 bits of the input
offset = next 13 bits of the input minus 8192
if count is zero
count = next 8 bits of the input
if count is zero
finish the unpacking
else
count = next bit of the queue * 2 + next bit of the queue
offset = next 8 bits of the input minus 256
copy count bytes at (output + offset) to the output

=== Video Block 172 ===

Looks like it's not used anywhere. TBD.

=== Video Block 173 ===

This is an overlay block. Reinterpret block header as:
word frame_size - size of the final unpacked frame (in bytes)
word codebook_size - size of the unpacked frame codebook
byte flags - bit 2 : use zero x/y coordinates
bit 6 : use color base 128, 0 otherwise
bit 7 : compression method (long runs)
byte salt - fixes up header's checksum to be 173 (0xAD)
If flags bit 2 is zero, read extra block's x and y coordinates, 16 bits each. Otherwise, assume them both set to zero.

Following decompression routines use slightly modified bit-reader. Unlike 171 decompression, now it takes bits starting from the highest one. Other rules remains the same.

After processing the header, unpack LZ-compressed codebook as follows:
repeat while codebook_size of output not generated
tag = next byte of the input
if bit 7 of tag is set
if length_code not yet encountered or already depleted
length_code = next 8 byte of the input
temp = top nibble of the length_code
else
temp = low nibble of the length_code
assume length_code depleted
offset = 7 bits of tag merged with lowest bit of temp
count = top 3 bits of temp plus 2
copy count bytes at (output - offset - 1) to the output
else
if tag is non-zero
tag = tag + color base (see flags bit 6)
output tag

Immediately after codebook rle-compressed raster begins. Decode it as follows:
if using long runs method (see flags above)
repeat while frame_size of output not generated
while next bit is zero
ouput = next byte of codebook
pixel = next byte of codebook
if next bit is zero
if length_code not yet encountered or already depleted
length_code = next byte of the input
length = top nibble of the length_code
else
length = low nibble of the length_code
assume length_code depleted
if length is zero
length = next byte of the input plus 16
fill next length + 4 bytes of the output with pixel
else
if next bit is zero
fill next 2 bytes of the output with pixel
else
if next bit is zero
fill next 3 bytes of the output with pixel
else
fill next 4 bytes of the output with pixel
else (short runs, same as above, but reordered)
repeat while frame_size of output not generated
while next bit is zero
ouput = next byte of codebook
pixel = next byte of codebook
if next bit is zero
fill next 2 bytes of the output with pixel
else
if next bit is zero
fill next 3 bytes of the output with pixel
else
if next bit is zero
fill next 4 bytes of the output with pixel
else
if length_code not yet encountered or already depleted
length_code = next byte of the input
length = top nibble of the length_code
else
length = low nibble of the length_code
assume length_code depleted
if length is zero
length = next byte of the input plus 16
fill next length + 4 bytes of the output with pixel

== Known issues ==
* Many movies from the game "Dune" do not have their own palettes and thereby reuse the current in-game palette.
* For some unknown reasons AABBBBB.HNM file from Dune decodes incorrectly.

== Games using HNM (1) ==
* [http://www.mobygames.com/game/dos/commander-blood Commander Blood]
* [http://www.mobygames.com/game/dragon-lore-the-legend-begins Dragon Lore: The Legend Begins]
* [http://www.mobygames.com/game/dos/dune Dune (CD)]
* [http://www.mobygames.com/game/dos/lost-eden Lost Eden]
* [http://www.mobygames.com/game/dos/megarace MegaRace]

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

Nintendo

2007-03-12T02:19:35Z

MovieMan: easier to read

* Website: http://www.nintendo.com/

Nintendo is a prevalent company in the video game business. It was only as recent as 2001, with the release of the [[Nintendo GameCube]], that the company released a video game console with [[:Category:Optical Multimedia Formats|optical storage]] whose games prominently featured [[FMV]].

[[Category:Multimedia-related Companies]]

Xvid

2007-03-12T02:16:21Z

MovieMan: isn't XviD a codec?

* Website: [http://xvid.org http://xvid.org]

XviD is an open source implementation of [[ISO MPEG-4]] for both encoding and decoding.

[[Category:Video Codecs]]

Xvid

2007-03-12T02:13:38Z

MovieMan: its open source

* Website: [http://xvid.org http://xvid.org]

XviD is an open source implementation of [[ISO MPEG-4]].

[[Category:Multimedia Programs]]