PMF Player

magiK · Post by **magiK** » Thu May 25, 2006 5:10 am

I guess the demo disc was good for something after all :)
The archive contains the sceMpeg lib stubs, the PMF Player module and a test app. Binaries for fw 1.5 are included as well. All the info was obtained by disassembly and sniffing with PSPLINK, but some things are still missing, like finding the resolution of the movie.
The test app will try to play a file named 'movie.pmf' from the root of the memory stick. It has no GUI but if someone wants to make one, fell free to do so.
A PMF file is actually some sort of MPEG-2 Program Stream containing AVC video and ATRAC3 audio elementary streams, yet all the MPEG-2 multiplexers I've tried seem to produce incompatible streams. Some PMF files have chapter information in their headers and some of the applications I've looked at show traces of a 'psmf' library that is used to interpret that information.

http://www.hypermagik.com/dl/pmfplayer10.rar

dot_blank · Post by **dot_blank** » Thu May 25, 2006 5:06 pm

very very nice :D
although your comments on some of the
prototypes are not exact and some even dont
show what return values are ...some have unknown
arguments but they do not say what to set as for
default ...but the test app works great thanx for
this very much ...im already using to playback
pmfs :)

moonlight · Post by **moonlight** » Thu May 25, 2006 9:01 pm

Good job!!

I was in the process of reversing the usage of the libmpeg, but i was having a lot of problems, it wasn't being as easy as the atrac3 one.

You have saved me a lot of time!!

I hope to see the stubs and headers soon in the pspsdk :)

jonny · Post by **jonny** » Fri May 26, 2006 12:56 am

wow great!

do you think we'll be able to get rid of the pmf format?

i was looking at

SceInt32 sceMpegAvcDecode(SceMpeg* Mpeg, SceMpegAu* pAu, SceInt32 iFrameWidth, ScePVoid pBuffer, SceInt32* iInit);

the only dependency from the pmf format seems the pAu parameter, maybe it's possible to fill it manually (maybe one of the fields is a pointer to raw frame data (there are too many "maybe" atm ... :))
(i can already mux avc in the pmp container and read raw video frames data ... do you understand where i'm trying to go? :)

many months ago i've made some tests in order to generate pmf files, but seems hard.
i was able to demux the video easly, but the pmf header, the audio and (iirc) additional obscure data muxed in the file make the pmf hard to generate.
(i should have the demuxer still around if someone want to take a look at how data is mixed in the pmf)

moonlight · Post by **moonlight** » Fri May 26, 2006 1:28 am

I've done a very simple gui for the player, based on the atrac3 player sample gui.

http://www.megaupload.com/?d=49PLOGXC

It's a bit lame, since it restarts itself after a file is played to avoid memory problems, but better than nothing ;)

Xcarecrow · Post by **Xcarecrow** » Fri May 26, 2006 8:28 am

Now only a pmf encoder is needed, and the perfect format pmf is ready. Best resolution, no 333mhz clock (to save battery), best quality, perfect.

magiK · Post by **magiK** » Sun May 28, 2006 7:08 am

jonny wrote:the only dependency from the pmf format seems the pAu parameter, maybe it's possible to fill it manually (maybe one of the fields is a pointer to raw frame data (there are too many "maybe" atm ... :))
(i can already mux avc in the pmp container and read raw video frames data ... do you understand where i'm trying to go? :)

After taking a closer look at the modules, I think I've got it. Here's a small sample that decodes a raw AVC stream straight to the frame buffer. The stream should have access unit delimiters. It turned out that the strange 0xBF stream inside the PMF's is actually a list of AVC AU sizes.
The sceMpegbase_BEA18F91 function uses sceDmacplusSc2MeLLI to copy the AU to some funny address 0x0004A000. Does anyone know more about that?

http://www.hypermagik.com/dl/avcdecme.rar
and a small AVC sample stream ripped from a pmf:
http://rapidshare.de/files/21552266/stream.e0.html

moonlight · Post by **moonlight** » Sun May 28, 2006 8:29 am

Perfect. We are closer to play our own AVC files 480x272 using the native psp functions :)

jonny · Post by **jonny** » Sun May 28, 2006 8:48 pm

!!!

starting making experiments :)

Post by **TyRaNiD** » Mon May 29, 2006 2:16 am

Magik, I am guessing the trick is in the name, that dmac function is copying data from SC (system controller i.e. the main cpu) to ME and that destination address is perfectly valid for the ME.

magiK · Post by **magiK** » Mon May 29, 2006 8:24 am

Further investigation showed that the stream must also contain buffering_period and pic_timing SEIs. I think that the Elecard's and MainConcept's AVC encoders are the only ones that output those SEIs into the stream. You can grab the Elecard encoder pack from here and use GraphEdit to create a compatible AVC stream. You should set the encoder to Main profile, Level 3, no b-frames, one reference frame and access unit delimiters enabled.

xxxstarmanxxx · Post by **xxxstarmanxxx** » Mon May 29, 2006 11:06 am

Hi magiK -

