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 <[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_uvf%2BUL58p98L%2BhVvJasKESPnZMbvuwMbqrdkPW5noRqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
