TextureNames creation failed when calling GLMediaPlayer.initGL

Hello there,

I've 4 media players playing different videos at the same time, in a very basic app where they are the only graphics I have.

When starting them up I get the following:

javax.media.opengl.GLException: Error initializing GL resources
        at jogamp.opengl.util.av.GLMediaPlayerImpl.initGL(GLMediaPlayerImpl.java:659)

Caused by: java.lang.RuntimeException: TextureNames creation failed (num: 4): err 0x500
        at jogamp.opengl.util.av.GLMediaPlayerImpl.createTexFrames(GLMediaPlayerImpl.java:693)
        at jogamp.opengl.util.av.GLMediaPlayerImpl.initGL(GLMediaPlayerImpl.java:633)

But this only happens around 80% of the time, sometimes I can start all 4 media players and they work fine.

It looks like glGenTextures is throwing an exception, but the only help I can find in the reference pages for that method:

http://www.khronos.org/opengles/sdk/docs/man/

is that it throws 'GL_INVALID_VALUE is generated if n is negative'.

But as the print out shows it's 4, I've call initStream using GLMediaPlayer.TEXTURE_COUNT_DEFAULT.

I'm baffled as to the cause of this exception, particularly as it only happens 'often' but not 'always'..

I'm running JOGL 2.2.0, with GL2ES2 profile, on a Linux machine using Intel Graphics with the Mesa driver 10.1.0.

Many thanks for any help as always :)

Update:

Instead of the above, sometimes I'm getting lock-wait time out exceptions from the StreamWorker threads:

Exception in thread "Thread-16-StreamWorker_1" java.lang.RuntimeException: Waited 5000ms for: <245e7588, 3576465f>[count 1, qsz 0, owner <Thread-14-StreamWorker_0>] - <Thread-16-StreamWorker_1>
        at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198)
        at jogamp.nativewindow.ProxySurfaceImpl.lockSurface(ProxySurfaceImpl.java:189)
        at jogamp.opengl.GLDrawableImpl.lockSurface(GLDrawableImpl.java:310)
        at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:654)
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:563)
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:520)
        at jogamp.opengl.util.av.GLMediaPlayerImpl$StreamWorker.makeCurrent(GLMediaPlayerImpl.java:1101)
        at jogamp.opengl.util.av.GLMediaPlayerImpl$StreamWorker.run(GLMediaPlayerImpl.java:1235)

As in post 1, this happens when I try to play another video on a second media player while the first media player is currently in the 'playing' state.

A quick timeline of events to show where the exception kicks in:

Media player 1 - call 'initStream' : state change Uninitialized -> Initialized
Media player 1 - call 'initGL' : state change Initialized -> Paused
Media player 1 - call 'play' : state change Paused -> Playing

A few seconds later while media player 1 is still in state 'Playing':

Media player 2 - call 'initStream' : state change Uninitialized -> Initialized
Media player 2 - call 'initGL' : exception thrown.

Hmm .. I tested manually w/ our 'simple' demo/test
and multiple instances w/o an issue.

Can you reproduce it w/ our demo:
  com.jogamp.opengl.test.junit.jogl.demos.es2.av.MovieSimple
?

If not, maybe you can copy/paste/patch it so it does
and offer a git pull w/ bug report.

~Sven

I've been trying that now, but I'm having trouble simply running the demo now I have 2 media players playing different videos. I'm getting different results each time I run the demo, sometimes it freezes, sometimes it throws exceptions, eg.:

