Hi Matthew, I'm a rookie in this linux/opencv area i wouldn't really know what it means, only learning from you. I posted a question https://groups.google.com/forum/#!category-topic/beagleboard/debian/VFuvveM_8Gc looking for a solution because it always happened when i plugged in the webcam on BBB. Running the command i previously mentioned ended my woes.
On Tue, May 24, 2016 at 1:04 AM, Matthew Witherwax <[email protected]> wrote: > 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. > ------------------------------ > From: Tinashe Mudavanhu <[email protected]> > Sent: 5/23/2016 4:58 PM > To: [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 >>> <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 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 >> > > [The entire original message is not included.] > > -- > 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/57438c64.87c30d0a.b3918.2ced%40mx.google.com > <https://groups.google.com/d/msgid/beagleboard/57438c64.87c30d0a.b3918.2ced%40mx.google.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/CADw4j_uWnjbQTp47Hj08bOBoAMHxvQaOnWKkJ7__%2BMzySCyEiA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
