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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>>> Sent: 5/25/2016 4:13 PM
>>> To: [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 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/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 [email protected].
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.
