Glad I could help. =] Let me know what you find out after looking into it a little bit more!
On Tue, Feb 18, 2014 at 11:31 AM, <[email protected]> wrote: > 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]> 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/to >>>>> pic/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]. >>> 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]. > 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.
