MVE format info needed

[shaktazuki]

Dear Descent community:

If anyone knows of an official description of the MVE file format, can you forward it to me at shaktazuki at gmail dot com? I am aware of the hacked description floating around, but I'm having problems implementing a player based on that description, and nobody seems willing or able to assist me (and FFmpeg doesn't compile on my Win32 machine).

Thanks in advance for any help.

[Pumo]

I don't know of any official description for MVE format, but if you want an MVE player i remember that Total Video Player/Converter supports Interplay MVE.

[Duper]

it was never officially released. D2 XL lets you watch the vids all you want.

[The Lion]

Total Video Converter is just a rip-off of FFmpeg.

MPlayer also uses FFmpeg (legally), and it provides Windows
binaries in addition to source code/RPMs. How did you try to
compile FFmpeg anyway?

[shaktazuki]

I tried to compile it under MSVC++ 2008 and it doesn't go. Too much Unix/Linux specific stuff, missing headers, and the like, I guess.

And it's highly difficult to get the MVE specific stuff out of FFmpeg.

I've been analyzing the code for FFmpeg and the original hacker's MVE code to figure out where I'm going wrong and coming up blank. If I can figure out why I'm running out of video data prematurely during the decoding process, I can complete my implementation.

I've written a minimal video data driver to illustrate my problem.

Anyone interested in taking a look?

[The Lion]

Sounds like you need to compile using MinGW/MSYS instead.

Not sure what options you need to use to ensure binary compatibility
though (assuming you're still using msvc for the rest of your code).

[shaktazuki]

I appreciate the suggestion; however, I know nothing about MinGW etc, and I feel that the time and trouble of learning it are very probably greater than the time and effort of finding a solution to the problem facing my own implementation.

As I said, if anyone wants, I can forward a copy of my minimal-MVE video data driver as well as the original hacker's MVE code and format description, as well as a link to some samples of MVE files.

Late note: After 3 or 4 weeks of being stuck at this point, I think I have discovered the problem.

There are an extra 14 bytes at the beginning of the video data that the hacker did not see fit to document in his format description. Failing to strip these bytes out at the front leads to incorrect data reads.

GRRRRRR!!!!!!

[SuperSheep]

This is from when I was attempting to reverse engineer the MVE format from a couple of movies. I didn't get very far but perhaps it may help in some way. Sure hate for it to go to waste which is what it has been doing for 7 years now.

[MVE Header]

Offset Size-Bytes Description
-------- ---------------- ---------------------------------------
00h 22 MVE File ID - 'Interplay MVE File',1A,00,1A,00
16h 2 (word) Unknown-0100h
18h 4 (dword) Pointer? Some kind of Checksum
1Ah 4 (dword) Pointer? Used during Checksum calculation


Start of Chunk Data
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 0Ah - UNKNOWN]

Offset Size-Bytes Description
-------- ---------------- ---------------------------------------
00h 2 (word) Chunk Length
02h 1 (byte) Chunk Type - 0Ah
03h 1 (byte) Unknown

04h 2 (word) Width - Suggested
06h 2 (word) Height - Suggested
08h 2 (word) Unknown

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 05h - UNKNOWN]

Offset Size-Bytes Description
--------- ---------------- ----------------------------------------
00h 2 (word) Chunk Length
02h 1 (byte) Chunk Type - 05h
03h 1 (byte) Unknown

04h 2 (word) Unknown
06h 2 (word) Unknown
08h 2 (word) Unknown
0Ah 2 (word) Unknown

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 0Ch - PALETTE]

Offset Size\\Bytes Description
--------- ---------------- ----------------------------------------
00h 2 (word) Chunk Length
02h 1 (byte) Chunk Type - 0Ch
03h 1 (byte) Unknown

04h 2 (word) First Palette Entry
06h 2 (word) Number of Palette Entries
08h NumPalEntries*3 Palette- R,G,B bytes. Aligned to byte boundary

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 01h - READMVENOW]

