PMF Player

magiK · Post by **magiK** » Sat Jun 03, 2006 1:50 am

Thanks Raphael but we're not quite there yet :)

jonny, I'm really pulling my hair over this one. I've made it freeze with a 200 frame sample, about 250kb in size, completely loaded into memory. It freezes at frame 59, the second frame of the second GOP. If I set the encoder to output the SPS/PPS headers only once, at the start, it gets past that point but freezes at frame 104.
I don't think CopyAu2Me can copy more data than iSize. The applications I've looked at are using that function to copy the AU from the interleaved stream so copying more that the size of the AU wouldn't make sense.
I'm thinking my buffering_period info is not correct but Elecard's headers certainly are yet you say it's still freezing. Can you upload a bad stream generated by Elecard so I can take a look and maybe eliminate some posibilities?

xxxstarmanxxx · Post by **xxxstarmanxxx** » Sat Jun 03, 2006 3:14 am

jonny wrote: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)

Hi Jonny -

I've yet to produce a crash encoding via quantisizer - although quant values have not been altered from magiK's graph settings.

All my freezing occur on variable bitrate encodes - and those freezes fluctuate depending on the min/max apeture.

All the best

J.

magiK · Post by **magiK** » Sat Jun 03, 2006 5:06 am

I've spotted the mistake in CopyAu2Me.
Replace this:

Code: Select all

		LLI&#91;i-1&#93;.iSize = iSize % DMABLOCK;
		LLI&#91;i-1&#93;.Next  = NULL;

with this:

Code: Select all

	if&#40;iSize % DMABLOCK&#41;
	&#123;
		LLI&#91;i&#93;.pSrc  = pSrc + i * DMABLOCK;
		LLI&#91;i&#93;.pDst  = &#40;void*&#41;&#40;MEAVCBUF + i * DMABLOCK&#41;;
		LLI&#91;i&#93;.iSize = iSize % DMABLOCK;
		LLI&#91;i&#93;.Next  = NULL;
	&#125;
	else
	&#123;
		LLI&#91;i-1&#93;.Next  = NULL;
	&#125;

Some clips encoded with x264 are still freezing though :(

jonny · Post by **jonny** » Sat Jun 03, 2006 7:49 am

i wasn't 100% accurate in my previous report :)
i'll try to summarize better:

- using the elecard encoder and loading the full clip on memory, none of the clips i've tryed crashes

- using the elecard encoder and buffered reads, many clips randomly crashes
usually the crash happen when the buffer is filled (if don't crash, i can spot, sometimes, artifacts in the decoding, so something is still wrong)

- using your x264 version, i have clips that crashes also when fully loaded in memory
that's why i think we should focus on only elecard clips atm

i've uploaded a clip and the test app, as you can see if the clip is fully loaded in memory, all goes well.
if you use buffered reads, it crashes
you can change the avc_reader_buffer_size parameter to check (using a buffer around 20MB will make the clip fully loaded in memory)

about CopyAu2Me and what i've said in the prev message, you can try "main_try_2.c"
here i read one frame at time from the memstick, as you can see it crashes really fast
and if you raise "read_ahead" (around 0.5MB), some initial frames are decoded better (that's why it seems CopyAu2Me transfer more data than iSize)

about the code i've added, i can't really spot errors
basically i first get frame positions and lengths using the access unit delimiters
the buffered reading routines seems also ok
(do you see anything wrong here?)
i've also already muxed frames inside a pmp (this is really the first thing i've tryed some days ago :) and i'm obtaining the same behavior when i try to play (clips crashes near the same points if i use the same buffer size of the testing app)

test app: http://www.megaupload.com/?d=VNBID6JZ
a clip (made with elecard): http://www.megaupload.com/?d=TIKGFP4V

magiK · Post by **magiK** » Sat Jun 03, 2006 8:27 am

Try adding a sceKernelDcacheWritebackInvalidateAll() after the fread().
PS: Looks like sceCtrlReadBufferPositive is slowing things down a lot :)

groepaz · Post by **groepaz** » Sat Jun 03, 2006 9:06 am

Looks like sceCtrlReadBufferPositive is slowing things down a lot :)

