Thank you very much for both of your responses. I will take a look at the code you both suggested.
In response to Matthew, the ODroid so far has proven to be great at almost everything. I have already turned off auto exposure and auto focus. The platform I have the camera on moves often near and far from objects as well as vibrates, so these of course caused issues.
The webcam seems to get the higher frame rate with no issue when I use external applications, such as Cheese. I even used framegrabber and another application someone made for the BBB to test and was able to get 30 fps. The problem seems to be directly related to OpenCV and how it uses v4l. Even if the resolution (in OpenCV) is set to the lowest resolution, the fps still maxes at 15fps. This rate is found with just image capture, so no other processing is performed. This seems like a hard limit that OpenCV is causing specifically on the ODroid setup.
Okay, so the problem you're having has to do with bugs in OpenCV, itself.
Unfortunately, the capture methods in OpenCV do not set the camera
properties correctly for video4linux devices. In other words, you may
write the line of code to set the frame rate to 30 fps, but the camera
isn't actually getting the instruction to change the frame rate.
The fix Matthew and I have used is to just use our own video4linux capture
code. You might be able to modify the OpenCV source code, but the capture
code is difficult to follow since there are so many layers of abstraction.
(There are a lot of wrapper classes used to handle v4l2 devices, v4l1
devices, Mac, Windows so that the programmer doesn't have to handle each
camera differently depending on his/her system.)
If you bypass OpenCV and capture directly like we did, you should test to see if you can capture successfully in YUYV format. OpenCV can convert YUYV to a Mat with less than 3% cpu use. If you capture in MJPEG, you will see cpu use of 90% or more to convert the image to a Mat. This isn’t so bad on the Wandboard because it only consumes one core, but can be intense on the single core BBB. I can tell you from testing with the Wandboard Quad, it can push 30 fps in YUYV over USB. However, it is only possible to stream from one camera at 30 fps in YUYV. In short it is a tradeoff. You can either saturate the USB and save processing or save bandwidth and increase processing. Something to consider depending on your needs.
Hello, ive been reading through this group and found it very useful. i am using an odroid U2 with a logitech c920, on ubuntu 12.11 and opencv 2.4.6.1
ive used the custom capture code found https://github.com/mdarling39/LinuxVision/blob/master/OCVCapture.cpp to capture. while it certainly uses less resources than the built in function in opencv. for some reason when i set the resolution to 1280720 the fps wont go past 10, but for any smaller resolution i am able to get 15 fps no problem. the cpu usage is not maxed out when i use 1280720 resolution.
Hello, ive been reading through the group and found i have found it very helpful. i am running an odroid u2 with ubuntu 12.11 and opencv 2.4.6.1.
i used the code i found in git :/mdarling39/ to capture from a logitech c920. i ran into an issue when i set the resolution to 1280*720 the fps would not go past 10. however for any smaller resolution i am able to get 15 fps no problem. the custom capture code certainly does use less resources than the built in opencv function. i have 2 threads, the main for capturing and the second for processing both of which do not max out their cpu so i cant figure out why im getting this fps drop.
My first question for you would be which pixel format are you capturing in? If you do a “v4l2-ctl -d /dev/videoX --list-formats-ext” in the command line (where X is 0, 1, … whatever your C920 is) you can see the various pixel formats, resolutions, and frame rates supported by the camera.
For YUYV, the maximum frame rate at 1280x720 is 10 fps. If you are using H.264 or MJPEG, the maximum frame rate is 30 fps.
I’m doubtful that that’s your problem since you are still only getting 15 fps at lower resolutions. (Can you get 30 fps at 640x480? That is the resolution I am using for my own project and might serve as a good baseline measurement.)
My only other thought for now is that your actual measurement of the frame rate could be wrong. I don’t have much experience with pthreads, but I know that some of the “clock” functions in the header have to be handled differently when you are multi-threading.
Those are my only ideas for now. I’ll keep racking my brain and let you know if I come up with something else.
you are absolutely right. at 1280x720 it is limited to 10 fps in YUYV format and i do get about 26fps in 640x480, but that could be just how fps are calculated. so it could be 30 in reality.
To make a long story short, the transfer method the PS3Eye uses to transfer data over USB doesn’t work on the BBB at high frame rates and/or high resolutions.
If the frame rate you are getting is sufficient, then the question becomes, what algorithm is being used to track faces?
Let me know what is going on, and I will help where I can.
I have done a lot of reading about using OpenCV with libjpeg-turbo on BBB and C920.
I’m running Ubuntu 12.04 with LXDE on BBB. I compiled libjpeg-turbo from source, I tried many version, 1.3.1, 1.3.0, 1.1.90 (of course I clean up before trying another version). But OpenCV seems to not recognize /opt/libjpeg-turbo/lib/libjpeg.a. After running ccmake, in Media I/O, JPEG is reported to use /opt/libjpeg-turbo/lib/libjpeg.a (ver ). Yes, the version info is missing, like that the library is not valid.
Even with version info missing, OpenCV compiled without any error, but performance is poor. I can run “time ./framegrabber -f mjpg -H 480 -W 640 -c 1000 -p” in ~34 secs, pretty close to 30 fps, but CPU usage is ~65%.
A few tips to get better video capture quality in highly dynamic motion situations:
Motion blur is not caused by low frame rate, it is caused by:
rolling shutters - global shutters exhibit much better motion capture
poor dynamic range - most sub $60 web cams have narrow dynamic ranges, so the shutter speed is often long
Insufficient light capture - between cheap optics and small CMOS chips, lower end cameras tend to do gather little light and thus, again, have long shutter times.
Note that megapixels has almost nothing to do with the above, other than that larger CMOS chips usually have higher MP. People need to stop worrying so much about resolution and demand better quality for any given resolution. <!-- your OCD wishes I had the other tag… now I’m not even going to finish this comment tag.
If you are paying less than $100 for a given camera, it is almost certainly a rolling shutter camera. If you find a good global shutter, high-dynamic range camera for < $100, please let us all know.