Offset Size\\Bytes Description
--------- ---------------- ----------------------------------------
00h 2 (word) Chunk Length, Probably always 0
02h 1 (byte) ChunkType - 01h
03h 1 (byte) Unknown

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 03h - CREATESOUNDBUFFER]

Offset Size\\Bytes Description
--------- ---------------- ----------------------------------------
00h 2 (word) Chunk Length, Probably always 0
02h 1 (byte) ChunkType - 03h
03h 1 (byte) TypeBufferSize (0-2 Bytes used for Sound Buffer Size, 1-4 Bytes used)

04h 2 (word) Unknown
06h 2 (word) Bytes Per Sample, 1 or 2. This determines Number of Channels as
if you have 1 Byte per Sample then you have 2 channels. 2 Bytes per channel
and you have 1 channel.
08h 2 (word) Samples Per Second
0Ah 2 or 4 (word or dword *Depends on TypeBufferSize) Sound Buffer Size

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 06h - CREATEFRAME]

Offset Size\\Bytes Description
--------- ---------------- ----------------------------------------
00h 2 (word) Chunk Length, Probably always 0
02h 1 (byte) ChunkType - 03h
03h 1 (byte) TypeBufferSize (0-2 Bytes used for Sound Buffer Size, 1-4 Bytes used)

08h 2 (word) Unknown
0Ah 2 (word) Unknown
0Ch 2 (word) Unknown
0Eh 2 (word) Unknown
10h 1 (byte) 0-Swap Surfaces, 1-Don't swap surfaces
12h 4? (dword) data?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Chunk Type 08h/09h - READSOUNDDATA]

Offset Size\\Bytes Description
--------- ---------------- ----------------------------------------
00h 2 (word) Chunk Length, Probably always 0
02h 1 (byte) ChunkType - 03h
03h 1 (byte) TypeBufferSize (0-2 Bytes used for Sound Buffer Size, 1-4 Bytes used)



2Ch-2Dh bytes per row??? scanlines??? crashes when too large, looks bad when 2 small
2Eh-2Fh Possibly video related, crashes hard on most different values
30h-33h 01 00 00 00 -Same in 3 different movies
339h 0 - Padding to align next data to 2 byte boundary. Not present if alrighty at
2 byte boundary.
33Ah-33Dh 04 00 15 00 -Same in 3 different movies
33Eh-33Fh ??? When changed does nothing
340h-341h ??? When changed, does nothing
342h-343h 00 00 -Same in 3 different movies
344h-345h 01 00 -Same in 3 different movies
346h-349h Offset pointer possibly??? way smaller in sound movie
34Ah-34Bh Different. Causes failure if changed 0a-sound file, 06-non-sound file
34Ch Major crashola if changed
34Dh No idea??? 01-sound file, 00-non sound file. No its not nound on/off
doesn't matter if changed
34Eh ??? I think the sound/non sound files have parted company at this point
doesn't matter if changed
34Fh ??? In sound file, doesn't matter if changed
350h ??? sound file, doesn't matter if changed
351h ??? sound file, doesn't matter if changed
352h-353h samples per second
354h-355h Synchronization possibly? when lowered, frames stop and start
356h-357h 00 00 ??? when changed, crashola
358h-359h 00 00 ??? when changed, nothing
35Ah-35Bh 01 00 ??? don't friggin know
35Ch-35Dh offset to data 11 bytes after wav data from 35C
35Eh-35Fh 01 00 ??? see above comment
360h-361h offset to 4 bytes before end of wave data. Weird
362h-363h 08 00
364h-365h 00 00 -Frame number
366h-367h 01 00 ??? see previous comments
368h-369h length of Wave data
36Ah-xxh Wave data - Size of length of Wave data

[shaktazuki]

How do you guys go about figuring this stuff out? Do you have the most awesome disassembler in the world, or something?

Well, you'll probably like this one: http://wiki.multimedia.cx/index.php?title=Interplay_MVE

It's based on the original hacker's description.

