Seems like Xuggle 5.4 causes yet another issue as reported by hyakki at http://www.emunewz.net/forum/showthread....9#pid73689 which does not occur with the old Xuggle. I confirmed this by using r2552 after replacing the Xuggle files with the old Xuggle and also reverting the IStreamCoder.open() calls to get it to work with the old Xuggle, so the issue is definitely due to the new Xuggle or the new ffmpeg embedded in the new Xuggle since r2552 with the old Xuggle doesn't have this problem at all. This issue doesn't hang the emulator since you can still press the Start button at any time during the movie and even during the black screen to go back to the title screen, but it just doesn't want to continue on to the title screen on its own after the movie ends. BTW, the first Dissidia game doesn't have this problem with the new Xuggle.
I wonder if it's a timing issue since as far as I can tell, the movie completes successfully at the end (reaches end of data properly) and the Xuggler threads (SQEXTEC Movie Decode, SQEXTEC Movie AudioOutput, and SQEXTEC Movie Streaming) do finish and stop once the movie ends. However, the new Xuggle produces a lot more End of Data than the old Xuggle when the end of the movie is reached. I've attached logs which show this. In the old Xuggle, 6 end of data events occur starting at time 261984. In the new Xuggle, 21 end of data events occur starting at time 260625. It seems that the new Xuggle is retrying the reads 2 additional times even after receiving 0 (end of data).
Also when I was looking at the JPCSP threads using the jvisualvm tool, the new Xuggle creates an additional unnamed thread (Thread-29) which isn't in the old Xuggle. This additional thread starts about 1-2 seconds after the 3 SQEXTEC threads start, and continues running continuously even after the SQEXTEC threads finish. What's odd is that this thread is always in the running state after it starts; it never sleeps or waits at all. Thread dump doesn't give any useful info on this thread so I have no idea what it's doing or whether it's doing anything useful other than getting caught in an infinite loop.
EDIT: I forgot to mention that I changed the ffmpeg buffer size to 32KB from 4KB since the old Xuggle defaults to 32KB and I wanted to make the logs of the old and new Xuggle to be directly comparable. Incidentally, the new Xuggle uses 8KB as the buffer size when playing movies even if we set it 4KB, so I think 4KB is too small and 8KB is the reasonable minimum size. I think it's better to just set it to 32KB like in the old Xuggle to avoid potential performance regression for slow machines due to the more frequent PacketChannel.read() calls.
I wonder if it's a timing issue since as far as I can tell, the movie completes successfully at the end (reaches end of data properly) and the Xuggler threads (SQEXTEC Movie Decode, SQEXTEC Movie AudioOutput, and SQEXTEC Movie Streaming) do finish and stop once the movie ends. However, the new Xuggle produces a lot more End of Data than the old Xuggle when the end of the movie is reached. I've attached logs which show this. In the old Xuggle, 6 end of data events occur starting at time 261984. In the new Xuggle, 21 end of data events occur starting at time 260625. It seems that the new Xuggle is retrying the reads 2 additional times even after receiving 0 (end of data).
Also when I was looking at the JPCSP threads using the jvisualvm tool, the new Xuggle creates an additional unnamed thread (Thread-29) which isn't in the old Xuggle. This additional thread starts about 1-2 seconds after the 3 SQEXTEC threads start, and continues running continuously even after the SQEXTEC threads finish. What's odd is that this thread is always in the running state after it starts; it never sleeps or waits at all. Thread dump doesn't give any useful info on this thread so I have no idea what it's doing or whether it's doing anything useful other than getting caught in an infinite loop.
EDIT: I forgot to mention that I changed the ffmpeg buffer size to 32KB from 4KB since the old Xuggle defaults to 32KB and I wanted to make the logs of the old and new Xuggle to be directly comparable. Incidentally, the new Xuggle uses 8KB as the buffer size when playing movies even if we set it 4KB, so I think 4KB is too small and 8KB is the reasonable minimum size. I think it's better to just set it to 32KB like in the old Xuggle to avoid potential performance regression for slow machines due to the more frequent PacketChannel.read() calls.