it implicitly waits for vblank, try sceCtrlPeekBufferPositive instead

jonny · Post by **jonny** » Sat Jun 03, 2006 5:37 pm

Try adding a sceKernelDcacheWritebackInvalidateAll() after the fread().

i feel quite stupid now :) (but more relaxed ^^ )

EDIT: i've got also seeks working, but every time i must call:

Shutdown();
Initialize();

or sceMpegAvcDecode crash.
is this the way to go? (maybe i'm still missing an easyer way :)

therock003 · Post by **therock003** » Sun Jun 04, 2006 2:33 am

Hey guys,sorry for bumping in here like that,but could you plz tellme what exactly are you testing here,and what you are trying to achieve?

magiK · Post by **magiK** » Sun Jun 04, 2006 3:30 am

jonny wrote:i've got also seeks working, but every time i must call:

Shutdown();
Initialize();

or sceMpegAvcDecode crash.
is this the way to go? (maybe i'm still missing an easyer way :)

It worked fine last time I tried it, without shutdown/init, even when jumping to a non-IDR frame (except for the garbled frames of course).

jonny · Post by **jonny** » Sun Jun 04, 2006 4:57 am

on the code i've posted, try to add:

Code: Select all

if &#40;controller.Buttons & PSP_CTRL_SQUARE&#41; &#123; i = 0; sceKernelDelayThread&#40;1000000&#41;; &#125;

after:

Code: Select all

SceCtrlData controller;
sceCtrlReadBufferPositive&#40;&controller, 1&#41;;
if &#40;controller.Buttons & PSP_CTRL_TRIANGLE&#41; break;

let the video play some seconds and press square, the video will seek to the start.
after this, try to keep square pressed now, looping on frame 0 now will generate the crash (this is the most simple example i can find about seeking to idr frame that crash).
also jumping on non idr frames seems to crash (try i+=2 in the loop)
(i'm sorry if i'm again missing something, but i can't really spot what)

jas0nuk · Post by **jas0nuk** » Sun Jun 04, 2006 4:59 am

therock003 wrote:Hey guys,sorry for bumping in here like that,but could you plz tellme what exactly are you testing here,and what you are trying to achieve?

lol, not too sure myself, I think originally they were trying to mux PMF files, but now they are trying to improve the PMF player?

magiK · Post by **magiK** » Sun Jun 04, 2006 8:00 am

jonny, strangely enough, clips encoded with the modified x264 encoder do not freeze while seeking. I'm guessing some setting in the Elecard encoder is responsible for this. You can grab an updated version of the x264 encoder from here. I've encoded a few clips with it and no freeze so far (fingers crossed).

therock003, jas0nuk, we're trying to properly decode an AVC stream using the PSP's integrated decoder.

jonny · Post by **jonny** » Sun Jun 04, 2006 6:07 pm

yep, tryed some clips around 10mins and no crashes so far, seeking everywhere also don't crash (fingers crossed too :)

digihoe · Post by **digihoe** » Sun Jun 04, 2006 7:32 pm

What is the highest resulotion possible? Is it 480*272 or is it 720*512?

Best regards!

excalibur · Post by **excalibur** » Mon Jun 05, 2006 8:13 pm

hi jonny, i have read that you have make a beta of pmp with avc support (pmf derivated) can i have a version for test , i have see that you avec pb with seek but in first version it s not very important ..
the beta version (or alpha if you preffered ;-) ) is interesting for make experience on the encoder..
great job and thanks...

jonny · Post by **jonny** » Mon Jun 05, 2006 9:46 pm

hi jonny, i have read that you have make a beta of pmp with avc support (pmf derivated) can i have a version for test

no :) (no beta testing is going on)
anyway, if all goes as expected, i should finish the muxer/player this week.
(the muxer is already finished, the player need some cleanup and a torture testing cycle)

@magiK:
your last x264 seems really ok, tested a full 2h movie with no crashes

therock003 · Post by **therock003** » Mon Jun 05, 2006 11:14 pm

So will this pmf player be better than our beloved pmp player?

jonny · Post by **jonny** » Mon Jun 05, 2006 11:43 pm

the player is based on pmpmod (with a reduced set of options atm) and it's not a pmf player (why should i do a pmf player if there is already one? :)
pure avc streams will be muxed inside a .pmp

Eingang · Post by **Eingang** » Tue Jun 06, 2006 2:51 am

therock003 wrote:So will this pmf player be better than our beloved pmp player?

Possibly performance of avc pmps will be better I guess.....

Djakku · Post by **Djakku** » Thu Jun 08, 2006 7:34 am

At the risk of sounding completely off topic, Ive found a link from DCemu about a UMD composer.. I dont know any japanese so I only read the english part and it seem that sony will soon release a umd video composer.. Would that be helpfull for your work, that I dont know but you might want to satifsy your curiosity :<)
https://www.universalmediadisc.com/umdcomposer/