I'm getting very interested in where this is going over the last couple of days.

I just spent a couple of hours trying some graphs on a source file - but i'm not getting anywhere at the mo.

Have you successfully managed to reproduce a stream using graphedit?

If so - could you post your graph for me to do some testing with???

All the best

J.

magiK · Post by **magiK** » Tue May 30, 2006 4:16 am

xxxstarmanxxx: Take a look at this image (the scaler is resizing to 480x272).
A stream using those settings is decoded by the PSP at around 180 frames per second.

hroo772 · Post by **hroo772** » Tue May 30, 2006 8:44 am

magiK wrote:xxxstarmanxxx: Take a look at this image (the scaler is resizing to 480x272).
A stream using those settings is decoded by the PSP at around 180 frames per second.

Do you mean that this actually plays with the current PMF player? or at least will it play with the PMF player?

dot_blank · Post by **dot_blank** » Tue May 30, 2006 10:17 am

magik: thanx for those settings :)

xxxstarmanxxx · Post by **xxxstarmanxxx** » Tue May 30, 2006 10:42 am

magiK wrote:xxxstarmanxxx: Take a look at this image (the scaler is resizing to 480x272).
A stream using those settings is decoded by the PSP at around 180 frames per second.

Hi m8

I've taken your setting - Thanks so much for these - and have muxed the resulting stream into an mpeg2 container (ps) using elecards Xmuxer Pro.

I still cant produce a valid pmf playback file though :( - ERROR: scempegquerystreamoffset() failed.

Here is my h.264 file info.

file type : MPEG2(PS)
video stream type : AVC/H.264
resolution : 480x272
profile:level : Main:30
aspect ratio : Extended_SAR (136x135) ( same results with 1:1)
frames count : 949
max frame size : 17 953
min frame size : 74
file size : 2 450 804
--------------------------------------------

framerate declared : 25.00
--------------------------------------------
real : 25.00

bitrate declared : 2 048 000
--------------------------------------------
real max : 787 400
real avg : 516 400
real min : 271 800
--------------------------------------------
position : 0x0 (0x0)
mb_addr : 0
size (in bits) : 347
mb_type : Intra(I_4x4)
slice_number : 0
transform_8x8 : 0
cbp bits : 0 1000 1 00 1 00
: 0100 10 10
: 1111
: 1111
quant_param : 24
pmode : Intra_4x4
ipred Intra_4x4:
DC DC DC DC
DC DC Horz Horz
DC DC Horz Horz
DC DiagDwnRight Vert Vert

File info obtained using ESEye.

Any further help much apreciated!

All the best

J.

jonny · Post by **jonny** » Tue May 30, 2006 5:36 pm

@xxxstarmanxxx:
you should use the sink filter to produce a raw stream, avcdecme.rar posted some messages above will play it.

@magiK:
you've done an amazing work, i'm really really impressed, i start thinking you have a sort of magic cap hidden somewhere :)

xxxstarmanxxx · Post by **xxxstarmanxxx** » Tue May 30, 2006 6:15 pm

jonny wrote:@xxxstarmanxxx:
you should use the sink filter to produce a raw stream, avcdecme.rar posted some messages above will play it.

@magiK:
you've done an amazing work, i'm really really impressed, i start thinking you have a sort of magic cap hidden somewhere :)

Sorry for sounding absolutely dumb guys...........

avcdecme.rar = what do I do with it - does it need compiling???? - if so how would I do that on a windows box (complete n00b at source code).

Thanks for all your time

J.

jonny · Post by **jonny** » Thu Jun 01, 2006 5:22 am

@magiK:

i'm getting some troubles :)
i'm doing tests with clips (the length of each clip is around 10 mins)
i'm encoding using the exact graph you posted (i'm only changing the bitrate in the 512-1024 range)
i get crashes, every clip crashes always at the same point (the point changes from clip to clip)
do you have an idea of what could be the cause?

i use this to test:
http://www.megaupload.com/?d=0P7PZTXP
i've only changed the code a bit to handle big files (my code looks quite ugly ^^)

(@xxxstarmanxxx: place the clips in ms0:/test.264 if you want to try some clips)

kaveman · Post by **kaveman** » Thu Jun 01, 2006 6:53 am

whoa! amazing work guys!

xxxstarmanxxx · Post by **xxxstarmanxxx** » Thu Jun 01, 2006 7:02 am

Thanks for info Jonny -

I managed to get my head around pspdev/cyywin/psptoolchain and compile it.

I much prefer encoding more!............LOL

Jonny - I seem to be having success with mainconcept h264AVC encoder rather than the elecard encoder (although they look and perform identically in the graph from what I can see).

I'm using mainconcept encoder in graphedit - bitrate control mode = constant quant.

The file buffers from the memory card (pause/resume) - but the luma/chroma performance is extremely good!!!!

Great stuff guys! - I cant wait for more coding with this!

J.

magiK · Post by **magiK** » Thu Jun 01, 2006 5:36 pm

