| Home | Forums | What's new | Resources | |
| PSX str format on saturn |
| luisoft - May 10, 2011 |
| 1 | 2 | Next> |
 |
luisoft | May 10, 2011 | ||
|
Its possible create a video player for saturn with the open source specification of str format? ( psx fmv format ) http://jpsxdec.googlecode.com/files/PlayStation1_S... dual sh2 can decompress psx fmv? | ||||
 |
antime | May 10, 2011 | ||
| There shouldn't be any technical reasons preventing it, someone just has to make a decoder. | ||||
 |
ExCyber | May 10, 2011 | ||
| Do you think the IDCT (which I think would be the main CPU-eating part) can be done on the SCU DSP, or is it not big/fast enough to handle that? | ||||
 |
DamageX | May 21, 2011 | ||
| I was just thinking maybe if the resolution is cut down a bit, say decoding only 4x8 or 4x4 pixels in a block, then maybe the Saturn can scrape together enough power to keep up? YUV->RGB conversion might as well be done with a lookup table. Knock Y down to 6 bits and U/V to 5 bits each and pull a 15-bit RGB value out of a 128KB table. Since there isn`t enough VRAM to do double buffering with a 32bpp screen anyway. Haven`t looked at the audio yet, I wonder if the 68K could decode it. | ||||
|
DamageX | Jun 18, 2011 | ||
|
I`m having a hard time even decoding the bitstream fast enough without iDCTs. The Playstation CPU manages it somehow, so maybe I just suck. But check this out, it shows video from a .STR file in RAM by using the DC coefficients only: http://www.hyakushiki.net/str3.zip... | ||||
 |
Chilly Willy | Jun 19, 2011 | ||||
The PSX CPU doesn't manage it somehow - it has extra hardware to decode the stream... just as the PS2 has extra hardware to decode MPEG2 data. | ||||||
|
ExCyber | Jun 19, 2011 | ||
| It's been a while since I've looked at it, but I'm pretty sure that the MDEC only decodes batches of macroblocks, i.e. the stream itself is still unpacked by the CPU first. | ||||
|
Chilly Willy | Jun 19, 2011 | ||||
I haven't looked at it in a while either, but the PS2 has hardware to help unpack the bitstream, so I'm guessing the MDEC does as well. I don't remember emulators passing an unpacked stream to the MDEC functions... I THINK it got a raw stream. I could be wrong, though. A 33MHz MIPS shouldn't have any trouble decoding the bitstream, but you need the CPU doing more than just decoding video streams, so it would make sense to put hardware to at least help with that in the MDEC. | ||||||
|
ExCyber | Jun 19, 2011 | ||
| I don't see any stream-unpacking code in PCSX's MDEC code, and some other documents strewn about on the web suggest pretty strongly that developers were able to make up their own bitstream formats (some of which reportedly use custom Huffman codes. | ||||
|
Chilly Willy | Jun 21, 2011 | ||||
That would certainly imply the CPU decodes the stream.  | ||||||
 |
m35 | Jun 23, 2011 | ||
|
Indeed the PlayStation MDEC chip only handled streams of 16-bit MDEC codes. There was no hardware support for parsing the bitstreams (3 distinct variations have been found in the wild and will soon all be documented...). It's hard to tell what bit parsing approach you've used in the ASM code. I've written about a couple methods... that should be pretty fast. If C/C++ compilation is possible, a C++ implementation is available in the Q-gears repo... (the code has been put together into a self-contained program in the download posted here...). Reevengi... might also include a C version. Both implementations get the colors wrong..., so you might want to tweak them for correct output. | ||||
|
ExCyber | Jun 23, 2011 | ||
| Has anyone gotten C++ working on Saturn? I've heard of people building sh-elf-g++ as part of a Saturn toolchain, but I don't recall hearing of any Saturn programs successfully built with it. | ||||
|
DamageX | Jun 23, 2011 | ||
|
My method was to read two bits and then check a lookup table to see whether the resulting value is valid, if so the value read from the table contains the coefficient/run of zeros, or if not, read another bit and check the lookup table again, etc. I found that I can replace this: ; mov #0,r0 ; sub r3,r0 ; mov r0,r3 with: neg r3,r3 (duh) and code alignment might be able to gain something but other than that I`m short on ideas. Maybe a large unwieldy method is needed, because a data rate of 300KB/s doesn`t allow a lot of cycles for processing one bit at a time. Perhaps a jump table with a series of routines for decoding from each position within the word. | ||||
|
Chilly Willy | Jun 24, 2011 | ||||
I've got C++ working on the MD and 32X. I can apply much of the 32X coding towards the Saturn. I meant to make a toolkit for the Saturn anyway so I could do some homebrew. | ||||||
|
m35 | Jun 25, 2011 | ||
| Tried my hand using Approach 3... in C (just bit parsing) in case you're interested link.... It needs more memory due to the 2048 byte lookup table. I don't know of any (theoretically) faster approach, so I'm curious if it really is fast (enough). | ||||
 |
timothyja | Jun 10, 2025 | ||
I didn't try the parsing code by m35 above but that part wasn't a huge bottleneck with my code (@ around 3 v-blanks to complete) compared to other parts. IDCT decoding and YUV to RGB take around 16-18 v-blanks to complete. Reading from cd was also taking 4 but this is because I didn't implement async reads. Note all this is done a single sh-2. But even using dsp and the second sh-2 there is a big performance gap to get it from 3fps to 15fps.
| ||||
 |
TrekkiesUnite118 | Jun 10, 2025 | ||
| Try taking a look at what Grandia does. It uses it's own custom DCT codec and hands off the YUV to RGB conversion to the SCU-DSP. They also ran at lower vertical resolutions and stretched it with VDP2's scaling features. | ||||
| 1 | 2 | Next> |