Adam, If your issue is a low frame rate coming from the PS3Eye, I have written about this problem here http://blog.lemoneerlabs.com/post/BBB-webcams 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. Matthew On Mon, Mar 31, 2014 at 4:50 AM, <a...@ben-dror.com> wrote: > Hi all, > > I worked on this project a while back - www.ben-dror.com/pinokio I want > to get it running on a beagle bone. > I have purchased a BBB and a ps3 eye. OpenCV face-tracking seems to run at > a very low frame-rate. I guess I am looking for around 15fps. > Please any insights would be greatly appreciated. > > Adam > > > On Wednesday, February 19, 2014 9:03:43 AM UTC+13, Michael Darling wrote: > >> 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, <qsc...@gmail.com> 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, <qsc...@gmail.com> 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 < >>>>>> fndrpl...@gmail.com> 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 >>>>>>> beagleboard...@googlegroups.com. >>>>>>> >>>>>>> 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/to >>>>> pic/beagleboard/G5Xs2JuwD_4/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> beagleboard...@googlegroups.com. >>>>> 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 >>> beagleboard...@googlegroups.com. >>> 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 > beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
