Xuggle 5.4 is available

[Itaru]

Interesting finding!
I've committed it in r2542 so that more people can test it. It doesn't seem to me it would break something.
I just kept the parameter "streamsCanBeAddedDynamically" to false as I don't think this is possible on a PSP.

Thanks for committing it to svn! And yeah, streamsCanBeAddedDynamically should be set to false, my mistake. It's certainly great that we don't have to go back to the old Xuggler, and hopefully there won't be any more surprises with the new Xuggler.

[legend80]

It's only with Mega Man X (that I can see) in gameplay but both it and 3rd Birthday crash frequently when their tile is selected in the browser.

Next step would be to try to reproduce the issue with a standard Xuggle player so that we can report it to the Xuggle team.

Could someone check if there is a standard player delivered with Xuggle (sorry I have no time to check myself)?
Extract the Browser PMF file from those games ("PSP_GAME/ICON1.PMF") and try to play it with the standard Xuggle player in 64bit. It should crash the same way as Jpcsp....

Still repro's with the new build. Damn. I was hoping that would be the end of this.

Also, I don't have those files in my ms0 folder. I have those for some other games but not 3rd Birthday/MegaManX.

[gid15]

It's only with Mega Man X (that I can see) in gameplay but both it and 3rd Birthday crash frequently when their tile is selected in the browser.

Next step would be to try to reproduce the issue with a standard Xuggle player so that we can report it to the Xuggle team.

Could someone check if there is a standard player delivered with Xuggle (sorry I have no time to check myself)?
Extract the Browser PMF file from those games ("PSP_GAME/ICON1.PMF") and try to play it with the standard Xuggle player in 64bit. It should crash the same way as Jpcsp....

Still repro's with the new build. Damn. I was hoping that would be the end of this.

Also, I don't have those files in my ms0 folder. I have those for some other games but not 3rd Birthday/MegaManX.

They are in the ISO of the respective games.

EDIT: the following should display the video (extract the ICON1.PMF from the ISO into the Jpcsp directory):

Code:

set PATH=%PATH%;lib\;lib\windows-amd64\
java -Djava.library.path=lib/windows-amd64 -cp lib/xuggle-xuggler-noarch-5.4.jar com.xuggle.xuggler.demos.DecodeAndPlayAudioAndVideo ICON1.PMF

[hyakki]

Still repro's with the new build. Damn. I was hoping that would be the end of this.

Also, I don't have those files in my ms0 folder. I have those for some other games but not 3rd Birthday/MegaManX.

Hm I am unable to reproduce it, I can click on and off fine with the 3rd birthday (though there is a slight delay), but no crashes or errors I tried it like 30 times, just to make sure I pressed the up and down arrows and went through all my games none generated any crash in the browser.
Tried using both 32bit and 64bit, java 6 and java 7

legend80 do you have any old xuggle manually installed it could be some type of conflict.

[Itaru]

Based on this report: http://www.emunewz.net/forum/showthread....5#pid72245 the end of data problem still occurs after a while. The fix is to set the buffer size for ffmpeg in the jpcsp.media.MediaEngine class just before calling the open() method on line 317 as follows:

Code:

container.setInputBufferLength(4096);

Seems like 4KB is the minimum size that doesn't cause the end of data problem. I suppose it can be set to 0x8000 bytes so that it behaves the same as in the old Xuggle where data is being read in 32KB blocks. I've tested it with 4KB buffer size and everything seems to be working fine. The bgm in Prinny has been playing and looping correctly for over 10 minutes now without stopping, so setting the ffmpeg buffer size to at least 4KB seems to squash the end of data problem for good.

Incidentally with the fix above, it seems to be safe now to completely remove the pre-initialization buffering done in jpcsp.connector.AtracCodec. Lines 365-376 can be replaced with:

Code:

} else me.init(atracChannel, false, true);

so that it starts initializing MediaEngine immediately without the pre-buffering. I've only tested this on 64-bit version with Java 7 though but so far so good.

[legend80]

Still repro's with the new build. Damn. I was hoping that would be the end of this.

Also, I don't have those files in my ms0 folder. I have those for some other games but not 3rd Birthday/MegaManX.

Hm I am unable to reproduce it, I can click on and off fine with the 3rd birthday (though there is a slight delay), but no crashes or errors I tried it like 30 times, just to make sure I pressed the up and down arrows and went through all my games none generated any crash in the browser.
Tried using both 32bit and 64bit, java 6 and java 7

legend80 do you have any old xuggle manually installed it could be some type of conflict.

Thanks for looking into this. I don't know what to say. I do not have any xuggle files on my pc except for the ones in my JPCSP folder.

There's no issues in x86 at all - only when using the x64 jar and libs. What could be causing this? Anything else I can try here for you guys? Should I uninstall J6 and try J7?

[serio]

does that game try to load an at3 music in the umd browser? maybe that's related to the crash, since it's still failing to load/play almost every at3 music while there, although it doesn't show the error anymore.

[hyakki]

it looks like his game has been patched or modified according to the 3rd birthday logo in his attached pic, perhaps its trying to load an unknown audio type......

[gid15]

Thanks for looking into this. I don't know what to say. I do not have any xuggle files on my pc except for the ones in my JPCSP folder.

There's no issues in x86 at all - only when using the x64 jar and libs. What could be causing this? Anything else I can try here for you guys? Should I uninstall J6 and try J7?

Could you try to play to video outside Jpcsp as I described above?

http://www.emunewz.net/forum/showthread....8#pid72298

Thanks!

[gid15]

Based on this report: http://www.emunewz.net/forum/showthread....5#pid72245 the end of data problem still occurs after a while. The fix is to set the buffer size for ffmpeg in the jpcsp.media.MediaEngine class just before calling the open() method on line 317 as follows:

Code:

container.setInputBufferLength(4096);

Seems like 4KB is the minimum size that doesn't cause the end of data problem. I suppose it can be set to 0x8000 bytes so that it behaves the same as in the old Xuggle where data is being read in 32KB blocks. I've tested it with 4KB buffer size and everything seems to be working fine. The bgm in Prinny has been playing and looping correctly for over 10 minutes now without stopping, so setting the ffmpeg buffer size to at least 4KB seems to squash the end of data problem for good.

Incidentally with the fix above, it seems to be safe now to completely remove the pre-initialization buffering done in jpcsp.connector.AtracCodec. Lines 365-376 can be replaced with:

Code:

} else me.init(atracChannel, false, true);

so that it starts initializing MediaEngine immediately without the pre-buffering. I've only tested this on 64-bit version with Java 7 though but so far so good.

The change for the buffer size has been committed in r2546. Thank you for the analysis!
I'm still waiting to remove the pre-initialization buffering until we better understand the situation...