pC.1b GLMediaPlayer[Uninitialized, vSCR 2147483647, frames[p 0, d 0, t 0 (0.0 s), z 0 / 166], speed 1.0, 0 bps, hasSW false, Texture[count 3, free 0, dec 0, tagt 0xde1, ifmt 0x1908, fmt 0x1908, type 0x1401], Video[id -1, <unknown>, 0x0, glOrient false, 0.0 fps, 0.0 fdur, 0 bps], Audio[id -1, <unknown>, 0 bps, 0 frames], uri http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4]
pC.1b 2 GLMediaPlayer[Uninitialized, vSCR 2147483647, frames[p 0, d 0, t 0 (0.0 s), z 0 / 166], speed 1.0, 0 bps, hasSW false, Texture[count 3, free 0, dec 0, tagt 0xde1, ifmt 0x1908, fmt 0x1908, type 0x1401], Video[id -1, <unknown>, 0x0, glOrient false, 0.0 fps, 0.0 fdur, 0 bps], Audio[id -1, <unknown>, 0 bps, 0 frames], uri http://video.webmfiles.org/elephants-dream.webm]
MovieSimple AttributesChanges: events_mask 0x20, when 1409755483747
MovieSimple State: GLMediaPlayer[Uninitialized, vSCR 2147483647, frames[p 0, d 0, t 0 (0.0 s), z 0 / 166], speed 1.0, 0 bps, hasSW false, Texture[count 3, free 0, dec 0, tagt 0xde1, ifmt 0x1908, fmt 0x1908, type 0x1401], Video[id -1, <unknown>, 0x0, glOrient false, 0.0 fps, 0.0 fdur, 0 bps], Audio[id -1, <unknown>, 0 bps, 0 frames], uri http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4]
MovieSimple State: ERR + Exception
com.jogamp.opengl.util.av.GLMediaPlayer$StreamException: RuntimeException while initializing: GLMediaPlayer[Uninitialized, vSCR 2147483647, frames[p 0, d 0, t 0 (0.0 s), z 0 / 166], speed 1.0, 0 bps, hasSW false, Texture[count 3, free 0, dec 0, tagt 0xde1, ifmt 0x1908, fmt 0x1908, type 0x1401], Video[id -1, <unknown>, 0x0, glOrient false, 0.0 fps, 0.0 fdur, 0 bps], Audio[id -1, <unknown>, 0 bps, 0 frames], uri http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4]
        at jogamp.opengl.util.av.GLMediaPlayerImpl$1.run(GLMediaPlayerImpl.java:580)
Caused by: java.lang.RuntimeException: Couldn't find audio codec 86018, Audio: aac (mp4a / 0x6134706D), 48000 Hz, 2 channels, 64 kb/s
        at jogamp.opengl.util.av.impl.FFMPEGv09Natives.setStream0(Native Method)
        at jogamp.opengl.util.av.impl.FFMPEGMediaPlayer.initStreamImpl(FFMPEGMediaPlayer.java:351)
        at jogamp.opengl.util.av.GLMediaPlayerImpl$1.run(GLMediaPlayerImpl.java:578)
MovieSimple AttributesChanges: events_mask 0x20, when 1409755484310
MovieSimple State: GLMediaPlayer[Uninitialized, vSCR 2147483647, frames[p 0, d 0, t 0 (0.0 s), z 0 / 166], speed 1.0, 0 bps, hasSW false, Texture[count 3, free 0, dec 0, tagt 0xde1, ifmt 0x1908, fmt 0x1908, type 0x1401], Video[id -1, <unknown>, 0x0, glOrient false, 0.0 fps, 0.0 fdur, 0 bps], Audio[id -1, <unknown>, 0 bps, 0 frames], uri http://video.webmfiles.org/elephants-dream.webm]
MovieSimple State: ERR + Exception
com.jogamp.opengl.util.av.GLMediaPlayer$StreamException: RuntimeException while initializing: GLMediaPlayer[Uninitialized, vSCR 2147483647, frames[p 0, d 0, t 0 (0.0 s), z 0 / 166], speed 1.0, 0 bps, hasSW false, Texture[count 3, free 0, dec 0, tagt 0xde1, ifmt 0x1908, fmt 0x1908, type 0x1401], Video[id -1, <unknown>, 0x0, glOrient false, 0.0 fps, 0.0 fdur, 0 bps], Audio[id -1, <unknown>, 0 bps, 0 frames], uri http://video.webmfiles.org/elephants-dream.webm]
        at jogamp.opengl.util.av.GLMediaPlayerImpl$1.run(GLMediaPlayerImpl.java:580)
Caused by: java.lang.RuntimeException: Couldn't find audio codec 86021, Audio: vorbis, 44100 Hz, 1 channels
        at jogamp.opengl.util.av.impl.FFMPEGv09Natives.setStream0(Native Method)
        at jogamp.opengl.util.av.impl.FFMPEGMediaPlayer.initStreamImpl(FFMPEGMediaPlayer.java:351)
        at jogamp.opengl.util.av.GLMediaPlayerImpl$1.run(GLMediaPlayerImpl.java:578)

One media player is playing:
http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4
the other:
http://video.webmfiles.org/elephants-dream.webm

This is making me worry that I've misunderstood how to use the component, but all I've tried to do is duplicate the applicable code of mPlayer for an mPlayer2, giving it a different URI in initStream, & playing/pausing it on the space bar.

Could you email / post your modified version of MovieSimple code? ( email: pdflower_3000@yahoo.co.uk )

It would be a big help to me if I can check I'm going about this the right way, e.g. how to set up multiple players. As well as confirm if what works for you on your devices works on my machine.

On 09/03/2014 04:47 PM, Peter F [via jogamp] wrote:
> I've been trying that now, but I'm having trouble simply running the demo now
> I have 2 media players playing different videos. I'm getting different results
> each time I run the demo, sometimes it freezes, sometimes it throws
> exceptions, eg.:
>

something seriously is going wrong .. probably your libav or ffmpeg version.
https://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/av/MovieSimple.java;h=0d11915285db13e81b4a7818cd6a7440a298d55a;hb=HEAD#l906

> being in jogl/make folder, enabling MovieSimple in scripts/tests.sh:

bash scripts/tests-x64.sh -windows 2 -urlN 0
http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4 -urlN 1
http://video.webmfiles.org/elephants-dream.webm

Works here ..

https://jogamp.org/files/screenshots/glmediaplayer/MovieSimple01-2urls.png

I see you're running what looks like the original MovieSimple code? but with arguments to run 2 windows through main. I was trying to add a second player so that I have two players in the same window.

Would having multiple windows mean each window has it's own unique GLContext to begin with? If so I'm not sure you'll get the deadlock to occur, if the GLMediaPlayer instances ( and more importantly the StreamWorkers ) aren't trying to all share the same initial Context given from the given GLAutoDrawable.

Are you able to run multiple players in the same window? specifically the deadlock occurs most ( but not all ) of the time when at least one media player is already playing, before you try to call initGL on another GLMediaPlayer instance.

Also, I'm not able to get the same code as you working, I'm running:

java -cp ../gluegen/build/gluegen-rt.jar:../gluegen/build/gluegen.jar:./build/jar/jogl-all.jar:./build/test/build/classes/ com.jogamp.opengl.test.junit.jogl.demos.es2.av.MovieSimple -windows 2 -urlN 0 http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4 -urlN 1 http://video.webmfiles.org/elephants-dream.webm

and either get:

1) two windows, both showing green boxes. Pressing space plays the video, but both windows show the elephants-dream.webm.

2)two windows, one showing a green box as above, but the other window is just black, no text or anything.

Running:

bash scripts/tests-x64.sh -windows 2 -urlN 0 http://archive.org/download/BigBuckBunny_328/BigBuckBunny_512kb.mp4 -urlN 1 http://video.webmfiles.org/elephants-dream.webm

gives me:

build-dir ../build-x86_64 is not a directory

I will investigate my libav & ffmpeg versions now.

Some system info:

uname -a:
Linux laptop 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

ffmpeg:
ffmpeg version 1.2.6-7:1.2.6-1~trusty1 Copyright (c) 2000-2014 the FFmpeg developers
  built on Apr 26 2014 18:52:58 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --arch=amd64 --disable-stripping --enable-avresample --enable-pthreads --enable-runtime-cpudetect --extra-version='7:1.2.6-1~trusty1' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-libcdio --enable-x11grab --enable-libx264 --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static
  libavutil      52. 18.100 / 52. 18.100
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.104 / 54. 63.104
  libavdevice    53.  5.103 / 53.  5.103
  libavfilter     3. 42.103 /  3. 42.103
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100

glxinfo:

server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.1.0
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL version string: 3.0 Mesa 10.1.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
16 GLX Visuals
36 GLXFBConfigs

On 09/04/2014 11:39 AM, Peter F [via jogamp] wrote:
> I see you're running what looks like the original MovieSimple code? but with
> arguments to run 2 windows through main. I was trying to add a second player
> so that I have two players in the same window.
>
> Would having multiple windows mean each window has it's own unique GLContext
> to begin with?
yes

> If so I'm not sure you'll get the deadlock to occur, if the
> GLMediaPlayer instances ( and more importantly the StreamWorkers ) aren't
> trying to all share the same initial Context given from the given GLAutoDrawable.
Since it works sequentially w/ one window, it shall not be an issue.

>
> Are you able to run multiple players in the same window? specifically the
> deadlock occurs most ( but not all ) of the time when at least one media
> player is already playing, before you try to call initGL on another
> GLMediaPlayer instance.

Good point - will add this use case.
You still have libav/ffmpeg issues unrelated to our JOGL,
i.e. that 'not supported coded' thingy.
  jogl/build-x86_64
  gluegen/build-x86_64
and so forth ..

I use this layour to have multiple target builds in one filesystem

~Sven

Thank you! Just to say I really appreciate all the help & feedback, it's a massive help!

I'll keep trying & see if I can find out more, I've also started to play with the android implementation.

If you get a test case working with multiple players I'd be over the moon to see how!

On 09/04/2014 10:38 PM, Peter F [via jogamp] wrote:
>
> I'll keep trying & see if I can find out more, I've also started to play with
> the android implementation.
>
> If you get a test case working with multiple players I'd be over the moon to
> see how!

Working within one window you mean, multiple window was demonstrated.

Yes, I guess I will also inject another GLMediaPlayerButton
to our graph UI demo.

Testing at least 2-3 instances to proof proper code cannot hurt.

~Sven

Yes, multiple players in one window.

The use case I have is a single window application, where the UI is a grid of cells/widgets, with each cell needing to be able to play a video at any arbitrary point in time - so multiple cells could be playing different videos at the same time - while drawing other graphics if not playing a video.

The problem is, when there are cells already playing videos, when other cells are being setup ( initStream(), initGL(), play() ) This is where the StreamWorkers - one of the already playing media players workers & the worker of the media player currently within the initGL call - can get deadlocked.

I've noticed if I pre-initialise videos while no others are playing, everything is ok ( I call initStream() & initGL() on all players before any of them call play() ). But this isn't something I will be able to do in the end - as there are so many different videos that can be played and I can't pre-load them all.

When I asked about the GLContext being unique per window, I thought that perhaps the problem might be that as it's a single window & thus all players are sharing the same original GLContext, the StreamWorkers, while one is running & one is being initialised, are becoming deadlocked while trying to make the context current?

Exception in thread "Thread-16-StreamWorker_1" java.lang.RuntimeException: Waited 5000ms for: <245e7588, 3576465f>[count 1, qsz 0, owner <Thread-14-StreamWorker_0>] - <Thread-16-StreamWorker_1>
        at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198)
        at jogamp.nativewindow.ProxySurfaceImpl.lockSurface(ProxySurfaceImpl.java:189)
        at jogamp.opengl.GLDrawableImpl.lockSurface(GLDrawableImpl.java:310)
        at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:654)
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:563)
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:520)
        at jogamp.opengl.util.av.GLMediaPlayerImpl$StreamWorker.makeCurrent(GLMediaPlayerImpl.java:1101)
        at jogamp.opengl.util.av.GLMediaPlayerImpl$StreamWorker.run(GLMediaPlayerImpl.java:1235)

