I'm using OpenCV's Java bindings with Gstreamer as a backend API for the VideoCapture class.
As expected VideoCapture#read(Mat) is a blocking call but using the VisualVM profiler I can see that the thread remains in the RUNNING state. If I have more capture threads than there are CPU threads, then the JVM thread scheduler gets confused and other threads in the Java app get starved.
I'm sure most of the time in VideoCapture#read(Mat) is spent in an IO wait state, but since OpenCV is blocking in native code, Java does not know what the thread state is and can't schedule other threads to run.
Perhaps the Java bindings are failing to call AttachCurrentThread() in JNI so Java can't track the native thread state?