jloyd / javacv

Automatically exported from code.google.com/p/javacv
GNU General Public License v2.0
0 stars 0 forks source link

OpenCVFrameGrabber does not operate in another Java thread's context #70

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
FYI, I use FrameGrabber.getDefault() in my own applications...

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

GoogleCodeExporter commented 9 years ago
Wonderful,

I'll start with that....

Thanks.

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

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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