This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Xuggle 5.5 (64bit) - SandyBridge/IvyBridge compatibility test
#11
hyakki, if it's not too much trouble, can you make a build of Xuggle 5.5 with AVX enabled for me to test? I just want to confirm whether it was indeed buggy AVX support which caused the instability problem. It's still possible that the instability bug is not due to AVX support in ffmpeg but due to a bug in 5.4 that got fixed in the latest GIT source. Even if it was due to buggy AVX support, perhaps that's what got fixed in the latest GIT source, in which case there shouldn't be any need to disable AVX.
Reply
#12
(11-09-2012, 12:50 PM)Itaru Wrote: hyakki, if it's not too much trouble, can you make a build of Xuggle 5.5 with AVX enabled for me to test? I just want to confirm whether it was indeed buggy AVX support which caused the instability problem. It's still possible that the instability bug is not due to AVX support in ffmpeg but due to a bug in 5.4 that got fixed in the latest GIT source. Even if it was due to buggy AVX support, perhaps that's what got fixed in the latest GIT source, in which case there shouldn't be any need to disable AVX.
sure, it will take about 30 minutes to build, I'll compile with everything default and add --enable-runtime-cpu-detect to ffmpeg.
If it wasn't buggy AVX it might of been a buggy GCC that compiled it, or it could of been fixed in the git source

Edit: Ok here is a default build with AVX and --enable-runtime-cpudetect
you should only need the .dll but I also included the other files.
Reply
#13
Thanks for the file, hyakki! Your AVX-enabled libxuggle-5.dll is crashy with Atrac3 audio just like the one included in Xuggle 5.4 on my Ivy Bridge Ultrabook. I switched back to your AVX-disabled dll file and all is well again on my Ultrabook. I also tried your AVX-enabled dll file on my non-AVX desktop PC and it works perfectly fine with Atrac3 audio as expected. I guess it really is the buggy AVX support in ffmpeg which is causing the instability problem. The AVX-enabled dll file works perfectly fine for any other audio and video formats on my Ultrabook, so I'd say the bug is isolated in the AVX code for ffmpeg's Atrac3 audio decoding routines.
Reply
#14
Thanks for the answer like always Hyakki. I hope they can update then.
Intel Core i5 - Geforce 560ti 1GB RAM - 8GB RAM - Windows 7 64bits
Reply
#15
(11-09-2012, 03:28 PM)Itaru Wrote: Thanks for the file, hyakki! Your AVX-enabled libxuggle-5.dll is crashy with Atrac3 audio just like the one included in Xuggle 5.4 on my Ivy Bridge Ultrabook. I switched back to your AVX-disabled dll file and all is well again on my Ultrabook. I also tried your AVX-enabled dll file on my non-AVX desktop PC and it works perfectly fine with Atrac3 audio as expected. I guess it really is the buggy AVX support in ffmpeg which is causing the instability problem. The AVX-enabled dll file works perfectly fine for any other audio and video formats on my Ultrabook, so I'd say the bug is isolated in the AVX code for ffmpeg's Atrac3 audio decoding routines.

ok good then narrowed it down to avx or runtime-cpudetect , maybe i'll try to make another build with avx disabled and still use runtime-cpudetect (they claim you are supposed to enable this for distribution builds)

Thanks for testing Smile
Reply
#16
(11-09-2012, 09:15 PM)hyakki Wrote: ok good then narrowed it down to avx or runtime-cpudetect , maybe i'll try to make another build with avx disabled and still use runtime-cpudetect (they claim you are supposed to enable this for distribution builds)

Thanks for testing Smile

No problem, I'd be happy to do more testing for any new build you make.
Reply
#17
Here is one with avx disabled but I kept on runtime-cpudetect (I guess it enables optimizations according to the users CPU type)
http://www.mediafire.com/download.php?ympk3tfjs5y68hn

The bug might come from this runtime-cpudetect flag, since it adjusts according to the cpu type, hopefully it is just AVX causing the bug though.
Reply
#18
(11-10-2012, 01:22 AM)hyakki Wrote: Here is one with avx disabled but I kept on runtime-cpudetect (I guess it enables optimizations according to the users CPU type)
http://www.mediafire.com/download.php?ympk3tfjs5y68hn

The bug might come from this runtime-cpudetect flag, since it adjusts according to the cpu type, hopefully it is just AVX causing the bug though.

Thanks for the build, hyakki! This one works perfectly fine on my Ultrabook when decoding Atrac3 audio, so there's nothing wrong with the runtime-cpudetect code. Looks like the culprit is the broken AVX code in ffmpeg.
Reply
#19
I've added the custom build for windows 64-bit in r2840. Could you check if the integration is correct?

Excellent work from Itaru and Hyakki to debug, resolve and test this very nasty issue!!!!
Always include a complete log file at INFO level in your reports. Thanks! How to post a log
Reply
#20
(11-10-2012, 06:44 AM)gid15 Wrote: I've added the custom build for windows 64-bit in r2840. Could you check if the integration is correct?

Excellent work from Itaru and Hyakki to debug, resolve and test this very nasty issue!!!!

Looks good, everything is working on my end.
Thanks for integrating it, hopefully it will work for everyone now Smile
Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)