Two inaccuracies: the size of the opcode segment is one word, not two, followed by the two bytes as described; and there are 14 mysterious bytes at the beginning of every video data segment, after the three word opcode descriptor. The video data is also padded to word boundary.

If I had a way to put attachments on this, I could post the anonymous hacker's code here too. D2-XL modified it somewhat and used it.

[SuperSheep]

I always wondered if the 1 word followed by 2 bytes was correct. lol

I got the information from looking at several different movies of various sizes, with and without audio using a program call frhed. It's basically an easy to use hex editor.

I would look for similarities between files and change data in places to see the effects. It is a long process and quite time consuming but alas, that is what must be done with no documentation. I also found this which aided a bit...

Re: Cutscene Res (Adam)

* To: fdl@warpcore.org
* Subject: Re: FDL: Cutscene Res (Adam)
* From: Adam Pletcher <adam@volition-inc.com>
* Date: Thu, 27 Aug 1998 16:50:31 -0500
* In-Reply-To: <http://ml.warpcore.org/fdl/199808/msg01180.html>
* Reply-To: fdl@warpcore.org
* Sender: owner-fdl@warpcore.org

At 02:59 PM 8/27/98 -0500, you wrote:
>You say you are willing to encode vids, right?

In my spare time, yeah. I can't guarantee quick turnaround on them, though.

> Well, noone has the time
>to do a major high action video. Also, not too many are concearned about
>the video resolution. Does the MVE format support 320x200 or anything
>else smaller than 640x480?

Yes, it does. Here are my official rules on submitting frames for MVE
compression:

- X dimension must be 640 or less, and a multiple of 16.
- Y dimension must be 320 or less, and a multiple of 8.
- frames must be 30 or 15 frames per second
- frames must be in 24 bit color (not 8, 16 or 32)
- frames must be given to me in TGA (Targa) format, compressed (meaning
they're RLE compressed, not raw... it's one of two flavors of the TGA
format compression).
- frames must be numbered sequentially in the format \"<whatever>XXXX.tga\"
where XXXX is a 4-digit number, starting with 0000, incremented by 1 each
frame, no gaps.

Regardless of frame size/shape, it will play back in 640x480 mode.

Soundtrack for the MVE (if any) needs to be a single 22k 16bit stereo VOC
file (not WAV).

>How big would the video be? (40 secs long, and with not much high
>action) At 320x200?

Amount of action doesn't matter. It would be about 6 megs at that resolution.

>(Correct me if I am wrong, but wasn't the D1 trailer only 20 MB because:
>A) it was widescreen, meaning top and bottom stayed same all the way
>through and/or B) it was 320x200)

It was smaller because it was 320x200, and used 8 bit color. FreeSpace
cutscenes use 16bit color. They're also twice the framerate, but that
doesn't add any size really.


--
Adam Pletcher
Volition, Inc.
adam@volition-inc.com
--------------------------------------------------------------------
****************FreeSpace Developer's Mailing List*******************
To unsubscribe from this list send e-mail to fdl-request@warpcore.org
with the BODY of the message containing \"unsubscribe\"
Read http://www.descent-freespace.com/lists/fdl for details!!

[shaktazuki]

Holy crap! Does that guy still work there?

I wonder if he'd release the official format description with source...

Well, if I can finish my project, I was thinking of writing a MVE compressor...

[update] It appears he hasn't got the goods. Drat.

[SuperSheep]

Found this... Might help if you can read the code...

http://fubar4.fubar.org/fs2netd/fs2_ope ... e/?C=M;O=A

[SuperSheep]

And another location...

http://svn.icculus.org/fs2open/trunk/fs ... /cutscene/

[shaktazuki]

Yes, that's based on the anonymous hacker's code. They haven't got the rights to it either; I checked

On the upside, I have finished my project. The downside is I have messed up somewhere in some video decoding operation (or two or three).

[Valin Halcyon]

If you get the D2X-XL source, it contains the MVE/L library we use.