The issue causing the select time out detailed in my article has to do with how much data is being sent over the USB and how it is sent. Reducing the frame rate reduces the load on the USB. Looking at the articles you linked, one says it solved an issue but not the select timeout, and the other shows an error message that says it could not allocate memory. Neither one of these are the cause of the select timeout I addressed.
The select timeout occurs when the select times out. Looks like in the cases in your links a previous call to allocate memory failed followed by select failing. I have never had an issue with memory allocation. All my troubles had to do with too much data on the USB. You might want to confirm what your actual problem is. -----Original Message----- From: "Tinashe Mudavanhu" <[email protected]> Sent: 5/23/2016 4:58 PM To: "[email protected]" <[email protected]> Subject: Re: [beagleboard] Re: VGA camera capture Hi Matthew, I looked into the article as i went through your discussion but did not try the framegrabber.c, will test it though. I finally got a solution to the problem from links listed below. It kind of made sense to me (lack of memory in ARM systems) because running the same code on my PC worked perfectly well. Running this command `sysctl vm.overcommit_memory=1` worked for me after a long struggle. What i'm not really sure are the implications (being it on Hardware or Software) if there comes a state when large size memory is really needed. [1]: https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=17773 [2]: https://tequals0.wordpress.com/2014/03/24/libv4l2-error-allocation-conversion-buffer-using-opencv-on-a-pi/ On Mon, May 23, 2016 at 10:25 PM, Matthew Witherwax <[email protected]> wrote: 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. 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 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 <a [The entire original message is not included.] -- 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/57438c64.87c30d0a.b3918.2ced%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
