I have finally managed to get a video stream (at least i can say for now) by changing the frame resolution inside the python opencv code using instructions on http://stackoverflow.com/questions/11420748/setting-camera-parameters-in-opencv-python. The maximum resolution i can set it to was 640x480 with a 5fps frame rate, increasing the frame rate will result in a select timeout message. At 320x240 i can set it up to 30fps and running htop the CPU utilization will be fluctuating around 86-90%. The python code was taking about 12% and most of the chunk was on tightvnc about 60% (maybe because of the frame window being displayed).
This is the code i was running; import cv2 #capture from camera at location 0 cap = cv2.VideoCapture(0) #set the width and height, and UNSUCCESSFULLY set the exposure time cap.set(3,320) cap.set(4,240) cap.set(5, 30) while True: ret, img = cap.read() cv2.imshow("input", img) #cv2.imshow("thresholded", imgray*thresh2) key = cv2.waitKey(10) if key == 27: break cv2.destroyAllWindows() cap.release() And also the resolution i forced the camera to in the opencv code is the one displayed after running v4l2-ctl -V; root@beaglebone:~/Project/Testing# v4l2-ctl -V Format Video Capture: Width/Height : 320/240 Pixel Format : 'YUYV' Field : None Bytes per Line: 640 Size Image : 153600 Colorspace : SRGB root@beaglebone:~/Project/Testing# What you figured out about bandwidth is really a serious issue. I have a friend who did not experience this problem on their RPi (only much higher resolutions resulted in select timeout messages, message because i don't think it is an error) maybe because it has many USB ports meaning higher bandwidth compared to BBB with only one. I wonder what will happen when connecting the BBB wirelessly, with a wifi dongle and camera on a USB hub. On Thu, May 26, 2016 at 8:39 AM, Tinashe Mudavanhu <tinam...@gmail.com> wrote: > Silva, > > It does have MJPEG but opencv is converting the format to YUYV. And also > does your board have I/O pins digital and analogue? > > On Thu, May 26, 2016 at 8:35 AM, Tinashe Mudavanhu <tinam...@gmail.com> > wrote: > >> The 160x120 video stream had no latency but the other camera with >> 1280x720 was slow, video was displayed as images being flipped like book >> pages. >> >> I need to understand something from your files. Does it mean the rest of >> my iris recognition code has to be in the framegrabber.py client file and >> also this file can also run on BBB? Do i need the zhelper.h file when my PC >> is running Ubuntu? >> >> Here is my setup like. I have a PC running Ubuntu connected to the BBB >> via usb and also sharing internet via the same cable (there is no wired >> connection, only the PC is connected to wifi). I want to see the video >> stream on my BBB for debugging purposes and once it is working fine it >> doesn't have to show the video stream. I am accessing the BBB Desktop/GUI >> via a tightvnc client running on my Ubuntu PC. Thats when i will move to >> the hub for a wired connection so that everyone connected to the hub can >> access web pages served by the BBB (running lighttpd webserver). >> >> I was successful in the part of running BBB as a webserver (without an >> video stream to show on the site because i don't need it) but then the >> first part of getting a video stream to show was not possible because of >> select timeout errors. >> >> On Thu, May 26, 2016 at 12:35 AM, Matthew Witherwax <ablec...@gmail.com> >> wrote: >> >>> Looks like framegrabber was able to capture images based on the output >>> you provided. Did you look at the images? >>> >>> If it works for you then the code for the subscriber here >>> http://blog.lemoneerlabs.com/post/bbb-mjpeg-streaming will show you how >>> to load it into opencv. >>> ------------------------------ >>> From: João M. S. Silva <joao.m.santos.si...@gmail.com> >>> Sent: 5/25/2016 4:13 PM >>> To: beagleboard@googlegroups.com >>> >>> Subject: Re: [beagleboard] Re: VGA camera capture >>> >>> If the camera has a good compression mechanism (e.g. MJPEG), it may be >>> softer on the USB bus. >>> >>> In our board, we are using OpenCV but we don't capture images with the >>> OpenCV instruction. Instead, we use something like this: >>> >>> https://linuxtv.org/downloads/v4l-dvb-apis/v4l2grab-example.html >>> >>> For video capturing there is also an example: >>> >>> https://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html >>> >>> Note that OpenCV uses v4l underneath. >>> >>> On 25/05/2016 16:51, Tinashe Mudavanhu wrote: >>> > Silva, >>> > >>> > There has to be way. Dereck Molloy >>> > https://www.youtube.com/watch?v=8QouvYMfmQo was able to get a video >>> > stream then its possible to video stream with BBB. I don't have much >>> > time to look for another development board because the Project is due >>> > next week. >>> > >>> > On Wed, May 25, 2016 at 5:48 PM, Tinashe Mudavanhu <tinam...@gmail.com >>> > <mailto:tinam...@gmail.com>> wrote: >>> > >>> > Hi, >>> > >>> > The same is happening on the other webcam i have (not sure if its >>> > openCV changing resolution). I bought it on AliExpress and has the >>> > following discription; HD 1.3 megapixel 960p 2.8-12mm varifocal >>> lens >>> > Aptina AR0130 android external usb camera module with IR cut >>> > ELP-USB130W01MT-FV >>> > < >>> http://www.aliexpress.com/item/HD-1-3-megapixel-2-8-12mm-varifocal-lens-android-external-usb-camera-module-with-IR/32295825258.html >>> >. >>> > The supplier can be found on http://www.elpcctv.com. >>> > >>> > Since there are no errors, what could be the problem? Is there some >>> > dependencies i have to install? >>> > >>> > I tested with your framebrabber.c code and was getting this (see >>> > below) with the Logitech webcam, >>> > >>> > root@beaglebone:~# time ./framegrabber -f mjpeg -H 480 -W 640 -c >>> > 1000 -I 30 >>> > Startup took 0.010000 seconds >>> > Captured 1000 frames in 0.220000 seconds >>> > Shutdown took 0.000000 seconds >>> > >>> > >>> > real 0m42.068s >>> > user 0m0.025s >>> > sys 0m0.223s >>> > >>> > The no name webcam was giving the following results; >>> > root@beaglebone:~# time ./framegrabber -f mjpeg -H 480 -W 640 -c >>> > 1000 -I 30 >>> > Startup took 0.020000 seconds >>> > Captured 1000 frames in 0.260000 seconds >>> > Shutdown took 0.000000 seconds >>> > >>> > >>> > real 2m10.965s >>> > user 0m0.033s >>> > sys 0m0.262s >>> > root@beaglebone:~# >>> > >>> > >>> > >>> > On Wed, May 25, 2016 at 5:23 PM, Matthew Witherwax >>> > <ablec...@gmail.com <mailto:ablec...@gmail.com>> wrote: >>> > >>> > There are no actual errors in the output you posted. >>> > >>> > Do you have access to any other webcams? I have tested this >>> > with the Logitech C920, the Logitech C270, and the PS3Eye. >>> > Without access to your webcam, it is hard for me to look into >>> > what is going on. >>> > >>> > >>> > On Wednesday, May 25, 2016 at 8:57:55 AM UTC-5, Tinashe >>> > Mudavanhu wrote: >>> > >>> > The timeout error resurfaced again, i followed you blog >>> post >>> > on >>> > >>> http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html >>> > but got the following errors in compiling libjpeg-turbo ; >>> > >>> > root@beaglebone:~/libjpeg-turbo-1.3.0/build# make >>> > make all-recursive >>> > make[1]: Entering directory >>> `/root/libjpeg-turbo-1.3.0/build' >>> > Making all in java >>> > make[2]: Entering directory >>> > `/root/libjpeg-turbo-1.3.0/build/java' >>> > make[2]: Nothing to be done for `all'. >>> > make[2]: Leaving directory >>> > `/root/libjpeg-turbo-1.3.0/build/java' >>> > Making all in simd >>> > make[2]: Entering directory >>> > `/root/libjpeg-turbo-1.3.0/build/simd' >>> > make all-am >>> > make[3]: Entering directory >>> > `/root/libjpeg-turbo-1.3.0/build/simd' >>> > make[3]: Nothing to be done for `all-am'. >>> > make[3]: Leaving directory >>> > `/root/libjpeg-turbo-1.3.0/build/simd' >>> > make[2]: Leaving directory >>> > `/root/libjpeg-turbo-1.3.0/build/simd' >>> > Making all in md5 >>> > make[2]: Entering directory >>> > `/root/libjpeg-turbo-1.3.0/build/md5' >>> > make[2]: Nothing to be done for `all'. >>> > make[2]: Leaving directory >>> `/root/libjpeg-turbo-1.3.0/build/md5' >>> > make[2]: Entering directory >>> `/root/libjpeg-turbo-1.3.0/build' >>> > make[2]: Leaving directory >>> `/root/libjpeg-turbo-1.3.0/build' >>> > make[1]: Leaving directory >>> `/root/libjpeg-turbo-1.3.0/build' >>> > root@beaglebone:~/libjpeg-turbo-1.3.0/build# >>> > >>> > >>> > Before compiling libjpeg-turbo i tested my code to see what >>> > will be happening on the resolution and frame rate. I am >>> > working with a Logitech QuickCam E3500 which has support >>> for >>> > both YUVY and MJPEG. I set the resolution to 320x240 with a >>> > 30fps frame rate but after running the code, got select >>> > timeout errors and the resolution had changed to 640x480 >>> > YUVY with a 15fps frame rate; >>> > >>> > root@beaglebone:~/libjpeg-turbo-1.3.0/build# v4l2-ctl -V >>> > Format Video Capture: >>> > Width/Height : 640/480 >>> > Pixel Format : 'YUYV' >>> > Field : None >>> > Bytes per Line: 1280 >>> > Size Image : 614400 >>> > Colorspace : SRGB >>> > root@beaglebone:~/libjpeg-turbo-1.3.0/build# >>> > >>> > >>> > >>> > >>> > On Tue, May 24, 2016 at 1:22 AM, Tinashe Mudavanhu >>> > <tina...@gmail.com> wrote: >>> > >>> > 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 >>> > <able...@gmail.com> 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 >>> > Sent: 5/23/2016 4:58 PM >>> > To: beagl...@googlegroups.com >>> > 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 >>> > <able...@gmail.com> 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 <tina...@gmail.com> 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 <james....@btinternet.com> >>> 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 <able...@gmail.com> >>> 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 >>> >> <james....@btinternet.com> wrote: >>> >> >>> >> >>> >> >>> >> >>> >>> [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 >>> beagleboard+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/574628d3.8847810a.511bf.33ec%40mx.google.com >>> <https://groups.google.com/d/msgid/beagleboard/574628d3.8847810a.511bf.33ec%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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CADw4j_twhZ1AYUFrXKmF2sgNomRgCoKZ%3D1xyKUxzBu0CoFxnag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.