Note: LucasForums Archive Project
The content here was reconstructed by scraping the Wayback Machine in an effort to restore some of what was lost when LF went down. The LucasForums Archive Project claims no ownership over the content or assets that were archived on archive.org.

This project is meant for research purposes only.

preliminary SAN documentation

Page: 1 of 1
 khalek
02-27-2003, 7:44 AM
#1
Mike Melanson is documenting the SAN format based on the ScummVM source, but its on hold for the moment as he's working on something else.

He has done some brief notes so far though.


Multimedia format research based on ScummVM

* a chunked multimedia format possibly with several variations
* multi-byte numbers are little endian (always?)
* no: the chunk lengths are big endian
* chunks are marked by FOURCCs; known FOURCCs:
- ANIM
- AHDR
- FRME
- NPAL
- FOBJ
- PSAD
- TRES
- XPAL
- LACT
- STOR
- FTCH
- SKIP
- STRK
- SMRK
- SHDR
- SDAT
- SAUD
- iMUS
- FRMT
- TEXT
- REGN
- STOP
- MAP_
- DATA
- ETRS
* carries a payload comprised of different chunk types
* these chunk types are known:
- codec 1
- codec 37
- codec 44
- codec 47

* codec 1: RLE encoding:
- for each line in image height:
- 16-bit number indicates encoded line size
- while there are still encoded data bytes for this line:
- next byte is code
- length = code / 2 + 1
- if bit 0 of code is set:
- value = next byte
- if value is 0:
- skip (length) pixels in output
- else:
- put (value) in output (length) times
- else:
- for each count in length:
- value = next byte
- if value is 0:
- skip pixel in output
- else:
- put value in output


* codec 37:
- assign width and height
- assign bw as block width
- assign bh as block height
- codec must operate on 4x4 blocks
- assign pitch as block width * 4 (not the same as width necessarily since
block width is rounded up to nearest multiple of 4)
- assign chunk size as size of input chunk - 14
- allocate a buffer with that size
- read chunk_size bytes into new buffer
- sequence number LE_16 @ chunk[2]
- decoded size is LE_32 @ chunk[4]
- maskflags = chunk[12]
- make table with pitch and chunk_buffer[1] as index:
- index *= 255
- if (index + 254 < sizeof(table) / 2)
- assert error condition
- for i = 0..255
- j = (i + index) * 2
- offsettable[i] = maketable_bytes[j+1] * pitch + maketable_bytes[j]
- if (chunk[0] == 0)

- else if (chunk[0] == 1)
- "missing opcode codec47" (?)

- else if (chunk[0] == 2)

- else if (chunk[0] == 3)

- else if (chunk[0] == 4)


* codec 44:
- iterate through the encoded chunk from 0 to size - 14 (?):
- size of encoded line = next LE_16 in chunk
- while size is not 0:
- count = next byte
- pixel = next byte
- put (pixel) in output (count) times
- if size of line is not 0 at this point:
- count = next LE_16 + 1
- copy (count) pixels from encoded stream to output
- at the end of line, output buffer rewinds by one pixel (?)


* codec 47:
- chunk size = size of chunk passed in minus 14 bytes
- sequence number = first LE_16 of chunk
- encoded graphic data begins at chunk + 26
- the bytes at chunk[12] and chunk[13] serve as initializers for
deltabufs[0] and [1] respectively


What do people think? When its finished this document should allow people to write their own smush player/decoder/whatever from it.

When this is done he is probably then going to make mplayer and xine play smush files yay :)

http://www.pcisys.net/~melanson/codecs/) is a list of some similiar documents he's done in the past.
 bgbennyboy
02-27-2003, 12:03 PM
#2
I think thats nifty as hell, very cool.
 john_doe
02-27-2003, 12:29 PM
#3
Very cool.
Back in '99/'00 when I worked on the Smush files I wanted to write something like that, too, but due to a lack of time and knowledge of the advanced codecs (I only had figured out the RLE variants then) it never came that far.
Good to see someone else does this now :)

(And now we need specs for CMI's version so we can make a Avi->Smush coverter for use with the ScummIDE when it comes out somewhen the next years (no sarcasm intended))
 khalek
02-27-2003, 5:20 PM
#4
comi uses codec47 I believe, if you don't feel like waiting you could always look at the ScummVM source yourself :)

Although the specs will be geared towards decoding not encoding.

For ScummIDE/homegrown games I often wonder if a fresh v8 only codebase for scummvm with support for things like divx, png images, mp3/vorbis audio might be the way to go. This way you don't need all the baggage and sanity checks from the older scumm games.
 ryangs
02-27-2003, 8:00 PM
#5
This sounds interesting. Does this mean I'll be able to convert the SMUSH videos from Behind the Magic into AVI's? (Or can I already do this? I've been looking for about an hour now around the internet and haven't found anything yet...)
 khalek
02-27-2003, 11:04 PM
#6
If someone writes a converter (or you could use mplayer if you use some form of unix when it hopefully gets smush support) yes. Assuming it uses the same codecs as the games that ScummVM supports.

Some rather brief notes I threw together on smush including the known games/titles that use it can be found here:
http://users.bigpond.net.au/tgray2/smush.txt)
 ryangs
02-28-2003, 9:37 AM
#7
Is coding a converter really that difficult? I'd assume if you can decode the movie, then writing it to an AVI, or even a series of bitmaps, wouldn't be too hard.

I guess decoding it must be the hard part. :)
Page: 1 of 1