keep up the GREAT work!!

digihoe · Post by **digihoe** » Thu Jun 08, 2006 8:33 am

https://www.universalmediadisc.com/umdc ... uction.pdf
On page 10 the specification of the AVC profile is stated... I guess I'll be having 720*480 :-)

Best regards!

magiK · Post by **magiK** » Fri Jun 16, 2006 7:07 am

I've traced things down to the VideoCodec driver so only the VideoCodec and the MpegBase modules are required to decode AVC. I've also managed to set up the decoder for 720x480 content but it freezes on everything I throw at it. It would be great if someone could upload the first 2-3MB of a 00001.MPS file from an original UMD movie for further investigation.

Here's some quick code:
http://www.megaupload.com/?d=L3Y4E0US

0okm0000 · Post by **0okm0000** » Fri Jun 16, 2006 1:00 pm

magiK wrote:I've traced things down to the VideoCodec driver so only the VideoCodec and the MpegBase modules are required to decode AVC. I've also managed to set up the decoder for 720x480 content but it freezes on everything I throw at it. It would be great if someone could upload the first 2-3MB of a 00001.MPS file from an original UMD movie for further investigation.

Here's some quick code:
http://www.megaupload.com/?d=L3Y4E0US

UMD-MS001-3.Initial D
00001.MPS size: 8,118,272
file link in PM ^^

jonny · Post by **jonny** » Fri Jun 16, 2006 5:28 pm

down to the metal :O :)

magiK · Post by **magiK** » Fri Jun 16, 2006 11:45 pm

Thanks a lot 0okm0000 ^^ Unfortunately it freezes with that sample as well so I'm back to the drawing board :(

magiK · Post by **magiK** » Sun Jun 25, 2006 9:29 pm

I'm not sure how I missed this but obviously mebooter_umdvideo.prx must be loaded in order to play 720x480 content. Unfortunately, sceMpegBaseCscAvc can only do 512x512 pixels at a time. The VSH player goes around this by doing three 256-pixel CSCs.
Tracing all that mess is not easy and in my opinion, not worthed.
First of all, you need the buffer to be on a 4MB boundary so you're wasting a good amount of memory, unless somehow you manage to put it to good use (the VSH player does). With a single 512x480 CSC, a Sony encoded stream was playing fast enough but my x264 encoded sample played at about 15-20fps.
So I think I'll put this on hold. 480x272 content looks good, plays fast and you get plenty of battery time with it :)

jonny · Post by **jonny** » Mon Jun 26, 2006 1:51 am

480x272 content looks good, plays fast and you get plenty of battery time with it :)

i agree. also i think near no one will want to use 720x480 on full movies anyway.

nyu! :)

Art · Post by **Art** » Sun Aug 06, 2006 5:19 am

I wonder if anyone can help me with this problem..

I can compile the player, and play a file ok, but if I insert the line:

Code: Select all

USE_PSPSDK_LIBC = 1

into a makefile to try to use it in an existing program, everything
goes nuts, and I get all sorts of compile errors.

If I exclude that line from the makefile of the test app, it doesn't work,
so I assume I need it.
What is the problem?