User avatar
cowpat
Posts: 90
Joined: Sat Apr 14, 2012 12:13 pm
Location: London
Contact: Website

Re: USB Cams and Motion on Debian

Wed Jul 11, 2012 8:50 pm

That's right. I cut the USB lead to the camera and wired the power to the camera directly from the 5v source (the switching regulator mentioned above) such that only the data pins were connected between the camera and the raspberry.

I think I may have to give up on this soon and start looking more closely at the alternatives - something like the pandaboard/beaglebone ? I'm sure they are not without their own issues.

User avatar
SteveDee
Posts: 342
Joined: Thu Dec 29, 2011 2:18 pm
Location: Sunny Southern England
Contact: Website

Re: USB Cams and Motion on Debian

Thu Jul 12, 2012 5:03 pm

I've disabled the polyfuses to remove any remaining doubt, and I'm now getting a healthy 4.93-4.98V at TP1 wrt TP2 (and at the USB socket).
My selection of webcams perform pretty much as before, therefore confirming your findings. The only difference is that the inrush current, when plugging in the Advent, is enough to re-boot the processor!
cowpat wrote:...I think I may have to give up on this soon...
I understand that. I think the video problems will "disappear" at some point, but battery power could be the bigger issue.

User avatar
cowpat
Posts: 90
Joined: Sat Apr 14, 2012 12:13 pm
Location: London
Contact: Website

Re: USB Cams and Motion on Debian

Thu Jul 12, 2012 8:20 pm

I agree... I've been looking more closely at some of the other USB issues that have been cropping, and there would appear to be a certain amount of ongoing work on the USB driver. I don't know enough about what I'm reading to definitely connect the issues - but as you say; we could see it spring into life one day.

Realistically I'd like to have a system tested and ready for February/March, when (fingers crossed) funding may become available for three more.... so rather than sit and wait for a fix, I've been preparing myself for what pitfalls might await me on other arm platforms. http://digitalcommons.calpoly.edu/cgi/v ... text=cpesp

Once the pi works (and i can buy more of them) it would be a no brainer, but at least this feels a bit more proactive than just waiting for a fix.

Looking at the beaglebone (which is favorite for price) there are quite a few posts about usb DMA issues with webcams, and a requirement to turn DMA off. I don't know how current this is for the bone - but could the frame corruption be related to DMA or buffering issues on the pi?

The fact that frame size, and not frame rate, are the issue makes me wonder. I had a look at USB DMA on the pi - but I don't really know enough about linux to say if it's on or off - and then my son woke up. That was my last feeble line of enquiry, and I was pretty much out of my depth there.

I did wonder if some of the better results people have seen are down to palette choice - some of the palettes have a lower bits per pixel?

In terms of the batteries - i see Prius packs are turning up on ebay!... (they are probably pretty knackered by the time the Prius has finished with them, but the concept of running on reconditioned prius cells quite appeals to me). Ultimately it will probably be lead acid AGM I'll just have to massively over spec the battery capacity... i guess 200Ah should get me through 3-4 days, but that's strictly a guess - obviously I'll have to measure exactly what power I'm using. A voltage cutout will still be needed for days I forgot to get out of bed, but in principle we'd never reach it. I was thinking 3x 78Ah might be more manageable in terms of mass)

User avatar
Jim Manley
Posts: 1593
Joined: Thu Feb 23, 2012 8:41 pm
Location: SillyCon Valley, California, and Powell, Wyoming, USA, plus The Universe
Contact: Website

Re: USB Cams and Motion on Debian

Wed Jul 25, 2012 5:24 am

About the batteries, you generally don't want to take lead-acids below 60% of capacity, deep-discharge marine lead-acids below about 50%, or gel-cells below 40%, or you will severely reduce the number of recharge cycles (more a factor of economics than anything else). You can use voltage droop as a rough measure of charge state, but, the curves are vastly different for various chemistries. Lead-acid gradually droops until about 70%, and the others maintain voltage higher until they start to quickly droop close to their required recharge state.

