Win7_x64: Trouble with ffmpeg shared libraries

I kind of hate to post this, since these sorts of library problems often boil down to embarrassing pilot error, but I'm stuck with regards to getting JOGL to play nicely with ffmpeg on my 64-bit Windows 7 box.

The short story is this: I can't get the FFMpegMediaPlayer class to work unless I put the ffmpeg dlls (avcodec, avformat, and avutil) into my machine's System32 directory. Adding their location to my system's PATH variable or pointing to them with -Djava.library.path hasn't worked.

Here's the longer story:

Eventually I'd like to do some video processing on movie files with JOCL/JOGL, but right now I'm just trying to get the MovieSimple demo to work (presently located here: https://github.com/sgothel/jogl/blob/master/src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/av/MovieSimple.java).

When I first tried to run the demo (right out of the jar), I was immediately presented with the following error:

java.lang.RuntimeException: FFMPEG Tool library incomplete: [ avutil false, avformat false, avcodec false]
    ...
FFMPEG: Not Available

Oops. I don't have an ffmpeg installation on my box, nor any shared libraries. So I headed to ffmpeg.zeranoe.com and downloaded a pre-built windows binary of ffmpeg-0.8-win64-shared (the latest version explicitly stated to be supported in FFMPEGDynamicLibraryBundleInfo.java), unzipped it, pointed the app to it with the VM argument -Djava.library.path="path/to/downloaded/ffmpeg/bin", and ran the app again. This time, the error is slightly different:

java.lang.RuntimeException: FFMPEG Tool library incomplete: [ avutil true, avformat false, avcodec true]
    ...
FFMPEG: Not Available

For some reason, the app picked up the avutil and avcodec dlls, but not avformat (yes, the file exists as "avformat-53.dll").
I then tried clearing the java.libary.path vm argument and adding the downloaded ffmpeg binary directory to my system PATH.  Running the app in this manner, it fails to pick up any of the three needed ffmpeg libraries. As a last resort, I tried dumping the dlls straight into the System32 folder. When I try to run the app again, it seems to find what it needs for ffmpeg. Instead of an error, it prints the following:

OK: Unresolved symbol <avcodec_open2>, but has alternative <avcodec_open>
OK: Unresolved symbol <avcodec_decode_audio4>, but has alternative <avcodec_decode_audio3>
OK: Unresolved symbol <avformat_close_input>, but has alternative <av_close_input_file>
OK: Unresolved optional symbol <avformat_network_init>
OK: Unresolved optional symbol <avformat_network_deinit>
OK: Unresolved symbol <avformat_find_stream_info>, but has alternative <av_find_stream_info>
LIB_AV Util  : 51.9.1
LIB_AV Format: 53.4.0
LIB_AV Codec : 53.7.0
...

The app proceeds to run until it encounters an error opening a URL, but that's a separate problem. I don't want to leave the libraries in System32 though; I want to be able to package them with my app so I can deploy it later without requiring end-users to download/install extra stuff.

So what am I doing something wrong here? I don't understand why the app can pull the libraries out of System32 but not a folder manually added to the PATH environment variable, or why it would only pick up 2 out of 3 files when using java.library.path. I poked around briefly in FFMpegDynamicLibraryInfo and the related classes and it looks like all three libraries are being loaded in the exact same manner. Running with -Djogamp.debug=true hasn't provide me with any additional insight - I can see it's checking the right locations, but why it's passing them over remains a mystery.

Hi

System.loadLibrary() can't load a DLL of a third party library that depends on another DLL of a third party library, it works if it depends on a system library. A possible workaround consists in loading the DLLs of a third party library that directly depend on system libraries, then you load the DLLs depending on the DLLs that you have just loaded at the previous iteration and so on. Sven has probably a smarter solution to suggest.

Just ran into the same issue.

Do you happen to find a solution for this one ?

Hi

Please try the latest aggregated build, maybe the fix of the bug 832 solves your problem.

Hi Julien,

Unfortunately, no :(

Just made the update and the av-format DLL is still not loaded.

On 03/12/2013 01:49 AM, Beangonz [via jogamp] wrote: Should be PATH, not 'java.library.path', since we load a DLL
not java related.

pls make a full bug report w/ bugzilla,
and attach the full debug log (zip/7z).

thank you, will validate later.

~Sven

Hi Sven,

Ok, done here for the record : https://jogamp.org/bugzilla/show_bug.cgi?id=850

So, I guess there's no workaround for now ?

On 10/08/2013 01:10 PM, monsieur_max [via jogamp] wrote:
> Hi Sven,
>
> Ok, done here for the record : https://jogamp.org/bugzilla/show_bug.cgi?id=850
>
Thank you very much!

> So, I guess there's no workaround for now ?

Last time I tested on Windows .. it worked for me.

So I will test again later.

If I can reproduce this issue I will work on a fix.

Pplease state the FFMPEG libs version w/ download link in Bug 850
if you haven't done yet.

~Sven

Replying in case of someone makes the same mistakes as i did.

For this feature to work on Windows, you have to use PATH and not -Djava.library.path
Simple as that.

Have fun !

Imagine that you want to use it in a web video player, you'll have to ask the end user to modify the PATH environment variable :(

On 10/21/2013 01:38 PM, gouessej [via jogamp] wrote:
> Imagine that you want to use it in a web video player, you'll have to ask the
> end user to modify the PATH environment variable :(

Not if we bundle it, i.e. load via our GlueGen native lib loading.

One of the enhancements already added to our bugzilla db.

~Sven