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. -----Original Message----- From: "João M. S. Silva" <[email protected]> Sent: 5/25/2016 4:13 PM To: "[email protected]" <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 > <[email protected]> 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 > <[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 > 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: >> >> >> >> [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/574628d3.8847810a.511bf.33ec%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