If I understand this correctly the newly initialising StreamWorker_1 is stuck waiting for a lock held by StreamWorker_0. StreamWorker_0, I assume, is the one currently attached to the already playing GLMediaPlayer & StreamWorker_1 is attached to the newly created player currently within it's initGL call. Could StreamWorker_0 also be stuck waiting for a lock held by StreamWorker_1?

Hello,

I know it's been a while since this came up, but I thought I'd get back in touch to let you know how things have turned out thus far.

I'm still not 100% sure what is causing the stream workers to become locked, but the chances are it's threading issue caused by our code - we have a multi-threaded system that isn't exactly thread safe yet, in particular when it comes to rendering it seems... So it looks like that one is on me.

I've been trying to get the GLMediaPlayer running on Android with mixed success, but in this case, failure would seem to be the result of the Android unit's MediaServer returning Codec instances that aren't compatible. I notice that JOGL's Android GLMediaPlayer uses an Android MediaPlayer, and then using the OpenGL texture ID contained within the SurfaceTexture, given to the Android MediaPlayer, to re-draw the video frame texture elsewhere. Pretty neat :)

You may be interested to know that this only seems to work where the devices MediaServer returns an instance of Android's OMXCodec - My theory is that only this really knows how to interact with the surface supplied by the Android Framework. I've had to circumvent JOGL slightly here and use Android's MediaCodec class, which is more likely to get an OMXCodec instance back from the OpenMax layer.

