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.
thank you. On Tuesday, February 18, 2014 2:12:16 PM UTC-5, Michael Darling wrote: > > 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 <ctime> 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. > > - Mike > > > On Sun, Feb 16, 2014 at 10:57 AM, <[email protected] <javascript:>> wrote: > >> 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/<https://github.com/mdarling39/LinuxVision/blob/master/OCVCapture.cpp>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. >> >> >> any help would be appreciated. >> >> Thanks >> >> On Thursday, January 30, 2014 3:17:40 PM UTC-5, Matthew Witherwax wrote: >> >>> 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. >>> >>> >>> On Thu, Jan 30, 2014 at 12:53 PM, Michael Darling >>> <[email protected]>wrote: >>> >>>> 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.) >>>> >>>> Hope that explains some things for you :) >>>> - Mike >>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "BeagleBoard" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>>> topic/beagleboard/G5Xs2JuwD_4/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/G5Xs2JuwD_4/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
