(04-10-2012, 11:22 AM)freefive Wrote: at
http://xuggle.googlecode.com/svn/trunk/repo/share/java/xuggle/xuggle-xuggler/
it claims that it supports all platforms, including win64, mac and so on.

or the old version, 3.4, is just enough?

(04-10-2012, 11:38 AM)gid15 Wrote:

(04-10-2012, 11:22 AM)freefive Wrote: at
http://xuggle.googlecode.com/svn/trunk/repo/share/java/xuggle/xuggle-xuggler/
it claims that it supports all platforms, including win64, mac and so on.

or the old version, 3.4, is just enough?

Thank you for the information!

Anyone volunteering to test Jpcsp with it? (e.g. update the Jars and DLLs from a standard Jpcsp build)

1. From http://xuggle.googlecode.com/svn/trunk/repo/share/java/xuggle/xuggle-xuggler/5.4/ go download the xuggle-xuggler-noarch-5.4.jar file.
   
2. If you use the 32-bit Windows version of JPCSP, you also need to download xuggle-xuggler-arch-i686-w64-mingw32.jar. If you use the 64-bit Windows version, you need to get the xuggle-xuggler-arch-x86_64-w64-mingw32.jar file instead.
   
3. UPDATED: Make a backup of the following files from your JPCSP lib folder to another folder:
   • xuggle-xuggler.jar
     
   • libxuggle-ferry-3.dll
     
   • libxuggle-xuggler-3.dll
     
   • libxuggle-xuggler-io-3.dll
     
   • swscale.dll
     
   • libvorbisfile-3.dll
     
   • libvorbisenc-2.dll
     
   • libvorbis-0.dll
     
   • libtheoraenc-1.dll
     
   • libtheoradec-1.dll
     
   • libtheora-0.dll
     
   • libspeexdsp-1.dll
     
   • libspeex-1.dll
     
   • libogg-0.dll
     
   • libmp3lame-0.dll
     
   • avutil.dll
     
   • avformat.dll
     
   • avdevice.dll
     
   • avcodec.dll
     
   • libx264-83.dll (only exists for 32-bit version)
     
   The dll files are located in the windows-x86 folder for the 32-bit version, or windows-amd64 for the 64-bit version. After making a backup of all those files, delete the original files. Thanks to hyakki for the list of unneeded ffmpeg dll files.
   
4. Copy the xuggle-xuggler-noarch-5.4.jar to the lib folder and rename it to xuggle-xuggler.jar.
   
5. Extract the 2nd jar file that you downloaded. You can just change the extension of that file from .jar to .zip and extract the file normally. There should be a file named libxuggle-5.dll inside. Copy this file to the windows-x86 folder for the 32-bit version, or to the windows-amd64 folder for the 64-bit version. This single libxuggle-5.dll file replaces all of the original xuggler and ffmpeg dll files which you've deleted previously.
   
6. UPDATED: If you're using revision r2530 or higher, skip this step. If you are still using an older revision and don't want to suffer the UMD Browser freeze bug for games that display video in the UMD Browser, then you must modify the JPCSP source code according to my previous post and recompile JPCSP. Alternatively if you don't want to mess with the source code, go to the JPCSP configuration dialog under the General tab and choose "Use Classic Open Dialog for UMD" instead of "Use UMD Browser" as a workaround to avoid the video freeze in the UMD Browser.
   
7. Test your games with the new Xuggle, preferably games with lots of movies. If you ever want to go back to the old Xuggle, just delete the xuggle-xuggler.jar and libxuggle-5.dll files and then restore all the original files from backup to their original location.
   

(04-12-2012, 09:12 PM)hyakki Wrote: Ill try out the new xuggle (btw looks like you can also remove all the old leftover ffmpeg dlls since they are embeded with the new libxuggle-5.dll, they are probably ok to leave but in my tests ill remove them to avoid any conflicts)

(04-12-2012, 02:21 PM)Itaru Wrote: It seems to be working, but it can cause a nasty freeze in the UMD Browser for some games due to uncaught NullPointerException in the PmfDisplayThread in the jpcsp.GUI.UmdBrowserPmf class. If the game has a video playing in the UMD Browser when you select it, it will freeze. It won't freeze if the game only displays a still image in the UMD Browser though. With Xuggle 5.4, it seems that the method toImage() in the com.xuggle.xuggler.video.IConverter class returns null. To keep it from freezing, just modify line 457 in the jpcsp.GUI.UmdBrowserPmf class to become:

Code:

457        if (display != null && getImage() != null) {
458            display.setIcon(new ImageIcon(getImage()));
459        }

The above modification will prevent the NullPointerException from happening in line 458 if getImage() happens to return null. I guess there's still a bug in the IConverter.toImage() method in Xuggle 5.4. I haven't done any extensive testing with Xuggle 5.4 yet, so who knows what other bugs lie in wait. I'll try to do more testing.