This is only on a select few devices that we're trying out, they're Android smart TV boxes from different Chinese manufacturers. The fault likely lies in their software - one drawback of an open source OS, or it could be their GPU firmware / drivers... I've tried running the JOGL demos from the Android Play Store, and the video ones don't work properly, if at all, on these devices.

For example, one device we tried was the Neo Minix:

When running the video cube demo, no video frames are drawn on the cube, the space where it should appear is black. However, the video frame does appear drawn behind the cube across the whole screen. In the logcat the device is not using the OMXCodec of the Stagefright library ( Can't quite remember which it does use, maybe ffmpeg ).

In conclusion, I don't think there's anything you need to worry about, I think the only thing to take away from this is that devices might not be correctly configured, so don't work as expected. On other devices I've tried, HP slate, Nexus7, Galaxy Tab, they all work fine with the JOGL and Android MediaPlayers.

Pete.

Hi,

probably the same problem here.

In our application we have instantiation of multiple video-containing windows and the problem occurs almost every time we run it.
We tried to reproduce the problem in a different project, so we chose MovieSimple.java demo which we modified so it deals with 4 videos and we managed to reproduce the same problem, but not so often - it occurs every once in a while.
We suspect the problem lies in time delay between video initializations and number of used videos - the shorter the time orgreater the number of videos, the greater the chance of problem manifestation.

Here are the console outputs of both projects:
1. Our application: http://pastebin.com/t2wj59pj (the ms time-stamp of a single video initialization are in  ">>>>>>>>>> 1441438808588" form)
2. MovieSimple.java modified demo: http://pastebin.com/P4G8LjYT

I managed reproduced a similar deadlock in a scenario when starting multiple videos (e.g. 4) at the same time, in 4 separate NEWT windows, at the same time. Using shared or different contexts and animator threads per window doesn't change anything.

It happens about 50% of the time and when I enable -Djogl.debug.GLMediaPlayer the problem goes away (probably the printing slows it enough to avoid deadlock).

The exact problem is that all 4 videos sometimes get stuck in Unintialized state after calling initStream() on GLMediaPlayer, with no exceptions thrown. I have traced the problematic threads to:
GLMediaPlayerImpl line 582: initStreamImpl(vid, aid);
FFMPEGMediaPlayer line 375: natives.setStream0(moviePtr, resStreamLocS, isCameraInput, vid, sizes, rw, rh, rr, aid, aMaxChannelCount, aPrefSampleRate);
FFMPEGv11Natives.setStream0(long, String, boolean, int, String, int, int, int, int, int, int) line: not available [native method]

The debugger show two threads with generic names (e.g. Thread-6 and Thread-7) stuck at the same line. When the problem doesn't occurr, those threads are not present.

Changing textureCount to 1 or 4 changes nothing (except with 4 I get 4 StreamWorker threads if the 2 above threads exit normally, otherwise no StreamWorkers get spawned at all).

When I manually introduce a synchronisation mechanism that ensures that each video's initStream() gets called only after previous video is NOT in state Uninitialised, everything works ok 100% of the time, however it would be nicer to be fixed under the hood.

It's hard for me to share a SSCCE since I'm working inside our framework built with Jogl but I guess the problem could be easily reproduced on a fast enough machine with MovieSimple x4 demo, with turning off all console prints.

I'm working on Windows 10 x64, using ffmpeg-2.8.3-win64-shared. Tried multiple libav and ffmpeg versions, same thing.

Does anyone have an idea what might be causing this? Is it a Jogl Java or native part error, or maybe something to do with ffmpeg?

Instead of guessing, why don't you try to reproduce this problem with MovieSimple x4 and all console prints off as you suggest? Thank you for your investigation.

I managed to reproduce it in MovieSimple after a lot of code cutting. At first, I couldn't get MovieSimple demo to spawn four windows within 1 millisecond (usually 20+ ms per window), whereas in our framework all windows take a total of 1 millisecond to initialise (not sure how something built with Jogl can be faster than raw demo itself, using the same jars, but I'll take that as a compliment :)). The problem only occurrs if initStream() is called within a few milliseconds multiple times for multiple GLMediaPlayers.

