Hi Tinashe, Please see my article here http://blog.lemoneerlabs.com/post/BBB-webcams There is a version of framegrabber.c linked to it that allows you to specify the frame rate with the command line parameter -I. If reducing the frame rate works for you, then the code for framegrabber should provide a starting point for accomplishing the same thing in your own program.
On Mon, May 23, 2016 at 2:43 PM, Tinashe Mudavanhu <[email protected]> wrote: > Firstly i would like to say i came across your discussion looking for > select timeout error solution but as i went through it i didnt notice if > you found a solution, but if you have it now, i would appreciate it. The > select timeout error still seems to be in existence even on BBB Rev C with > kernel 3.8.13-bone79. I am working on an Iris recognition system that > initially has to track eyes in a live video stream (from there captures > cropped eye images that will be processed). I have installed different > OpenCV versions, 2.4.9, 2.4.11 and 3.0.0 and in all of them i am getting > the same error. I am working with a Logitech, Inc. QuickCam E 3500 webcam. > I am accessing the BBB Desktop using Tightvnc client on my PC running > Ubuntu 14.04 LTS. > > What is surprising is that it is capable of video streaming with opencv > installed by apt-get (apt-get install python-opencv) but the limitation > with this version is that it has very old cv bindings and documentation on > some functions for Histogram equalisation is not available online. I am > stuck, i need your help. > > On Tuesday, 10 September 2013 16:50:46 UTC+2, Matthew Witherwax wrote: >> >> Getting another BBB or raspberry pi probably wont help, but a U2 from >> HardKernel here >> http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341370451 >> probably would. You can use the BBB to do all IO and use the processing >> power of the U2 to handle compute intensive tasks. That is actually my end >> goal. The cpu use I stated earlier was without showing the image. >> Displaying the image will increase cpu use. >> >> I am also working on a tracking application with the webcam mounted on a >> servo. For my purposes, I do not need to see the image on the BBB and can >> push it over wifi to my laptop if I want to view it. >> >> As far as cv code, what are you looking for? I have posted a tool on my >> blog here http://blog.lemoneerlabs.com/post/shades-of-red to help you >> find HSV values from images to allow you to to find values to threshold >> target colors. I will post another one on using HSV ranges to threshold an >> image to isolate things like a red colored ball. I have been implementing >> OpenCV code using python right now for experimentation, but you should be >> able to translate it to C++ or your language of choice. >> >> The command v4l2-ctl --list-formats-ext will tell you the pixel formats >> and resolutions supported by your camera. >> >> Hope this helps, >> >> Matthew Witherwax >> >> >> On Tue, Sep 10, 2013 at 8:48 AM, James Richins <[email protected]> >> wrote: >> >>> Matthew, >>> >>> It does remind of something on Derek Molloy's site in that he adds >>> coding to deal with the h264 codec for taking stills with opencv. I >>> hesitated at the idea. Interestingly even using an additional bbb or >>> raspberry pi might not even help. I'm looking at camera tracking >>> objects/object recognition and servo control. >>> I might find that by not displaying the video on the monitor, that the >>> tracking and servo control can work less than 100% CPU. >>> I have yet to implement the cv code for that, it's a real struggle to >>> find good code. And not get errors. I have managed servo control through >>> python and manual entering numbers so its ultimately possible. >>> I'm not sure if my camera does anything other than yuyv. I'd be >>> interested in connecting an Ethernet cam to the Ethernet port and read >>> camera data from there, but you'd probably run into the same problem. >>> Ethernet cam to pc processing cv code, wifi to beaglebone servo control >>> might be good. But its probably a slow process and too complicated for me. >>> >>> Anyway good luck with your project. >>> >>> James >>> >>> On 10 Sep 2013, at 13:57, Matthew Witherwax <[email protected]> wrote: >>> >>> James, >>> >>> I have not done any cpu testing other than while saving single frames. >>> In MJPEG format, capturing a single frame at 1920x1080 30 fps and saving it >>> was taking about 6% cpu. Doing the same in YUYV at a reduced resolution >>> and converting to jpeg was taking about 70%. I would not rush out to buy a >>> h264 camera. First, I am not sure OpenCV decodes h264 streams. Second, if >>> it did, I am not sure you would see much improvement because of the need to >>> decode the h264 stream. If the BBB does this in hardware is likely wont be >>> bad, but if it is a software implementation we are just shifting the >>> burden. I am currently working through several tradeoffs. YUYV should >>> give the truest image free of compression artifacts, but will be larger and >>> require more resources to capture and process. MJPEG may suffer from >>> compression artifacts, but images can be captured more quickly and at >>> higher resolutions. One has to decide what combination of frame rate, >>> resolution, and fidelity are required. I am currently working through the >>> permutations to see what suits my application. >>> >>> An option I have open is to send the captured images over a wifi link to >>> a computer that runs all the OpenCV code and pipes back the data I am >>> after. This leaves the BBB mostly free to do other work. I will update as >>> I progress. >>> >>> Matthew Witherwax >>> >>> >>> On Tue, Sep 10, 2013 at 7:35 AM, James Richins <[email protected] >>> > wrote: >>> >>>> >>>> >>>> Did you register anything on CPU usage. I know running moustache >>>> placing cv code it will run at 100% CPU on a standard webcam. Is pre >>>> processing less cpu intensive or will cv code always push the bb to the >>>> max? >>>> I didn't think I'd rush to buy a h264 hardware encoding cam if its the >>>> software and running at 320 is just as efficient as preencoded hd video. >>>> >>>> >>>> On 10 Sep 2013, at 13:16, Matthew Witherwax <[email protected]> wrote: >>>> >>>> João, >>>> >>>> 1. Glad to hear you are making progress. My blog is at >>>> blog.lemoneerlabs.com. Unfortunately I have yet to post my write up >>>> on the USB cameras, but I will get it done soon. I can tell you with the >>>> Logitech C920 it is possible to capture 1920x1080 frames with the FPS set >>>> to 30 in both MJPEG and YUYV format. >>>> >>>> 2. v4l2grab sets the format to YUYV before grabbing the frames. It >>>> then converts the captured frame to a jpeg and saves it. I will post a >>>> version to my blog this week that uses MJPEG instead. Typical MJPEG >>>> implementations encode each video frame as a jpeg. The code I wrote puts >>>> the webcam in MJPEG mode for capture and saves the returned frame. In the >>>> case of the Logitech C920, the returned frame is a jpeg image. It seems by >>>> going this route the camera actually creates the jpeg sparing the BBB from >>>> having to do it. In addition, the jpeg is considerably smaller than the >>>> YUYV frame resulting in less load on the USB. I would appreciate you >>>> testing the output when I post the code as it is entirely possible that not >>>> all cameras handle MJPG the same, and the result might not be a valid jpeg. >>>> >>>> 3. 13.2 MB/s is the limit I was able to reach through testing. You >>>> should note the webcam I tested with for that number only did bulk >>>> transfers which guarantee delivery. It may be slightly higher for >>>> isochronous transfers as frames can (and seem to) get dropped. I am not >>>> sure why that is the limit. It maybe a hardware issue or a USB driver >>>> implementation issue. During further testing on several laptops, the newer >>>> ones could reach a higher throughput even though all had a USB 2 bus which >>>> would lead me to believe it is hardware related, but it is a question for >>>> the hardware guys. >>>> >>>> 4. I will post my code this week. Please test it with your MJPEG >>>> capable cameras, and let me know the results. >>>> >>>> 5. The UVC implementation in Linux does not support still image >>>> capture. This means tools like v4l2grab set the camera to record in a mode >>>> that uses no compression or intra-frame compression ( >>>> http://en.wikipedia.org/wiki/Intra-frame) and then grab frames from >>>> the stream. This is why the format and frame rate affect the capture. The >>>> stream has to be open and the data pulled before we can grab an image. >>>> >>>> 6. Possibly, see 3. >>>> >>>> 7. For my purposes, I have not tested plug-and-play so I cannot say >>>> much about it. >>>> >>>> >>>> On Mon, Sep 9, 2013 at 1:15 PM, João M. S. Silva < >>>> [email protected]> wrote: >>>> >>>>> Thanks Matthew, Don. >>>>> >>>>> Here is my follow up: >>>>> >>>>> 1. Matthew, what is you blog address? >>>>> >>>>> 2. I compiled v4l2grab and used the -I switch to adjust the fps. I >>>>> found out that with the Logitech camera I can capture 640x480 at up to 6 >>>>> fps. With -I 7 or above, it hangs. With another cheap camera, even -I 1 >>>>> hangs! >>>>> >>>>> 3. Is 13.2 MB/s somehow BBB's limit? Why? >>>>> >>>>> 4. My cheap cameras are YUYV capable and one of them is MJPEG capable. >>>>> The Logitech is both YUYV and MJPEG capable. >>>>> >>>>> 5. As I've read elsewhere UVC does not allow to get still images, so >>>>> video performance issues affect still image capturing, right? is there a >>>>> way to capture pure still images (bandwidth limitations should be >>>>> irrelevant in that case)? >>>>> >>>>> 6. Overall, this is an issue from the BBB, right? All of this works in >>>>> my laptop and in BBXM. Is it a bug from the BBB USB implementation? >>>>> >>>>> 7. I also found BBB's USB is not really plug-and-play. Sometimes >>>>> devices don't get recognized and a reboot is needed. >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> 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/2NO62mGcSvA/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/2NO62mGcSvA/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/2NO62mGcSvA/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/2NO62mGcSvA/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/2NO62mGcSvA/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/2NO62mGcSvA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/ecbcf781-d04a-4a40-b6d3-1a33e5e26267%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/ecbcf781-d04a-4a40-b6d3-1a33e5e26267%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAD6ZcAVYeJGAbrsrC2PK34S-5suznkhj53%3DoK%2Bg-YRX6O27G-w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