A much better method is to monitor current draw over time and when you're near the low-capacity limit (depending on the chemistry), it's time to recharge or shut down. Just for "fun", I build electric drives for sailboats as either replacements for, or augmentation of, "infernal"-combustion engines that are constantly on the verge of needing an overhaul and fail just when you really need them. You do not want to run an expensive bank of upwards of a dozen-plus batteries down to the point where there's no reserve when the weather turns nasty, the rocks are looming, and your anchors are dragging!

Once cameras are working well, the next step will be taking advantage of the GPU's 3-D abilities and using two cameras in Kinect-style scene-reconstruction and object recognition (even if at reduced frame rates, but, what do you want from a $35 computer?).
The best things in life aren't things ... but, a Pi comes pretty darned close! :D
"Education is not the filling of a pail, but the lighting of a fire." -- W.B. Yeats
In theory, theory & practice are the same - in practice, they aren't!!!

User avatar
cowpat
Posts: 90
Joined: Sat Apr 14, 2012 12:13 pm
Location: London
Contact: Website

Re: USB Cams and Motion on Debian

Wed Jul 25, 2012 9:52 pm

Jim Manley wrote:Once cameras are working well,
I think that is really the key point! I think that the market for these devices is really opening up so even if the USB troubles rattle on for months hopefully in the meantime we'll also see more arm fixes in linux media drivers etc.

Maybe I'll find a non-emphia capture card that works properly on arm too... i'm going to start looking at TV sticks with video input next.

I've seen 640x480 stream from a beaglebone using my webcam, but I'm having a murderous job at loading the updated drivers that I need for the em28xx module... so i've gone back to 320x240 on the pi for a while.

Regarding the batteries - I found the Yuasa datasheets pretty much tell the story... I think the, given the size of the batteries I'm looking at my margin of error is going to be pretty low and i'll effectively not reach the voltage cutoff if I change the batteries every x days. The answer is balancing cost of batteries with cost of changing them... If you I save enough days in the field by discharging them further - it might actually pay off, even if they are rubbished by the end of the project.

User avatar
with ice cream
Posts: 143
Joined: Mon Jul 30, 2012 7:25 am

Re: USB Cams and Motion on Debian

Mon Aug 13, 2012 11:36 am

SteveDee wrote:Now switched from Squeeze to Wheezy, and my Advent Sonix USB cam now works great (no instability).

I can view and control motion remotely via Firefox, and with simple file sharing enabled I can remotely access my motion video, copy & delete files. Its all looking good!
I seem to have the same camera and I can't get it to work with motion and my raspbian setup. What did you do?

User avatar
SteveDee
Posts: 342
Joined: Thu Dec 29, 2011 2:18 pm
Location: Sunny Southern England
Contact: Website

Re: USB Cams and Motion on Debian

Mon Aug 13, 2012 4:35 pm

with ice cream wrote:...I can't get it to work with motion and my raspbian setup...
It doesn't work for me on Raspbian either. It only works on Wheezy beta, and only up to 352x288.
Given the voltage drop (due to the high current draw from this camera) I'm surprised it works at all without a powered USB hub.

Its looking like there is a fundamental USB problem which is resulting in instability with USB cameras & capture devices (the USB sub-system has been implicated). But if you want to try Wheezy beta, then I suggest that once you get Wheezy running, you install guvcview and test your camera to see what resolutions work, before trying to install & configure motion.

User avatar
with ice cream
Posts: 143
Joined: Mon Jul 30, 2012 7:25 am

Re: USB Cams and Motion on Debian

Mon Aug 13, 2012 4:46 pm

SteveDee wrote:It doesn't work for me on Raspbian either. It only works on Wheezy beta, and only up to 352x288.
Thanks for the feedback. I am actually using a powered hub but that doesn't seem to make a difference. When I run motion in setup mode it reports a few errors, no images are stored, and after a while the whole Raspberry Pi freezes.

I don't want to start setting up a new distribution so I guess I will look into getting another camera.

User avatar
with ice cream
Posts: 143
Joined: Mon Jul 30, 2012 7:25 am

Re: USB Cams and Motion on Debian

Sat Aug 25, 2012 11:19 am

