Bug 1286 - Multiple GLMediaPlayers init stream deadlock
Summary: Multiple GLMediaPlayers init stream deadlock
Status: UNCONFIRMED
Alias: None
Product: Jogl
Classification: JogAmp
Component: util (show other bugs)
Version: 2.4.0
Hardware: pc_x86_64 windows
: P4 major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2016-01-20 16:10 CET by Alan Sambol
Modified: 2016-01-20 16:11 CET (History)
1 user (show)

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments
Modified MovieSimple test that initialises 4 video streams (3.37 KB, text/x-csrc)
2016-01-20 16:10 CET, Alan Sambol
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Sambol 2016-01-20 16:10:59 CET
Created attachment 771 [details]
Modified MovieSimple test that initialises 4 video streams

When starting multiple videos at the same time (e.g. 4), 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. 

The problem only occurrs if each player's initStream() is called within 1-2 milliseconds of another.

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. 

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

It even happens even without any rendering or NEWT window initialisation - see attached test class. If loading a local video, about 50% of times all the players are stuck in Uninitialised state with the two threads described above deadlocked. When using big buck bunny video, it happens always.

If Thread.sleep() is added between each initStream() or only one window is used, the player normally enters Initialised state after a small time of being Uninitialised.

For some reason, I can't reproduce it in pure MovieSimple demo, because I can't get 4 windows shown within 1 ms, but in my application it happens fairly often that two videos are started at the same ms.