gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Quick question.

#22084 - Chris - Sun Jun 13, 2004 2:50 am

Hey, I was just wondering if anyone knew this:

I am thinking of switching my in-development game to this console. One issue is this: The game has 3D cutscenes, that are AVI files on the computer. They are quite large files. I wonder - will I be able to put these video clips on? I dont know if anyone knows, it's eary days, but this is a crucial issue.

-Chris

#22086 - Miked0801 - Sun Jun 13, 2004 3:08 am

Sure - with really, really good compression :) At least the DS has the horse power to do some decent algorithms to get 90%+ compression :)

#22096 - tepples - Sun Jun 13, 2004 6:50 am

License a GBA Video codec from Majesco and you'll probably be able to put FMV on both screens.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#22107 - ampz - Sun Jun 13, 2004 2:59 pm

DS carts are as large as 1Gbit (128MByte).

#22111 - Miked0801 - Sun Jun 13, 2004 3:46 pm

But why license something that you can do yourself for much cheaper? Of course, if you don't have time, then it makes sense. :)

#22133 - tepples - Sun Jun 13, 2004 8:34 pm

Miked0801 wrote:
But why license something that you can do yourself for much cheaper?

Because video is a patent minefield, and it might cost more to pay lawyers to verify that your video codec violates no patents than to actually develop the codec itself. When you outsource your codec, you're also outsourcing the legal work that went into it.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#22144 - Miked0801 - Sun Jun 13, 2004 9:21 pm

Nah, you just roll your own compression scheme. Compression isn't that hard of a concept if you take some time to study it. It's all about predicting what the next byte will be. If you can predict that next byte to even a 50% probability, you'll get 87.5% lossless compression. When 75% sure, that goes up to 95% (heck even 6.25% sure yields 50%.) With a bit of image smoothing/quantizing and before frame, after frame, and a few pixels of previous data for use as predictors, movie compression isn't that tough of a beast to conquer. It'd probably take me about 2 weeks to roll a scheme on the above idea that would be close to the video only side compression of Majescos codec. By close, I mean within a couple percentage points of there stuff which I estimate to be roughly 97-98% compression from the studies I've done. No reverse engineering, no LZW cheating (though in the US, the patent on it expired a couple months ago), just solid Huffman/Arithmetic algorithms with a good model.

#22149 - tepples - Sun Jun 13, 2004 9:37 pm

Even if you "roll your own", you may still run into a subsisting patent. Alexander Graham Bell beat Elisha Gray to the patent office for a broad patent on telephones[1], and Gray was barred from selling telephones without Bell's permission during the term of the patent even though he "rolled his own". For a more recent example, see the story of LZRW1.

[1] No, it wasn't "just by a couple hours"; the facts were more in Bell's favor than some shady "Patent Your Invention Right Now!" firms would have you think. Bell filed a finished patent app a couple hours before Gray filed a first draft called a "caveat".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#22153 - Miked0801 - Sun Jun 13, 2004 10:23 pm

Fair enough. But, if I follow that pages standards, I can't use any methods that are popular. A sticky area to be certain though.

#22157 - ampz - Mon Jun 14, 2004 12:19 am

There are free compression schemes...

#22175 - tepples - Mon Jun 14, 2004 4:24 am

The free video codecs such as Theora probably aren't designed for real-time decompression of 256x384 pixels within 67 MHz.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#22185 - ampz - Mon Jun 14, 2004 12:04 pm

No, but depending on the type of video, general purpose compression could be a alternative.
Compression will be nowhere near as good as with a video compression scheme, but at least it decreases the size of the video to some degree. Especially if there is lots of the same colors in the video.

#22204 - Miked0801 - Mon Jun 14, 2004 6:20 pm

Converting a 16-bit image to a palettized 4-bit image per frame and then using built in GBA routines will yield decent compression. I wanted better than that though :)

#22206 - keldon - Mon Jun 14, 2004 6:43 pm

well using a combination of creating area zones and matching pallettes and also generating the next frame using the previous frame is a pretty decent method for moving images.

#22208 - Miked0801 - Mon Jun 14, 2004 7:33 pm

You just described the basics of MPEG compression :)

#22209 - keldon - Mon Jun 14, 2004 8:15 pm

Miked0801 wrote:
You just described the basics of MPEG compression :)


yes, but I thought of that myself :) I honestly didn't know MPEG did that ??? But then again looking at them, it does look a little like it ...

#22218 - ampz - Tue Jun 15, 2004 12:05 am

You can implement a _very_ simple version of the above method if:
A: Your video is rendered or computer generated in some way (static objects in two adjacent frames are exactly identical).
and:
B: Only small portions of the screen is updated most of the time.

I belive MPEG can rotate, skew, scale, compress (change x/y relationship) and move picture elements (tiles) from one frame to another. Right? There must be some kind of filtering algorithms to smooth the edges between two tiles as well..

#22223 - Miked0801 - Tue Jun 15, 2004 1:46 am

I only said he had mentioned the basics :)

Still, averaging the pixel velocity between frames (1 value for all pixels instead of on a per 16x16 pixel matrix as MPEG) and using that as a predictor to the next screen with arithmetic compression will by itself yield in the neighborhood of 75% lossless compression. (On a computer generated scene where your not cutting from 1 area to the next or fading.) Add a little bit of logic for moving areas and some quantizing and you get Majesco level compression :)

#22237 - keldon - Tue Jun 15, 2004 11:20 am

Oh yes, that is of course the basics, other standard data compression algorithms are used in MPEG compression and Audio. But it's mainly a directional steer.