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:
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:
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.
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);