forums.ps2dev.org

[Kojima]

Hi, I was just wondering what are my options for real time video playback in my app?
It's purely for the intro movie and perhaps cut scenes.

My artist sent me the file in mov format, which I gather is not psp friendly, so what formats libs should we be aimming for? Or do I have to write my own decoder(Gasp!)?

Thanks.

[Raphael]

There are several open source video decoders out there. XVid, OGG, ffmpeg... you name it. Stick with one of those and convert your video material into the appropriate format on your PC. For only very small intros and alike you could possibly even just use something simple like mng or flic.
You should note though, that these decoders most likely aren't well suited for such low-end hardware and need a lot of optimizations to get smooth playback (as it was needed with pmp mod).

[Kojima]

Thanks for the options, but are there any already ported to psp do you know? Or are the only ports internal to the media players etc?

I'm not against porting one myself, but you know, for something so trivial (Intro movie) I'd rather not spend a month coding it :)

[Raphael]

AFAIK, no codec was ported as such to the psp, so you're stuck. Only real port I know of is ffmpeg inside pmp mod/psplayermt and that's probably more of an overkill for only intro animations (?).
I'd really suggest sticking with something simple like mng, that should be easy to port and is also easy to implement (though you have bigger animation files).

[jockyw2001]

Use ffmpeg or mencoder to reencode the clip's elementary video and audio streams. Video to mpeg4 or avc and audio to mp3. Alternatively ask your mm guy to deliver a mpeg4+mp3 or a avc+mp3 file (.avi or .mp4).

Then mux the resulting streams to pmp format with pmp muxer and integrate pmp mod 2.01 or pmp mod avc 1.02 sourcecode in your app to do the playback.

PS: looking at your posting frequency, it seems you are the fastest developing developer :)

[Kojima]

When you say mng, do you mean the sister format of png that supports animations? It's the only thing I can find called mng.

Seems decent, but I see what you mean about file size when every frame = 20/30k, but with a 1gig mem card a few anims shouldn't be too big to worry about.
I welcome any other suggestions from other people, like an easy to port lib for windows.


Also, one important question if I do port this (I'll release it for everyone to use btw, no reason to keep it to myself) is how would you suggest blitting the video frame to vpu?

I could easily do it using pspgl, but on windows this kind of software to vid mem to texture blits are really slow, even on g5s. How is the bandwidth on the psp?
Can I blit directly to video ram like I did in my raycaster lib?(In releases section.)

Jocky, either that or I just talk more crap than anyone else :)

[Kojima]

I've decided it would be fun to write my own format and encoder on the pc and write a decoder on the psp.
It'll probably be similar to mng(I.e zlib compression) but I'll release it soon for everyone to use. I'd love to hear any suggestions you may have for it.

[Raphael]

Yes, with mng I was reffering to the Multi-Networks-Graphics format.

Well, you have one other possibility, that is to use the internal AVC decoding of the psp. This would solve pretty much all problems at once - regarding file size, implementation effort and performance. You could either take the source from pmf player or from pmp mod avc for the decoding (though the audio decoding is done via ffmpeg, that's for pmp mod avc at least, so you probably want to change that with an other approach like at3 or something?).

If you really want to go for your own encoding, I'd really suggest you use at least the simplest compression schemes from mpeg4 codecs. That would be doing a DCT/quantization on blocks of 8x8 or (better) 4x4 pixels (the latter could possibly even gain from vfpu usage) and doing delta-frame encoding most of the time (only encode the difference pixels to the previous frame, so on low motion scenes this gives pretty good compression already).
Combining this with some zlib/gzip compression might lead to some already good starting compression, though that's not much more then mng does.

For the blitting, it's probably best to decode each frame to a buffer in sys ram and then copy the buffer to vram, or better yet, simply use a sceGuSetFrameBuffer call like in pmp mod. Doing direct writing to VRAM is much better than on PC (relative to the overall performance), but still not recommended.

If you got more questions, you're welcome :)

[Kojima]

Thanks for the ideas, it's somewhat similar to what I've just knocked up.

Here's how I do it, please comment on whether it's worth it or not.

As this is my first ever encoder for animations I wanted to do something relatively simple so it didn't grow beyond my control and ultimately fail so I did this,

for each input video convert to 256x256 frame ( A good texture size for psp )
then for each frame split it up into 16x16 chunks, which gives you 16*16*16 sized chunks, a good size I thought. Then compress each chunk with zlib.
I call each chunk a cell. and each cell is given a color weight that is computed based on color change since the last frame.
If the weight goes over a certain threashold, it is then encoded into the file, if not, a simple 4 byte 'use last frame chunk' id is given.

So on playback, it creates a blank cell, reads in every cell from the frame, then displays, then next frame, only changed cells are read.

So far the windows size(The encoder) is nearly complete, so it's just the psp implentation.

I do have on question, regarding zlib, is it similar to the zlib module I use now?

now I just have two functions, Compress and uncompress, each take dest/src/src len/dst len. I recall a C++ version of zlib being this straight forward. IS the psp version similar/compatible with this version of zlib I'm using?

[Raphael]

[Kojima]

Yeah it's just a record of how much change has occured since the last frame.
But I was aware of the problem you speak of, the gradual change, so to compensate, if a frame cell has no change and is not to be saved, I overwrite the last changed cell into it's memory, so the next check
is with the original cell used, not the rejected cell.

Check my thread for a demo, it worked pretty well, and more remarkbly worked first run on the psp. A first for me :)

Thanks for your help.

[Raphael]

[Kojima]

Yeah that's because I used an old avi lib of mine, and i never did get around to returning frame speed. so to add support for that i would need to get my old project compiling again. I'm sure you know all too well how much of a nightmare it is getting an old project to compile again :)

[Raphael]

Hehe, you tell it ;)