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.
Psp VideoPlayback (Not media viewer)
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).
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).
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).
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
- Posts: 339
- Joined: Thu Sep 29, 2005 4:19 pm
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 :)
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 :)
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 :)
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 :)
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 :)
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 :)
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?
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?
Just always try as much as you feel capable of :)Kojima wrote: 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,
So far ok :)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.
Do I understand correctly, that your "color weight" is in some way a "delta information" which can reproduce the original cell, or is it just a measure of change?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.
If you only save difference information from every previous frame and skip some of these informations based on your 'weight', you need to be aware that if you don't compensate for that, you might get wrong results. Imagine you have a cell that changes only slightly for hundreds of frames, but where the changes sum up (a smooth fade/transition). So if the change is below your threshold for every single frame, you will lose this fade/transition.
You could compensate this by forcing to encode full cells after 16 frames or so for example.
I'm really curious to see your results :), though I believe you miss most compression unless you use some sort transformation and quantization of the color blocks (cells). But you could probably add that later on, depending on how clean you write your current implementation.
Yep, it's just a port of the official version zlib.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?
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.
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.
I just had a quick peek at it. You seem to miss information on playback speed in your file, so when you playback a file encoded at different fps than your default, you will get too fast or too slow playback. Apart from that, it's a nice base to work upon :)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.
Good luck