OpenCVFrameGrabber does not operate in another Java thread's context

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create OpenCVFrameGrabber and start it in one thread - In my case it's an 
inner class implementing Runnable

2. .grab() with the new Thread - it will block forever on IplImage image = 
cvRetrieveFrame(capture) in JavaCV;

What is the expected output? What do you see instead?
This was not the same behavior as cvCreateCameraCapture(index) in which this 
was possible.

What version of the product are you using? On what operating system?
Latest - javacv-bin-20110511.zip . Windows ... strangely this works on Fedora :P

Please provide any additional information below.
I believe I can easily work around this issue by creating and starting the 
capture in the second thread, but I wanted to raise awareness to what possibly 
is a quirky OS difference in JavaCV...

I noticed there was VideoInputFrameGrabber in this new release, would you 
advise to test for OS type and use VideoInputFrameGrabber on windows machines?

Regards,
Greg.

Original issue reported on code.google.com by supert...@gmail.com on 14 May 2011 at 12:56

[GoogleCodeExporter]

Due to OS limitations FrameGrabber objects are not guaranteed to work across 
threads :(

Yes, VideoInputFrameGrabber is almost always better on Windows. 
com.googlecode.javacpp.Loader.getPlatformName().startsWith("windows"); will 
tell you if you're running under Windows. But the best alternative is to offer 
the user the choice.

Original comment by samuel.a...@gmail.com on 14 May 2011 at 1:46

• Changed state: WontFix

[GoogleCodeExporter]

Thanks Samuel,
Appreciate it.
I'll propagate the choice to the user and take your advice on a default "lowest 
common denominator"

Original comment by supert...@gmail.com on 14 May 2011 at 2:11

[GoogleCodeExporter]

FYI, I use FrameGrabber.getDefault() in my own applications...

Original comment by samuel.a...@gmail.com on 14 May 2011 at 2:16

[GoogleCodeExporter]

Wonderful,

I'll start with that....

Thanks.

Original comment by supert...@gmail.com on 14 May 2011 at 2:18

[GoogleCodeExporter]

On Mac, when i try ti instance a new FrameGrammer with 
FrameGrabber.getDefault():

Try
{
         FrameGrabber g =  FrameGrabber.getDefault().newInstance();
} catch (InstantiationException ex)
        {
            Logger.getLogger(Detector.class.getName()).log(Level.SEVERE, null, ex);
        } catch (IllegalAccessException ex)
        {
            Logger.getLogger(Detector.class.getName()).log(Level.SEVERE, null, ex);
        }

i got the following exception:

java.lang.InstantiationException: com.googlecode.javacv.OpenCVFrameGrabber
    at java.lang.Class.newInstance0(Class.java:340)
    at java.lang.Class.newInstance(Class.java:308)

Original comment by loigi...@gmail.com on 29 Jun 2011 at 12:18

[GoogleCodeExporter]

loigi..., as indicated in the README.txt file, you need to install OpenCV 2.2.0

Original comment by samuel.a...@gmail.com on 29 Jun 2011 at 4:04

[GoogleCodeExporter]

Just updated OpenCV with mac ports... It Doesn't work the same.
Maybe my code is wrong! Can you provide an example?

Original comment by loigi...@gmail.com on 2 Jul 2011 at 10:04

[GoogleCodeExporter]

http://www.google.com/codesearch#search&q=newInstance+package:http://javacv\.goo
glecode\.com

Original comment by samuel.a...@gmail.com on 3 Jul 2011 at 2:58

[GoogleCodeExporter]

Hello,
I think more than just the FrameGrabber is affected by a 2 thread interchange.
I have an example where CvRect looks invalid after being exchanged to another 
thread's context.  I looked for verification of this in the README.txt, but did 
not find it.

My work around would simply be to move the data to a Java Object.  However, the 
IplImage does not seem to be adversely affected.  Am, I just getting lucky? Or, 
can I look for differences between the two structures in JavaCV which would 
show the reason?

Original comment by supert...@gmail.com on 14 Sep 2011 at 2:50

[GoogleCodeExporter]

CvRect is just a block of memory.. AFAIK the only thing that could go wrong is 
that the address value gets passed to some C function, and comes back in Java, 
under a different reference, and then the original CvRect reference in Java is 
lost. In that case, the native memory also gets deallocated by the garbage 
collector, and the second Java reference then points to garbage. This also 
happens if the native memory is allocated in something like CvMemStorage, 
wrapped in a CvRect or CvPoint, and trying to access it after the CvMemStorage 
gets garbage collected... JavaCPP doesn't do magic with C++ unfortunately :(

Original comment by samuel.a...@gmail.com on 15 Sep 2011 at 8:28