The only way I could get MovieSimple to load them that fast was turning off NEWT window initialisation and rendering completely.

The following piece of code gives GLMediaPlayers stuck in Uninitialised state roughly 50% of the time, with the same threads deadlocked as in post above:
        for(int i=0; i<windowCount; i++) {
            mss[i] = new MovieSimpleDeadlock(null);
            mss[i].initStream(defURI, vid, aid, textureCount);
            System.out.println("Init stream " + System.currentTimeMillis());
        }
       
        while (true) {
        for(int i=0; i<windowCount; i++) {
            System.out.println(mss[i].mPlayer.getState());
        }
        }

Should I submit a bug report?

Whole modified MovieSimple runnable demo:
<nabble_a href="MovieSimpleDeadlock.java">MovieSimpleDeadlock.java

EDIT: Seems like attaching files doesn't work, here it is again: http://pastebin.com/2n6r81vf

Yes fill a bug report and of course your test case is helpful, thanks.

Bug report here: https://jogamp.org/bugzilla/show_bug.cgi?id=1286

On a related note, I also discovered that calling GLMediaPlayer.destroy() while it is loading a video in Uninitialised state (very tiny window of time) causes JVM crash:

Stack: [0x000000007d590000,0x000000007d690000],  sp=0x000000007d68f030,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [jogl_desktop.dll+0xb530]
C  0x0000000002465e34

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.util.av.impl.FFMPEGv11Natives.setStream0(JLjava/lang/String;ZILjava/lang/String;IIIIII)V+0
j  jogamp.opengl.util.av.impl.FFMPEGMediaPlayer.initStreamImpl(II)V+581
j  jogamp.opengl.util.av.GLMediaPlayerImpl$1.run()V+12

Good finding. Maybe GLMediaPlayer.destroy() should check that the video isn't uninitialized before trying to dispose its native resources.