(05-07-2012, 02:31 AM)hyakki Wrote: yeah ieframe is not an big issue, i don't see any other problems with the dll from that ss, so that means it must be something else causing the crash, like a invalid registry entry or something is corrupt, usually these types of problems its just better to backup and reinstall windows since they are troublesome to track down. You could try something like ccleaner to fix bad registry entry's but some claim it does more harm then good..
Never had an issue with CCleaner myself. Gave it a shot, cleaned up the reg, but still crashing.
I don't think this will be fixed without drastic action unforunately. Shame. So i'll either run with x86 or use rev r2537 and below.
thewildpendulum, does it still crash if you use the Win 32-bit version of r2551? Also try r2537 Win 64-bit version, does it work fine? What processor is your notebook using?
05-12-2012, 08:05 AM (This post was last modified: 05-12-2012, 08:36 AM by Itaru.)
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.
(05-11-2012, 03:57 AM)Itaru Wrote: thewildpendulum, does it still crash if you use the Win 32-bit version of r2551? Also try r2537 Win 64-bit version, does it work fine? What processor is your notebook using?
it doesn't happen at all on the 32bit, but i do run into outOfMemory errors.
r2537 64bit works fine.
i have an i7-2670qm @ 2.2. my graphics card is a radeon hd 7690m xt
(05-11-2012, 03:57 AM)Itaru Wrote: thewildpendulum, does it still crash if you use the Win 32-bit version of r2551? Also try r2537 Win 64-bit version, does it work fine? What processor is your notebook using?
it doesn't happen at all on the 32bit, but i do run into outOfMemory errors.
r2537 64bit works fine.
i have an i7-2670qm @ 2.2. my graphics card is a radeon hd 7690m xt
FINALLY, someone with the same results as me! Stability issues on x64 with that stupid xuggle-5 lib.
Hopefully, a revert or a JPCSP fix can get done. Good luck!
Based on legend80 and thewildpendulum's cases so far, my initial hypothesis is that the new ffmpeg embedded in the new Xuggle may be using the new Intel AVX instructions. Newer CPUs (Sandy Bridge and Ivy Bridge) have a new instruction set called AVX which extends SSE. When in 64-bit mode, the new ffmpeg may be using AVX and due to a bug in ffmpeg's AVX code or in the compiler, it becomes unstable. Older generation CPUs are not affected since ffmpeg falls back to SSE. Also 32-bit mode is not affected since AVX is only available in 64-bit mode.
This hypothesis still needs to be proven though. legend80 and thewildpendulum, try running r2552 in 64-bit mode after disabling AVX and see whether it's stable. If I'm not mistaken, I believe AVX can be disabled through the mainboard's BIOS settings. If it's possible to disable AVX, please perform the test to prove or disprove my hypothesis. Thanks!
(05-13-2012, 02:13 AM)Itaru Wrote: Based on legend80 and thewildpendulum's cases so far, my initial hypothesis is that the new ffmpeg embedded in the new Xuggle may be using the new Intel AVX instructions. Newer CPUs (Sandy Bridge and Ivy Bridge) have a new instruction set called AVX which extends SSE. When in 64-bit mode, the new ffmpeg may be using AVX and due to a bug in ffmpeg's AVX code or in the compiler, it becomes unstable. Older generation CPUs are not affected since ffmpeg falls back to SSE. Also 32-bit mode is not affected since AVX is only available in 64-bit mode.
This hypothesis still needs to be proven though. legend80 and thewildpendulum, try running r2552 in 64-bit mode after disabling AVX and see whether it's stable. If I'm not mistaken, I believe AVX can be disabled through the mainboard's BIOS settings. If it's possible to disable AVX, please perform the test to prove or disprove my hypothesis. Thanks!
Good hypothesis. That has to be it.
I have an Asus p8p67 but I see no way in Bios to disable that (checked the manual also) unfortunately.
05-13-2012, 06:06 AM (This post was last modified: 05-13-2012, 06:22 AM by hyakki.)
I have a first gen i7 930 so I don't have the AVX extensions and the 64bit xuggle works here (no windows error reporting crashes at-least).
I dont think there is any way to disable cpu extensions, though the AVX would also take effect on the 32bit one also as i'm pretty sure its not a 64bit only instruction set, so I doubt that is causing the crashes people are experiencing. http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
Another possibility is no one is installing the correct visual c++ runtimes for 64bit (maybe they just have the 32bit ones installed), though I believe legend80 also tried installing all the runtimes.
Im going to go look through the google code issue page for xuggle and see if anyone else gets crashes in other applications.
Anyways does the new xuggle bring any new benefit to jpcsp? if not then I don't see any problem reverting.
05-13-2012, 06:20 AM (This post was last modified: 05-13-2012, 06:21 AM by legend80.)
(05-13-2012, 06:06 AM)hyakki Wrote: Another possibility is no one is installing the correct visual c++ runtimes for 64bit (maybe they just have the 32bit ones installed), though I believe legend80 also tried installing all the runtimes.
Just to confirm, I did reinstall everything (including SPs) with no effect.
05-13-2012, 06:30 AM (This post was last modified: 05-13-2012, 06:34 AM by Itaru.)
According to Intel's documentation on AVX, the new instruction set can only be accessed in 64-bit mode due to using the new VEX prefix ( http://en.wikipedia.org/wiki/VEX_prefix ) unless the documentation is wrong or I misread it. You can download the documentation at http://software.intel.com/file/37205 and it says so on the first page. I've never used AVX so I don't really know for sure.
I assumed that it's possible to disable AVX in all mainboard BIOSes, but I guess it's only a feature which is available on Intel mainboards and BIOSes. That sucks. If other people with Sandy Bridge or Ivy Bridge CPUs can confirm the instability with r2552 in 64-bit, that would help. Oh, and I guess you have to be using Windows 7 SP1 64-bit for AVX support. legend80, are you currently using Windows 7 SP1 64-bit? I assume that plain Windows 7 64-bit without SP1 will not have this problem since it doesn't support AVX yet.