with ice cream wrote: I seem to have the same camera and I can't get it to work with motion and my raspbian setup. What did you do?
For those that are still following this thread: I returned the camera and got a supposedly working Microsoft VX-800 LifeCam instead. It still didn't work. But the most recent firmware update changed it. It works! (At least at the lowest possible resolution. I haven't dared to crank it up yet.)

User avatar
SteveDee
Posts: 342
Joined: Thu Dec 29, 2011 2:18 pm
Location: Sunny Southern England
Contact: Website

Re: USB Cams and Motion on Debian

Sat Aug 25, 2012 3:41 pm

with ice cream wrote:...for those that are still following this thread... It works! (At least at the lowest possible resolution...
I've just installed Raspian 2012-08-16 (armhf) and run update+upgrade, and its now working with similar limitations as per Wheezy-Beta (armel), but a big improvement of the earlier Raspian.

The only slight differences are that my Advent/Sonix doesn't crash the guvcview video window when I take the resolution above 352x288, and my EyeToy stays up for a few seconds longer than before.

Tests conducted using guvcview.

Advent/Sonix run resolutions:-
160x120
176x144
320x240
352x288
...the frame rate is always 0.5 to 3.0 (i.e. rate is not resolution dependant)

With these resolutions:-
640x480
1280x960
1280x1024
...I get a black (blank) video window, but at least guvcview doesn't crash.

EyeToy camera:-
320x240 starts out great at 14fps for about 8-10seconds, then frame rate drops and video stops (freezes).
Higher resolution does not run.

tbr
Posts: 16
Joined: Mon Jul 23, 2012 9:12 pm

Re: USB Cams and Motion on Debian

Sun Aug 26, 2012 11:01 pm

This might not be much help as I can't get that technical (Complete command line & linux newbie) but I bought a Microsoft lifecam vx-800 for my pi last week.

Ive had it running using motion at 320 x 240 on Rasbian for 2 days until I stopped the recording, that was recording a time lapse in mpg1, and motion activated movie clips. (as well as a usb wifi adaptor to allow remote access to the HTML stream page off-site) Not very high fps, not sure what but the motion actived clips were at a guess 5-10 fps at the most.

I've even tested it in the car running off the cigerette lighter and it worked fine.

A quick slightly off topic question regarding the webcam, I'm getting horrible whiteout if I point the camera outside, I've tried fiddling with motions config files but nothing seems to have any great effect, any ideas? I want to record a time lapse of a road trip soon and as it stands the footage won't really be usable.

User avatar
SteveDee
Posts: 342
Joined: Thu Dec 29, 2011 2:18 pm
Location: Sunny Southern England
Contact: Website

Re: USB Cams and Motion on Debian

Fri Sep 07, 2012 12:16 pm

I'd put my USB camera problems to one side a few weeks ago, but today I ran update/upgrade to see if there have been any improvements with Raspian.

Running my EyeToy camera, I find that this now runs up to 640x480 without freezing. However, the image flickers/breaks-up at irregular intervals (maybe 1-5 times per 30seconds) so its still not ready to be used with the Motion app. Moving the mouse around the screen (to force cpu to 100%) causes severe breakup, but video keeps going.

Reducing the resolution and/or increasing the RPi cpu speed didn't seem to make any difference either way.

I tried Dom's recent mod and enabled via: dwc_otg.fiq_fix_enable=1
Unfortunately my combi keyboard/mouse pad will not work with this, so need to investigate further.

Other points.

Using the terminal command:-
modinfo uvcvideo
...part of the output includes:-
parm: clock:Video buffers timestamp clock
parm: nodrop:Don't drop incomplete frames (uint)
parm: quirks:Forced device quirks (uint)
parm: trace:Trace level bitmask (uint)
parm: timeout:Streaming control requests timeout (uint)

I've no idea what these params do, however I created a file: /etc/modprob.d/uvcvideo.conf
and added:-
options uvcvideo nodrop=1

After running:-
# sudo rmmod uvcvideo
# sudo modprobe uvcvideo
...I tested my Advent/Sonix camera using: guvcview -v
and found this has stopped the "Could not grab image..." error and I can now see some video for resolutions like 640x480 and above. This video only shows for the top 5% or so of the frame. But this is 5% more than the completely black/blank frame I get for high resolutions without the nodrop option.

I tried setting "quirks" to a couple of values, but it had no affect and I have not found any info on what this param does.

kokki
Posts: 5
Joined: Sat Jul 14, 2012 1:31 pm

Re: USB Cams and Motion on Debian

Sun Sep 16, 2012 10:23 am

I got Logitech C200 working on Debian Wheezy 2012-08-16 ..upgraded, updated everything. And ffmpeg from multimedia.org and motion from trunk. And resolution is 640x480.. sometimes the video is closed, but I did some perl code to check the log and restart the motion if video is closed. Seems to work ok. But is there any software that I can watch the MJPEG by the framebuffer, without X?

Not tested any ffmpeg-videos, only jpegs to "disk".

arcanon
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am

Re: USB Cams and Motion on Debian

Fri Nov 16, 2012 12:02 am

Sounds like we need to debug the software to see where this is failing.

arcanon
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am

Re: USB Cams and Motion on Debian

Fri Nov 16, 2012 6:24 pm

So compiling motion I see this error (not such a suprise..):

[1] [NTC] [VID] v4l2_select_input: - CAMERA
[1] [ERR] [VID] v4l2_select_input: Error selecting input 0 VIDIOC_S_INPUT:
[1] [NTC] [VID] vid_v4lx_start: Using V4L1
[1] [ERR] [ALL] motion_loop: Video device fatal error - Closing video device

Now need to get the info about why the fatal error.

arcanon
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am

Re: USB Cams and Motion on Debian

Fri Nov 23, 2012 12:03 am

Ok, so the issue seems to be a HW limitation?:
ENOSR During an OUT transfer, the host controller
could not retrieve data from system memory fast
enough to keep up with the USB data rate

seen from:

enable tracing:
echo 0xffff > /sys/module/uvcvideo/parameters/trace

look at /var/log/syslog

Nov 22 22:40:17 raspberrypi kernel: [ 1355.109985] uvcvideo: USB isochronous frame lost (-63).

nomad
Posts: 5
Joined: Sat Dec 01, 2012 4:09 am

Re: USB Cams and Motion on Debian

Sat Dec 01, 2012 8:52 am

My RPi arrived in the mail this week and my first project is to create a Debian (Wheezy) based portable cam. I am familiar doing this in the PC world with Ubuntu, motion and my QuickCam Pro for Notebooks.

My initial installation worked like a charm. I had installed Debian, updated and used apt-get to install motion and did a base config in motion.conf. It worked well with settings:
@ 320x240 @ 12, 24 and 30FPS (web @ 12FPS, 20FPS)
@ 640x480 @ 12, 24 and 30FPS (web @12FPS, 24FPS)
@ 960x720 @ 12, 24 and 30FPS... web FPS couldn't keep up. CPU was maxed out but video was working.

When I set the web to display at 30FPS, everything fell apart. Motion no longer worked, /dev/video0 was unavailable until I did an rmmod uvcvideo / modprobe uvcvideo and the httpd process woudldn't run.

I've tried everything; I've even started from scratch and wiped out the card and repeated my steps and it has not worked.

Running "mplayer tv://" yields a green screen, followed by a frame or two of mixed up colours. The actual image is there, but everything is saturated red or blue. Then back to solid green screen, then red/blue image. rinse-wash-repeat.

I initially thought it was power issues. My testing across tp1/tp2 showed...
5V & 1A: 4.75V @ idle. 4.6-4.7V with network & webcam plugged in and running, 4.6-4.7V
5V & 750mA: 4.8V idle. Crash. With network & webcam plugged in... reset.
5V & 550mA: 4.88V@idle 4.55V with network, webcam and HDMI plugged in.
5V & 130mA: Wouldn't even boot (as expected)

Testing fuse F3 has yielded good results with little voltage drop so I believe the fuse is fine.

I spent quite a bit of time trying various combinations of mplayer command line options. None achieved positive results although it did allow me to capture jpegs of the ugliness that I'm seeing. If anyone is interested, I can post them.

By running motion with palette 2, I am now able to keep motion streaming the awful image... which does me no good. It is continually blue/red.

I'm at a loss how motion / webcam could work so perfectly for 15 minutes of testing, then be totally useless after that. I'm out of ideas for trouble-shooting. I'm out of available power adapters.

User avatar
with ice cream
Posts: 143
Joined: Mon Jul 30, 2012 7:25 am

Re: USB Cams and Motion on Debian

Sat Dec 01, 2012 1:01 pm

nomad,

Keep an eye on this thread (USB redux). It might be related to a general USB issue.

I tried lower resolutions with my Logitech Fusion but motion would always change to a higher one:

Code: Select all

[1] Test palette YUYV (352x288)
[1] Adjusting resolution from 352x288 to 1024x576.
And then it would time-out.

I had to switch to palette 2 (MJEPG) to have a more or less stable process.

How did you enforce lower resolutions?

nomad
Posts: 5
Joined: Sat Dec 01, 2012 4:09 am

Re: USB Cams and Motion on Debian

Sat Dec 01, 2012 5:06 pm

I read that and it's crossed my mind that it may be USB related. However, my problem is that it *was* working and it *was* streaming at high resolutions but now it's not.

I can force resolution in these ways...
for mplayer: mplayer //tv: -tv width=320:height=240 (excluding any other options)
for motion config setting the width & height to 320 and 240 respectively.
I can demonstrate these settings are affecting their respective programs by switching between 320/640/960 and 240/480/720 and the resulting poor image is displayed in the correct size.

I tried reducing the frame rate in motion to 320x240@2FPS, palette 2 (mjpeg), and it continues to run with the funky blue/red images.

I was up until 4:30am this morning trying everything I could think of to get back to a working setup. If it had not worked before, I could give up and write it off as software or hardware problems... but I saw it working and captured initial video in all 3 resolutions, streamed via motion.

User avatar
SteveDee
Posts: 342
Joined: Thu Dec 29, 2011 2:18 pm
Location: Sunny Southern England
Contact: Website

Re: USB Cams and Motion on Debian

Sat Dec 01, 2012 6:10 pm

with ice cream wrote:...I tried lower resolutions with my Logitech Fusion but motion would always change to a higher one...How did you enforce lower resolutions?
This might not help, but motion will only work with supported resolutions.
For example, running guvcview with my EyeToy shows that the only supported resolutions are: 320x240 and 640x480

nomad
Posts: 5
Joined: Sat Dec 01, 2012 4:09 am

Re: USB Cams and Motion on Debian

Mon Dec 03, 2012 5:36 pm

SteveDee wrote:
with ice cream wrote:...I tried lower resolutions with my Logitech Fusion but motion would always change to a higher one...How did you enforce lower resolutions?
This might not help, but motion will only work with supported resolutions.
For example, running guvcview with my EyeToy shows that the only supported resolutions are: 320x240 and 640x480
The Logitech QuickCam Pro for Notebooks supports resolutions of 320x240, 640x480, 960x720. I use motion and this camera on other machines configured for these resolutions. I know it works and works well.

The problem must be with hardware, software or power of the Raspberry Pi.

mskvorc
Posts: 1
Joined: Sun Dec 02, 2012 7:55 pm

Re: USB Cams and Motion on Debian

Mon Dec 03, 2012 8:13 pm

Hi guys,

I have a problem with my Microsoft LifeCam NX6000. I can get the picture but colors are very strange. It seems like the pallete is wrong but i can use only MJPG.
Here is the picture taken from Windows OS

http://img7.imageshack.us/img7/5776/windowsb.png

and here is the picture taken using motion on RP (latest raspbian wheezy image - 2012-10-28)

http://img716.imageshack.us/img716/3148/motion.png

Does anyone know how can I fix this? Someone in this thread said that he used this camera and everything was fine.

Thank you

motion log:

Code: Select all

pi@raspberrypi /etc/motion $ sudo motion
[0] Processing thread 0 - config file /etc/motion/motion.conf
[0] Motion 3.2.12 Started
[0] ffmpeg LIBAVCODEC_BUILD 3482368 LIBAVFORMAT_BUILD 3478784
[0] Thread 1 is from /etc/motion/motion.conf
[0] motion-httpd/3.2.12 running, accepting connections
[1] Thread 1 started
[0] motion-httpd: waiting for data on port TCP 8080
[1] cap.driver: "uvcvideo"
[1] cap.card: "MicrosoftÂŽ LifeCam NX-6000"
[1] cap.bus_info: "usb-bcm2708_usb-1.2"
[1] cap.capabilities=0x04000001
[1] - VIDEO_CAPTURE
[1] - STREAMING
[1] Test palette MJPG (1024x768)
[1] Using palette MJPG (1024x768) bytesperlines 0 sizeimage 1572864 colorspace 00000008
[1] found control 0x00980900, "Brightness", range 0,160
[1]     "Brightness", default -8193, current 128
[1] found control 0x00980901, "Contrast", range 5,50
[1]     "Contrast", default 57343, current 43
[1] found control 0x00980902, "Saturation", range 0,150
[1]     "Saturation", default 57343, current 48
[1] found control 0x00980903, "Hue", range -127,127
[1]     "Hue", default -8193, current 0
[1] found control 0x00980910, "Gamma", range 1,5
[1]     "Gamma", default 57343, current 3
[1] mmap information:
[1] frames=4
[1] 0 length=1572864
[1] 1 length=1572864
[1] 2 length=1572864
[1] 3 length=1572864
[1] Using V4L2
[1] Resizing pre_capture buffer to 1 items
Not a JPEG file: starts with 0xbb 0xa8
Not a JPEG file: starts with 0x95 0x23
[1] Started stream webcam server in port 8081
[1] File of type 8 saved to: /var/www/motion/01-20121202200551.swf
[1] File of type 1 saved to: /var/www/motion/01-20121202200551-01.jpg

arcanon
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am

Re: USB Cams and Motion on Debian

Fri Dec 07, 2012 7:37 pm

So I tried using MJPG-streamer and I can now get HD working. Here is the tutorial

http://wolfpaulus.com/journal/embedded/ ... ypi_webcam

The strange thing is that if I try capture at 5fps at 1920x1080, it does not work, but at 15-30fps its fine. This seems to fit with the error I got before that the host was too slow. Running at the higher fps would capture the frame faster and the USB bus does not get confused?

whodah
Posts: 2
Joined: Fri Jan 18, 2013 9:56 pm

Re: USB Cams and Motion on Debian

Fri Jan 18, 2013 11:03 pm

My goal: an inexpensive (relatively speaking), but higher quality stationary (no need for PTZ) "IP" web camera. (I.e. I didn't want a full sized computer next to the camera.)

My findings: a novel, but lots of (hopefully) helpful info.

Running Raspberian by following instructions here: http://www.raspbian.org/RaspbianInstaller

From here:
http://www.phillips321.co.uk/2012/11/05 ... ream-cctv/
" ... the important thing to note is that it outputs as mjpg which means the raspberrt pi will not need to do any CPU intensive encoding ... "

I've got two usb web cameras that I am testing:
  • Microsoft LifeCam Studio 1080P
  • Logitech C910 1080P
From the same site, I got mjpg-streamer installed. (I did have to "apt-get install gcc" first, probably from not selecting all of the appropriate modules during the raspbian install.) fswebcam reveals that:

Microsoft LifeCam Studio 1080P:
src_v4l2_set_pix_format,541: Device offers the following V4L2 pixel formats:
src_v4l2_set_pix_format,554: 0: [0x56595559] 'YUYV' (YUV 4:2:2 (YUYV))
src_v4l2_set_pix_format,554: 1: [0x47504A4D] 'MJPG' (MJPEG)
src_v4l2_set_pix_format,554: 2: [0x3032344D] 'M420' (YUV 4:2:0 (M420))
Using palette MJPEG

Logitech C910 1080P:
src_v4l2_set_pix_format,541: Device offers the following V4L2 pixel formats:
src_v4l2_set_pix_format,554: 0: [0x56595559] 'YUYV' (YUV 4:2:2 (YUYV))
src_v4l2_set_pix_format,554: 1: [0x47504A4D] 'MJPG' (MJPEG)
Using palette MJPEG
mjpg-streamer runs either camera at 1280x720 with no problems directly hooked up to the Pi. It is set at 15 FPS, but I realistically get 5 or so. The cpu usage is miniscule on either, bounces around 7-9% on the Microsoft, 3-7% on the Logitech. Load is 0.01-0.03 in either case. Most of the time, the 'top' command was above mjpg-streamer in either case. Heck, both cameras even give me 1920x1080 at ~5FPS too. I couldn't tell a load/cpu difference between 1280x720 vs 1920x1080.

I'm monitoring very blue light, a saltwater reef aquarium. It has 14K bulbs and then actinic supplement bulbs. I like how the Microsoft looks/mounts/footprint way better than the Logitech. But the Logitech has a way better picture (less washed out and closer to real colors than the Microsoft). To be fair, they both look great when running typical windows drivers and their software that has color correction. In either case, I wanted to mount them inverted 180 degrees (flipped) for cord management. As best I can tell, mjpg-streamer doesn't do that (nor does input_uvc.so, nor does output_http.so, but someone please correct me if I'm wrong!). So I started looking at motion which I thought I read somewhere could do that. (That feature has become irrelevant to me if ya keep reading at least for the time being.)

Logitech:
Image
bigger: http://i1290.photobucket.com/albums/b52 ... 81cb39.jpg

Microsoft:
Image
bigger: http://i1290.photobucket.com/albums/b52 ... 629e64.jpg
So I got motion installed very easily. However, the output was all garbled. Started reading. Started diagnosing. Here is what I found:

Microsoft LifeCam Studio 1080P:
I could get this bad boy working at 1280x720 by setting:
v4l2_palette = 2
That was the key. When set to 8, it was garbage.

Not as much luck w/ the Logitech HD Pro Webcam C910 1080P:
v4l2_palette = 2
1280x720 = distorted
1280x960 = distorted
960x720 = distorted
640x480 = works
320x240 = works

I grabbed a USB 2.0 powered hub. No difference.

Neither supports 1920x1080 as one gets an error that 1080 is not modulus 16. (And any other height that is not modulus 16 errors out w/ the same thing.)

CPU usage was through the roof with either camera. motion would suck up 97% CPU and induce loads at 1.0 +-0.1.

Conclusions:
Raspberry Pi can handle 1920x1080 at ~5FPS plugged directly in without any problems using mjpg-streamer. This tells me that something is not right with motion. (My configs or setup or motion itself?)

Currently: I'm still trying to get it to stream to my Android vs. the Chrome browser in Windows. :P

Thoughts?

User avatar
SteveDee
Posts: 342
Joined: Thu Dec 29, 2011 2:18 pm
Location: Sunny Southern England
Contact: Website

Re: USB Cams and Motion on Debian

Sat Jan 19, 2013 10:13 am

whodah wrote:...CPU usage was through the roof with either camera. motion would suck up 97% CPU and induce loads at 1.0 +-0.1.
...I'm still trying to get it to stream to my Android...
Looks like you are getting fabulous video results, and thanks for sharing.

Here are a few points/comments.
As I said in an earlier post, there is no doubt that some webcams work on Pi, while some have problems. I run my troublesome EyeToy about once a month to see if any recent updates have fixed my problem. I get random horizontal breaks in the image once or twice every 20 seconds or so. Its the same on either available resolution, and the cpu% is well below 100%. If I move the mouse across the screen, the image exhibits this problem continually until I stop the mouse. So I'm still hoping that the ongoing USB issues will eventually fix this (see the "USB Redux" thread).

I don't know why motion is sucking the life out of your cpu. But you could try to disable ffmpeg from stitching together the jpeg images, just to see how much impact this is having. I think you can do this from the motion config file.

I use CamBuddy on Android to view mjpeg streams from motion. It works great!

Return to “Graphics, sound and multimedia”

Who is online

Users browsing this forum: Dan Lavin and 8 guests