Bug 1286

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.