rindarith / javacv

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

HIGHGUI ERROR: V4L2: getting property #0 is not supported #89

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
In 

http://code.google.com/p/javacv/source/browse/trunk/javacv/src/com/googlecode/ja
vacv/OpenCVFrameGrabber.java#174

Line 174

return_image.timestamp = Math.round(cvGetCaptureProperty(capture, 
CV_CAP_PROP_POS_MSEC)*1000);

returns a system error:
HIGHGUI ERROR: V4L2: getting property #0 is not supported

I don't know your intended design for this framegrabber, but might this get a 
regular timestamp, if the this particular framegrabber is to support "general - 
cheap webcams" ?  I don't think most webcams have a "film current position in 
milliseconds or video capture timestamp"...

Original issue reported on code.google.com by supert...@gmail.com on 24 Jul 2011 at 9:49

GoogleCodeExporter commented 9 years ago
You can comment out that line if you find the "error" annoying, or ask the 
OpenCV team to "fix" it somehow. They could for example provide the system 
timestamp when the image was retrieved... but ask them why they provide an API 
that is not functional, not me.

Original comment by samuel.a...@gmail.com on 25 Jul 2011 at 7:20

GoogleCodeExporter commented 9 years ago
Hello Samuel,
I certainly did not intend to offend you in any way.  That's why I was saying 
that I did not know your "intended design", to state my ignorance.  I do know 
and appreciate your project, and have enough experience with it to know that 
you are an exceptional designer.  

I was getting this error and started to look into the details. If this function 
is not called the time getting a frame is decreased by ~10-20 ms - there is no 
System error message either.  I was wondering if the design was to support 
cheap web cams because of the comment in the source, "// default to a gamma of 
2.2 for cheap Webcams, DV cameras, etc." for gamma support.

Looking at it a little deeper, it appears this is a bug from OpenCV
"CV_CAP_PROP_POS_MSEC Film current position in milliseconds or video capture 
timestamp"

I mistakenly thought it was for AVI files/format only.

I have entered a ticket as you suggested 
https://code.ros.org/trac/opencv/ticket/1254 and hopefully they will change it 
in my lifetime.

In the interim, I could change it in JavaCV - but I don't want to add 
unnecessary, unsupported, or unwanted code with my ignorant bumbling. 

Through my application, I'll give the end user the option of any FrameGrabber 
with the additional ability to switch to the method of just opening a 
cvCreateCameraCapture since this, without the error currently has the best 
performance.

Again, thanks for your guidance and any more suggestions you might have.

Regards,
Greg.

Original comment by supert...@gmail.com on 25 Jul 2011 at 5:14

GoogleCodeExporter commented 9 years ago
You're welcome, and don't worry, you did not offend me.. I'm just annoyed that 
things always seem incomplete.

I did not realize that line had a performance hit. Maybe there is some problem 
with the screen I/O on your machine? Anyway, when I said you can modify JavaCV, 
I meant for your own version in your application. Just bundle your own modified 
javacv.jar. I don't consider commenting out one line to conflict with the 
license. That's why I make the source code available in the first place :)

Original comment by samuel.a...@gmail.com on 26 Jul 2011 at 4:14

GoogleCodeExporter commented 9 years ago
Thanks for the suggestion, but I think I'll let the end user deal with 
selecting the appropriate grabber/capture (until willowgarage fixes hit, ha!). 
I could change it and re-build the jar, but it would be something to merge each 
time I got an update from javacv, which I do not want to do.
Regards,
Greg.  

Original comment by supert...@gmail.com on 26 Jul 2011 at 5:19

GoogleCodeExporter commented 9 years ago
Hum, I'll check what kind of values it returns when it fails. If it does not 
change starting from the second frame, I could simply assume that any future 
values are also invalid and we can stop calling it...

Original comment by samuel.a...@gmail.com on 26 Jul 2011 at 5:23

GoogleCodeExporter commented 9 years ago
Fixed in latest release

Original comment by samuel.a...@gmail.com on 20 Aug 2011 at 1:33

GoogleCodeExporter commented 9 years ago
Thanks !
Speed of light faster than willow garage :)

Original comment by supert...@gmail.com on 20 Aug 2011 at 1:36