Xuggle 5.4 is available

[legend80]

And why would it be a ram issue if it only happens on the x64 bit version and after the new lib integration?

as far as i know 32 bit system doesn't let you assign more than 2 gb of ram to any application and struggles with accessing 4 gb globally (usually gets less than that, mine only shows 3.5 gb total even though i also have 4). 64 bit removes that limit, so it can access all of it.

maybe that's related to the problem.

Oh gotcha. Yep, that may be part of this.

[anrib]

I'm sorry, I do not understand English, I use a translator.

OS: windows 7 64 bit
jdk1.7.0_03

I can not figure out how to install huggler?

Just copy libxuggle-5.dll in \Windows\System32 no effect

[Itaru]

I can not figure out how to install huggler?

There's no need to install Xuggler. It's already included in Jpcsp. What you need to install is SonicStage to get sound working in movies.

Unfortunately I have confirmed that there is indeed a nasty bug in Xuggle 5.x which breaks AT3 playback. Games affected are those which use AT3 for music such as Disgaea Afternoon of Darkness and Prinny Can I Really Be a Hero since ffmpeg is used to decode those AT3 files. The title music in Patapon is also affected since it's in AT3 format, so it's not just Nippon Ichi titles. Disgaea 2 has no problems with bgm since it uses AT3+ format. AT3+ files which are decoded externally either through SonicStage or SoundForge are not affected at all.

In the previous Xuggle 3.4, AT3 playback works fine. However in Xuggle 5.x, the IContainer.readNextPacket() method in Xuggle returns an error after around 8 seconds of AT3 playback. The return code is a very large negative number which Xuggle categorizes as IError.Type.ERROR_UNKNOWN. Both 32-bit and 64-bit versions are affected. I think it's a bug in the ffmpeg that is embedded in the libxuggle-5.dll file since the return code in the readNextPacket() method just returns whatever code that ffmpeg returns when it exits. Xuggle 5.2 and 5.3 also have the same problem.

Looks like we'll have to revert r2538 until the problem is hopefully fixed in the next Xuggle 5 release.

[legend80]

Looks like we'll have to revert r2538 until the problem is hopefully fixed in the next Xuggle 5 release.

Yep, that lib is screwed up. Kill it and wait for the next version. Report issues to them and hopefully they'll address them in the next release!

[gid15]

Unfortunately I have confirmed that there is indeed a nasty bug in Xuggle 5.x which breaks AT3 playback. Games affected are those which use AT3 for music such as Disgaea Afternoon of Darkness and Prinny Can I Really Be a Hero since ffmpeg is used to decode those AT3 files. The title music in Patapon is also affected since it's in AT3 format, so it's not just Nippon Ichi titles. Disgaea 2 has no problems with bgm since it uses AT3+ format. AT3+ files which are decoded externally either through SonicStage or SoundForge are not affected at all.

In the previous Xuggle 3.4, AT3 playback works fine. However in Xuggle 5.x, the IContainer.readNextPacket() method in Xuggle returns an error after around 8 seconds of AT3 playback. The return code is a very large negative number which Xuggle categorizes as IError.Type.ERROR_UNKNOWN. Both 32-bit and 64-bit versions are affected. I think it's a bug in the ffmpeg that is embedded in the libxuggle-5.dll file since the return code in the readNextPacket() method just returns whatever code that ffmpeg returns when it exits. Xuggle 5.2 and 5.3 also have the same problem.

Looks like we'll have to revert r2538 until the problem is hopefully fixed in the next Xuggle 5 release.

Hmm, could you post a log file while inserting the following in LogSettings.xml:

Code:

<logger name='hle.sceAtrac3plus'> <level value='debug' /> </logger>
<logger name='PacketChannel'> <level value='debug' /> </logger>

One reason could be that Xuggle 5.4 now requires more look-ahead data for the Atrac3. I already had similar problems with the previous versions: old Xuggle/ffmpeg required 3 * 0x8000 Atrac3 data bytes before it could be started.
See jpcsp.connector.AtracCodec.java, Line 365.
Maybe the new one requires even more... the DEBUG logging of PacketChannel will show if Xuggle/ffmpeg tries to read more data than available at the start of an Atrac3 decoding (log of "PacketChannel: End of data").

[gid15]

here is a log from Disgaea Afternoon of Darkness (at end of the file is where bgm was playing for about 5 seconds then cuts off)

Thank you! From the log, ffmpeg is trying to read more data than available in the Atrac3 buffer, which is interpreted as end of the audio by ffmpeg.
Could you provide a log with r2537 and the same log settings for comparison?

I will check if there are new API methods to better control the ffmpeg behavior...

EDIT: is there any difference in the log file between 32 and 64 bit versions?

[hyakki]

bgm audio cuts off with r2541 64bit one aswell.
in r2537 the bgm audio works ok I played game to the same point as r2541,

[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....

[Itaru]

I think I've found a workaround for the end of data problem with the new Xuggle during AT3 playback. The workaround is to modify line 315 in the jpcsp.media.MediaEngine class as follows:

Code:

if (container.open(channel, IContainer.Type.READ, null, true, decodeVideo) < 0) {

The queryStreamMetaData parameter has to be set to false for AT3 decoding to work properly without the end of data read problem, and it has to be set to true for video decoding to work properly. Using decodeVideo to set the queryStreamMetaData parameter in the above code seems to work nicely. I haven't done much testing with this workaround yet, and I'm not even sure that the workaround is a good idea.

I've also tried reducing the look-ahead size in line 365 of the jpcsp.connector.AtracCodec class after applying the workaround above. I've tried reducing the look-ahead size to 0x7000 bytes and AT3 playback still works correctly. However, setting it to 0x6000 causes end of data problem.

[gid15]

I think I've found a workaround for the end of data problem with the new Xuggle during AT3 playback. The workaround is to modify line 315 in the jpcsp.media.MediaEngine class as follows:

Code:

if (container.open(channel, IContainer.Type.READ, null, true, decodeVideo) < 0) {

The queryStreamMetaData parameter has to be set to false for AT3 decoding to work properly without the end of data read problem, and it has to be set to true for video decoding to work properly. Using decodeVideo to set the queryStreamMetaData parameter in the above code seems to work nicely. I haven't done much testing with this workaround yet, and I'm not even sure that the workaround is a good idea.

I've also tried reducing the look-ahead size in line 365 of the jpcsp.connector.AtracCodec class after applying the workaround above. I've tried reducing the look-ahead size to 0x7000 bytes and AT3 playback still works correctly. However, setting it to 0x6000 causes end of data problem.

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.