Here's a modified version of the x264 encoder. It adds some kind of buffering_period and pic_timing SEIs to the stream. They're not 100% valid but it seems to work anyway. I use the following settings for testing:
x264 --crf 25 -A all --level 3 --pictiming --aud --no-psnr --thread-input --progress --output out.264 in.avs

jonny wrote:@magiK:

i'm getting some troubles :)
i'm doing tests with clips (the length of each clip is around 10 mins)
i'm encoding using the exact graph you posted (i'm only changing the bitrate in the 512-1024 range)
i get crashes, every clip crashes always at the same point (the point changes from clip to clip)
do you have an idea of what could be the cause?

I've experienced the same strange behaviour as well. It appears that changing the bitrate by one kbps gets it going past that point but it may still freeze further on (though it never happened on 25min clips). I've tried various settings and matched all the relevant header values with the ones found in a stream ripped from some pmf and the freeze was still there. Changing the bitrate by 1 kbps fixed that and the 25 min stream played without a hitch. Using h264_parse I've noticed that the only difference between the stream that freezes and the one that works (bitrate +1kbps) is the slice sizes, the headers remain identical. Is it possible that the psp decoder has a strange CPB alignment restriction? Maybe a more H264 knowledgeable person can shed some light on the situation.

jonny · Post by **jonny** » Thu Jun 01, 2006 6:39 pm

Here's a modified version of the x264 encoder. It adds some kind of buffering_period and pic_timing SEIs to the stream. They're not 100% valid but it seems to work anyway. I use the following settings for testing:
x264 --crf 25 -A all --level 3 --pictiming --aud --no-psnr --thread-input --progress --output out.264 in.avs

the puzzle is near to be finished with this, awesome.

about the freezes, maybe a sort of zero padding at the end of each frame could help.

have you already done tests with seeking?
atm i've tryed random seeks but crashes.
i guess seeks must be done on keyframes to work (afaik keyframes can be already identifyed in the access unit delimeter).

going to check

magiK · Post by **magiK** » Fri Jun 02, 2006 3:06 am

jonny wrote:have you already done tests with seeking?
atm i've tryed random seeks but crashes.
i guess seeks must be done on keyframes to work (afaik keyframes can be already identifyed in the access unit delimeter).

Yes, I've just tried seeking and it works. With AVC, you should always seek to an IDR frame. An AVC stream can have I frames inside GOPs that are not seekable, because a P frame after an I frame may refference another P frame before that I frame in the same GOP. The primary_pic_type field in the AU delimiter does not indicate if the AU contains an IDR on a non-IDR picture, it only indicates the slice type i.e. I, P, etc. A solution for finding IDR frames would look like this: after an AUD with primary_pic_type = 0 is found, check the type of the next NAL. If it's a sequence parameter set (type 7), the AU is an IDR.

xxxstarmanxxx · Post by **xxxstarmanxxx** » Fri Jun 02, 2006 1:59 pm

Hi all -

Here's a test.264 encode from my latest tests

Blade Trinity Trailer 264 - quant - 14.2mb
Download

Quality overall is quite good - however heavy blocking on section that have no detail.

This also pauses while it reads from the memorystick.

File was encoder using the quantisizer setting in mainconcept encoder.

All the best

J

digihoe · Post by **digihoe** » Fri Jun 02, 2006 3:47 pm

xxxstarmanxxx wrote: Quality overall is quite good - however heavy blocking on section that have no detail.

Yes the quality is great! I upscaled it to fullscreen on the computer and it does display very nice...
But how do we get sound to work for this container?

Best regards!

jonny · Post by **jonny** » Fri Jun 02, 2006 5:23 pm

@magiK:
thanks for the info (i'll probably use h264_parse for the first tests :)
about the random crashes, i've still not found a solution :(
it seems something related to CopyAu2Me.
some stuffs i've noticed:
- if the clip is fully loaded in memory (so up to 21MB), there are no crashes
- CopyAu2Me seems to transfer more than iSize. seems that, if there is not enough "next frames data" after B+iSize, the app crashes (this will also explain why loading the full clip in memory work)

hroo772 · Post by **hroo772** » Fri Jun 02, 2006 11:14 pm

I was wondering if you guys have taken a look at the PMP sourcecode to see the way the PMP player buffers its video from the memory stick? Just to see if this would prevent the video from lagging whenever the buffer runs out.

Raphael · Post by **Raphael** » Sat Jun 03, 2006 12:01 am

If you look closer, jonny actually is the one developing PMPMOD (you meant that one, right?), so he knows best about the buffering involved :)

PS: magiK, you're really great, I'd vote this the best finding of the year in homebrew dev :)

jonny · Post by **jonny** » Sat Jun 03, 2006 12:13 am

the purpose of the code i've posted is to identify the cause of random crashes (by crash i mean the psp freeze and the app no more respond)
every comment (about the code i've posted) not focusing on the resolution of this problem is really superfluous (having smooth playback is not the purpose and not the problem here)

forums.ps2dev.org

PMF Player

PMF Player

Nice progress!