Hello dear jogamp maintainers. This case happens on a linux desktop where ffmpeg libraries too recent for jogamp are installed. To ensure that decoding is possible, I provide *working* ffmpeg libraries with my program. There are embedded and loaded using LD_LIBRARY_PATH. It works perfectly fine on computers not having such libs installed and computer having older libs installed. However, when the system has more recent libs, some "future proof" code loads thoses too recent libs. Those libs are not compatible with the current jogamp code. The issue is located in FFMPEGDynamicLibraryBundleInfo::getToolLibNames(). For each libs you'll notice a "dummy future proof" lib version. In a perfect world, the best solution would be to have an updated jogamp that manages the latest ffmpeg versions. But even in this case, adding unsupported versions to the list of the accepted library names is not so future proof. Any idea on a workaround while waiting for a fix ? Thanks in advance. Maxime
A little try and fail later, I found an easy workaround for this issue. The workaround consists in : - providing the latest working ffmpeg libs for jogamp in a directory - create symbolic linksfor every .so and name them with the latest version - use LD_LIBRARY_PATH to specify this directory at program launch As an example, here are the commands I executed inside the directory : ln -s libavcodec.so.56 libavcodec.so.57 ln -s libavdevice.so.56 libavdevice.so.57 ln -s libavfilter.so.5 libavfilter.so.6 ln -s libavformat.so.56 libavformat.so.57 ln -s libavresample.so.2 libavresample.so.3 ln -s libavutil.so.54 libavutil.so.55 ln -s libswresample.so.1 libswresample.so.2 ln -s libswscale.so.3 libswscale.so.4 ln -s libvpx.so.2 libvpx.so.3 ln -s libvpx.so.2 libvpx.so.4
Please follow Bug 1420, which shall cover this issue including providing self deployed ffmpeg libs. Will resolve this issue for 2.4.0 release. *** This bug has been marked as a duplicate of bug 1420 ***